Our first funnel numbers are in… WTF?

🚀 Road to 1,000,000 Votap users - Day 80 | Current: 1467

50% of people who click through to our App Store page install the app.
70% complete registration, including phone verification and profile setup
23% of installs started the trial.
1 in 7 trials has converted to paid so far.

The data isn’t perfect yet. AppsFlyer is delayed in places, hence somehow having more first voters than registrations, and the sample is still small.

Here’s what excites me: we haven’t optimized or A/B tested ANYTHING yet. This is the baseline. Now we start breaking the funnel apart and seeing how far we can push it.

Download Votap from the App Store!

More tomorrow.

68 views

Add a comment

Replies

Best

the number i'd stare at is install to trial. 50 percent to install and 70 percent through registration are both strong, so the 23 percent starting a trial is where you're actually losing people, and that is after they already handed over a phone number. that's a lot of commitment to ask before anyone has seen value. worth testing the product first and moving verification to right before the paywall. i'd also hold off reading the 1 in 7 paid number for now, at this sample it is mostly variance and it is easy to optimize toward noise.

agree the 1/7 is irrelevant right now with the sample size. For the install to trial percantage: we have a mandatory trial (you cannot enter the app without it). So 20% is better than I thought since we are optimizing ads for installs and not “trial starters”. With sufficient conversion event volume we will switch the objective.

Honestly, having a baseline before touching anything is valuable. It’s easy to A/B test yourself into confusion when you don’t know what the original funnel actually looked like.

for sure I did want to get a baseline before doing anything. And the baseline is way better than expected!

I see that the step nobody has questioned yet is whether a mandatory trial belongs here at all. You've now got phone verification and a trial start both sitting in front of the first thing a person came to do, which is vote. The 23% isn't really an ads targeting problem, it's the price of asking for the decision before the value.

I run the other shape on a tool I build: no trial, no card, a few free flashcard generations on signup, then you buy credits. The trade is real in both directions though. People pay after they've already got something out of it, which makes the purchase easy, but I have no MRR line and no idea whether someone with a balance is active or just sitting on it. Your model tells you far more per user than mine does, so I'd rather you kept the trial and knew what it costs you

 Let me clarify: the user registers (creates profile), then goes through onboarding, which is interactive - so they are essentially tapping things live in the app. The onboarding includes finding your politician and voting on them. The mandatory trial comes AFTER the onboarding and voting so people got their "aha" moment before encountering the paywall.

You are also right that this type of funnel is easier to track - your objective is trial start and that's it. I am still debating wether to let every user have free access immediately. The thing is they can start the trial, cancel it and after 7 days when it runs out they can still use Votap as a free user. I have premium features like extra charts, filters etc. but voting is always free.

I am generally leaning towards a system I have right now but maybe optimizing the funnel in terms of they can vote and see the app before the registration (because yes that's a big commitment), but then they have to start the trial as it is and optimize meta ads for the "trial start" event and not installs so we aren't throwing money of out the window for people who are going to install but never start the trial.

What would you do in my situation?

 Fair, I had the order wrong, and the "aha" landing before the paywall changes my answer.

Then the number I would stare at is the one between your own two: 70% complete registration, 23% start the trial. That's two thirds of the people who already installed and already registered, and everything in that gap is onboarding plus the paywall screen. Moving registration later widens the top of the funnel but leaves that wall exactly where it stands

So before any A/B test I'd split it into two events, onboarding complete and paywall seen. Completely different fixes and right now you can't tell which one you have.

On switching Meta to trial start, I would count the events before flipping it.

 My thought process behind (maybe) moving the registration AFTER they vote and try the app is that more people would be willing to register but that one I don't think is the bottleneck. Roughly 70% install -> register rate seems high to me.

After the end of onboarding (after they vote and discover the app) it shows them the trial paywall immediately. I don't quite have the "onboarding finish" count here (but I do have that data elsewhere).

So essentially: Onboarding finish count = Paywall seen count.

For the Meta side of things: do you agree that having the campaign optimize for installs with a setup I have (mandatory trial) is worse than optimizing for events which are deeper in the funnel (voting, trial start or even trial convert)? Do you have experience with optimizing Meta campaigns for custom events not just installs? Cheers!

 yes, but run the numbers before you flip it, because by your own data you're right on the edge rather than clearly above it. 1467 users in 80 days is roughly 18 registrations a day, and trial starts are 23/70 of that, so call it 6 a day, around 40 a week. That's about what a single ad set needs to get out of learning, and it's before you split budget across several.

The answer on the second question is no. I've not run Meta campaigns optimizing for custom events. My acquisition is organic, so treat the ads half of this as reading rather than experience, and check my per-day maths against your actual event counts, I'm deriving it from a cumulative number.

The thing I'd actually go get is the number you said you have elsewhere. Onboarding finish equals paywall seen, fine, but pulling it into this view still splits the 70 to 23 drop into two piles: people who quit partway through onboarding, and people who reached the paywall and said no. One is a pacing problem in the flow, the other is pricing and timing.

Caveat: My tool gives 5 free generations and then sells credits, so there's no paywall screen anywhere in my flow to get wrong.