Adapty 用户在比较来自不同来源的相似数据集时，可能会遇到数据差异。这种情况尤其容易在以下比较中出现：

• Adapty 数据图表与应用商店报告之间的比较
• Adapty 数据图表与第三方数据图表之间的比较
• Adapty 内部不同数据图表之间的比较

故障排查流程

Adapty 与其他平台之间的大多数数据差异都是正常现象，原因在于不同数据源对相同数据的处理方式不同。

但有时，这些差异也可能意味着你的 Adapty 配置存在问题。

如果你怀疑各平台之间的数据存在出入，最好的排查方式是导出原始数据并对比文件内容。

• 即使是应用商店本身也可能存在数据处理和展示方面的问题。请访问商店的原始交易数据，以获得最准确的对比参考。
• 在将 Adapty 与其他分析平台进行比较时，请以商店的交易报告作为真实来源和对比基准。
• 使用较小的数据集更容易定位差异。建议对比少量数据——聚焦某个特定产品的单日数据。
• 判断差异是由定价还是事件数量引起的。定价问题可以通过更新产品来解决；事件数量问题则可能表明存在服务端问题。
• 查看事件流以监控传入事件——你可能会发现一些异常行为。

确定数据出现分歧的位置后，可以排查以下常见原因：

服务器通知与 RTDN 问题

如果未正确配置应用商店连接，Adapty 将无法接收必要的事件数据。这尤其会影响那些无需用户直接操作就会触发的事件——例如订阅续费、账单问题等。

请尽快完成服务器对服务器的配置（App Store | Play Store），并等待商店建立连接。

您可以手动上传缺失的 App Store Connect 数据到 Adapty。

数据缺失

使用旧版应用的用户

如果部分用户运行的是不含 Adapty SDK 的旧版应用，Adapty 将无法接收其数据。因此，Adapty 与其他来源的数据数量将出现差异。

集成问题

部分 Adapty 集成（例如 Adjust 或 AppsFlyer）需要在应用中添加额外代码才能正常工作。如果你只在 Adapty 看板中完成了配置，但没有更新应用代码，相关数据将无法出现在 Adapty 中。

缺少历史数据

Adapty 无法访问您应用的历史数据，除非您手动导入。如果数据图表的时间范围早于您接入 Adapty 的时间，且您未导入历史数据，则图表数值将与其他来源存在差异。

数据延迟

Adapty 致力于为您的应用经济提供接近实时的分析。以下是相关限制和例外情况：

• 当您首次集成 Adapty 时，数据可能不会立即显示。
• 启用与第三方平台的集成后，数据完全同步前可能存在一定延迟。
• Adapty 收到商店数据后，还需要 15-30 分钟 进行处理，才会显示在 Analytics 页面上。
• 由于涉及的变量较多，Adapty 与第三方之间的数据交换并非总是实时的。
• 部分高级数据图表（例如同期群趋势预测）的计算需要积累一定量的数据，Adapty 只有在收集到足够数据后才会执行这些计算。

随时间变化的指标

基于同期群的指标将用户按其执行的某个操作进行分组——安装、付费墙浏览、试用开始或首次付款——然后持续追踪这些用户后续的行为。转化率、同期群、留存率和 LTV 均采用这种方式；数据图表对比表标注了哪些指标属于此类、哪些不属于。如果某用户在三月安装应用，并于七月完成订阅，则该用户会在七月提升三月的”安装到付费”转化率。

将两年前某个月与上个月进行比较，实际上是在用一个已稳定的数字对比一个尚未定型的数字。正确的做法是：在经过相同时长之后，再对各时间段的数据进行比较。

安装到试用的数据在数天内即可趋于稳定，而安装到付费和试用到付费则可能持续增长数月。在报告中比较各月数据中说明了比较前需等待多长时间。

时间与日历

日期与时区

数据出现差异，最常见的原因之一就是时区设置不同。

Adapty 按 UTC 时区计算天数。如果其他平台使用不同的时区，计算结果就会有偏差。随着统计周期拉长，这种偏差会逐渐缩小。

