关于归因的常见问题

When using Tenjin, you’ll notice that there are two types of installs: Reported installs 报告安装 and Tracked Installs.

Reported installs 报告安装 指的是广告渠道声称您的广告活动在他们的平台上所带来的激活；而 跟踪激活 are installs that an unbiased 3rd party attributes to an ad network’s campaign, taking into account the other campaigns you’re running on other 广告网络. When looking at Tracked Installs, you are looking at an Install 安装 metric that is holistic – it’s based on all campaigns, even ones that you’re running on other 广告网络. Reported installs 报告安装, on the other hand, is calculated in a vacuum by the ad network you’re running on – it’s only based on what that ad network sees.

So are Reported installs 报告安装 supposed to be the same as Tracked Installs? Not always. The point of 归因 ISN’T to make Tracked Installs = Reported installs 报告安装. In fact, sometimes 归因 is supposed to do the exact opposite. The point of 归因 is to take a holistic view of ALL the campaign activity on the various 广告网络 you’re using at the same time, and attribute users to the most appropriate campaign. Only an unbiased 3rd party can do this.

有点困惑对不对，我给您举一个例子： You’re running campaigns on two 广告网络 at the same time, Applovin and Tiktok. You set the CPIs to $1.00 for each campaign on each ad network. A unique user clicks on your Applovin campaign, then later that same user clicks on your Tiktok campaign, then installs the app. What happens? How is everything tracked for that user?

Since Applovin and Tiktok don’t talk to each other, there is no way for them to reconcile the unique user interacting with both ad campaigns on separate networks at the same time. As a result, the Reported Install 安装 count for Applovin would be “1” and the Reported Install 安装 count for Tiktok would be “1” also. Here’s what we have so far:

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

That’s what 归因 solves. By using a 3rd party 归因 provider like Tenjin, Tenjin will place the user into the Tiktok campaign as a “追踪安装” (based on the last click in this case). This way, the unique user who clicked on Applovin and then Tiktok will be associated with Tiktok’s campaign and NOT Applovin’s. In this example the count for Tracked Installs and Reported installs 报告安装 would look like this:

Now the unique user is in the appropriate ad network campaign for downstream analysis of your campaigns. If the user starts generating LTV, then you know what the effectiveness of your Spend 花费 is. This is the only way you can measure your ROI 投入产出分析 on an apples-to-apples basis.

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

In this case ROI 投入产出分析 = (LTV/Spend 花费 -1).

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

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

