Welcome to ChurnJitsu, your weekly briefing on the art of retention.
Let’s dive in.
🥊 TL;DR
A user who comes back after three weeks away is reactivated, not retained. Averaging the two hides the churn underneath.
Your weekly active count scores a twenty-second open the same as a daily habit. Measure the gap between meaningful sessions instead.
Instrument a custom
app_reactivated_7devent, then watch what that cohort does over the following seven days.
🎯 Master Class
One comeback can make a losing week look like a good one.
Your app reports 10,000 active users this week. Solid.
Now suppose 2,000 of them opened it for the first time in three weeks, looked at it for twenty seconds and left again. The weekly active number does not flinch. Your product is losing its regulars and the chart says things improved.
That happens because most dashboards answer one question: did this person open the app inside the window? Firebase ends a session after 30 minutes of inactivity by default (About Analytics sessions), so a single short open after weeks of silence lands in the same bucket as a daily user’s fifth visit. One bit of information, read as a habit.
Three behaviors are worth pulling apart.
Staying
These users keep showing up inside your product’s normal cadence. A daily habit app and a tax app do not share a cadence, and daily usage would be an absurd expectation for a travel app. Decide what a healthy interval looks like for your product before you borrow somebody else’s Day 7 target off a dashboard.
Returning
A reactivated user has real history with your app, then a meaningful silence, then a new session. The silence is the whole point. The person remembers enough to come back, and the habit has already broken.
A reactivation campaign can lift weekly actives without touching the reason people left in the first place. Count it, give the campaign credit for what it did, and keep it out of your core retention number.
Sticking after the return
This is where you find out whether the comeback meant anything. Monday’s returning user either completes something useful and comes back inside your normal cadence, or they tapped a push out of curiosity and you will not see them again. Those are different outcomes and your dashboard currently scores them the same.
An install campaign, a lifecycle email and a shipped product fix all produce more opens. Only the last one changes what the user finds when they get there.
The event to instrument
Ask your developer for a custom Firebase Analytics event named app_reactivated_7d. Firebase lets you define your own events and parameters (Log events); it will not log this one for you.
The spec, in five lines:
Fire it once when an existing user foregrounds the app at least 168 hours after their previous qualifying session.
Read the stored previous-session timestamp before you overwrite it. You are keeping that timestamp yourself, because Firebase does not hand it back to you.
Do not fire on a genuine first session, or when you have no session history you trust for that user.
Attach one parameter,
return_source, with a value ofpush,email,organicorunknown. Useunknownunless you have a real deep link or campaign signal. A guessed source is worse than no source.Keep the gap configurable. 168 hours is a starting definition, not an industry law. A fitness app and a tax app should not share an inactivity threshold.
One trap: first_open fires again on reinstall, not only on the original install (Automatically collected events). A returning user who deleted the app and came back looks brand new to the device. If that distinction matters to you, the “existing user” test has to run on your server against an account rather than on the client.
What to do with the cohort
Put every user who fires the event into a reactivation cohort and watch two numbers for seven days:
What share completes your core action?
What share returns for another qualifying session?
Compare both against your regular-user baseline, then compare cohorts by acquisition channel. A channel that brings back 1,000 people for one empty open is worse than one that brings back 200 who resume using the product.
Be careful with the conclusion. Better post-return behavior tells you which cohort is healthier, not that the channel or the message caused it. That takes a controlled test.
The product move
Somebody returning after 30 days should not get the same screen as a user opening for the third time today. Give them the shortest path back to something useful: where they left off, or what changed while they were gone. An onboarding tour treats them like a stranger, and a win-back discount tells them the product was never worth full price.
Your dashboard should answer a harder question than “did they come back?” It should answer “did they come back and keep coming back?” That is the difference between buying traffic and building a product people return to.
Your move this week: write down your product’s healthy interval, then check whether your current active-user definition can tell a daily regular apart from a three-week comeback. If it cannot, the event above is your next ticket.
Seven days after that event first fires, you will know whether last month’s reactivation spend bought you users or opens.
Inman