Attribution 归因常见问题

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

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

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

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

我们都知道脸书谷歌这两家也不会互通有无，那他们肯定也无法确定这位点击了两家广告的用户到底应该归功于谁，那么最终结果就是，脸书和谷歌都说这个用户归功于他们——脸书会给出一次为“1”的报告激活（Reported Installs），谷歌那边也一样，就好像下面这张图：

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

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

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

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

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

这也让您知道，在这个例子当中，您的谷歌广告活动比您的脸书活动，更有效。

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

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

  第X天的留存率=唯一第X天留存的客户数/唯一第0天激活的客户

• 我们认为使用相对时间可以使所有用户处在同一水平线上，无论用户是在哪个时区，昼夜长短如何。它还使我们能够“规范化”我们的其他生命周期指标，例如累计收入、累计 ROI 和 CPR 。

举个例子：

• 隶属于“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天留存率需要等到激活后的（X+2）天才能稳定，也就是说在（X+3）天最终确定。

等待三天才能拿到这个数值？这听上去很奇怪，而且为什么是3天？这么安排的原因是什么？

还记不记得刚才提到的小明？那个半夜23点59分激活应用的小明，他的第0天（也就是1月1日23点59分起，1月2日23点59分止这段时间），不会被记入留存；而在最极端的情况下，他在第X天的晚上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” 指的是“群组收入”，有点困惑对不对？我来给您举个例子：

假设今天是10月20号，请看下图：

在这个例子当中：

• 总收入（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分配广告收入的主要方式之一是使用SDK中的会话计数来计算LTV或ROAS。有多种逻辑可以用来分配广告收入。其中一种则是我们按照用户产生的应用会话比例（在当天、在该应用中）来为每个来源渠道分配广告收入。
• 举个例子：
  • 来自发布者 API 的数据：
    • 4/20/2016
    • Cool Game
    • 20美元的广告收入
  • 来自 Tenjin SDK 的数据:
    • 4/20/2016
    • Cool Game
    • 30个 Meta 会话
    • 40个 Google 会话
    • 30个 Twitter 会话
  • 每个渠道的预估广告收入:
    • 4/20/2016
    • Cool Game
    • $6 Meta 广告营收
    • $8 Google 广告营收
    • $6 Twitter 广告营收
• 同类广告收入稍微复杂一些，但使用相同的估算方法。 在确定应用会话比例时，还会考虑用户的激活日和生命周期的第 n 天。
• 但是，AppLovin 使用展示层级广告收入 (ILRD) 来计算 ROAS。 一般来说，根据分配逻辑，他们的 ROAS 高于 Tenjin LTV。

• TikTok面板仅显示SKAN数据来报告 iOS14的激活，而非MMP数据。具体细节可在这里查看。因此我们的跟踪激活与报告激活不匹配.

由于两个平台之间用于 ROAS 计算的方法不同，所以 Tenjin 0D ROAS 和 Mintegral 0D ROAS 之间会存在差异。

• IAA ROAS：

Tenjin 采用基于会话的聚合方法来计算广告收入 LTV 和 ROAS。 相反，Mintegral 使用基于 ILRD 的收入方法来计算 ROAS。 这种区别导致预期差异约为 30%。

• IAP ROAS：

Tenjin 根据净内购金额计算 LTV 和 ROAS（扣除 30% 或 15% 应用商店佣金后，具体取决于您在 Tenjin 中配置的商店折扣）。 相比之下，Mintegral采用总内购金额来计算ROAS，导致差异高达30%。

成功配置后，尽管存在指标上的差异，您依然可以使用 Mintegral 开启 ROAS 广告投放。

如需进一步说明或信息，欢迎联系 support@tenjin.com 。