Analytics, Crash Reporting and Observability

Analytics feel like they can wait, because they don't change the product. They can't wait, because without them, every decision after launch is a guess. Install them before you have users. Data is not retroactive: every day without them is information permanently lost.

The concept

Three different tools that answer three different questions, and you need all three:

The core discipline: instrument before launch. You cannot reconstruct what users did last week if you weren't recording it. Retroactive data does not exist, which makes this the one thing you genuinely cannot defer.

⭐ The six numbers that matter before product-market fit

Ignore vanity metrics. For most products, six numbers decide whether you have a business:

Multiply activation × conversion × retention and you get install → paying customer, which tells you what a user is worth and therefore what you can spend to acquire one (Chapter 01).

D7 is the one to obsess over. If it's under ~10% for a consumer product, no amount of marketing saves you, you're pouring users into a leaky bucket (Chapter 9).

Events: about twenty, not two hundred

Every event should answer a question you'd act on. Cover four areas:

 ONBOARDING FUNNEL   step viewed (with index) · completed · dropped
 MONETIZATION        paywall viewed · plan selected · purchase started /
                     completed / FAILED (with reason) · restore
 CORE LOOP           the key action, opened / completed · investment step
 HEALTH              app opened · permission granted/denied · SYNC FAILED

Instrument failures, not just successes. purchase_failed with a reason, sync_failed with an op type. Silent failures are the expensive ones (Chapter 29), and a _failed event is how they become visible.

Step-viewed-with-an-index on a multi-step funnel gives you the exact drop-off curve, the single most actionable dataset you can have, for one line of code per screen.

Crash reporting is separate and non-negotiable

Analytics tells you what users did; crash reporting tells you when your app broke. Without it, you learn about a crash from a 1-star review. Two lines wire a global handler to a service, and it catches the silent failures your analytics won't.

One identity across every system

The same user id must thread through auth, payments, and analytics, or you can never connect "this user converted" to "this user came from that channel." Track anonymous users from first open, then alias to the real id at sign-in so the pre-signup funnel isn't orphaned.

Wrap it so it can't crash your app

An analytics call must never break your product. Wrap every one in a try/catch, SDK errors taking down production apps is a real, recurring event. One call-site shape, one swappable provider.

Analytics changes your privacy obligations

Adding analytics means you now collect data, update your App Privacy label and privacy policy, and under GDPR you may need consent for non-essential analytics. Choose privacy-preserving tools (self-hosted or EU-hosted, cookieless) to minimise this (Chapter 40).

📐 Best practice

Install crash reporting first, two lines, highest safety value.

Turn on your payment provider's dashboard, free subscription analytics you already have.

Instrument ~20 events, each answering a question you'd act on.

step_viewed with an index on funnels.

Instrument failures, not just successes.

One user id across auth, payments, analytics; alias anonymous → real on sign-in.

Wrap every analytics call so it can't crash the app.

Cohort your retention, aggregate hides regressions.

Store UTMs with the signup so channel attribution is possible (Chapter 46).

Update the privacy label and policy when you add analytics.

Install all of this before launch.

💀 Common mistakes

⭐ No analytics at launch. Can't tell why conversion is bad. Data isn't retroactive.

No crash reporting. You learn about crashes from reviews.

Mismatched user ids. Can't join revenue to behaviour.

Orphaned anonymous funnel. Pre-signup data lost.

Two hundred events. Nobody reads the dashboard; measurement theatre.

Only success events. The expensive failures stay silent.

No UTM storage. Can't attribute paying users to channels.

An analytics SDK that crashes the app. Worse than no analytics.

Privacy label mismatch after adding analytics.

Vanity metrics, total installs, page views, instead of retention and conversion.

Aggregate (uncohorted) retention, mixes cohorts, hides everything.

The professional workflow

 BEFORE LAUNCH (an afternoon)
   crash reporting (two lines)
   payment-provider dashboard confirmed on
   analytics wrapper + ~20 events
   one user id across auth / payments / analytics
   web analytics + UTM capture on signup
   privacy label + policy updated

 WEEK 1 AFTER LAUNCH
   onboarding funnel drop-off · D1 · paywall conversion · crash-free %

 MONTH 1
   D7 and D30 · trial→paid · which step loses people · channel attribution

 THEN, AND ONLY THEN
   A/B test the biggest measured drop-off

Note the order: you cannot A/B test until you can measure. Every optimisation idea is blocked on step one.

Tools, websites & costs

Everything a pre-launch product needs is free. The bottleneck is never cost, it's remembering to do it before you have users.

Alternatives & trade-offs

