A blog was recently published outlining the hierarchy of metrics that Pinterest track for monitoring growth. Two particular KPIs jumped out at me:
- An activation metric (they call 1d7s) that tracks the percentage of new signups that come back to the app within 7 days.
- An engagement metric (they call 1rc7) that tracks the percentage of new signups that repin or click a pin within 7 days.
While the first one is applicable to any app, the second one adds to that by looking at the usage of a given key feature within 7 days.
These activation and engagement KPIs of Pinterest are nice for several reasons. The activation metric goes beyond the first session. If the primary challenge for an app on that first visit is to give the user a compelling reason to come back again, it's a measure of whether that happened. In an ideal world, you may wish all your users to visit your app on a daily basis. However, you haven’t necessarily proved your worth yet. So I’d argue that 7 days is a nice minimum time frame, and one that also allows for the natural fluctuations of the week.
The engagement KPI focuses on re-pinning or clicking on a pin, a direct usage of one of the primary features of the app. Clearly they want every new signup to perform this action within 7 days. Something compelled the user to install your app, so ensuring they engage with the main feature in a timely fashion is key.
The problem is that not all users will come back in 7 days. Not all users will find, never mind use, what you think is the key feature. This is where you need to be thinking as much about re-engagement as engagement. If your assumption is that you will engage users as you’ve prescribed, then you should also assume that you will lose people, possibly many more than you think.
How do we solve this re-engagement problem? The first thing to remember is that a proportion of new users will always bounce, they will never come back after the first visit. They’re the window-shoppers, the diehard fans of the other team. However, there are plenty of voters who sit on the fence in any election, so if you get a chance to talk to that voter, you have to seize the opportunity to ask for permission to talk to them again. Push notifications are a fantastic vehicle for re-engaging with those users, for bringing them back to your app. However, like all such tools, they have to be used with great care.
First of all, you need to ask the user permission to send them push notifications. Many apps make the mistake of asking this immediately when the new user first opens the app. The user has no idea what your app does, whether they like it or not, and whether they want such “interruptions”. So the timing of that request is vital. And ideally, it needs to be within the first session. This is where in-app messages come in. Instead of simply triggering the default system permission request, it’s worth displaying a prior in-app message, explaining to the user what they get with such notifications. Use visuals, maybe even video, to explain why they should sign-up for notifications. Then ask them if they’d like to receive such notifications. If they say yes, call the system prompt and you’ve got their permission. If they say no, then save that system-level request for another day, another session.
You can re-target those users with another in-app message when they’ve had a better chance to understand and use your app. If they don’t come back, they don’t come back. Likely as not they were always going to be a bounced user and sending them a push notification was simply going to dilute your campaign.
Within that first session, it’s worth considering triggering the in-app message for push notifications permission off an event, however small, that gives the user a feel good factor or a sense of something completed. It may be after they’ve stepped through the tutorial, registered their social media details, ran a search, or read an article. You get the idea!
I’d like to come back to the engagement KPI, which monitored the percentage of users who reached that milestone moment of using a specific and presumably important feature. In order to report such a KPI, you need to ensure you’re tracking such usage. Don’t always assume you know what that primary feature is. You may think feature A is the killer feature for your app because you’ve spent 3 months developing it, but be prepared to discover that actually most users seem to be attracted to feature B in their first 7 days of using your app. Feature B was a last minute simple add-on but it may be that very simplicity that resonates with the first-time user.
By looking at the stats of what features those initial sign-ups found and used within 7 days, you’re getting a very good understanding for the initial impression of your app to new users. You may find a natural funnel of engagement through your feature set. Carefully targeted push notifications and in-app messages can then be used to guide users to discover and enjoy your full feature set. The more they use, the more reason they have to come back and stay sticky.
Above all, don’t always trust your wording and timing. New users are a hasty bunch, ready to abandon you easily. So be sure to A/B test those messages, whether in-app or push, and compare those variants not simply for immediate conversion, but downstream goals relevant to the message. If you’re promoting a feature to engage a user, track whether they actually use that feature, and how often, across multiple sessions.
The message here is to always be thinking about re-engagement alongside engagement. Get ready for push notifications, and use in-app messages and A/B testing to optimise the uptake of this channel to guide your user base beyond that first week in your app.