• 广告网络 ignore 3rd party 归因 technology – Meta, Twitter, Google and a few others rely on their own internal technology to let 归因 partners know when an Install 安装 should be awarded to their networks. When users for these networks overlap, the 3rd party technology can’t control if the ad network claims a Reported Install 安装 even when the 归因 technology only picks one ad network to associate the download with.
• Install 安装 Callbacks(回传） and click URLs are not set up properly – The most fixable of the problems is when click URLs and Install 安装 Callbacks(回传） are set up improperly by the advertiser. This can usually get fixed right away by double checking that the proper click URLs are getting used and the Install 安装 callback in the 归因 technology is functioning properly.
• Inaccurate methods for tracking clicks and installs are used with ad network SDKs – When an ad network does not support collection of an advertising ID (IDFA or GAID), then the 3rd party 归因 technology will generally rely on probablistic 归因.
• Doubling up on ad network and 归因 SDKs – 归因 systems send Install 安装 Callbacks(回传） to 广告网络 to notify an ad network of an Install 安装. If the app has a duplicate SDK that sends an ad network Install 安装 Callbacks(回传）, there can be double counting of Reported installs 报告安装.
• 广告网络 use a different 归因窗口 from ours (usually for SANs).

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

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

the N-day 留存率 = unique N-day retained users / unique 0-day users

• We believe using relative time puts all users on equal footing, no matter what time zone they may be in, or what their circadian rhythm might be. It also enables us to “normalize” our other lifetime metrics, such as cumulative revenue, cumulative ROI 投入产出分析, and cost-per-retained user. (NOTE) Tenjin now supports 留存率 calculation using the UTC-based cohort strategy. With this approach, Day 1 begins at the first UTC midnight following each user’s Install 安装 timestamp. This method helps align 留存率 calculations with other platforms that use UTC-based timestamps, reducing discrepancies in metrics.

To enable this feature for your account, navigate to My Account → Manage User → Cohort Strategy and select the desired option.

上一个问题我们提到的定义：X日保留用户指的是在激活X个24小时之后，（X+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分之间返回了应用，我们就叫他“一日留存用户”；
• Therefore, the 1-day 留存率 for the “Sept 1” cohort is not finalized until 2015-09-04 00:00.

In general, the x-day 留存率 for a given cohort is not finalized until AFTER (x+2) FULL days after acquisition. Or in other words, on the (x+3)th day it will remain constant.

等待三天才能拿到这个数值？这听上去很奇怪，而且为什么是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” 指的是“群组收入”，有点困惑对不对？我来给您举个例子：

在这个例子当中：

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

This means the app generated $94.27 from all users (regardless of when those users were acquired) in September (non-cohort), and the app generated $91.70 in the lifetime from the users that were acquired in September (cohort). Revenue is usually useful when you manage daily cashflow and LTV is to measure your campaign ROI 投入产出分析.

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

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

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

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

• It is important to know what “today” is, in relation to the selected date range because you need to know how “old” the included users are. If today is Oct 20 and the given date range is Sept 1-30, your “oldest” users are 50 days old (Oct 20 minus Sept 1), and your “youngest” users are 20 days old. The 90-day LTV total of $91.70 is all the revenue generated by users in 30 cohorts (each day of September). Consequently, given this date range in the example, 50-day LTV, 51-day LTV …, 89-day LTV, and 90-day LTV would all be the same value, since your oldest users are only able to generate 50 days of revenue after the Install 安装.

收入是否等于 X 天 LTV?

Probably not. You would need ALL users in a single UTC day (00:00 to 23:59) to have EXACTLY the same Install 安装 date. This is extremely unlikely.

The assumption here is that your app is based on in-app ads.

• Currently, one of the main ways Tenjin allocates ad revenue is by using the sesion counts from SDK to calculate LTV or ROAS. This total must be somehow distributed and assigned to each user’s source channel. We use the proportion of app sessions generated by the user (on that day, in that app) to estimate how much ad revenue to assign to each source channel.
• 举个例子：
• Data from publisher 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 天。
• However, AppLovin uses impression-level ad revenue(ILRD) to calculate LTV or ROAS. In general, their ROAS is higher than Tenjin ROAS based on the allocation logic.

We now support Ad Mediation LTV and ROAS. You can use the Ad Mediation ROAS metric from the Tenjin dashboard which will be closer to your Applovin MAX ROAS. Details 这里.

• TikTok 报告的是 SKAN 安装量而非 MMP 安装量（适用于 iOS 14 活动的 SKAN 方案，详见 这里 说明），因此我们的 tracked_installs 数据存在差异，相比于 reported_installs.

具体细节可在这里查看。

Discrepancy between Tenjin DAU and Firebase DAU numbers are expected as the logic used for counting and tracking installs and DAU is different in both platforms. In Tenjin, we use the first app_open event as the Install 安装 event and all subsequent app_open events are recorded for sessions. It is also recommended to always use the latest Tenjin SDK and initialize it on every OnResume. If you continue to see large data discrepancies, email us at support@tenjin.com with details to investigate further.

A discrepancy between Tenjin 0D ROAS and Mintegral 0D ROAS is expected due to the different methodologies utilized for ROAS calculations between the two platforms.

• IAA ROAS:

Tenjin employs a 会议-based aggregation method to compute Ad revenue LTV and ROAS. Conversely, Mintegral used the ILRD-based revenue approach for its ROAS calculations. This distinction leads to an expected discrepancy of approximately 30%.

• IAP ROAS:

Tenjin calculates the LTV and ROAS based on the net IAP amount (after 30% or 15% app-store commission, contingent upon the store-cut you’ve configured in Tenjin). In contrast, Mintegral adopts the gross IAP amount for its ROAS calculations, resulting in a discrepancy of upto 30%.

Upon successful configuration and setup, you should be able to start ROAS campaigns with Mintegral, despite the expected discrepancies.

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

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

For Install 安装 Events: Meta usually handles Install 安装 deduplication automatically. So if both Meta SDK and Tenjin report an Install 安装, it typically only counts once.

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

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