All-in-one vs best-of-breed. PostHog does analytics, replay, flags and A/B in one free tool, simplest to start. Best-of-breed (Amplitude for analytics, Sentry for errors) is more powerful and more integration. Start all-in-one; specialise when you outgrow it.

Privacy-first vs full-featured. Cookieless, self-hosted analytics avoids consent banners and data-sharing obligations; ad-tech-adjacent tools give attribution at a privacy cost. For most products, privacy-first is enough and cheaper legally.

Client-side vs server-side events. Client events capture UX and are lossy (blockers, offline). Server events are reliable for anything money-related. Send purchases server-side; UX events client-side.

Quantitative vs qualitative. Analytics tells you what; session replay and interviews tell you why. Use both, analytics finds the cliff, replay and interviews explain it.

Checklist

• Crash reporting installed (do this first)
• Subscription-provider analytics switched on
• An analytics wrapper with one call-site shape, wrapped in try/catch
• ~20 events across funnel, monetization, core loop, and failures
• step_viewed with an index on funnels
• One user id across auth, payments, analytics
• Anonymous users tracked and aliased on sign-in
• Web analytics + UTMs stored per signup
• Privacy label and policy updated
• Retention is cohorted
• I can state my D1, D7, activation, and conversion, or I know I can't and I'm fixing it today

📓 Case Study: a 19-question funnel measured by nothing

Project: SOLIS. This is the largest single gap in the entire build, and it undercuts much of the work around it.

The product had: a 19-question onboarding funnel with 8 interstitial screens, a paywall with two placements, a 450-item course built around retention, and a landing page with a waitlist.

It measured none of it. No product analytics, no funnel instrumentation, no cohorts, no crash reporting. It was impossible to answer:

• Where users dropped out of the 19-question funnel
• What percentage reached the paywall, and what percentage converted
• D1, D7, or D30 retention
• Which lesson people stopped at
• The waitlist conversion rate, or where signups came from
• Whether the app crashed, and where

⭐ The part that makes this instructive: the plan named the exact metrics on day 4.

What we measure: D1/D7/D30 retention (the only numbers that matter pre-marketing), quiz→paywall view rate, paywall→purchase conversion, and day-8 lock → upgrade rate.

That list is correct and complete. It was never implemented, not because it was hard (it's an afternoon), but because it produced no visible progress. Every day for 24 days there was something more visible to build: content, art, a backend, payments, an onboarding funnel. Analytics lose the daily argument to anything you can see.

The consequence is precise. If the app launched tomorrow and converted at 1%, there would be no way to know whether the problem was the funnel, the paywall, the price, the app, or the traffic. Every subsequent decision would be a guess, and the optimisation would land on the wrong thing.

And it isn't just post-launch. The plan itself flagged an open question, "the funnel is ~40 screens; long converts, but is a lot to maintain. Full set, or a leaner ~20-screen cut? Recommend building the core first, then judging length live." You cannot judge it live without measurement. Every "we'll test this later" in the project was quietly blocked on a thing that was never built.

Two identity foundations were laid correctly, which is worth crediting: the payment provider was told to use the app's own user id, and the backend tied the same id across auth and sync. So if analytics had been added, one identity would already have threaded through, the hard part was done, the easy part skipped.

�the confession, generalised. The product was genuinely high-quality, good content, considered design, real engineering. And it was built almost entirely on reasoning about what works, borrowed from other companies' published data, with no feedback loop of its own. The queue-vs-calendar retention model, the 19-question funnel, the 3-day trial, all well-argued, none measured. So the honest status of nearly every design decision in the whole project is plausible and untested.

📐 Analytics is not a growth-phase tool. It's the thing that turns "we think this works" into "we know." Without it, a beautiful product is an elaborate, expensive guess. Install it before the first user, it's the cheapest afternoon in the build and the one you can never do retroactively.

Lessons

1. ⭐ Install analytics before you have users. Retroactive data does not exist, the one thing you genuinely cannot defer.
2. Naming the metrics is not measuring them. The right list on day 4 is worthless unbuilt.
3. Analytics lose to features daily because they produce no visible progress. Schedule them like a feature.
4. Six numbers matter pre-PMF. D1, D7, D30, activation, conversion, trial→paid.
5. D7 is the one. Under ~10% and marketing can't save you.
6. Your payment provider's dashboard is free analytics. Turn it on.
7. Crash reporting is two lines and catches silent failures.
8. One identity across every system, or you can't connect revenue to behaviour.
9. Instrument failures, not just successes.
10. Twenty events, not two hundred. Each must answer a question you'd act on.
11. You cannot optimise what you cannot measure. Every improvement idea is blocked on this.

Next: Chapter 39: Company Formation and Legal Basics →

This completes Part VII, Shipping.