App Analytics For AI-Built Apps: What To Track After Launch

Launch day for a vibe-coded app usually ends with a dashboard full of numbers that tell you nothing. Installs are up, sessions exist, crash-free rate is green — and you still cannot say which screen loses people or whether the paywall is working. This guide covers app analytics for AI-built apps: the small set of events worth instrumenting after launch, the decision logic behind each one, and how to wire them up on a Capacitor or app builder stack without drowning in dashboards.

Why launch analytics fail on AI-powered apps

Most founders who ship with Lovable, Base44 or Replit arrive at the App Store with whatever analytics the web app already had. That data was designed for a browser: page views, referrers, bounce rate. On a phone, those concepts either break or mislead. A single app session can span twenty screens with no page loads at all, and there is no referrer once the install happens.

The second failure is volume. It is tempting to auto-capture every tap, and every modern SDK will happily do it. Six weeks later you have four hundred event names, no definitions, and no one willing to trust a number in a board update. Auto-capture is a safety net, not a measurement plan.

The third is the gap between product data and revenue data. Your product tool knows a user opened the paywall. Apple knows they subscribed. Unless those two are joined by a stable user identifier, you cannot answer the only question that matters after launch: which behaviour predicts payment?

Decide what to measure before you install an SDK

Start from the decision, not the dashboard

Write down the three decisions you expect to make in the next sixty days. Typically they are: whether to change the onboarding flow, whether to move or reprice the paywall, and where to spend the first acquisition budget. Each decision implies two or three numbers. Anything that does not feed one of those decisions is noise you will pay for in engineering time.

Define one activation moment

Activation is the first action that proves the user got the value you promised. In a habit tracker it is logging a second day. In an AI tool it is a completed generation the user keeps. Pick one, write it as a single sentence, and treat it as the north star of your user interaction data. Everything else is diagnostic.

Separate counting from understanding

Counting tools tell you how many. Session replay and qualitative feedback tell you why. Early on you need far less counting than you think and far more watching. Ten recorded sessions of real onboarding usually beat a month of funnel charts.

The seven metrics that matter in month one

Install-to-activation rate

Of everyone who opens the app for the first time, what share reaches your activation moment in the first session? Below 25% and your onboarding, not your marketing, is the constraint.

Day 1, day 7 and day 30 retention

Retention is the single hardest number to fake and the one investors ask for. For a consumer utility, roughly 25% at day 1 and 10% at day 30 is a workable baseline; a B2B tool used weekly will look different, so read the curve shape rather than the absolute.

Paywall view to trial start

Track views, starts and the ratio. A low ratio with high views is a pricing or copy problem. Low views is a placement problem — the paywall is buried.

Trial to paid conversion

Only visible after the trial length has elapsed, so instrument it on day one or you will be blind for a fortnight.

Crash-free sessions

Anything below 99% will quietly cap retention no matter what you change in the funnel.

Time to first value

Seconds from first open to activation. It is the number most responsive to design changes and the easiest to move in week one.

Revenue per install

The number that decides whether paid acquisition is viable at all. Until you know it, treat every ad budget as research spend.

Designing an event tracking schema you will not regret

Name events as object plus past-tense action

paywall_viewed, trial_started, project_created. Consistency beats cleverness; mixed conventions are how a schema becomes unreadable within a quarter.

Keep the list under twenty-five

A first release needs roughly: app_opened, onboarding_step_completed, signup_completed, activation_event, core_action_completed, paywall_viewed, purchase_started, purchase_completed, purchase_failed, notification_opened, error_shown. That is enough to run a company.

Put the detail in properties

One core_action_completed event with a type property is far more useful than nine near-identical event names. Properties can be grouped later; event names cannot easily be merged.

Write the tracking plan down

A shared sheet with event name, when it fires, properties and owner takes an hour and saves the reconciliation arguments that otherwise consume every second month.

Mapping user journeys from install to paid

