Instrument 5–10 Events First, App Analytics for Product Teams

Analytics for apps means event-driven measurement of user behavior combined with performance data: taps, screens, purchases, crashes, and load times, all tied to individual users and sessions. The single highest-leverage move is to instrument core events first, export the raw data, and pair it with session-level observation so numbers come with context. Teams that skip the export step or skip the qualitative layer end up with dashboards that show what happened but never why.

What mobile app analytics actually measures

App analytics rests on four data types that answer different questions. Events are discrete actions, a button tap or a completed purchase. Sessions group events into a single visit, bounded by inactivity timeouts. User properties describe the person, plan tier, device, or acquisition source. Performance traces capture technical health: screen render time, network latency, app start duration.

Google Analytics for Firebase auto-captures a set of common events, like app opens and in-app purchases, while letting teams log custom events for anything specific to their product. That combination matters because auto-collected events give you a baseline for free, and custom events let you track the actions that actually define success in your app.

Each data type maps to a stage of the product lifecycle:

• Acquisition: install source, first-open events, campaign attribution.

• Activation: onboarding completion, first key action, time-to-value.

• Retention: repeat sessions, cohort return rates, feature reuse.

• Monetization: purchase events, subscription starts, revenue per user.

• Quality: crash events, ANR events, latency traces.

Treating these as one undifferentiated stream is the most common instrumentation mistake. A retention metric and a crash metric need different owners, different alert thresholds, and often different tools to interpret.

Core metrics and KPIs product teams track

Retention is usually read as Day 1, Day 7, and Day 28 cohorts: the percentage of users who return on each of those days relative to their install date. A healthy Day 1 number without a matching Day 28 number usually signals an onboarding problem rather than an acquisition one.

Lifetime value and average revenue per user depend on where you draw the boundary. Decide up front whether ad revenue, refunds, and free trials count, because mixing definitions across teams produces LTV figures that cannot be compared quarter to quarter.

Funnels track the percentage of users completing each step of a flow, and abandonment rate is the inverse at each step. Tying funnel drop-off to a specific experiment or release lets you separate a design regression from normal seasonal variation.

Crash and ANR rates have real consequences beyond user frustration. Android vitals reports thresholds, including a user-perceived crash rate around 1.09% and an ANR rate around 0.47% measured across Android overall, and apps that exceed the bad behavior thresholds can lose visibility in the Play Store.

Instrumentation and SDK setup that holds up over time

Good instrumentation starts narrow and grows deliberately. Begin with whatever your SDK auto-collects, then add a short list of custom events tied directly to business outcomes, not every button on the screen.

1. Audit auto-collected events before adding anything custom, since duplicating what the SDK already tracks wastes engineering time.

2. Name events consistently, using a verb-noun pattern like purchase_completed rather than inconsistent variants across platforms.

3. Limit parameter values to a controlled set where possible, since high-cardinality free-text parameters (like raw search queries) can blow up your event volume and cost.

4. Use DebugView or your SDK’s debug mode during development, since most SDKs batch events, often hourly, to save battery and bandwidth, which makes live debugging without it painful.

5. Set up quota monitoring before launch so an unexpected event storm does not silently break reporting or budgets.

Google Analytics for Firebase supports up to 500 distinct event types with free, unlimited reporting, which is generous but still finite, so plan your event taxonomy rather than letting it grow ad hoc.

Pro Tip: Review your event list every quarter and retire anything nobody has queried in the last 90 days.

Combining quantitative and qualitative signals

They rarely tell you why. That is where session replay, heatmaps, and funnels each play a distinct diagnostic role.

• Funnels show where users drop off across a sequence of steps.

• Heatmaps show where users click, scroll, or hesitate on a single screen.

• Session replay shows the exact sequence of actions a real user took before abandoning.

A typical diagnosis works backward: a cohort segment shows that new users on a specific device type have a higher onboarding drop rate, then session replay for that segment reveals a form field rendering off-screen on smaller devices. Some tools combine session replay, heatmaps, and event-linking so a metrics anomaly and the recorded session behind it live in the same dashboard, cutting the back-and-forth between analytics and support tickets.

Privacy has to be built into this layer, not added later. Masking personally identifiable information in recordings, honoring consent before recording starts, and documenting data retention periods are baseline requirements under GDPR and CCPA, not optional extras.

Pro Tip: Mask input fields by default in session replay tools, then explicitly unmask only the fields your team has confirmed contain no sensitive data.

For more on matching qualitative methods to specific problems, see this breakdown of session replay use cases.

Performance and stability monitoring worth watching

Crash reporting from your analytics SDK and Play Console’s Android vitals are not the same measurement. SDK crash reporting is typically real-time and tied to your specific build, while Android vitals aggregates quality signals across a rolling window, commonly 28 days, and compares your app against Android devices overall.

That aggregation matters because Play Console’s thresholds affect store visibility, not just your internal dashboards. Google’s own reference points include marks of bad behavior for user-perceived crash and ANR rates across the platform, and exceeding these can flag your app for reduced visibility.

Practical monitoring should include:

• Crash-free session rate tracked per release, not just per day.

• ANR rate segmented by device model, since low-memory devices often carry a disproportionate share.

• Alerts on regression, triggered when a new release’s crash rate exceeds the prior release’s baseline by a defined margin.

• Latency traces by region, since network conditions vary enough that a single global average hides real problems.

