How to Use Data-powered In-app Experiences for Personalized User Onboarding

This is part 4 of a 5-part series titled Data-powered Messaging For True Personalization – powered by Piwik PRO.  

“Welcome! Here’s a checklist of all the things we want you to do right away. If you’re stuck, make sure to ask our AI-powered chatbot for help. And don’t forget to join our community of helpful humans. Okay now click here to learn how our product works.” 

I’m sure this bombardment sounds familiar, doesn’t it? After all, that’s how most products greet new users. And that too at a time when data hasn’t been more abundant and the drum beat of personalization hasn’t been louder.

The biggest priority for startups that offer a self-serve product is to increase their activation rate by driving users to the activation milestone or the aha moment. And to make that happen sooner rather than later, most well-meaning products tend to overwhelm new users with the bombardment described earlier. 

So what’s the solution?

Personalized in-app experiences, powered by data.  

In-app experiences include in-app messages, tours, tips, and walkthroughs but not push notifications. Check out Part 3 of this series if you’re looking to deliver data-powered push notifications instead of in-app experiences. 

I also recommend referring to Part 2 which covers data-powered onboarding emails. The basic steps apply to in-app experiences as well. 

Alright! Let me start by stating the obvious: in-app experiences should be data-powered – as in triggered based on a user’s actions – instead of being shown to new users the moment they land inside a product. Additionally, whenever possible, these experiences should further be personalized for each user persona based on the persona data collected at the time of onboarding. 

Your app is like a store

Imagine entering a store and instead of being given the opportunity to explore, you’re greeted at the entrance by a staff member who wants to give you a tour and tell you what the store sells and what’s on offer, and so on. 

Annoying isn’t it? 

Now consider this: You enter the store, explore at your own pace, and the moment you pick up a couple of outfits to try, someone guides you to the trial room. Or the moment you pick up a shoe, someone is there to bring you a pair of the right size. And they also tell you about a new collection that you might like based on what you picked. Once you’re done shopping, someone guides you to the checkout and tells you about a store offer that you’re eligible for. 

I’m sure that’s an experience that’ll bring you back to the store for more. 

This superior experience was made possible because the store employees were observing your actions (collecting data) and offered to help at the right moment – when it was evident that you needed help. 

Your app is also like a store. You need to let users explore, collect data while they’re at it, and offer to help when they need it.   

Now let me walk you through the two steps to onboard new users and guide them to the aha moment in your app using data-powered in-app experiences. 

Step 1: Drive users to the setup moment

Instead of dropping a list of things a user needs to do as soon as they land in your app, focus on driving users to the setup moment. This is essentially when the user has completed a task that’s a prerequisite for them to use your product. Below are three examples of setup moments from the world of B2B SaaS: 

• Email Marketing: Verifying the sender domain 
• Workflow Automation: Connecting the first app (that a user wishes to use in a workflow)
• Event Analytics: Setting up the event data pipeline 

Unless the setup moment is reached, one cannot move forward to the aha moment. Moreover, a user might have to perform more than one task to reach the setup moment and in some cases, invite another user to help with a task. 

Depending on your product, you can trigger in-app experiences at this stage of the onboarding process using event data, persona data, or both. 

Let’s go deeper into each of the above examples. 

Email Marketing

In-app experiences work best when a user can perform the said task right then and there, instead of waiting for someone else to do it for them. To verify one’s sender domain, the user has to leave the app or seek someone’s help. Therefore, before delivering an in-app message asking the user to verify the sender domain, it’s worthwhile to get the user to do something quick and easy – such as importing a CSV file with email addresses. Once the user completes that easy step, they’re likely to act upon a message asking them to do something more time-consuming. 

Therefore, in this scenario, it’s recommended to trigger an in-app experience only for the segment of users who perform the ListImported event. 

Workflow Automation

For certain types of tools, a user needs to perform just one step to reach the setup moment. However, that step might not be as straightforward as importing an email list. To start using a workflow automation tool, a user has to connect an app that they wish to use in an integration which, depending on the app they try to connect, might involve several sub-steps. For instance, if the app doesn’t support an OAuth connection, the user has to visit that app, copy the API key, and paste it into the automation tool’s interface. In this scenario, it makes sense to trigger an in-app experience as soon as the user initiates the process of connecting an app by clicking the relevant button. 

In other words, the in-app message is triggered for the segment of users who perform the ButtonClicked event where the event property button_name is equal to “Add Connection”. 