Draw the user flow as a straight line: install, first open, onboarding complete, activation, second session, paywall, purchase. Then instrument each transition. What you are looking for is not the biggest drop — first-open to onboarding always drops hardest — but the drop that is out of line with comparable apps.

Segment by acquisition source as soon as you have one. Users who arrive from a web-to-app funnel behave differently from organic App Store search traffic, and averaging them hides both. If you run referrals, tag the invited cohort separately; invited users usually activate faster, and that difference is the business case for a referral engine for apps rather than more ad spend.

Finally, join the product funnel to the store funnel. App Store Connect gives you impressions, product page views and conversion to install. Your in-app data starts after that. Read them together and you can tell whether a weak week was a listing problem or a product problem — and if it is the listing, an ASO score will point at the metadata and creative doing the damage.

Choosing a mobile analytics tool for an AI builder stack

Product analytics

PostHog, Amplitude or Mixpanel all work. PostHog is the pragmatic default for an early AI app development team because funnels, replay and flags sit in one place and the free tier is generous.

Crash and performance

Firebase Crashlytics or Sentry. Non-negotiable, and both take under an hour to add.

Subscription analytics

Whatever handles your in-app purchases should own revenue truth. Receipts are validated server-side, so revenue reported by the product tool is always an estimate; treat the billing layer as authoritative and let the product tool explain the behaviour behind it.

Attribution

Skip it until you are spending real money on ads. Before that, self-reported attribution in onboarding — one question, one tap — is cheaper and often more accurate on iOS.

Implementation: nine steps to trustworthy data

1. Write the tracking plan first. Eleven events, defined in a sheet, before any code.
2. Install the SDK in the native shell, not only in the web layer, so lifecycle events such as background and foreground are captured correctly.
3. Set a stable user ID at signup and alias the pre-signup anonymous ID, otherwise every funnel breaks at the account step.
4. Instrument the activation event and the purchase events next. Those two carry most of the value.
5. Add crash reporting and set an alert threshold at 99% crash-free sessions.
6. Send purchase events server-side from your receipt validation, so refunds and renewals stay accurate.
7. Tag your app version and build number on every event; without it, regressions are untraceable.
8. Verify in a debug view on a real device, running the whole flow twice, before you trust anything.
9. Build three saved dashboards only: activation, retention, revenue. Delete the rest.

Once the numbers are trustworthy, they should trigger action elsewhere in the product. A lapsed-trial cohort is exactly what a lifecycle message is for — see how we approach app analytics for AI-built apps feeding push notification triggers on a native build.

Privacy, ATT and what Apple expects

Every SDK that collects user data must be declared in App Privacy answers in App Store Connect, and the answers must match reality. Reviewers do check obvious mismatches, and a wrong declaration is a slow, avoidable rejection.

App Tracking Transparency applies only if you track users across other companies' apps and websites — typically an ad attribution SDK. First-party product analytics used inside your own app generally does not need the ATT prompt, but it does need a privacy manifest entry and an accurate declaration. Avoid sending email addresses or raw personal data as event properties; a hashed ID is enough for every analysis you will actually run.

Add an account deletion path and make sure deletion removes analytics identifiers too. This is a guideline requirement, not a nicety.

Running a weekly review that changes decisions

Thirty minutes, same time each week, three numbers: activation rate, day 7 retention, revenue per install. Write one sentence on what moved and why you think so, then choose exactly one change to ship. Analytics without a standing review becomes wallpaper within a month.

When the numbers are stable and the funnel is understood, the constraint moves from measurement to distribution — that is the point to bring in post-launch app growth support rather than more instrumentation.

Your next move

You do not need a data team to run an AI-built app well. You need eleven events, three dashboards, a weekly half hour, and a native build that can act on what the data tells you. Most founders we work with get that in place in a week and spend the following month actually improving the product instead of arguing about numbers.

If your app is not live yet, get the launch right first — the instrumentation is far easier to add before submission than after. Book a free launch review and we will map the events, the paywall and the App Store submission together.