关于归因的常见问题

当您在使用 Tenjin 的时候，您会留意到两种不同的激活：Reported Installs（报告激活）以及Tracked Installs（跟踪激活）

Reported Installs（报告激活）指的是广告渠道声称您的广告活动在他们的平台上所带来的激活；而Tracked Installs（跟踪激活）指的是一个公正的第三方归因服务商，综合考虑您所有广告活动在各个广告渠道的表现，最终给出的真实激活情况。当查看Tracked Installs（跟踪激活）的时候，实际上这是一个综合评定后的数据，也就是说安装判定会综合考虑你在各个广告渠道上所有相关的广告活动；而Reported Installs（报告激活），它基于单个广告渠道的计算，而并不会考虑您在其他广告渠道的投放。简单说就是--广告渠道说多少激活，就是多少激活。

这里存在一个问题：Tracked Installs（跟踪激活）是否会和Reported Installs（报告激活）相等？
答案是不确定的，归因这件事并不是在追求两者的数值相等，某种情况下甚至还要认可它们的不相等。归因的核心在于全面了解您在每一个广告渠道上进行的每一个广告活动，将每一个用户归因于那个真正起效果的活动——而这正是Tenjin的强项。

有点困惑对不对，我给您举一个例子： 有一天您正在处理两个广告渠道上的同一个广告活动：Meta 和 Google。这时候有一名用户点击了脸书上的广告，然后他/她又打开了谷歌，点击了同一款应用的广告，最终他/她下载了应用，激活的成本都是 1 美金。问题来了：这一次下载算是脸书的，还是谷歌的？怎么去追踪这个用户的全部行为？

由于Applovin和TikTok之间不存在数据互通机制，无法识别同一用户在两个独立平台同时参与广告活动的行为。因此，Applovin报告的安装量将显示为“1”，TikTok报告的安装量同样显示为“1”。目前情况如下：

但是这就讲不通了对不对？我们只收获了一个用户对不对？而这个用户必须被归属到其中一个广告渠道中去！

这就是 Tenjin 能提供帮助的地方，通过和我们这样的第三方归因厂商合作，我们会公平地将这个用户判给真正起作用的广告渠道，假设这个用户被判给谷歌了（依据最终点击原则），而这位用户所带来的激活就是Tracked Installs（跟踪激活）。所以，这位点击了脸书广告又点击了谷歌广告的新用户，他/她应该被归属于谷歌的广告活动，而非脸书的，就像下图：

OK，现在这个用户已经归因完成，接下来就可以针对这次广告活动做进一步分析，如果这个用户开始产生 LTV ，您就会知道这次广告活动的效果。这也是在同样情况下衡量 ROI 的唯一办法。

假设这名用户带来了90天2.5美元的 LTV ，我们会得到分析如下图：

在这种情况下， ROI = ( LTV /花费（spend） -1)。

这表明对于该特定用户而言，您的tik tok广告活动比Applovin广告活动更有效。

一般来说，两者在自归因渠道的差异可能会达到30%，而非自归因渠道的可能达到10%。这主要是因为以下几个原因：

• 广告渠道往往忽视了第三方归因公司的能力：
  Meta、Twitter、Google 以及其他几个背靠于自身强大的技术让归因厂商接受哪次激活应该归属于他们。但是当用户同时使用了这些渠道，第三方技术就难以控制这次激活到底应该归属于哪家渠道。
• 激活回调和 URLs 没有设置好：
  最常见的错误是您的激活回调和URLs没有设置好。这个问题要解决很简单，只需要重复检查一下两者是否正确，是否正常运行即可。
• 不准确的跟踪点击/激活和广告渠道SDKs一起使用了：
  当一个广告渠道并不支持收集用户信息（例如 IDFA 或者 GAID ），那么第三方归因公司只能通过概率归因来确定用户。
• 过度使用了广告渠道以及归因SDKs：
  归因公司会发送激活回调给广告渠道，如果应用内有一个 SDKs 又发送了一次激活回调给渠道，那么报告激活可能会被记录两次。
• 广告渠道使用了与我们不同的归因（通常出现在自归因渠道）。

“留存率”是个很简单的概念，但是在应用它的时候有不少需要注意的细节。在 Tenjin ，我们一般会计算“传统留存率”：第X天留存用户指的是激活X天之后依旧打开应用的用户，这么定义的话似乎很简单，但是其中存在两个不同的理解方式：
（1）用户留存的绝对时间；
（2）用户留存的相对时间。
我们以（1）用户留存的绝对时间举个例子，假如有名用户在1月1日激活应用，并且在1月2日返回，这叫“一日用户”，但是如果这个用户是在1月1日的晚上23点59分激活，并且在1月2日的0点01分返回，这名用户实际上只隔了两分钟就返回了，这时候还叫他/她“首日留存用户”就不准确了。

• 在 Tenjin ，我们默认用的是相对时间。每一个用户都有自己的“生命周期”——从首次激活后开始计算。用户的“生日”就是第0天，24个小时后才是第一天，第N天留存用户指的就是在N个自然24小时之后，（N+1）个自然24小时之前依旧留存的用户。

N 天留存率 = N 天回归用户 / 第 0 天用户

• 我们认为采用相对时间能让所有用户处于平等地位，无论身处哪个时区或遵循何种生物节律。这同时使我们能够对其他生命周期指标进行标准化处理，例如累计收入、累计投资回报率以及每保留用户的成本。
  
  注意:Tenjin现已支持基于UTC时区的用户群组策略计算留存率。该方法将第1天定义为用户安装时间戳后的首个UTC午夜。此方案有助于使留存率计算与采用UTC时间戳的其他平台保持一致，减少指标差异。

