アトリビューションFAQ

When using Tenjin, you’ll notice that there are two types of installs: Reported installsインストール指標 and Tracked Installs.

Reported installsインストール指標 are installs that the Ad Network（アドネットワーク） claims to drive for each of your campaigns. トラッキングされたインストール 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 ad networks. When looking at Tracked Installs, you are looking at an インストール metric that is holistic – it’s based on all campaigns, even ones that you’re running on other ad networks. 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 ad networks 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 ad networks 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 インストール count for Applovin would be “1” and the Reported インストール count for Tiktok would be “1” also. Here’s what we have so far:

しかし、これでは意味がありません。獲得したユニークユーザーは 1 人だけでした。ユニークユーザーはいずれかのキャンペーンにのみ関連付けられる必要があります。

That’s what アトリビューション solves. By using a 3rd party アトリビューション provider like Tenjin, Tenjin will place the user into the Tiktok campaign as a “追跡インストール（Tracked Install）” (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日間のLTV2.5ドルを生み出したとします。分析すると次のことがわかります。

この場合、ROI = (LTV/Spend -1) となります。

これにより、そのユニークユーザーにとってTiktokキャンペーンがApplovinキャンペーンよりも効果的であることがわかります。

通常、以下の理由により、SANでは最大30%程度の不一致、非SANでは最大10%程度の不一致が予想されます。

• Ad networks ignore 3rd party アトリビューション technology – Meta, Twitter, Google and a few others rely on their own internal technology to let アトリビューション partners know when an インストール 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 インストール even when the アトリビューション technology only picks one Ad Network（アドネットワーク） to associate the download with.
• インストール コールバック and click URLs are not set up properly – The most fixable of the problems is when click URLs and インストール コールバック 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 インストール 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（アドネットワーク） と アトリビューション SDKs – アトリビューション systems send インストール コールバック to ad networks to notify an Ad Network（アドネットワーク） of an インストール. If the app has a duplicate SDK that sends an Ad Network（アドネットワーク） インストール コールバック, there can be double counting of Reported installsインストール指標.
• Ad networks use a different アトリビューションウィンドウ from ours (usually for SANs).

継続率はシンプルなメトリックですが、実際の計算ではいくつかの方法があります。デフォルトの設定だと、Tenjinでは、「クラシック」計算での継続率を採用しています。N日の継続ユーザは、獲得後N日にアプリに戻ってきたユーザです。この解釈には、(1) 絶対時間 (2) 相対時間の二通りがあります。例えば、ユーザが5/1の23:59に獲得され、5/2の00:01にアプリに戻ってきた場合、２分しか経過していません。

• デフォルトの設定だとTenjinでは、相対時間での計算を採用しています。それぞれのユーザには「生涯時間」が存在して、獲得日からの日数で計算されます。獲得日時が0日の起点となり、その24時間後が1日の始まりとなります。 同様に、N日の継続ユーザは獲得日時から24 x N時間から 24 x (N+1)時間内にアプリに戻ってきたユーザとなり、N日継続率はユニークなN日ユーザ / ユニークな0日ユーザとなります。

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 インストール 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.

上記で述べたように、相対時間の定義だとN日継続ユーザーとは、獲得後24 x N時間から 24 x (N+1)時間の間にアプリに戻ってきたユーザーのことです。

おそらくこれを理解する最良の方法は、下記の例に従うことです。

• ※「9月1日」コホートに属するユーザーは、2015年9月1日 00:00から2015年9月1日 23:59までの間に獲得されたユーザ。
• 最新の「9月1日」ユーザー (ジョーと呼びます) は、2015年9月1日 23:59にアプrをインストールしました。
• ジョーの0 日目は24時間続き、2015年9月2日 23:59 に終了します。
• ジョーが 2015年9月2日 23:59 から 2015年9月3日 23:59 までの間の任意の時点でアプリに戻った場合、彼は1日継続ユーザーとしてカウントされます。
• 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日待つのは奇妙に思えるかもしれません。どう説明すればよいのでしょうか?　最悪の場合、ユーザーは1日の終わり (「1 日目」) に取得される可能性があります。彼の0日目 (最初の24 時間) はリテンション (「2 日目」) にはカウントされません。そして最悪の場合、x日目 (「3 日目」) の24 時間の終わりにアプリに戻ってくる可能性があります。

• Tenjinのアプリ内課金がiTunesコネクトやGoogleプレイコンソールの値と違うのはなぜですか?
• それ以上の差異がある場合、下記の可能性が考えられます。
• Tenjinの売上はネット表示となります(アップル/グーグルの30%ストアカット後)
• レシート検証機能を実装していない場合、TenjinがSDKから取得した全てのアプリ内課金を表示するのに対し、一部の売上がアップル/グーグルではリジェクトされている可能性があります。これを解消するには、レシート検証機能を必ず実装してください(iOS SDK)
• 直近でTenjin SDKを実装していて、アプリのアップデートがボランタリーアップデートの場合、一部のユーザはTenjin SDK実装済みのアプリをダウンロードしていないため、全ての売上情報がTenjin上に表示されません。これは時間とともに解消されます。

一般に「Revenue」という場合、コホートと非コホートの2種類のメトリクスがあります。Tenjinではこの二つを明確に区別しています。 「Revenue」は常に非コホート値であり、「LTV」は定義上常にコホート値です。例を見てみましょう。今日が10/20であると仮定します。

この例では、

• トータルRev = $94.27
• 90日トータルLTV = $91.70

これは、アプリが9月 (非コホート) にすべてのユーザー (ユーザーの獲得時期に関係なく) から94.27ドルを生成し、9月に獲得したユーザー (コホート) からライフタイムで91.70ドルを生成したことを意味します。通常、Revenueは毎日のキャッシュフローを管理するときに役立ち、LTVはキャンペーンのROIを測定するために役立ちます。

Tenjinの数字を他のツールで表示される数字と比較する場合は、この違いに注意してください。また、IAP収益 (またはLTV) と広告収益 (または LTV) も区分されているため、収益がどこから来ているかを確認できます。

Revenueは、選択した日付範囲における毎日のキャッシュフローです。

• 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 インストール.

Revenueがx日のLTVと等しくなることはあるでしょうか?

Probably not. You would need ALL users in a single UTC day (00:00 to 23:59) to have EXACTLY the same インストール date. This is extremely unlikely.

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 インストール 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 D0 ROAS and Mintegral D0 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は、ネットのIAP金額に基づいてLTVとROASを計算します (Tenjinで設定したストアカットに応じて、アプリストア手数料の30%または 15%を差し引いた後)。対照的に、MintegralはROAS計算にグロスのIAP金額を採用しているため、最大30%の不一致が生じます。

構成とセットアップが正常に完了すると、予想される差異にもかかわらず、Mintegralを使用してROAS キャンペーンを開始できるようになります。

さらに詳しい説明や情報が必要な場合は、support@tenjin.comまでお問い合わせください。

インストール時にTenjinによって生成されるUUID（Analytics Installation ID）は、デバイスレベルでは永続的ではありません。したがって、ユーザーがアプリを再インストールすると、Analytics Installation IDがリセットされ、新規インストールの数がカウントされます。これにより、再インストールの頻度によっては、Tracked Installsがわずかに増加する可能性があります。

For インストール Events: Meta usually handles インストール deduplication automatically. So if both Meta SDK and Tenjin report an インストール, it typically only counts once.

アプリ内イベント(購入、収益、広告インプレッションなど)の場合: これらは自動的に重複が除去されません。片方のソースからのみイベントを送信する：アプリ内イベントを送信するには、TenjinまたはMeta SDK のいずれか一方のみを選択してください。両方を選択しないでください。

Meta SDKで自動イベントログを無効にする： MetaのSDKを使用している場合は、autoLogAppEventsEnabledをオフにして、デフォルトで収益/購入イベントが送信されないようにして ください。