アトリビューションFAQ

Tenjin上では二種類のインストールが存在します。(1) Reported Installs (2) Tracked Installs　です。

Reported installsインストール指標 とはアドネットワークから取得したインストール数です。 トラッキングされたインストール とは、特定のネットワークのキャンペーンに対し、アトリビューションプロバイダが計測したインストールで、他ネットワーク上のキャンペーンを考慮した数値になります。 Tracked Installsはより公平なインストールの数値である一方、Reported Installsはアドネットワークが確認できたインストールのみを元にした数値となります。

では、Tracked InstallsはReported Installsと同じであるはずですか? では、Tracked InstallsはReported Installsと同じであるはずですか?

例: あなたは、ApplovinとTiktokという2つのアドネットワークで同時にキャンペーンを実行しています。各アドネットワークのキャンペーンごとにCPIを1.00ドルに設定します。ユニークユーザーが Applovinキャンペーンをクリックし、その後、同じユーザーがTiktokキャンペーンをクリックして、アプリをインストールします。何が起こるのですか？そのユーザーのすべてはどのようにトラッキングされますか?

ApplovinとTiktok は相互に通信しないため、別々のネットワーク上で両方の広告キャンペーンを同時に操作するユニークユーザーを調整する方法はありません。その結果、ApplovinのReported Installsは「1」となり、TiktokのReported Installsも「1」になります。これまでに得られたものは次のとおりです。

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

それはアトリビューションが解決するものです。Tenjinのようなサードパーティのアトリビューションプロバイダーを使用することで、Tenjinはユーザーを「Tracked Installs」としてTiktokキャンペーンに配置します (この場合は最後のクリックに基づいて)。こうすることで、ApplovinをクリックしてからTiktokをクリックしたユニークユーザーは、ApplovinではなくTiktokのキャンペーンに関連付けられます。この例では、Tracked InstallsとReported Installsの数は次のようになります。

それはアトリビューションが解決するものです。Tenjinのようなサードパーティのアトリビューションプロバイダーを使用することで、Tenjinはユーザーを「Tracked Installs」としてTiktokキャンペーンに配置します (この場合は最後のクリックに基づいて)。こうすることで、ApplovinをクリックしてからTiktokをクリックしたユニークユーザーは、ApplovinではなくTiktokのキャンペーンに関連付けられます。この例では、Tracked InstallsとReported Installsの数は次のようになります。

したがって、獲得したユーザーが 90日間のLTV2.5ドルを生み出したとします。分析すると次のことがわかります。

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

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

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

• アドネットワークはサードパーティのアトリビューションテクノロジーを無視します。Meta、Twitter、Googleおよびその他のいくつかの企業は、独自の内部テクノロジーを利用して、アトリビューションパートナーにネットワークへのインストールがいつ付与されるべきかを知らせます。これらのネットワークのユーザーが重複している場合、アトリビューションテクノロジーがダウンロードを関連付けるアドネットワークを1つだけ選択する場合でも、サードパーティテクノロジーはアドネットワークがreported installsを主張するかどうかを制御できません。
• インストール コールバックとクリックURLが適切に設定されていない - 最も修正可能な問題は、クリック URLとインストールコールバックが広告主によって不適切に設定されている場合です。通常、この問題は、適切なクリックURLが使用されているか、アトリビューションテクノロジーのインストール コールバックが適切に機能しているかを再確認することですぐに修正できます。
• クリックとインストールをトラックするための不正確な方法がアドネットワーク SDKで使用されている - アドネットワークが広告ID (IDFAまたはGAID) の収集をサポートしていない場合、サードパーティアトリビューションテクノロジーは通常、確率論的アトリビューションに依存します。
• アドネットワークとアトリビューション SDKの重複 - アトリビューションシステムは、インストールコールバックをアドネットワークに送信して、広告ネットワークにインストールを通知します。アプリにアドネットワークインストールコールバックを送信する重複したSDK がある場合、Reported Installs数が二重にカウントされる可能性があります。
• アドネットワークが、当社とは異なるアトリビューションウィンドウ (通常はSAN) を使用している場合。

継続率はシンプルなメトリックですが、実際の計算ではいくつかの方法があります。デフォルトの設定だと、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日ユーザとなります。

N日継続率 = ユニークなN日継続ユーザ/ユニークな0日ユーザ

• 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 Retention Rate 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 retention rate 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日継続ユーザーとしてカウントされます。
• ※ したがって、「9月1日」コホートの1日継続率は、2015年9月4日 00:00まで確定しません。

一般に、特定のコホートのx日継続率は、ユーザ獲得後 (x+2) 日後まで確定されません。言い換えれば、(x+3) 日目には一定のになります。

この指標が安定するまで丸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日間の累計として表示されます。

• 含まれるユーザーの「年齢」を知る必要があるため、選択した日付範囲に関連して「今日」が何であるかを知ることが重要です。今日が10月20日で、指定された日付範囲が9月1日から9月30日の場合、「最も古い」ユーザーは50日経過し (10月 20日から9月1日を引く)、「最も若い」ユーザーは20日経過しています。 90日間の LTV合計91.70ドルは、30コホート (9月の各日) のユーザーによって生み出された収益のすべてです。したがって、この例のこの日付範囲では、最も古いユーザーは50 日分のデータしか生成できないため、50日のLTV、51日の LTV ...、89日の LTV、および90 日の LTV はすべて同じ値になります。

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

おそらくそうではありません。 1つのUTC日(00:00から23:59) のすべてのユーザーのインストール日がまったく同じである必要がありますが、これは非常に可能性が低いです。

インストールのカウントとトラッキングに使用されるロジックが両方のプラットフォームで異なるため、Tenjin DAUと Firebase DAUの間の不一致が予想されます。 Tenjinでは、最初のアプリ起動イベントをインストールイベントとして使用し、後続のすべてのアプリ起動イベントが記録されます。また、常に最新のTenjin SDKを使用し、`OnResume`ごとにSDKを初期化することをお勧めします。引き続き大きなデータの不一致が見られる場合は、support@tenjin.comまで詳細をメールでお問い合わせください。

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は、セッションベースの集計方法を採用して、広告収益のLTVとROAS を計算します。逆に、MintegralはROAS計算にILRD ベースの収益アプローチを使用しました。この違いにより、約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がわずかに増加する可能性があります。

インストールイベントの場合: Meta SDKは通常、インストールの重複を自動的に処理します。そのため、Meta SDKとTenjinの両方でインストールがレポートされた場合、通常は1回しかカウントされません。

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

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