要为您的账户启用此功能，请前往My Account → Manage User → Cohort Strategy，然后选择所需选项。

上一个问题我们提到的定义：N日保留用户指的是在激活N个24小时之后，（N+1）个24小时之前依旧留存的用户。

举个例子：

• 隶属于“1月1日“这个群体的用户指的是在1月1日零点后，1月1日晚23点59分这个时间段内激活的用户；
• 最后一个“1月1日”用户（暂且叫他小明）可能正好是在1月1日晚23点59分激活的；
• 小明的“第0天”指的是1月1日23点59分起，1月2日23点59分止这段时间；
• 如果小明在1月2日23点59分到1月3日23点59分之间返回了应用，我们就叫他“一日留存用户”；
• 然而，“1月1日”这个群体的“一日留存率”得等到1月4日的0点才算得出来。

简单来说，某个群体用户的X天留存率需要等到激活后的（N+2）天才能稳定，也就是说在（N+3）天最终确定。

等待三天才能拿到这个数值？这听上去很奇怪，而且为什么是3天？这么安排的原因是什么？ 还记不记得刚才提到的小明？那个半夜23点59分激活应用的小明，他的第0天（也就是1月1日23点59分起，1月2日23点59分止这段时间），不会被记入留存；而在最极端的情况下，他在第N天的晚上23点59分返回。

• Tenjin 直接从您的 SDK 中收集 IAP 收入，而 iTunes connect 或 Google play 控制台直接通过商店购买显示其数量。根据我们的经验，这些收入最多可能相差 20%。
• 如果您发现差异很大，则可能会出现这些情况：
• Tenjin 显示的收入是净值（在 Apple/Google Play 商店削减 30% 之后）；
• (仅适用于 iOS)如果您不验证收据，Tenjin 会计算通过我们的 SDK 传递的所有收入。 但部分收入可能会被苹果拒绝。 为避免这种情况，请确保使用我们的收据验证 (iOS SDK)
• 如果您新集成了我们的 SDK，并且自愿更新应用的，那么部分用户还没有 Tenjin SDK。 在那种情况下，您不会在 Tenjin 中看到所有收入。 随着时间的推移，这应该会消失。

当我们在讨论“收入”的时候，我们一般讨论的是两类收入：“同群组收入”和“非同群组收入”，在 Tenjin，对这两者我们有非常清晰的区分标准：“收入”一般指的是“非同群组收入”，而 “LTV” 指的是“群组收入”，有点困惑对不对？我来给您举个例子：

在这个例子当中：

• 总收入（Total Rev） = $94.27
• 90天内总 LTV（90-day Total LTV） = $91.70

这意味着咱们这个应用在 9 月份（非群组）从所有用户（无论这些用户是何时获得的）中产生了 94.27 美元，并且该应用在整个 LTV 中从 9 月份获得的用户（队列）中产生了 91.70 美元。 当您管理每日现金流时，收入通常很有用，而 LTV 通常用于衡量您的广告系列投资回报率。

当您将 Tenjin 里面的与您在其他工具中看到的数字进行比较时，请注意这一差异。 我们还将 IAP 收入（或 LTV）和广告收入（或 LTV）分开，因此您可以更好地了解您的收入来源。

收入指的是选定日期范围内的现金流。

• 还是以上一个问题给出的例子，日期范围选择在9月1日到9月30日，所有用户在该日期范围内发生的应用活动（IAP 或广告收入）产生了 94.27 美元的收入。

x 天 LTV 是在选定日期范围内获得（激活应用）的用户产生的收入，作为激活应用程序后 X 天的累计总和。

• 选定日期范围、知道“今天”是什么日子是非常重要的，因为您必须要知道您的用户激活应用多久了。假如今天是10月20号（还是沿用上面的例子），选定的日期范围是9月1日到9月30日，那么激活时间最长的用户已经有50天这么久（9月份的30天加上10月份的20天）并且激活时间最短的用户也有20天（就10月份这20天）。90 天的 LTV ，总计 91.70 美元，是 30 个队列（9 月的每一天）中用户产生的所有收入。因此，给定例子中的这个日期范围，50 天 LTV、51 天 LTV ……、89 天 LTV 和 90 天 LTV 都将是相同的值，因为您最老的用户只能产生 50 天的 安装后的收入。

收入是否等于 X 天 LTV?

可能不会。 您需要在一个自然日（00:00 到 23:59）内的所有用户都具有完全相同的安装日期。 这是极不可能的。

Tenjin DAU 和 Firebase DAU 之间的差异是预料之中的，因为用于计算和跟踪激活的逻辑以及两个平台的 DAU 是不同的。在 Tenjin 中，我们使用第一个 app_open 事件作为激活事件，并为会话记录所有后续的 app_open 事件。 我们还建议始终使用最新的 Tenjin SDK 并在每次 OnResume 时对其进行初始化。

Tenjin 在应用安装时生成的 UUID（分析安装 ID）不会在设备上持续存在。因此，当用户重新安装应用时，分析安装 ID 会重置，导致新安装次数增加。这可能因重新安装频率而略微增加追踪安装数。这将导致新增用户数量有所增加，具体取决于用户重装的频率。

对于安装事件： Meta通常会自动处理重复安装。因此，如果Meta SDK和Tenjin都报告了安装事件，通常只会计算一次。

对于应用内事件（如购买、收入或广告展示）： 这些不会自动去重。您需要选择从Tenjin或Meta SDK发送应用内事件，不能同时选择两个。

禁用Meta SDK中的自动事件日志： 如果您使用的是Meta SDK，请关闭 autoLogAppEventsEnabled，停止默认发送收入/购买事件。