An app install is a beginning, not an explanation. A store dashboard can tell you how many people downloaded an app, while a crash report can tell you whether it failed. Neither shows whether a new user reached the useful part of the product, which screens caused friction, or whether people came back after the first session. That is the job of mobile app analytics.
The most useful setup starts with a small number of observable actions. Record the screens people actually reach, the product milestones they complete, and the account identity your application already knows after login. Then inspect those signals in the context of your website activity. Talivia mobile app analytics supports this approach with SDKs for React Native, Flutter, and native iOS; the native Android package is in preparation.
This guide explains what to measure first, how native tracking differs from a website script, how to keep web and app activity in one workspace, and where additional integrations are still needed.
What mobile app analytics should answer
A useful report should help a product team answer three questions. Where do people go? Screen views show whether a user reaches onboarding, the core feature, settings, or checkout. What do they complete? Named events distinguish a successful action from merely opening a screen. Who returns? Sessions and known account IDs provide context for repeat use without pretending that every device is automatically one person.
Choose events from decisions you might actually make. If users reach the onboarding screen but rarely complete the first project, the team can inspect that step. If an advanced feature is used only by a small group of returning customers, the team can decide whether to simplify discovery or change the feature. A list of every tap rarely provides the same clarity.
For an early app, a compact event plan might be:
| Signal | Example | What it tells you |
|---|---|---|
| Screen view | Home, Onboarding, Project | Which parts of the app people visit |
| Product event | signup_completed | Whether account creation actually succeeded |
| First-value event | first_project_created | Whether a new user reached the core benefit |
| Repeat-value event | project_shared | Whether users return for a meaningful action |
| Known identity | A stable internal account ID | Which activity belongs to a signed-in customer |
Use names that describe durable business outcomes. A button label or component name can change next week; the meaning of a completed signup should not.
Before adding an event, write down its trigger, the expected properties, and the person who owns its definition. Decide whether a second attempt should create another event, and whether the event can arrive after the screen changes. These details matter when a team later compares onboarding versions or builds a conversion report. A short event dictionary also helps mobile and web developers use the same business names even though their navigation systems differ.
Native apps need an SDK, not the web tracking script
The Talivia browser script tracks web pages, including an Expo Web build. Native app screens do not have the same browser document or route history. A React Native, Flutter, Swift, or Kotlin app therefore uses its platform SDK and sends app activity to Talivia's existing event collector.
| Platform | Integration | Current availability |
|---|---|---|
| React Native and Expo | @talivia/react-native | Published on npm |
| Flutter for iOS and Android | talivia_flutter | Published on pub.dev |
| Native iOS with Swift | Talivia Swift package | Available through Swift Package Manager |
| Native Android with Kotlin | Talivia Android SDK | Maven Central release pending |
The mobile analytics documentation contains installation and code examples for each platform. If you use Expo for both native and web, install the React Native SDK in the native app and use the Expo Web guide for browser pages. The same code snippet does not cover both runtimes.
Instrument the moments your app already knows
The mobile SDKs use three deliberate calls. Call screen() when navigation changes. Call track() after a meaningful action succeeds. Call identify() when your own authentication flow knows the customer. Rotate the anonymous identity with reset() on logout so a shared device does not blend two accounts.
For example, do not emit signup_completed when a user taps the submit button. Emit it after your backend confirms that the account was created. Similarly, record first_project_created after the project exists, not when the create sheet opens. Place screen() in your navigation callback rather than assuming the SDK can infer whether a modal, tab, or nested route represents a new screen in your product.
This explicit approach lets tracking fit the business logic you already have. It also makes a failed action easy to distinguish from a success. Keep event properties small: a plan name or feature category can be useful, while email addresses, access tokens, and free-form private content generally do not belong in analytics payloads.
Bring website and app activity into one workspace
If your product has a website and an app, use the same Talivia Website ID and the website's hostname when configuring the mobile SDK. That puts web and app activity in one workspace. Use the same stable account ID for identify() after login on each surface to link known customer identity records.
There is an important limit: current funnels still group by visitor token. They do not automatically merge a browser visitor and a phone's anonymous visitor into one cross-device funnel just because both later identify as the same account. Treat known-identity links as useful customer context, not as proof that every anonymous pre-login action belongs to one continuous person.
Acquisition has a similar boundary. A website session may have a referrer or campaign parameter. A native install needs its own attribution evidence. The mobile SDKs do not automatically capture app-store install sources, deep-link campaigns, or ad-network attribution. If those are important to your business, plan a separate trusted integration and a clear handoff into the app.
Keep app events and payment truth separate
A mobile event can report that checkout started or that an app showed a success screen. It cannot, by itself, prove that money was collected. Store purchases can be refunded, delayed, or fail verification; client events can also be repeated or forged. Record authoritative revenue from your backend or a supported payment integration, then join it to the customer or session using evidence you control.
Talivia's revenue attribution is built around confirmed payment data. That distinction matters when a team asks whether a feature contributes to paying customers. Product events describe behavior; verified payment records describe the commercial outcome. Keeping both accurate makes the combined report useful.
Verify a small journey before expanding tracking
Start with one test user and one expected path. Open the app, reach Home, complete onboarding, perform the first-value action, sign in if the flow requires it, and then inspect the event order in Talivia. Confirm that each visible screen is recorded once, that a failed action emits no success event, and that the stable account ID appears only after authentication.
Test the edges too. Leave and reopen the app to see whether a new session begins after the inactivity window. Log out and verify that the anonymous identity rotates. Disable connectivity, record an event, reconnect, and check retry behavior. Current mobile SDK queues hold at most 100 events in memory; pending events are lost when the app process exits, so this is not durable offline analytics.
Finally, initialize analytics only when your app's consent and privacy settings permit collection. Document the event names and properties you send. The goal is to answer a few important product questions with trustworthy data, not to turn every interaction into an unreviewed event stream.
Mobile app analytics works best when screen views, product milestones, identity, and verified revenue each have a clear role. Start with the mobile app analytics overview, choose your platform's SDK guide, and verify one real journey before adding more events.
