アトリビューション FAQ

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

  • Reported Installsとはアドネットワークから取得したインストール数です。
  • Tracked 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の数は次のようになります。

これで、ユニークユーザーは、キャンペーンの下流分析に使用する適切なアドネットワークキャンペーンに紐付けられました。ユーザーがLTVを生成し始めたら、スペンドの効果がどの程度であるかがわかります。これが、ROIを個別に測定できる唯一の方法です。

したがって、獲得したユーザーが 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日ユーザ

• Tenjinではこのやり方により、全てのユーザをタイムゾーンに依存しない基準で同等に評価することが可能となります。同様の計算方法は、他の生涯メトリック、LTVやROI, 継続ユーザあたりのコストでも使われています。

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

※「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はアプリ内課金をSDKから直接取得しているのに対し、iTunesコネクトやGoogleプレイコンソールではストアの課金情報を直接表示しています。経験上これらの値は約20%程度ずれる傾向があります。

• それ以上の差異がある場合、下記の可能性が考えられます。

  1. Tenjinの売上はネット表示となります(アップル/グーグルの30%ストアカット後)
  2. レシート検証機能を実装していない場合、TenjinがSDKから取得した全てのアプリ内課金を表示するのに対し、一部の売上がアップル/グーグルではリジェクトされている可能性があります。これを解消するには、レシート検証機能を必ず実装してください(iOS, Android)
  3. 直近で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は広告収益LTVの計算方法の一つとして、SDKからのセッション数を使用して広告収益を割り当てる方法を採用しています。ユーザーが（その日にそのアプリで）生成したアプリセッションの割合を使用して、各ソースチャネルに割り当てる広告収益を見積もります。

• 例,
  • パブリッシャー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）を使用してLTVまたはROASを計算します。一般的に、それらのROASは、割り当てロジックに基づくTenjin ROASよりも若干高くなります。

• TikTokは、こちら で説明されているように、iOS 14キャンペーンではMMPインストールではなくSKAN インストールをレポートするため、tracked_installsと reported_installsとは正確には一致しません。

TenjinとTikTokのアトリビューションの詳細な違いは こちら をご覧ください。

2つのプラットフォーム間でROASの計算に使用される手法が異なるため、Tenjin 0D ROASと Mintegral 0D ROASの間に差異が生じることが予想されます。

• 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までお問い合わせください。