Three weeks after launch, Puppy Routine (an iOS potty-training app that predicts when your puppy needs to go out) got its first paid subscription. The whole 90-day funnel fits in one line:
151 App Store impressions → 15 product page views → 8 downloads → 1 paid monthly subscription
Two things surprised me.
People who open the listing mostly install. Almost nobody opens it, and a big part of that is zero ratings next to the icon in search results. Which led to...
The app only asks for a rating after it has predicted three potty breaks correctly and the owner has used it on three different days. That's a reasonable gate. The bug was when the check ran: only at the moment a prediction was confirmed. This user got through three confirmations on day one, before the three-day condition could be true, and then kept logging every day without another confirmation. So the check never ran again, and the one person most likely to leave five stars was never asked.
Here's what they did on day one (anonymous install ID, bucketed events, no personal data):
They're still logging about 40 events a day on day five. They also opened the weekly report 18 times while it still said "not enough data yet", so people want their week before it's a full week.
Question for anyone who has been here: when did you put the paywall in front of people? My one data point says "day one, once they've seen it work". One data point is not a strategy.
Agree — first 10 users usually come from one channel you over-index on, not “everywhere a little.”
Congrats on the first paid subscriber—the repeated opens of the weekly report before enough data is especially actionable. I’d keep that as a clearly labeled preview rather than hide it, then test paywall timing against a value event with a small cohort. Since the sample is still tiny, I’d treat the current funnel as a hypothesis and watch a few more installs before declaring impression → page view the main leak.
SIGNAL: One paid user from 151 impressions is a real start — and the funnel read is useful: the cliff is impression → page view, not page → install. People who open the listing mostly convert; almost nobody opens it.
GAP: With n this small, the rating bug and the paywall timing are both true problems, but they sit after the harder one: why someone taps through from search at all. Zero ratings explain part of that. The other part is whether the listing names one near-term decision (“will this predict the next break well enough that I stop guessing tonight?”) versus a feature list. Until that claim is sharp, ratings fix a step that many never reach.
ACTION: Keep the day-one value trigger you already saw work, but for the next ~20 installs treat the listing headline + first screenshot as the experiment — one falsifiable promise, one proof moment (prediction → confirmation). Log which search terms drove the opens. The weekly-report hunger (18 opens on “not enough data”) is also a signal: ship an early, clearly labeled provisional read so people feel a decision forming before day five.
Curious: of the search terms that produced those 151 impressions, which ones actually led to a page view — and did any of them sound like a decision rather than a category?
— Francisco / TrixellaIQ — competitive intelligence for D2C brands
https://trixellaiq.com (sample on the site)
One measurement caution on the funnel read: at 151 impressions the step rates carry a lot of uncertainty. Impression to view is 15/151 (roughly a 6-16% interval at 95% confidence), but view to install is 8/15, where the 95% interval runs roughly 27-79%. So view to install could plausibly be the worse step; this n does not really pin down which step is weakest. I would hold off ranking the steps until a few hundred more impressions.
One angle nobody raised: for a potty-training app, monthly may not be the worse plan — it may be the right one. This is a temporary-need product; nobody house-trains a puppy for a year. The user opened the paywall six times before buying, which reads to me like they were wrestling with the commitment itself, not which tier to pick. I'd test framing monthly as the plan built for the job rather than defaulting to annual. Aligning the plan with the actual job duration could convert better than a price anchor.
The correction in the comments is the part I found most useful. The first funnel read suggested “value-triggered paywall,” but the minute-by-minute log changed the interpretation: the user paid during a bad day, before a prediction had been confirmed. That makes the second accident of the day a much more testable product moment than the original funnel summary. I’d keep that as a hypothesis, not a conclusion, and watch whether the next few users repeat it.
Really solid approach — I'm juggling something similar myself (building Xstream4K on the side), what's been the hardest part for you so far?
151 impressions to a paying customer is a strong signal that the offer was clear enough for a small audience. I would keep the core promise stable for a week, then fix the weak step with one event per funnel stage, especially which screen opened the paywall and when the rating gate became eligible. What did they buy in one sentence, and what almost made them bounce before checkout?
Across the next few users, what behavior would convince you someone has experienced enough value to see the paywall on day one—prediction accuracy, logging frequency, or repeated use of a specific feature?
Love the honest funnel. Since ratings are the bottleneck, asking happy users at the right moment (after a successful week of the routine, not on day one) is the lever. And for the ones who aren't happy, a quick in-app "what's not working?" catches them before they leave a 1-star. We build that kind of short feedback flow at chatform.in (I work on it), one question at a time with a follow-up when the answer is vague.
Your data points to a value-triggered paywall more than a time-triggered one. I’d test showing it after the second or third successful prediction, while keeping basic logging free—the user has felt the payoff, but hasn’t built enough history to feel trapped.
I thought so too, then pulled the minute-by-minute log and it says the opposite, so I got this wrong in the post.
This user opened the app, logged five accidents that had already happened in six minutes, looked at the paywall at minute six, took the puppy out a few times with nothing happening, and subscribed at minute fifty. Not a single prediction had been confirmed yet. They didn't pay after seeing it work. They paid in the middle of a bad day, for a plan.
Three of my six real installs arrived like that, mostly accidents in their first logs. The two that didn't pay never completed one take-out task and were gone within three days.
So in 1.4 the moment I'm building around is the second accident of the day. The app offers a reset (take-out trips on a tighter clock until bedtime, one tap), and the paywall is a quiet link on that card, not a gate. Tiny sample, so I'd happily be proven wrong again.
Jack, that rating bug is exactly the kind of small state-check issue that can quietly cost you reviews when traffic is still tiny. A simple fix is to make the rating eligibility check a reusable function triggered by every relevant state change, not only prediction confirmation, with a guard so it fires once. I’m available to clear similar tracking, backlog, or frontend issues while you keep pushing Puppy Routine forward.
Glad to connect?
That's close to what shipped in 1.3. The check is one function now, and it runs when either half of the condition changes (confirmed predictions or active days) and whenever the Today screen opens, instead of hanging off a single counter. The lesson I took: a gate with two conditions needs to be re-checked when either one moves, not just the one that feels like "the moment".