安装应用只是起点，不能解释之后发生了什么。应用商店后台可以告诉您下载量，崩溃报告可以告诉您应用是否出现故障，但两者都无法说明新用户有没有体验到产品的核心价值、哪些页面造成阻碍，以及用户在首次会话后是否回来。这些才是移动应用分析需要回答的问题。
有用的接入方案从少量可观察的操作开始：记录用户真正到达的页面、完成的产品关键节点，以及应用在登录后已经知道的账户身份，再把这些信号放到网站活动的上下文中查看。Talivia 移动应用分析提供 React Native、Flutter 和原生 iOS SDK；原生 Android 包仍在准备中。
本指南介绍应该先衡量什么、原生应用追踪与网站脚本有什么区别、如何在同一个工作区查看网站与应用活动，以及哪些能力仍需额外集成。
移动应用分析应该回答什么问题
有用的报表应该帮助产品团队回答三个问题。**用户去了哪里？**页面浏览能显示用户是否到达新手引导、核心功能、设置或结账页面。**用户完成了什么？**具名事件可以区分成功完成操作和只是打开某个页面。**谁又回来了？**会话与已知账户 ID 为重复使用提供上下文，同时避免假设每台设备天然属于同一个人。
根据团队可能采取的行动来选择事件。如果用户到达新手引导页面，却很少创建第一个项目，团队就可以检查这一环节。如果只有少数回访客户使用高级功能，团队可以决定是改善功能入口，还是调整功能本身。记录每一次点击通常无法带来同样清晰的结论。
早期应用可以先采用简洁的事件计划：
| 信号 | 示例 | 可以了解什么 |
|---|---|---|
| 页面浏览 | Home、Onboarding、Project | 用户访问应用的哪些部分 |
| 产品事件 | signup_completed | 账户创建是否真正成功 |
| 首次价值事件 | first_project_created | 新用户是否体验到核心价值 |
| 重复价值事件 | project_shared | 用户是否回来完成有意义的操作 |
| 已知身份 | 稳定的内部账户 ID | 哪些活动属于已登录客户 |
事件名称应描述稳定的业务结果。按钮文案或组件名称下周可能改变，但“注册完成”的业务含义不应该随之改变。
原生应用需要 SDK，而不是网站追踪脚本
Talivia 浏览器脚本追踪网页，包括 Expo Web 构建。原生应用页面没有相同的浏览器文档或路由历史，因此 React Native、Flutter、Swift 或 Kotlin 应用需要使用对应平台的 SDK，将应用活动发送到 Talivia 现有的事件接收端。
| 平台 | 接入方式 | 当前状态 |
|---|---|---|
| React Native 与 Expo | @talivia/react-native | 已发布至 npm |
| 适用于 iOS 与 Android 的 Flutter | talivia_flutter | 已发布至 pub.dev |
| 原生 iOS / Swift | Talivia Swift 包 | 可通过 Swift Package Manager 使用 |
| 原生 Android / Kotlin | Talivia Android SDK | 等待 Maven Central 发布 |
移动应用分析文档包含每个平台的安装说明和代码示例。如果您同时使用 Expo 构建原生应用与网页，请在原生应用中安装 React Native SDK，并按照 Expo Web 指南追踪浏览器页面。同一段代码不能覆盖这两种运行环境。
在应用已经知道结果的地方添加追踪
移动端 SDK 使用三个明确的调用：导航变化时调用 screen()；有意义的操作成功后调用 track()；应用自己的认证流程确认客户身份后调用 identify()。退出登录时使用 reset() 更换匿名身份，避免共用设备上的两个账户活动混在一起。
例如，不要在用户点击提交按钮时就发送 signup_completed，应等后端确认账户创建成功后再发送。同样，应该在项目实际创建后记录 first_project_created，而不是在创建窗口打开时。请把 screen() 放在导航回调中，不要假设 SDK 能自行判断弹窗、标签页或嵌套路由在您的产品中是否算作新页面。
这种明确的接入方式可以适应您已有的业务逻辑，也让失败操作与成功结果容易区分。事件属性应保持精简：套餐名称或功能类别可能有用，而电子邮箱、访问令牌和自由输入的私密内容通常不应该进入分析数据。
在同一个工作区查看网站与应用活动
如果产品既有网站又有应用，请在配置移动端 SDK 时使用与网站相同的 Website ID 和网站域名。这样网站与应用活动会出现在同一个工作区。两个终端登录后都使用相同的稳定账户 ID 调用 identify()，即可关联已知客户身份记录。
但这里有一个重要边界：当前漏斗仍按访客标识统计。即使浏览器访客与手机上的匿名访客后来都标识为同一个账户，也不会自动合并成一条跨设备漏斗。已知身份关联可以提供有用的客户上下文，却不能证明所有登录前的匿名操作天然属于同一个连续旅程。
获客来源也有类似边界。网站会话可能带有引荐来源或活动参数，而原生应用安装需要独立的归因证据。移动端 SDK 不会自动采集应用商店安装来源、深度链接活动或广告网络归因。如果这些信息对业务重要，请规划单独的可信集成和进入应用时清晰的数据交接方式。
将应用事件与真实付款区分开
移动事件可以表示结账已开始，或应用显示了成功页面，但它本身无法证明款项已经收取。应用商店购买可能退款、延迟或验证失败；客户端事件也可能被重复发送或伪造。请从后端或受支持的付款集成记录权威收入数据，再通过您掌握的证据把它连接到客户或会话。
Talivia 的收入归因以已确认的付款数据为基础。当团队想知道某项功能是否有助于带来付费客户时，这一区别尤为重要：产品事件描述行为，经过验证的付款记录描述商业结果。只有两类数据都准确，组合报表才真正有用。
扩大追踪范围前，先验证一条短旅程
从一个测试用户和一条预期路径开始。打开应用、进入 Home、完成新手引导、执行首次价值操作，并在流程需要时登录，然后在 Talivia 中检查事件顺序。确认每个可见页面只记录一次、失败操作不会发送成功事件，以及稳定账户 ID 只在认证后出现。
也要测试边界情况。退出再打开应用，检查超过非活跃时间窗口后是否开始新会话。退出登录，确认匿名身份已更换。关闭网络、记录事件、重新连接，再检查重试行为。当前移动端 SDK 的队列最多在内存中保存 100 个事件；应用进程退出后待发送事件会丢失，因此它不能用作持久化离线分析。
最后，仅在应用的同意与隐私设置允许采集时初始化分析功能，并记录所发送的事件名称与属性。目标是用可信数据回答几个重要的产品问题，而不是把每一次交互都变成未经审查的事件流。
当页面浏览、产品关键节点、身份和已验证收入各有清晰职责时，移动应用分析才能发挥作用。先查看移动应用分析概览，选择适合平台的 SDK 指南，并在添加更多事件之前验证一条真实旅程。
