Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Churn risk prevention - identify at-risk users #3366

Closed
paolodamico opened this issue Feb 17, 2021 · 2 comments
Closed

Churn risk prevention - identify at-risk users #3366

paolodamico opened this issue Feb 17, 2021 · 2 comments
Labels
concept Ideas that need some shaping up still enhancement New feature or request stale

Comments

@paolodamico
Copy link
Contributor

This feature idea was inspired by #3032. The gist is having a way to identify at-risk users that could churn, so we can take action (probably out of the PH for now) to prevent it.

Context

This is a feature that can be particularly valuable not only because it is useful for our users, but because it can directly help our team when dog-fooding it.

  • Goal: Increase retention by a) preventing user churn in our own product (particularly of key users, e.g. users that fit our key persona, users we've onboarded, paying customers, and in general any user that has been successfully activated....), and b) offering a feature that will provide more value to our own users, therefore helping retain users better.
  • Assumptions: There are patterns to the way the users churn. We can detect users in the short span where they're showing signals of churn risk but before it's too late to prevent churn.
  • Success metrics: If we are able to improve our own retention by preventing churn, this is already successful (i.e. did we manage to recover at risk users?). In addition, success from this tool can come from value driven by our own users, i.e. are our own users using this?

Worth mentioning that the scope of this issue is mostly at identifying at-risk users, rather than what actions to take to prevent dormancy/churn.

We have a recurring use case of users that particularly care about almost every single of their end-users, and who do follow-up constantly with them (manually checking to make sure they're driving value from their product). Having something like this would significantly aid this process.

Initial Ideas

  • From the initial issue, identifying key users is an important piece of this (in case we're concerned with a particular subset of customers vs. the entire user base, e.g. activated users, high-volume users, ...). However, I'll leave that to Idea: Retention leaderboard #2828, as it'll be either something along those lines or something we can already do with our current cohorts functionality.
  • The most basic version of this would be something that lets you define some action/event that entails a user is active (e.g. $pageview at the most basic), and then a natural frequency (e.g. weekly, monthly). You would then have a view where you get users that haven't been seen for more than x natural frequency time periods.
    • We could also generate periodic alerts on Slack or email when users enter this at-risk zone.
  • Following Analytics by group/teams #2247, it'd be very useful to be able to identify teams/companies/groups at risk, rather that an individual level (e.g. if a dev (User A) set PH up but another dev in their team is the one who uses constantly, it might not make sense to take corrective actions for User A).
  • Aside from having a view that shows users currently at risk, it'd be very helpful to compute every natural frequency period which users have now become at-risk users (or stopped being at-risk users), i.e. triggering an event for every user when this happens. This opens a whole bunch of possibilites like:
    • Using something like Workflow triggers feature #3357 to trigger corrective actions for those users automatically (e.g. sending them an email, promo discount, scheduling a call, ...)
    • Notifying the team internally (e.g. CX, Sales Executive) when users become at risk
    • Have historic metrics of at-risk users (e.g. we would be able to see how much users become at-risk over time).
    • Related to the above, we could also correlate becoming at-risk to churning to determine post-facto the accuracy of our signals.
    • We could incorporate these events in the normal course of analytics business (e.g. cohortize at-risk users, funnel with at-risk users, ...)
  • The alternate approach to churn prevention (and one that can be more proactive), is determining certain actions that signal intention to churn early on. An ad-hoc approach is manually determining such actions (e.g. contacting support too much, experiencing multiple errors, ...) and then tracking them. As a scalable product feature this would require some mechanism (like correlation analysis, a regression model, or even some more complex ML stuff) that allows to identify these signals dynamically.

What others are doing

  • There are some products that have some feature for churn prediction/prevention. Most of them employ some black-box algorithm to determine risk signals, and then use outside communication (e.g. email, push, SMS) to try to reengage users (part of the key value mentioned is optimizing for when and through which mediums to send such communications). These products are mostly targeted at the re-engaging part. Examples: Airship.
  • Amplitude's Compass could be used to determine which events correlate with a user becoming dormant. [[EPIC] New analytics views #1279]
@paolodamico paolodamico added enhancement New feature or request concept Ideas that need some shaping up still discussion labels Feb 17, 2021
@paolodamico paolodamico changed the title Churn risk prevention - identify at-risk useers Churn risk prevention - identify at-risk users Feb 17, 2021
@posthog-bot
Copy link
Contributor

This issue hasn't seen activity in two years! If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in two weeks.

@posthog-bot
Copy link
Contributor

This issue was closed due to lack of activity. Feel free to reopen if it's still relevant.

@posthog-bot posthog-bot closed this as not planned Won't fix, can't repro, duplicate, stale Apr 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
concept Ideas that need some shaping up still enhancement New feature or request stale
Projects
None yet
Development

No branches or pull requests

2 participants