App Analytics Implementation

Start with questions, then decide the events

Installing an analytics SDK takes an afternoon, and that is the trap. Without a plan, every developer names events differently, the same action fires twice on Android, and six months later nobody trusts the funnel. Tepia starts by collecting the questions your team actually needs answered, such as where new users stop between install and their first order, whether the new onboarding raised week one retention, or which push campaigns bring lapsed users back.

Each question becomes one or more events in a tracking plan. The plan defines the event name in a consistent object and action format, the exact moment it fires, its properties and allowed values, whether it is sent from the app or the server, and which person owns it. Tepia also agrees on one activation event with you, the action that best predicts a user sticks around, because almost every dashboard later measures against it.

What a tracking plan looks like in practice

Here is a shortened example from the kind of plan Tepia writes for a service booking app. A full plan usually runs to 40 to 80 events, far below platform limits and small enough to keep accurate.

Screen views, app opens and crashes come from the SDKs automatically, so the plan focuses on the actions that tie to outcomes. Crash reporting runs alongside in Firebase Crashlytics or Sentry so product and engineering look at the same releases.

Choosing the analytics stack

Tepia picks tools by who will read the data and what else the app already uses:

• Firebase and Google Analytics 4 suit most mobile apps. They connect directly to Crashlytics, Remote Config and A/B Testing, and the BigQuery export gives you raw events for SQL analysis.
• Mixpanel or Amplitude fit product teams who live in funnels, cohorts and retention curves and want answers without writing queries.
• PostHog works when you want product analytics, feature flags and session replay together, with the option to host it yourself.
• An event router such as Segment lets the app send each event once while your data team routes it to several destinations, which keeps SDK count and app size down.

Whatever the tools, Tepia builds a thin analytics layer in the app so the vendor can change later without touching every screen. For reporting beyond what the vendor dashboards show, our data analytics and dashboards team builds views on top of the warehouse export.

Turning events into product decisions

Data only pays off when someone acts on it. Tepia sets up a short weekly view for each client: new installs, activation rate, week one and week four retention by signup cohort, and the conversion of the core flow, split by platform and app version. When a release changes one of those numbers, the version split shows it within days.

For changes that are worth testing, Tepia uses Firebase Remote Config with A/B Testing, or the experiment features in Amplitude or PostHog, to show two versions of a screen to separate groups and compare the activation event. We size each test so it can reach a clear result, and we write down the decision it is meant to inform before it starts. That habit keeps experiments from turning into a list of inconclusive charts.

Privacy, consent and store disclosures

Analytics is where many apps get into trouble with App Review and regulators, so Tepia treats it as part of security and compliance work. On iOS, tracking users across other companies’ apps or websites requires the App Tracking Transparency prompt, and Apple expects privacy manifests for commonly used SDKs. Your App Store privacy label and the Google Play Data safety section must match what each SDK actually collects, and Tepia keeps an inventory so they stay accurate after every release.

We also keep personal information out of event properties, honor GDPR and CCPA consent choices before events are sent, and pass account deletion requests through to analytics vendors. Health apps need extra care: sending protected health information to a third party analytics tool without a business associate agreement is a real HIPAA risk, so Tepia uses tools that sign one or keeps health events on your own infrastructure.

How Tepia approaches app analytics

Analytics runs through the six phase Tepia process, whether the app is new or already live.

1. Discovery: stakeholder interviews to gather questions, a review of any existing events and dashboards, and an Investigation Summary that lists every SDK and what data it collects. The output is the tracking plan and an agreed activation event.
2. Design: wireframes annotated with the events each screen fires, plus consent and permission screens designed with copy your legal team approves.
3. Development and Testing: the analytics layer and server side events are built with the features. Test plans include an event check for each user story, verified in Firebase DebugView or the vendor’s live view on real devices during Alpha and Beta.
4. Training: product and marketing staff learn to read the funnels, retention charts and BigQuery tables, and how to request a new event through the plan instead of around it.
5. Launch: dashboards are switched to production data, a baseline is recorded for the first two weeks, and privacy labels are confirmed in both stores.
6. Support: the tracking plan is versioned, broken events are tracked as bugs, and new features ship with their events defined.

Analytics also feeds our app retention engineering work. See the full process or contact Tepia to review your current setup.

Frequently asked questions