你可以为每个应用修改时区设置。

Apple 财年日历

Apple 使用自己的财务日历来确定销售周期和付款日期。

日历中的每个”月份”由 4 或 5 周组成，可能包含相邻日历月份的日期。付款通常在销售周期结束后 30–45 天内发放。

例如，“2026 年 1 月”的销售周期从 2025 年 12 月 28 日开始——比日历月份的起始日提前 4 天。该周期的预计付款日期为 3 月 5 日。

不要将 Apple 收款报告中的数据与自然月进行比较。请改为选择与相应销售周期对应的自定义日期范围。

交易日期

部分服务（例如 AppsFlyer）在展示交易记录时可能会应用同期群规则，将交易归因到应用的安装日期，而非交易本身的发生日期。

收入计算

费用与税款

根据设置，Adapty 数据图表可以显示您的毛收入、扣除应用商店佣金后的收入或扣除应用商店佣金及税款后的收入。

部分应用商店和第三方平台可能不支持显示毛收入，或会自动扣除税款。如果您发现两个收入数据图表之间存在差异，请确认两者的对比口径是否一致。

取消与退款

不同平台对退款数据的显示方式不同。Adapty 将退款视为负收入。如果用户订阅后次日申请退款，这两个事件都会反映在 Adapty 数据图表中——各自对应其发生的日期。其他平台可能会从原始交易中直接扣除退款金额。

沙盒购买

事件流会显示沙盒账户的购买记录，而分析数据图表则不会显示。但是，如果您的历史导入数据包含沙盒购买记录，Adapty 将无法区分，其数据图表将会反映历史沙盒购买记录。

安装与下载

应用商店（尤其是 Apple App Store）可以直接追踪用户下载数据。其统计数据可能包括已安装但从未启动应用的情况。

无论您的安装定义如何设置，Adapty 只能在用户启动应用时才能注册一次安装。

国家/地区与商店

为确保报告准确，Adapty 可能会根据 用户的 IP 地址推断其所在国家/地区。商店则始终将下载和购买行为归因到特定的应用商店。

如果需要明确区分这两者，可以使用 Country by store account 属性创建新的市场细分，并按市场细分筛选分析数据。

产品定价

如果产品定价错误导致收入差异，更改价格并不会对历史数据产生追溯效果。要更改现有交易的价格，您需要通过导入正确数据来强制覆盖。

用户在价格变更后恢复旧购买时，Apple 可能会错误报告购买金额。您需要导入历史数据，以便 Adapty 反映正确的金额。

归因冲突

Adapty 对每笔交易只能使用单一归因来源，且无法在事后覆盖此数据。

如果您的配置包含多个相互不一致的归因提供商，则同一笔交易在两个不同平台上可能显示为两个不同的流量来源。

术语差异

不同平台对同一概念可能使用不同的名称。与收入相关的数据图表在各平台之间的叫法也不尽相同：

Adapty	App Store Connect	Google Play Console
Gross revenue	Sales	Gross Revenue
Proceeds after store commission	N/A	N/A
Proceeds after store commission and taxes	Proceeds	Earnings
ARPPU	Proceeds per paying user	ARPPU

其他数据图表在定义上也可能存在差异：

• 订阅：
  • Adapty 不将新试用计入订阅。新订阅始终以实际付款交易为起点。
  • Google Play Console 等其他平台可能将每次试用都计为一个新订阅，即使尚未完成首次付款。
• 留存率：
  • Adapty 根据订阅续费次数来衡量留存率。
  • App Store Connect 将”在指定日期打开应用的用户”视为留存用户。没有订阅的用户也会被计入，但当天未打开应用的订阅用户则不会被计入。
  • Google Play Console 的”Retained Installers”指标根据应用在用户设备上的安装天数来衡量留存率，即使用户未打开应用也会被计入。

数据图表与事件的不匹配

数据图表的汇总数值与集成收到的事件数量之间存在差异，这是正常现象，并非传输失败。名称看起来相同，但定义却不一样。