Prioritize fixes by multiplying affected user count against severity, a crash affecting 2% of sessions on a widely used device model usually outranks a rarer crash on an old device with a shrinking install base.

Monetization and subscription analytics teams need

For subscription apps, App Store Connect exposes metrics that product analytics tools often miss entirely: trial-to-paid conversion, subscriber retention, churn, and normalized Monthly Recurring Revenue.

• Conversion windows are measured at 1, 7, 14, 35, and 40 days after download, giving a standard set of checkpoints for comparing cohorts across releases.

• Sales versus proceeds is a distinction finance and product teams need to agree on early, since gross sales figures overstate what the business actually retains after platform fees.

• Revenue cohorts let you see how a specific acquisition month or campaign performs over time rather than looking at revenue as one aggregate number.

• Exporting App Store data into the same pipeline as your event analytics is what makes attribution and LTV calculations possible across the whole funnel, not just the download.

App Store Connect’s analytics dashboard attributes downloads to the purchase platform while usage is attributed to the device OS in use, a distinction worth knowing before reconciling install counts against active user numbers.

Why raw data exports to BigQuery matter

Dashboards summarize. Raw exports let you ask questions nobody built a report for. Firebase’s documentation confirms that once the SDK is added, you can export unsampled events to BigQuery for custom analysis and machine learning use cases, something aggregated dashboards cannot replicate.

• Unsampled analysis means every event counts, not a statistical extrapolation from a sample.

• Joining external data, like CRM records or experiment assignments, becomes possible once events sit in a queryable warehouse.

• Performance correlation analyses, such as app start latency by country or frozen-frame ratios against network type, come from exporting performance traces the same way.

• Cache hit rate and similar technical metrics are easier to compute when raw request-level data is available rather than pre-aggregated.

Before relying on any export, validate it: confirm row counts match expected event volume, watch for schema changes across SDK versions, and set partitioning and sampling rules early so query costs do not creep up as data volume grows. Firebase’s Performance Monitoring export guide documents the table structure for duration traces, screen traces, and network requests, which is worth reviewing before writing your first queries.

Choosing and rolling out your analytics stack

Selecting a platform comes down to five criteria: raw export availability, qualitative features like replay or heatmaps, integration depth with your existing stack, privacy controls, and a pricing model that will not punish you for growth.

Watch for red flags before committing: opaque export limits buried in fine print, event-based pricing that penalizes normal cardinality growth, and any tool that cannot mask personal data by default.

1. Plan: define the five to ten events that map directly to activation and revenue.

2. Instrument: implement auto-collected events first, then layer in custom events with consistent naming.

3. Validate: use DebugView or an equivalent debug mode to confirm events fire correctly before shipping.

4. Export: connect raw data to BigQuery or your warehouse and verify row counts against expected volume.

5. Iterate: review event definitions quarterly and retire what nobody queries.

Assign clear ownership: engineering owns instrumentation quality, product owns the event taxonomy, and whoever handles compliance signs off on data retention and masking before launch. For a closer look at what to check when evaluating qualitative tools specifically, see this guide to choosing a session replay tool.

What most teams get wrong about measurement

The biggest trap is not under-instrumenting, it is over-instrumenting and then never pruning. Teams track two hundred events, half of them redundant, and the resulting noise makes root cause analysis slower, not faster. The instrumentation that survives a year is the kind someone can explain in one sentence per event.

The second trap is treating qualitative and quantitative data as separate workflows owned by separate people. The fastest fixes come from someone who can see the funnel drop and the session recording in the same sitting. For a broader look at how behavioral metrics connect to product decisions, this guide to behavioral analytics metrics is worth a read, and marketing teams looking at how analytics ties into growth reporting can find useful framing in this piece on analytics for content marketing.

See this approach in action with LiveSession

Everything this guide recommends, event tracking paired with session-level context, lives in one place with LiveSession. Session replay, heatmaps, and event-linking sit next to your funnels, so when a metric moves, the recorded sessions behind it are one click away instead of a separate investigation. Privacy controls, including input masking, are built in rather than bolted on, which matters once GDPR or CCPA obligations enter the conversation.

LiveSession’s plans include a Free tier at $0 per year, a Basic plan at $54 per year, and a Pro plan at $83 per year, with an Enterprise option available on request. If your team is instrumenting events but still guessing at the reasons behind the numbers, start a free trial or request a demo and see the qualitative layer next to your existing metrics.

Sources

• App Store Connect Analytics — Subscriptions

FAQ

What is analytics in apps?

Analytics in apps is the practice of tracking events, sessions, and performance data to understand how people use a product and how well it runs. It combines behavioral data, like taps and completed purchases, with technical data, like crash rates and load times.

How do you do an analysis of an app?

Start by defining the core events that map to activation, retention, and revenue, then instrument those events with a consistent naming convention. From there, export raw data for deeper queries and pair the numbers with session replay or heatmaps to understand why users behave the way the data shows.

How do you find app analytics?

Most teams access app analytics through their SDK’s dashboard, such as Firebase’s reporting interface, or through the App Store Connect analytics dashboard for iOS-specific and subscription metrics. Raw event data is typically found by exporting to a data warehouse like BigQuery for custom queries.

Can you use Google Analytics for an app?

Yes, Google Analytics for Firebase is built specifically for mobile and web apps, offering free, unlimited reporting on up to 500 distinct event types along with auto-captured events like app opens and in-app purchases. It also supports custom event logging and raw export to BigQuery for advanced analysis.