TL/DR: Your product needs to engage with its users. It helps them understand more about your product and helps them use your product successfully. By automating engagements (vs having people manually perform outreach with users) you’re ensuring all of your users consistently get the best experience.

Subscribe now

In my previous post, I described how I started Growth Engineering at ShiftLeft. This post is about expanding on the same growth engineering concepts and architecture to implement user engagement workflows with product usage data.

graphs of performance analytics on a laptop screen — Photo by Luke Chesser on Unsplash

Product usage data

Product usage data is essential to sending users the proper messaging. This data is about how your users use your product, what features they’re touching, what actions they have performed, etc. This data comes from three different places:

Databases and warehouses — Where your product data lives
Apps like Intercom and Stripe
Events via instrumentation

Among those three, data from your product database is going to be the most valuable source of truth about how your users interact with your product, for one main reason: it’s data you already have because it’s where your product state is.

On the other end of the spectrum, instrumentation can be difficult to work with because you have to know what to instrument ahead of time, it’s not retroactive, and it can be difficult to get access to the original data when events are aggregated away into another system.

Engagement workflows

There are various ways of engaging with users, e.g. email, in-app messaging, demo flows, etc., and a range of tools to implement those workflows. For example, you can create complex multi-step email engagement workflows through HubSpot, start a conversation on Intercom, or activate an in-app guide with Pendo.

Photo by Brett Jordan on Unsplash

Regardless of what product you use to implement engagement workflows, the most important part of the implementation is taking advantage of the right product usage data.

Triggering engagements

Most engagements are triggered on product usage data, but getting that data into a workflow system can be tricky.

Fortunately, you don’t have to implement complex data pipelines or services yourself. Using a CDP like Segment lets you send events from instrumentation to apps like HubSpot. Reverse ETL solutions like Hightouch or Census let you sync data from your databases and warehouses into apps.

If you use Segment, you can set contact properties in HubSpot with Track events. You can instrument your app (either front-end or back-end) with these events on certain activities performed by users:

analytics.track(
  user_id='YOUR_USER_ID',
  event='Bought Item',
  properties={
    'email': 'peter@example.com',
    'used_feature_x': true,
  },
  context={
    'traits': {
    'firstname': 'Peter',
    'lastname': 'Gibbons'
  }
})

With this event, the used_feature_x property in HubSpot will be added for users when they use a certain feature.

In reverse ETL products, a query against your product DB or warehouse might look something like this:

SELECT
  id, name, email,
  (SELECT 1 FROM feature_x WHERE user_id = users.id) AS used_feature_x
FROM users

Architecture example

Now that we’ve covered the general concepts, let’s look at how this looks in practice. The following diagram shows how an example of how a system can be architected to send data-driven customer engagements.

Data: In this architecture, the source of product usage data is the product database and events generated by the product. The combination of the two, DB + events, paints a full picture of user behavior in your product. A useful architecture decision is to send events to your database or warehouse as an additional destination. This is extremely important to consolidate data from multiple sources.

Workflows: HubSpot was chosen as the engagement workflow in this architecture. HubSpot’s workflow system allows you to build rich, multi-step engagements without code. Notifications can be sent to both end users and internal teams. For example, for the same trigger (new user signup) one notification might send a welcome email to the new user, and another notification might send a message to an internal Slack channel to notify your team about the new signup.

This architecture is great for getting started, but there are a few cons:

HubSpot’s system is based on contacts and individual users, not accounts that are comprised of multiple users.
Product usage data ends up as contact properties, which is a very simple data model that removes a lot of context from the original data.

The nice part about this architecture is that the data side is not tightly coupled with the workflow side, so you can easily swap out HubSpot with another solution, or add additional engagement solutions to handle different use cases. Additionally, by consolidating all of the data in your own database or warehouse, you’re free to extract more insights using other BI solutions like QuickSight, Looker, or Tableau.

Here are my recommended articles for this week.

Friends Don’t Let Friends Buy a CDP
And a counter-view to the above blog
Scott Brinker @chiefmartec
Trigger alert: this is a post that's bound to stir debate in the CDP community. But I think it's a really interesting debate to dig into. hightouch.com/blog/friends-d… by @tejasmanohar @HightouchData #martech
hightouch.comFriends Don’t Let Friends Buy a CDPRead how spending the first half of his professional career at Segment drove Tejas Manohar to disrupt the 15 billion dollar CDP category
9:33 PM ∙ Sep 14, 2022
41Likes5Retweets

Growth Engineering for Data-Driven…