新订阅数据图表与 subscription_started 事件的区别

新订阅数据图表与 subscription_started 集成事件统计的内容并不相同。“新订阅”数据图表的数值通常会高于 subscription_started 事件的数量。

区别点	新增订阅数据图表	subscription_started 事件
报告内容	某时间段内启动的订阅数量	实时记录付费订阅开始的时刻
用途	追踪新增付费用户数量	将购买行为记录到你的分析平台、MMP 或自有后端
时间逻辑	按购买日期统计，以你的报告时区为准	在购买发生时发送
试用转化	计入统计	不发送——Adapty 改为发送 trial_converted
已撤销的交易	撤销后从统计中排除	已发送，不会撤回
SDK 从未识别的用户画像	其购买行为计入统计	不出现在事件动态中

活跃订阅数据图表与 subscription_active 事件

活跃订阅数据图表与 subscription_active 集成事件的区别，不仅在于统计口径，更在于各自的用途。

差异点	活跃订阅数据图表	subscription_active 事件
报告内容	每个周期结束时存活的订阅数量	某个订阅在最初几天内存活下来
用途	跟踪订阅用户群的规模与增长	转发给 MMP，用于对留存用户进行竞价
时机	每个周期结束时重新计算	在订阅开始后的配置天数内发送，范围为 1 至 90 天
是否重复	是，每个周期都会	否——Adapty 仅检查一次，不会再次触发
试用转化	试用转为付费后计入	永不发送——计时器仅在 subscription_started 时启动，转化时发送 trial_converted
已取消续订	不计入	只要用户仍有访问权限，仍会发送
退款	移除，包括从历史日期追溯移除	如果退款先于事件发生则不发送；如果退款在事件之后发生则不会撤回
可用性	始终计算	仅在已启用该功能的集成中发送

活跃试用数据图表与 trial_active 事件的区别

活跃试用数据图表与 trial_active 集成事件的用途不同，不仅仅是统计口径有差异。

区别	活跃试用数据图表	trial_active 事件
报告内容	尚未到期的免费试用数量	试用在最初几天内未中断
用途	查看当前正在运行的试用数量	优化 MMP 出价，针对留存的试用用户
时间节点	每个周期结束时重新计算	在试用开始后的指定天数（1 到 90 天）发送
是否重复	是，每个周期都会重复	否——Adapty 只检查一次，不再重复
试用转化	持续计入直至试用转化，下一周期从统计中移除	已转化的试用不会发送此事件
可用性	始终计算	仅在你已开启的集成中发送

两者在取消订阅方面的处理一致：关闭自动续订的用户仍保留在数据图表中，事件依然会发送，直到试用期到期。

筛选后的总计超过未筛选的总计

在应用了Period筛选条件的情况下，添加产品筛选或按产品分组会改变某个周期的统计含义。在不涉及产品的情况下，Activation 统计的是一条订阅链中的第一笔付款。而一旦涉及产品，它统计的是该订阅链中每个产品的第一笔付款——因此，曾切换过产品的用户会为每个产品各贡献一次 Activation。两种视图都不会重复计算同一笔交易，它们统计的是不同的用户群体。

使用哪种方式取决于你想回答的问题：不分组查看所有产品，回答的是”我们新增了多少付费用户”；按产品筛选的视图，回答的是”有多少用户首次开始使用该产品”。取消 Period 筛选条件后，两者都可以与未筛选的总数对齐。

付费墙视图转化率下降

如果你的应用使用了 Flow Builder，付费墙视图 -> 试用 和 付费墙视图 -> 付费 的转化率在整个历史数据中都有所下降。

用户当前看到的流程界面现在会被计入付费墙浏览次数。此前，流程界面的浏览量仅单独计入流程数据图表，导致这两项比率在计算时，是用购买数除以一个未包含任何流程界面的付费墙浏览量——因此数值偏高。您现在看到的比率才是准确的。

每位用户每天仅计一次，无论他们浏览了流程中的多少个界面，也无论他们是否同时看到了通过付费墙编辑工具搭建的付费墙。