ビットを失うまでの価値はある？シングルソースモデルによるiOS 14.5以降のアトリビューションの真実

モバイルマーケターと広告主にとって、iOS 14.5以降の計測はより複雑になっています。2020年6月に初めてiOS 14が発表されてからというもの、モバイル計測パートナー（MMP）とアナリティクスプラットフォームは、iOSにおける計測を支援するソリューションを開発してきました。Adjustはこれらの変更点に対応し、データプライバシーを重視しつつクライアントの成長加速をサポートする次世代のソリューションを構築しています。

Adjustでは、デバイスレベルのデータとSKAdNetwork（SKAN）データを活用する、精度の高い、包括的な表形式レポートを作成することに重点を置いています。一方で、一部の同業他社のソリューションは「オールインワン」または「シングルソース」のアプローチを採用しています。これは、App Tracking Transparency（ATT）フレームワークでアトリビュートされたインストールを使用して、SKANフレームワークでアトリビュートされたインストール間の重複を予測するものです。理論上は何の問題もないように聞こえますが、実際は大きな欠陥があります。特に問題なのは、1ビットが丸ごと失われる点です。

SKANインストールとATTインストールの重複を予測することで、どのSKANインストールがすでにATTによってアトリビュートされたかを確認するのは、理論上可能です。これはつまり、集計データレベルで、SKANインストールの合計数 = モバイル計測プロバイダー（MMPがレポートする）ペイドインストールの合計数を確認することが可能であることを意味します。2つのデータセット間に予期せぬ差異があることも確認できるでしょう。しかし、差異が生じてもその対処方法はありません。つまり、数字が一致しないことを証明するためだけに大切なビットを無駄にすることになります。

2つの例を見てみましょう

はじめに、私たちが「False Hope — 偽りの希望」と呼ぶ例を紹介します。

1. 期間：2022年7月

   MMPペイドインストール数：80,000

   MMPオーガニックインストール数：40,000

   SKANインストール数：100,000、アトリビュートされたビットを使用したところ80,000が1を返した（=アトリビュートされた）

   この場合、ユーザー獲得（UA）マネージャーはすべてのSKANインストールがアトリビュートされたと思いこみ、MMPも同じ数のペイドインストールを示していることから、正しい数がレポートされていると誤解する恐れがあります。しかし、これは間違いです。一見、インストール数は一致しているようにも見えますが、もう少し深く掘り下げる必要があります。仮に、80,000のアトリビュートされたSKANインストールのうち、40,000がFacebookにアトリビュートされ、残り40,000が最小限のキャンペーン情報でGoogleにアトリビュートされたとしましょう。一方で、MMPはFacebookに20,000、Googleに20,000、Webキャンペーン（現在はSKANでのアトリビューション不可）に20,000、AppLovinに20,000がアトリビュートされたとレポートしています。つまり、合計数は一致しているものの、アトリビュートされたパートナーが食い違っているのです。MMPを介してアトリビューション期間の相互参照を行うことは可能ですが、SKANのアトリビューション期間が確認できないため、2つのデータセットを正確に比較することはできません。合計数が一致しているからといって、それが必ずしも「信頼できる唯一の情報源」という訳ではないのです。

2. 次に、私たちが「The Dead End — 行き止まり」と呼ぶ、より典型的な例を紹介します。

   期間：2022年7月

   MMPペイドインストール数：80,000

   MMPオーガニックインストール数：40,000

   SKANインストール数：60,000、アトリビュートされたビットを使用したところ40,000が1を返した（=アトリビュートされた）

   この場合、UAマネージャーは、MMPがペイドインストールとしてレポートしたインストール数の半分だけがSKANの合計数に含まれていることがわかります。その後UAマネージャーは、残りの40,000という「行方不明の」インストールが、SKANが対応していないキャンペーン（Web、メール、インフルエンサーキャンペーンなど）のものかどうかを確認します。例えば、MMPが50,000を複数のWebキャンペーンに、20,000をGoogleに、10,000をFacebookにアトリビュートしたとしましょう。GoogleとFacebookには、それぞれ30,000のSKANインストールがアトリビュートされました。これらの数字をどのようにマッピングしたらいいのでしょうか？SKAN側で行方不明の40,000は、Webキャンペーンの50,000と一致しません。また、SKANとMMPがレポートしたGoogleとFacebookのアトリビューション数がそれぞれ大きく違っているのはなぜでしょうか？ 理論上は、MMP側の計測データについては具体的に調査できますが、SKAN側では同じことができません。つまり、「行き止まり」の状態です。

シングルソースモデルから理論上予測できるパフォーマンスKPIは、全体のeCPI（実質インストール単価）、CPE（エンゲージメント単価）、ROAS（広告費の回収率）ですが、精度に関して本質的な制限があるため、パフォーマンスの予測に使用する計算式に基づいてキャンペーンを最適化（スケーリング、一時停止、停止）することは決しておすすめできません。精度の制限については、以下で詳しく説明します。

簡単にまとめると、シングルソースモデルは、両フレームワークのiOSインストール数の合計を予測したもの（数が大きくあくまで概数）を提供するものの、その代償としてビットを失うことになります。

シングルソースモデルでは、6番目の一番大きい値のビットがTRUE/FALSEフラグに割り当てられるため、イベントや収益範囲条件のマッピングに使用可能な63のconversion valueの半分が失われてしまいます。これをバイナリー（2進法）で表すと次のようになります。

オールインワンモデルとシングルソースモデルは、精度が求められるエコシステムにおいて、「推定」に依存し過ぎているアプローチです。ここからは、オールインワンモデルとシングルソースモデルで行われる主な推定を4つ挙げ、それぞれの問題について説明します。