Additionally, when the user selects the app they wish to connect, they should see another message specifying the method one has to use based on the app they choose (event AppSelected where event property app_name = “Gmail”).

Event Analytics

For tools where someone from another team – typically Engineering or Data – needs to complete the setup process, the primary user should be able to explore the product using dummy data before involving another team member. This practice is becoming increasingly common for tools that involve a heavier lift in terms of setup, and event analytics tools fit squarely into this bucket. I recommend offering a guided tour of a demo instance and waiting for users to complete an action, such as building a dummy report, before triggering a message or a guide asking them to bring their data in. 

However, if the user belongs to Engineering or Data – based on their input in the onboarding survey – then it makes sense to trigger the setup guide immediately instead of asking them to explore the product. Additionally, for apps that offer role-based access control, it’s always a good idea to include the user’s role in the trigger conditions for in-app experiences. This is especially true when guiding users to parts of the product that can only be accessed by users who have been assigned certain roles.

In this scenario, the setup guide is triggered only for the segment where the user properties team_name = “Data” OR “Engineering” and user_role = “Manager” OR “Admin”.

Step 2: Drive users to the aha moment

The next step after a user reaches the setup moment is to guide them to the aha moment. In most cases, a user has to complete multiple tasks between the setup and the aha moments. Once again, let’s look at what it takes to drive users to the aha moment or the activation milestone for each of the three products we’ve discussed. 

Email Marketing

The aha moment takes place when a user sends their first email or activates a campaign. 

After importing a list of email addresses, one has to create a segment, create and configure a campaign, create at least one email, and then activate the campaign or in case of a broadcast, hit send. For the most part, one might need help creating a segment or a campaign so it’s worthwhile to trigger a walkthrough as soon as the user reaches the setup moment by importing an email list.

Here, since the domain verification takes place at the account level and requires one to leave the app, it’s best tracked as an account property (is_domain_verified = TRUE). 

Workflow Automation

The aha moment takes place when a user activates their first workflow. 

To get there, at the very least, a user needs to set up a trigger, set up an action, and then test-run their workflow. If all goes well, the user activates the workflow and experiences the value of the product for the first time. In other words, the user reaches the aha moment or the activation milestone.  

However, the user remains one step away from the aha moment if they save a workflow but don’t activate it. This happens to be the right time to trigger an in-app message asking the user to activate the workflow or reach out for help if they’re stuck. Here, the user has performed the WorkflowSaved event but not WorkflowActivated and therefore, belongs to the segment (or audience) called Workflow Saved But Not Activated.

I worked for a leading workflow automation company where, to guide users to the activation milestone, we created three separate walkthroughs that triggered one after the other as soon as the user completed the previous step successfully. 

The first one was triggered when the account property connections_count > 0 (at least one connection was added), and the next two were triggered when each of the previous walkthroughs was completed successfully. This was also due to a limitation of the product where it wasn’t possible to track adding a trigger or an action as events, preventing us from triggering anything when a user completed those steps. Also, if a user chose to dismiss a walkthrough, they weren’t shown the next one. 

Event Analytics

The aha moment takes place when the user builds their first report using live data. 

In this case, if a user has already gone through the walkthrough earlier and built a report using dummy data, it doesn’t make much sense to trigger another one. On the contrary, it makes perfect sense to do so if the user is logging in for the first time. In essence, a user should see the in-app guide showing them how to build a report only once, ideally the first time they log in.

A user reaches the aha moment once they build a report using live data and at that point, they can be prompted to share the report either by creating a public link, using the Slack integration, or inviting a colleague to the workspace. It’s essential to let users know about all the sharing possibilities and triggering a quick tour of the sharing capabilities is a good idea. Now, reports_count is an account property; therefore, a user property of boolean type is needed to trigger this tour for every new user who creates a report (is_report_created = TRUE).

Wrapping up

In-app experiences can be very effective but only if a good amount of effort and thinking goes into the setup. It helps to keep in mind that unlike onboarding emails, where the goal is to bring users back into the product, in-app experiences are meant to help users while they’re already in the product, and ultimately increase activation and expand product usage. The last thing you want is to annoy users by delivering irrelevant or redundant experiences. 

Try this today

Conduct the following exercise to put what you’ve learned into action:

• Map out the various parts of the product that will benefit from an in-app experience
• List down the persona and the trigger conditions for each of those

This is easier said than done but once you have this map, creating effective messages and walkthroughs will be a lot easier. 

Good luck!