← All case studies
May – Aug 2026Burn by Cara Loren

The activation metric was wrong. I rebuilt analytics on ground truth.

The team's headline activation metric, "3 workouts means 80% convert," was guiding push strategy and trial length. It was built on a broken field. I re-checked it against billing data, found trials double-counted too, and rebuilt the metrics on ground truth.

Role
Lead developer
Timeline
May – Aug 2026
Stack
PostHogRevenueCat APISQLReact NativeTypeScript
analytics/identity.ts · simplified
// Web trials were counted by email in one system,
// by UUID in the other, so the overlap was invisible.
posthog.identify(user.id, { email: user.email });

// Logout must reset, or the next user inherits this ID.
onSignOut(() => posthog.reset());

- track('WorkoutComplete')
+ track('workout_completed', { program_id, day })

✓ one identity per person · one event per real occurrence
  • −33 ptsCorrection to the headline activation metric
  • ~30%Overstatement in reported trial volume
  • 67%Onboarding drop-off found on a single step, then removed

The problem

Burn’s team made product decisions on a simple rule: users who finish three workouts convert to paid at 80%. It shaped push notifications, trial length and how the team talked about engagement. Trial counts fed the same dashboards.

Both numbers came from data that didn’t hold up.

What I did

Re-checked the metric person by person. I re-verified every user in the cohort against actual billing entitlements instead of the database field the original analysis used. That field had been set when someone started a trial and never reset.

The real number: three workouts converts at 46.7%, not 80%. And the curve has no cliff at three; it keeps climbing, reaching 80% only at seven or more workouts. The bigger finding was that 70% of users never finished a first workout at all. The real problem was getting people started, not getting them to three.

Found trials counted twice. Web trials were being recorded twice, once from Stripe and once from RevenueCat. Each system identified the person differently (email in one, a UUID in the other), so the overlap was invisible in any single dashboard. Reported trial volume was roughly 30% too high. I also showed that trial-to-paid conversion couldn’t be measured correctly with the existing tracking, and specified what would fix it.

Cleaned up event tracking. I removed duplicate events, added an identity reset on logout so shared devices stopped merging users, moved event names to a consistent structured format, and built cohorts and dashboards the team could trust.

Acted on the funnel. A single profile step in onboarding was losing 67% of the people who reached it. I removed the questions we didn’t need, including gender and a gift address.

The outcome

The team replaced a wrong threshold with a real curve and a clearer target: the first workout. Trial reporting was corrected, and new analytics events are now checked against a second source before they ship.

What I’d tell another team

A dashboard that agrees with your intuition deserves the most suspicion. Before you steer by a metric, reconcile it against a second source of truth.

Hiring a full-stack or mobile engineer?

I’m based in Seattle, working globally, and open to full-stack and mobile roles across apps, payments and the systems behind them. Email is the fastest way to reach me.