1. 複数の異なる不明な予測モデル：合計インストール数の計算式は、SKAN経由かつATTフラグ付きでアトリビュートされたペイドインストールの数が、ATTフレームワークでアトリビュートされたペイドインストールの合計数と同じだと想定します。Adjustは、経験上それが誤りであることを知っています。理由は以下のとおりです。

• 一致したデータを得るには、キャンペーンパートナーが両方のフレームワークをサポートしている必要がありますが、現時点でインフルエンサーキャンペーンやWebトラフィックなどはサポートされていません。
• API連携パートナーは、ユーザーの同意がなくATTフレームワークのインストールを主張できないことがありますが、まったく同じユーザーがSKANフレームワークでAPI連携パートナーにアトリビュートされる可能性が非常に高いです（ユーザーの同意の有無に関係なくアトリビューションが発生するため）。
• エンゲージメント情報とSKANのアトリビューション ウォーターフォール モデルを検証できないため、インストールが特定のパートナーにどのようにアトリビュートされたかを調べることができません。
• SKANとATTのアトリビューション期間が異なります。

2. フレームワークごとのパートナーアトリビューション：SKANがインストールを特定のパートナーにアトリビュートした場合、MMPも同様にアトリビュートすると仮定し計算されます（前述したように、インストールがATTフレームワークでアトリビュートされたかどうかの情報を持つビットにパートナーソースは含まれません）。つまり、肯定も否定もできない情報のため、信頼に足りません。また、合計数だけを見ているため、どちらかの側のインストール数が均等になると想定することもできますが、1.で述べたように、これは両方のフレームワークでまったく同じパートナーとキャンペーンを実施していることが前提です。つまり、パートナーに関する情報に乖離があると、状況は複雑になります。SKANの仕組みを考えると、このような状況は決して珍しいことではありません。広告主は、ATTフレームワーク内で内部マーケティングキャンペーン（クロスプロモーション、メールマーケティング、インフルエンサーキャンペーン、モバイルWebキャンペーン）のみを実施するしかありません。ただし、シングルソースモデルでは、ATTインストールもアトリビューションフラグ「true」で送信され、インベントリの重複によりSKANが同一のデバイスを広告ネットワークにアトリビュートした場合、ATTフラグを含むSKANインストールの合計に追加されます。つまり、ATTペイドインストール = SKANペイドインストール（ATTフラグを含む）と想定することはできず、算出された全体のeCPIまたはROASは不正確なものになります。

3. インストール日：インストール日は、ポストバックに具体的なタイムスタンプが含まれないため、SKAN側においても推定値でしかありません。この推定値は、使用されるCV期間と、ポストバックにゼロでないCVが含まれるかどうかに基づいて算出されます。ここでの大きな問題は、Googleの場合、他の全パートナーの場合と同様に、SKANのタイムスタンプにGoogleがポストバックを受け取った日が含まれていないことです。代わりに、タイムスタンプにはエンゲージメントが行われたと推定される日が含まれます。これも、Googleによる推定です。そのため、Googleが「エンゲージメントが発生した」と推定する時間からSKANのインストール日を推定する必要があります。これもまた、推定に依存し過ぎていると言わざるを得ません。

4. プライバシー規定：シングルソースの計算をしようとすると、Appleのプライバシー規定によってさらに複雑な問題が生じます。SKANからパートナーに送信される一部のポストバックにはCV=nullが含まれます。つまり、「このSKANインストールはATTフレームワークでアトリビュートされたものか？」という問いに答えるのに必要な情報をポストバックから得られないということです。null値を返すポストバックの割合は、パートナーやキャンペーンによって大きく異なり（~10%〜40%）、あるキャンペーンが他のキャンペーンよりnull値の割合が大きい理由は必ずしも明らかではありません。Appleのプライバシー規定に抵触するかどうかを決定するのは、Appleのみです。SKANのペイドインストール（ATTフラグを含まない）に関しては、プライバシー既定がどう適用されるかが曖昧であるため、乗算係数で推定する方法がなく推定の域を超えません。

iOSキャンペーンデータのシングルソース/オールインワンのアプローチは、あまりにも多くの推定に基づいています。現在アプリマーケティング市場で提供されているSKANとATTのデータを組み合わせるソリューションは、いくつもの推定に依存しており、クライアントが使用できるconversion valueの半分を犠牲にしています。精度が低くアクションにつながらないデータと引き換えにビットを失うのは無駄です。アプリを成長させるために最適化されたデータが必要なのであれば、安直な手法に頼ってはいけません。予算をどこに配分するか、どのキャンペーンを一時停止/スケーリングするか、どのチャネルに力を入れるかなど、重要な戦略的意思決定には、わかりやすく、正確でアクションにつながるデータが不可欠です。

SKANのあらゆる制約を考慮した上で、AdjustはアナリティクスソリューションDatascapeのレポート機能を使用して、データを並べて比較することをおすすめしています。Datascapeでは、取得したデータがすべてわかりやすい、詳細なフォーマットで表示されるため、「信頼できる唯一の情報源」として使用できます。Datascapeでは、SKAN関連の各種KPI（コンバーション、収益、イベント）を使用して、通常のAdjustアトリビューションデータと並べて表示できる包括的なレポートを作成可能です。Datascapeを活用して、データの精度を確保しましょう。

複雑なiOSのエコシステムにおいて計測を行うのに最も効果的なのは、機械学習と予測を活用して正確なeCPI、CPE、ROASを特定することです。Adjustでは、この課題を解決する次世代ソリューションを開発しています。つまるところ、マーケターが求めているのは、投入した費用に対してキャンペーンにもたらされる収益が明確にわかるツールです。このシンプルなツールこそが、キャンペーンの一時停止/スケーリングの意思決定を迅速に行うのに重要なのです。

詳細はAdjustの担当者までお問い合わせください。