GAIDなしのモバイルアトリビューション：広告IDなしでインストールを測定する方法

広告IDへのアクセスなしでモバイルアプリのアトリビューションをどのように処理するか？ GAIDやIDFAなしでもアプリのインストールを計測することは可能ですが、基盤となるアーキテクチャが変化します。永続的な広告識別子に依存するのではなく、プラットフォームが提供するアトリビューションフレームワーク、Google Play インストールリファラ、ファーストパーティのコンテキストパラメータルーティング、およびサーバーサイド検証を現代のパイプラインでは組み合わせて使用します。

広告IDとは、広告および測定の用途向けにモバイルプラットフォームによって提供されるリセット可能なソフトウェア識別子のことです。AndroidではGoogle Play開発者サービスを通じて提供される広告IDであり、AppleプラットフォームではIDFAへのアクセスはApp Tracking Transparencyフレームワークによって管理されています。

TL;DR：IDフリーモバイルアトリビューションの概要

Google広告IDは、単一のドロップイン識別子に置き換えられるわけではありません。その代わり、アトリビューションは以下のような目的別に構築された個別のプリミティブに分割されます：

• 有料広告キャンペーンのレポート（Android）：Playで配信されるインストールのストア経由のキャンペーンパラメータ取得には、Google Play インストールリファラ APIを使用します。

• 有料広告キャンペーンのレポート（iOS）：プラットフォームによって署名された、プライバシーを保護するポストバックには、Apple AdAttributionKitおよびSKAdNetworkを使用します。

• Web-to-App オンボーディングおよびリファラル：プロモコード、ルームID、招待者トークンを初回起動時に復元するために、ファーストパーティのインストールコンテキスト復元レイヤー（OpoInstallなど）を使用します。

• クロスアプリリターゲティング：認可されたプラットフォームサポートの識別子または測定メカニズム、および適用されるプラットフォームポリシー、ユーザーコントロール、同意要件への準拠が必要です。

アーキテクチャ決定マトリクス：適切なおすすめアトリビューションプリミティブの選択

アプリケーションに適した技術的メカニズムを決定するために、具体的な運用要件とプラットフォームの機能を照らし合わせて評価します：

GAIDの代替：実際に機能するもの

エンジニアリングチームが「GAIDの代替」を探す際、単一のツールで複数の切断された運用上の問題を解決しようとすることがよくあります。本番環境では、GAID依存のアーキテクチャを4つの独立したソリューションに分解する必要があります：

                        レガシーGAIDワークフロー
                                 │
     ┌───────────────────────────┼───────────────────────────┐
     │                           │                           │
     ▼                           ▼                           ▼
有料キャンペーンROI       Web-to-Appルーティング        リファラル紐付け
     │                           │                           │
     ▼                           ▼                           ▼
Playインストールリファラ /  ファーストパーティコンテキスト  ファーストパーティリファラル
AdAttributionKit            パラメータルーティング        トークン復元

• GAIDベースのインストールコンテキスト取得の代替：Playで配信されるインストールについては該当する場合にGoogle Play インストールリファラを使用し、さらに広告ネットワークの統合やプラットフォームがサポートするアトリビューションAPIを併用します。これらのフレームワークは、永続的なハードウェアや広告識別子を露出させることなく、インストールの発信元コンテキストを提供します。

• オンボーディングおよびディープリンク向けのGAIDの代替：ファーストパーティのインストールコンテキスト復元レイヤー（OpoInstallなど）を導入します。広告IDを照会してクリックログを結合する代わりに、自社所有のキャンペーンURL経由で動的パラメータを渡し、クライアントSDKを介して最初のアプリ起動時にそれらを復元します。

• ユーザーアイデンティティ向けのGAIDの代替：デバイスレベルの広告キーではなく、認証されたファーストパーティのアカウントシステム（OAuthや内部ユーザーUUIDなど）を使用します。

コアアーキテクチャ分類：各プリミティブが提供するもの

GAID vs インストールリファラ vs ファーストパーティパラメータ復元

AndroidアプリのアトリビューションにおけるGAIDの代替手段

Google広告IDにアクセスできないAndroid端末で運用する場合、エンジニアリングチームは特定のキャンペーンチャネルに合わせた代替メカニズムを導入します：

モバイルアトリビューションプラットフォーム（MMP）がGAIDなしで測定を処理する方法

AppsFlyer、Adjust、Singular、Branchなどのモバイル計測パートナー（MMP）は、広告識別子が不在の場合でも測定をサポートできるように技術アーキテクチャを調整しています：

マクロな広告ネットワークレポート用にMMPを、ミクロなオンボーディングパーソナライゼーション用にファーストパーティのコンテキストルーティングレイヤーを組み合わせることで、エンジニアリングチームはオペレーティングシステムのプライバシーサンドボックスを侵害することなく、補完的な測定およびオンボーディングスタックを確立できます。

広告IDの制限が決定論的モバイルアトリビューションを混乱させる理由

永続的な広告識別子への歴史的依存

十年にわたり、モバイルパフォーマンス広告は、AndroidのGoogle広告ID（GAID）やiOSの広告主向け識別子（IDFA）といったプラットフォームの広告識別子によって駆動される、デバイスレベルの決定論的マッチングに依存してきました。この従来のワークフローでは、広告ネットワークは広告のインプレッション時またはクリック時にユーザーの広告IDをキャプチャしていました。その後アプリがインストールされて起動されると、統合されたアトリビューションSDKがデバイスのOSにクエリを送信し、一致する広告IDを取得していました。

シンプルなサーバーサイドでの一致ルックアップ（$GAID*{\\text{click}} == GAID*{\\text{install}}$）により、マーケティング投資とアプリインストールの間にある明確な結びつきが確立されていました。このメカニズムにより、リアルタイムのセッション状態やコンテキストパラメータの伝送を必要とせずに、決定論的なマルチネットワークアトリビューション、クロスパブリッシャープロファイリング、および自動リターゲティングが可能になっていました。

識別子のゼロ化とプラットフォーム制限のメカニズム

モバイルOSのアーキテクチャは、ユーザーの明確な同意なしにクロスアプリのデバイス追跡を制限するよう進化しています。

Appleプラットフォームでは、Apple App Tracking Transparencyのガイドラインにより、アプリケーションにATTrackingManager.requestTrackingAuthorizationを介したトラッキング承認の要求が義務付けられています。承認が得られない場合、OSはIDFAの提供を保留します。アプリケーションは、広告識別子がアクセス可能であると仮定することなく、denied（拒否）、restricted（制限）、およびnotDetermined（未決定）の状態を適切に処理する必要があります。

Androidでは、Android 13の動作変更に関するドキュメントに従い、GoogleはGoogle Play開発者サービス内に明示的な権限コントロールを導入しました。Android 13（APIレベル33）以上をターゲットとするアプリケーションの場合、開発者は広告IDにアクセスするためにマニフェスト内でcom.google.android.gms.permission.AD_IDパーミッションを宣言する必要があります。このパーミッションが省略されている場合、またはユーザーが広告トラッキングを制限している場合や広告IDを削除した場合、Google Play開発者サービスは、デバイスの状態やGoogle Play開発者サービスの動作に応じて、ゼロ化された識別子（00000000-0000-0000-0000-000000000000）を返すか、識別子が利用不可であることを示します。

決定論的広告アトリビューションパイプラインの破綻

広告識別子が利用できない場合やゼロ化されている場合、識別子の一致に依存するアトリビューションパイプラインは、信頼性の高いユーザーレベルのマッチングを実行できなくなります。ゼロ化された、または利用不可の広告識別子は、個々のコンバージョンジャーニーを区別するための固有のキーを提供できません。

キャンペーン測定とコンバージョン追跡を維持するために、エンジニアリングチームは広告ID依存からの脱却を進める必要があります。モダンなアーキテクチャでは、インストールのアトリビューションを永続的なデバイス識別子から切り離し、ファーストパーティのコンテキストルーティングとプラットフォーム提供の測定フレームワークに依存しています。

このアーキテクチャにおいて、OpoInstallは、Google Play インストールリファラ、AdAttributionKit、SKAdNetwork、その他のプラットフォーム経由の広告アトリビューションシステムの普遍的な代替品としてではなく、ファーストパーティのインストールコンテキスト復元・遅延ディープリンクレイヤーとして提示されています。

Androidの広告IDパーミッションとAppleのATTがアトリビューションに与える影響

Android 13以降におけるGoogle PlayのAD_IDパーミッションポリシー

Google Playは、広告識別子の抽出に対してきめ細かなポリシーガバナンスを施行しています：

• マニフェスト宣言の要件：Android 13（APIレベル33）以上をターゲットとするアプリは、マニフェスト内で<uses-permission android:name="com.google.android.gms.permission.AD_ID"/>を宣言する必要があります。省略された場合、AdvertisingIdClient.getAdvertisingIdInfo(context)への呼び出しはゼロを返すか、利用不可の状態を示します。

• ユーザーのプライバシーコントロール：ユーザーが広告トラッキングを制限している場合や広告IDを削除した場合、Google Play開発者サービスはゼロまたは利用不可の状態を返します。Google Playの開発者ポリシーでは、他の永続的なデバイス識別子を使用してリセットされた広告IDをブリッジまたは再構築することを明示的に禁止しています。

• 機密性の高いアプリに対するポリシー除外：Google Playのポリシーでは、児童をターゲットとするアプリやファミリーポリシーの制約を受けるアプリでのAD_IDパーミッションの宣言を禁止しており、開発者にIDフリーの測定パイプラインの採用を求めています。

AppleのAppTrackingTransparencyフレームワークと承認状態

iOSでは、識別子へのアクセスはATTrackingManager.AuthorizationStatusのシステム状態によって管理されます：

• notDetermined（0）：ユーザーがまだATT承認リクエストに応答していません。アプリケーションはIDFAへのアクセスが可能であると仮定してはなりません。

• restricted（1）：ペアレンタルコントロールまたはデバイス管理プロファイルによってデバイスが制限されており、トラッキングがシステム全体で無効になっています。

• denied（2）：ユーザーがプロンプトで「Appにトラッキングしないよう要求する」を明示的に選択したか、iOSのプライバシー設定でトラッキングリクエストをグローバルに無効にしています。アプリケーションはIDFAに依存してはなりません。

• authorized（3）：ユーザーがサードパーティのアプリやWebサイトにまたがるトラッキングの許可を明示的に付与しており、Appleのプラットフォームポリシーに従ったIDFAへのアクセスが許可されます。

重要なアーキテクチャ上の境界に関する声明

重要な区別：アトリビューションアーキテクチャからGAIDやIDFAを削除したからといって、すべての代替追跡技術が自動的にプライバシーセーフになるわけでも、ポリシーに準拠するわけでもありません。AppleのApp Tracking Transparencyフレームワークのガイダンスによると、Appleは「トラッキング」を、ターゲティング広告または測定のためにアプリから収集したユーザーまたはデバイスデータをサードパーティのデータと紐付けること、またはデータをデータブローカーと共有することと定義しています。エンジニアリングパイプラインが永続的なクロスアプリIDを再構築するためにデバイスの特性を収集する場合、広告IDがアクセスされたかどうかに関係なく、プラットフォームのトラッキングポリシーの対象となり続けます。ファーストパーティパラメータルーティングは、ユーザーが開始したジャーニーの即時のオンボーディングおよびコンバージョンコンテキストにスコープが限定されている必要があります。

IDフリーアトリビューションが意味しないこと

IDフリーアトリビューションとは、識別子を一切使用しないアナリティクスを意味するわけではありません。アプリは、内部のプロダクト機能に必要なアカウント識別子、ファーストパーティのセッション・トークン、またはディープリンクパラメータを引き続き処理できます。アーキテクチャ上の目的は、すべての測定データが完全に匿名であると主張することではなく、インストールマッチングのための永続的なクロスアプリ広告識別子への依存を排除することです。

混同してはならない3つのアトリビューションの課題

広告識別子なしでモバイルアトリビューションを設計する際、エンジニアリングチームは3つの異なる運用目的を区別する必要があります：

ファーストパーティのルーティングメカニズムは、GAIDやIDFAを必要とせずに遅延ディープリンクやリファラルアトリビューションを解決できますが、プラットフォーム経由の広告アトリビューションの万能な代替品として提示されるべきではありません。

成長チームがファーストパーティのアトリビューションレイヤーを導入すべき時期

独立したファーストパーティアトリビューションレイヤーの導入は、特定のプロダクトワークフローを運用するアプリケーションにおすすめです：

• SaaSおよびサブスクリプションアプリ：マーケティングトラフィックがデスクトップまたはモバイルWebで始まり、事前認証済みのセッション復元を必要とするネイティブアプリのアカウントへとコンバージョンするB2Bプラットフォーム。

• ゲームアプリ：新しいプレイヤーが手動のルームコードなしで、初回起動時に自動的に招待者のマッチ、ギルド、またはルームに参加する必要があるマルチプレイヤーまたはソーシャルゲーム。

• Eコマースプラットフォーム：パーソナライズされたウェルカムディスカウントを提供する、またはモバイルWebキャンペーンからネイティブのチェックアウト画面へとアクティブなショッピングカートの状態を直接復元するショッピングアプリ。

• リファラルおよびロイヤルティプラットフォーム：ユーザーにクーポン文字列のコピー＆ペーストを強いることなく、信頼性の高い招待者と被招待者のトークン紐付けを必要とする有機的なバイラルループを駆動するプロダクト。

IDフリーのファーストパーティパラメータルーティングに向けたアーキテクチャ設計図

永続的なデバイス識別子からのアトリビューションの切り離し

この記事では、ユーザー起点のWeb-to-appジャーニーを通じたキャンペーンまたはリファラルコンテキストのファーストパーティ送信を説明するために、コンテキストパラメータルーティング（ファーストパーティ遅延アトリビューションまたはインストールコンテキスト復元とも呼ばれます）を使用します。

近代的なアトリビューションアーキテクチャは、物理デバイスの追跡を試みるのではなく、マーケティングエンゲージメントのトランザクションコンテキストに焦点を当てています。見込み客がキャンペーンリンクをクリックすると、そのインタラクションにはキャンペーンメタデータ、チャネルトークン、およびアプリケーションルーティングパラメータを含む一時的なルーティングペイロードが割り当てられます。

このペイロードはユーザーのジャーニーに沿ってコンバージョンファネルを通過し、システムレベルの広告IDにクエリを送信することなく、モバイルアプリが起動時にコンテキストの意図を復元できるようにします。

2層のアトリビューションアーキテクチャ

エンタープライズ向けのアトリビューションアーキテクチャは、直接的なディープリンクとストア経由のインストールフローを分離します：

                ユーザーのマーケティングインタラクション
                          │
         ┌────────────────┴────────────────┐
         │                                       │
   ダイレクトアプリリンク                  ストア / 広告フロー
         │                                       │
 ユニバーサルリンク /               ┌──────┴───────┐
    Appリンク                      │                           │
         │                       Android                       Apple
         │                   Play インストール                プラットフォーム広告
         │                      リファラ                     アトリビューション
         │                            │                              │
         └──────────────┬────────┴──────┬───────┘
                                       │                              │
                                         アトリビューション / ルーティングシグナル
                                                        │
                                             サーバーサイド検証
                                                        │
                                    ┌─────────┴─────────┐
                                    │                                      │
                              コンテキスト発見                         シグナルなし
                                   │                                      │
                             ルーティング / 紐付け                     オーガニック /
                             ファーストパーティ                       優雅なフォールバック

コンテキストパラメータルーティングとフォールバックの技術的メカニズム

ファーストパーティパラメータ転送の役割

ファーストパーティパラメータ転送は、標準的なWebクエリのパースと、安全なサーバーサイドのセッションキャッシングに依存しています。開発者は、パラメータバインディングモデルに関する技術仕様についてOpoInstall SDKドキュメントを参照できます。

実装がAppleのトラッキングの定義に該当しない場合、直接的なオンボーディングのみに使用されるファーストパーティパラメータルーティングには必ずしもATTは必要ありません。チームは実際のデータフローと目的をAppleの現在のポリシーに照らして評価する必要があります。

プラットフォーム固有のインストールアトリビューションフォールバック

直接的なディープリンクがストアのインストールによって中断された場合、プラットフォーム固有のプリミティブが構造化されたアトリビューションデータを提供します：

• Android（Google Play インストールリファラ）：Google Play インストールリファラ APIガイドでは、Playストアのインストールに関連付けられたリファラ情報が公開されており、クリックとインストールのタイムスタンプが提供されます。APIドキュメントでは、リファラデータの可用性ウィンドウとして90日間が指定されています。アプリケーションは、これを永続的なインストール識別子として扱うのではなく、独自のアトリビューションおよび再インストール処理のルールに従ってこの値を永続化および処理する必要があります。パラメータはGoogle Play経由で明示的に渡される必要があることに注意してください。任意のランディングページのクエリパラメータが自動的にこのAPIに反映されるわけではありません。

• Appleプラットフォームのアトリビューション：Appleの最新のアプリアトリビューションスタックには、サポートされている広告ワークフロー向けのSKAdNetworkとの相互運用性に加えて、Apple AdAttributionKitフレームワークが含まれています。AdAttributionKit自体にはATT承認プロンプトは必要ありません。ただし、同じアプリ内の他のデータフローは引き続きトラッキングを構成する可能性があり、したがってATT承認が必要になる場合があります。AdAttributionKitは、Appleのアトリビューションフレームワークに登録された適格な広告ネットワークを備えた、Appleの署名付き広告フレームワーク内で動作します。

クリップボードベースのアトリビューションを主要な戦略にすべきではない理由

クリップボードまたはペーストボード転送は、主要なアトリビューションデザインではなく、例外的なフォールバックメカニズムとして扱うべきです。クリップボードへのアクセスは、ユーザーに表示されるプライバシー通知、プラットフォームの制限、およびOSバージョン間での一貫性のない可用性をもたらします。ペーストボードストレージを評価する際は、以下の点に注意してください：

• 明示的なスコープ設定：ペイロードは短命にし、意図されたファーストパーティのフローに必要な最小限のアプリケーション固有のデータに限定する必要があります。機密値は、転送中および保存時に適切に保護する必要があります。

• 即時のクリーンアップ：アプリケーションは、初期起動シーケンス中に消費された一時的なパラメータトークンを速やかにクリアまたは上書きする必要があります。

• ポリシーコンプライアンス：明確に定義されたファーストパーティのユーザーフローが存在し、適用されるプラットフォームポリシーのレビューに従う場合にのみ、ペーストボードメカニズムを使用します。

優雅なフォールバックと未計測（アトリビューションなし）の状態

回復力のあるプライバシーアーキテクチャは、過度なデバイスフィンガープリンティングを通じてアトリビューションマッチを強制しようとはしません：

• ダイレクトアプリリンク / ユニバーサルリンク：アプリがすでにデバイスにインストールされている場合の即時のネイティブアプリ起動。

• ストア経由のパラメータ受け渡し：利用可能な場合のプラットフォームAPI（Google Play インストールリファラなど）を介したキャンペーンパラメータの取得。

• ファーストパーティパラメータの復元：狭い時間枠内での、アクティブなWebランディングページのインタラクションに対する新規インストールセッションのマッチング。

• シグナルなし（未計測）：ネットワーク条件が変化した場合、セッションの有効期限が切れた場合、または一致するコンテキストが存在しない場合、アプリケーションはユーザーのオンボーディング体験を中断することなく、クリーンなデフォルト状態へ安全にフォールバックします。

実装シナリオ例：OpoInstallによるコンテキストの復元

これらのプリミティブが本番環境でどのように動作するかを理解するために、2つの同時獲得チャネルを実行しているクロスプラットフォームのモバイルゲームアプリを考えてみます：

• チャネルA（有料プログラマティック広告）：App StoreおよびGoogle Playにリダイレクトする、外部広告ネットワーク上で実行されている広告キャンペーン。

• チャネルB（ユーザーバイラル共有）：既存プレイヤーがソーシャルメッセージングアプリを介してカスタム招待リンク（https://game.example.com/join?room=9876&inviter=usr_432）を共有すること。

*   

[チャネルA：有料広告] ──> [ストアダウンロード] ──> [Playリファラ / AdAttributionKit] ──> [集計された広告ROI]
[チャネルB：招待]  ──> [Webランディング] ──> [ファーストパーティトークン復元]    ──> [ゲームルームへ自動参加]

新規ユーザーがチャネルA経由でインストールした場合、アプリケーションはGoogle Play インストールリファラAPIまたはApple AdAttributionKitに依存してキャンペーンパフォーマンスをマーケティングダッシュボードに報告します。ユーザーがチャネルB経由でインストールした場合、ファーストパーティルーティングSDKが初回起動時に動的な招待トークンをキャプチャし、広告IDの照会やATTプロンプトのトリガーを行うことなく、新しいプレイヤーを直ちにルーム9876に参加させます。

IDフリーモバイルアトリビューションにおけるよくある本番環境での障害ケース

永続的な広告識別子に依存しないアトリビューションアーキテクチャを導入する際、エンジニアリングチームは特定の運用上の障害モードに頻繁に遭遇します：

• 障害ケース1：ストアリダイレクト後にランディングページのパラメータが失われる：キャンペーンリンクがエンコードされていない中間URL短縮サービスを経由してリダイレクトされる場合、channelCodeやreferrerなどのクエリパラメータが、ランディングページのスクリプトやApp Storeの宛先に到達する前に削ぎ落とされる可能性があります。

• 障害ケース2：重複する紹介報酬の引き換えと冪等性ロックの欠如：本番環境において、モバイルクライアントがローカルの永続化フラグを確認せずにActivity.onResumeやアプリのフォアグラウンドイベントごとにパラメータ復元を呼び出すと、ユーザーが重複する報酬請求や繰り返されるディープリンクナビゲーションをトリガーしてしまう可能性があります。

• 障害ケース3：再インストール状態の誤管理：Google Play インストールリファラは最大90日間の過去のリファラデータを保持しますが、クライアントのバックエンドがアカウントがすでに登録を完了しているかどうかを検証しない限り、再インストールされたアプリケーションは以前のインストールライフサイクルからの古いアトリビューションデータを受け取る可能性があります。

• 障害ケース4：幅広いマッチングウィンドウによるオーガニックインストールの誤分類：共有ネットワークやユーザー密度が高い環境でサーバーサイドのセッションマッチングウィンドウが広すぎる設定になっている場合、オーガニックインストールが関係のないWebクリックセッションと衝突する可能性があります。

ファーストパーティのインストールコンテキスト復元のためのSDK統合パターンの例

クライアントサイド統合の概要

ファーストパーティのインストールコンテキスト復元SDKを使用すると、広告IDを必要とせずにコンテキストパラメータの復元を実装できます。開発チームは、OpoInstallモバイルSDKパッケージおよび統合リソースをダウンロードできます。

SDK APIの注意点： 以下に示す初期化と取得のライフサイクルは、例示的な疑似実装です。以下のAPI名は意図的な例示であり、ベンダーのドキュメントとして扱われるべきではありません。本番環境では、アトリビューションの取得を個別のActivityライフサイクルに直接結合するのではなく、SDKでドキュメント化されているアプリケーションレベルの初期化とインストールコンテキストのライフサイクルを優先してください。本番稼働の前に、すべてのクラス、メソッド名、コールバック型、および設定キーをベンダーの最新ドキュメントと照らし合わせて検証してください。

// Android実装：IDフリーのパラメータ抽出（アーキテクチャパターン）
// パートAでの位置：[CODE_BLOCK_01]
// 注意：OpoInstall SDKの契約に基づく例示的な疑似実装。

// ----------------------------------------------------------------------------
// 1. AndroidManifest.xml（サンプル抜粋）
// ----------------------------------------------------------------------------
/*
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.myapp">
    <uses-permission android:name="android.permission.INTERNET"/>
    <application android:name=".CustomApplication" android:label="@string/app_name">
        <!-- ベンダーのドキュメントで指定されている方法を使用してアプリケーションキーを設定します -->
        <meta-data android:name="com.opoinstall.APP_KEY" android:value="YOUR_APPKEY"/>
    </application>
</manifest>
*/

// ----------------------------------------------------------------------------
// 2. CustomApplication.kt：アプリケーションレベルの状態機械ライフサイクル
// ----------------------------------------------------------------------------
package com.example.myapp

import android.app.Application
import android.util.Log
import com.opoinstall.api.OpoData
import com.opoinstall.api.OpoError
import com.opoinstall.api.OpoInstall
import com.opoinstall.api.ResultCallBack

class CustomApplication : Application() {

    enum class AttributionState {
        NOT_STARTED,
        FETCHING,
        PROCESSED
    }

    override fun onCreate() {
        super.onCreate()
        
        // メインプロセスでファーストパーティルーティングSDKを初期化します
        OpoInstall.initialize(this)

        // アプリケーション層でインストールコンテキストを一度だけ取得します
        if (getAttributionState() == AttributionState.NOT_STARTED) {
            fetchInstallContext()
        }
    }

    private fun fetchInstallContext() {
        setAttributionState(AttributionState.FETCHING)

        OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
            override fun onResult(opoData: OpoData?) {
                setAttributionState(AttributionState.PROCESSED)
                if (opoData != null) {
                    val channelCode = opoData.channelCode
                    val customData = opoData.data
                    Log.d("InstallContext", "復元されたコンテキスト：チャンネル=$channelCode, データ=$customData")
                    handleInstallContext(channelCode, customData)
                }
            }

            override fun onError(opoError: OpoError?) {
                // 一時的なネットワーク障害が発生した場合、状態を再試行可能にするかクリーンにフォールバックできます
                Log.w("InstallContext", "アトリビューションクエリが次のステータスで完了しました：${opoError?.errorMsg}")
                setAttributionState(AttributionState.PROCESSED)
            }
        })
    }

    private fun getAttributionState(): AttributionState {
        val raw = getSharedPreferences("attribution_prefs", MODE_PRIVATE)
            .getString("state", AttributionState.NOT_STARTED.name)
        return AttributionState.valueOf(raw ?: AttributionState.NOT_STARTED.name)
    }

    private fun setAttributionState(state: AttributionState) {
        getSharedPreferences("attribution_prefs", MODE_PRIVATE)
            .edit()
            .putString("state", state.name)
            .apply()
    }

    private fun handleInstallContext(channelCode: String?, customData: String?) {
        // 復元されたコンテキストを内部のアカウント／ルーティングサービスにディスパッチします
    }
}

iOS実装：Swiftライフサイクルの統合

iOSでは、アプリケーションライフサイクルデリゲート内にSDKを統合します。クロスアプリトラッキングが実行されない場合、SDKはAppTrackingTransparencyの承認リクエストを呼び出すことなく、メイン実行スレッド上で非同期にインストールパラメータを取得します。

以下のSwift実装は、例示的な初期化およびパラメータ抽出ワークフローを示しています：

// iOS統合パターン：アプリケーションレベルのインストールコンテキスト取得
// パートAでの位置：[CODE_BLOCK_02]
// 注意：疑似コードのみ。型名とメソッド名は例示用のプレースホルダーです。

// ----------------------------------------------------------------------------
// 1. Info.plist（サンプル抜粋）
// ----------------------------------------------------------------------------
/*
<!-- ベンダーのドキュメントで指定されている方法を使用してアプリケーションキーを設定します -->
<key>com.opoinstall.APP_KEY</key>
<string>YOUR_APPKEY</string>
*/

// ----------------------------------------------------------------------------
// 2. AppDelegate.swift：ライフサイクルの初期化とコンテキストの取得
// ----------------------------------------------------------------------------
import UIKit
// 注意：SDKモジュールのインポートは意図的に省略されています。パッケージマネージャーによって提供されるモジュール名を使用してください。

enum InstallContextState: String {
    case notStarted = "NOT_STARTED"
    case fetching = "FETCHING"
    case processed = "PROCESSED"
}

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        
        // ATT承認を呼び出さずにファーストパーティルーティングSDKを初期化します
        OpoInstallSDK.initWith(self)

        // アプリケーションエントリポイントでの状態機械チェックにより取得をガードします
        if getInstallContextState() == .notStarted {
            fetchInstallContext()
        }

        return true
    }

    private func fetchInstallContext() {
        setInstallContextState(.fetching)

        // 遅延インストールパラメータを非同期で取得します
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted({ [weak self] (appData: OpoinstallData?) in
            DispatchQueue.main.async {
                self?.setInstallContextState(.processed)

                if let data = appData?.data {
                    let channel = appData?.channelCode
                    self?.handleInstallContext(channelCode: channel, customData: data)
                }
            }
        })
    }

    private func getInstallContextState() -> InstallContextState {
        let raw = UserDefaults.standard.string(forKey: "install_context_state") ?? InstallContextState.notStarted.rawValue
        return InstallContextState(rawValue: raw) ?? .notStarted
    }

    private func setInstallContextState(_ state: InstallContextState) {
        UserDefaults.standard.set(state.rawValue, forKey: "install_context_state")
    }

    private func handleInstallContext(channelCode: String?, customData: String) {
        // 復元されたコンテキストを内部のアカウント／ルーティングサービスにディスパッチします
    }

    // ディープリンク用のユニバーサルリンクデリゲートコールバック
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }
}

クライアント実装に関するエンジニアリング上の考慮事項

• UIスレッドをブロックしないライフサイクル：アトリビューションSDKは常に非同期で初期化し、アプリ起動時にメインUIスレッドをブロックすることなくパラメータをクエリします。

• ローカルの冪等性処理：状態機械または永続フラグ（NOT_STARTED、FETCHING、PROCESSEDなど）を維持し、パラメータ抽出をクリーンに管理して不要なAPIクエリを防ぎます。

• サーバーサイドの再送（リプレイ）防御：バックエンドのトランザクションログに対して動的パラメータペイロードを検証し、紹介コードやプロモーション用トークンが悪意を持って再送されないようにします。

プラットフォームアトリビューションAPIとプライバシーサンドボックスへの移行

Androidのプラットフォームアトリビューションとプライバシーサンドボックスへの移行

AndroidのアトリビューションレポートAPIは、クロスパーティの識別子に依存することなく、アプリとWeb全体でプライバシーを保護する測定をサポートするように設計されました。

AndroidのアトリビューションレポートAPIは、サポートされているプライバシーサンドボックスの統合で利用可能ですが、インストールリファラやMMP統合の万能な代替品ではありません。本番環境での適用性は、特定のAndroidバージョン、広告テクノロジーの統合、登録要件、およびエコシステムのサポートによって異なります。チームは、アトリビューションレポートを本番依存関係にする前に、最新のAndroidプライバシーサンドボックスのドキュメントを確認する必要があります。

Playで配信されるAndroidアプリの場合、Google Play インストールリファラは、Playストアのインストールに関連付けられたキャンペーンパラメータを取得するための実用的なファーストパーティメカニズムであり続けます。広告ネットワークやアトリビューションプロバイダーも、プラットフォームサポートの測定インテグレーションを提供している場合があります。

Appleのプラットフォームアトリビューション：AdAttributionKitとSKAdNetwork

iOSでは、AppleがAdAttributionKitを中心としたプライバシー保護アトリビューションメカニズムを提供しており、サポートされている広告ワークフロー向けのSKAdNetworkとの相互運用性に加えて、App Storeや代替マーケットプレイスにまたがるアプリ広告キャンペーンをサポートしています。これらのフレームワークは、永続的なデバイス広告識別子を露出させることなく、プラットフォーム経由のアトリビューションシグナルを提供します。レポートの粒度とタイミングは、Appleのプライバシー閾値とアトリビューションウィンドウによって引き続き管理されます。

ファーストパーティルーティングとプラットフォームAPIの共存

プラットフォームのプライバシーAPIとファーストパーティのコンテキストルーティングは、異なるエンジニアリング要件を解決します：

• プラットフォームプライバシーAPI：マクロレベルの広告測定、広告ネットワークのROI計算、および永続的な識別子を必要としないプログラマティックキャンペーンの最適化向けに設計されています。

• ファーストパーティパラメータルーティング：ミクロレベルのアプリオンボーディング、インスタントなユーザー間紹介報酬の紐付け、ディープリンクルーティング、および直接的なWeb-to-appコンバージョンジャーニー向けに設計されています。

サンドボックス環境でアトリビューションの精度を検証する方法

広告IDにアクセスできない場合のインストールアトリビューションの検証

アプリケーションがさまざまなデバイスおよびパーミッションの状態でインストールアトリビューションを正しく処理していることを確認するには、次を行います：

• AD_ID不在の状態：AndroidManifest.xmlからcom.google.android.gms.permission.AD_IDパーミッションを除外したAndroidのテストビルドをデプロイし、アプリがクリーンに初期化されることを確認します。

• ユーザー識別子の制限：Google Play開発者サービスを搭載したAndroidテストデバイスで、システム設定の広告制限を有効にするか広告IDを削除し、パラメータ抽出がクラッシュまたは停止しないことを確認します。

• Playストアキャンペーンのシミュレーション：Google Play インストールリファラメカニズムを介して期待される値を明示的に渡すテストキャンペーンURLを使用して、インストールジャーニーをトリガーします。任意のランディングページのクエリパラメータが自動的にインストールリファラの値になると仮定しないでください。

• 再インストールの検証：以前にアトリビューションされたインストールの後にアプリケーションを再インストールし、アトリビューションフローが古い初回インストール状態を誤って再利用していないことを確認します。

• オーガニックフォールバックの検証：リンクされていないビルドを起動し、ハングすることなくgetInstallParamがクリーンにnullまたはオーガニックフォールバックに解決されることを確認します。

物理iOSデバイスでのATT拒否状態のシミュレーション

トラッキングが拒否された場合のiOSパラメータ取得をテストするには：

• Xcode経由で物理iOSデバイスにテストビルドをインストールします。

• SDKのパラメータ取得メソッドが非同期で実行され、ATTのプロンプト表示やIDFA APIへのクエリを行わずにパラメータが正常に解決されることを確認します。

• コールドスタートとバックグラウンド復帰の両方のライフサイクルにわたるアプリ起動の動作をテストします。

データ最小化のためのネットワークペイロードの監査

セキュリティおよびコンプライアンスチームは、HTTPプロキシを使用してクライアントサイドのネットワークトラフィックを検査する必要があります：

• ID除外の確認：発信されるアトリビューションリクエストに、IMEI、MACアドレス、Android ID（SSAID）、または未承認のIDFA文字列などの永続的な識別子が含まれていないことを確認します。

• トランスポートセキュリティ：アトリビューションAPI通信に、現在のTLS設定と標準的な証明書検証を備えたHTTPSが使用されていることを確認します。

• ペイロード保護：転送中または一時バッファに保存される動的トークンが適切な保護標準を利用していることを確認します。

OpoInstallによるIDフリーアトリビューションインフラストラクチャの構築

広告IDに依存しない成長スタックを評価するエンジニアリングチームには、3つのコア技術機能が必要です：

1. シームレスなコンテキスト復元：手動での紹介コードやハードウェアIDの収集なしで、Webランディングページからネイティブアプリケーションへとカスタムメタデータを渡すこと。

2. クロスプラットフォームのキャンペーンコンテキスト管理：複数のアプリケーションビルドを必要とせずに、プラットフォームをまたいでWeb-to-appおよびモバイルキャンペーンを管理すること。

3. 厳格なプラットフォームコンプライアンス：ファーストパーティのアプリケーションサンドボックス内で完全に動作し、OSのプライバシー制約を尊重すること。

モバイル測定およびルーティングの実装パターンを探索するには、OpoInstallドキュメントを参照するか、OpoInstall開発者コンソールにアクセスしてください。

まとめと決定フレームワーク

広告識別子の制限がますます厳しくなる中で持続可能なモバイル成長アーキテクチャを構築するために、エンジニアリングチームはレガシーのGAIDおよびIDFA依存関係から脱却する必要があります。OSや規制ポリシーがクロスアプリトラッキングの制限を続けるにつれて、永続的なデバイス識別子に依存することは構造的な脆弱性をもたらします。

モダンなアトリビューションフレームワークは、ファーストパーティパラメータ転送、プラットフォーム経由の測定API、および回復力のあるクライアントサイドSDK抽出を組み合わせたものです。コンテキストルーティングアーキテクチャを導入することで、モバイルチームはプラットフォームのプライバシー要件に準拠しつつ、信頼性の高いWeb-to-appコンバージョンジャーニーを維持できます。

関連資料

• 概念：広告IDの制限、コンテキストパラメータルーティング、インストールリファラ、AdAttributionKit、App Tracking Transparency

• テクノロジー：Google Play インストールリファラ API、Google Play開発者サービス広告API、Apple ATTフレームワーク、Apple AdAttributionKit、OpoInstallモバイルSDK

• セキュリティトピック：モバイルデータの最小化、再送（リプレイ）保護、トランスポートセキュリティ

• API：Google Play インストールリファラ API、Google広告ID API、Apple App Tracking Transparency API、OpoInstallインストールパラメータAPI

公式ドキュメント

Android

• Google Play開発者サービス広告IDドキュメント

• 広告IDに関するAndroid 13の動作変更

• Google Play インストールリファラ APIガイド

Apple

• App Tracking Transparencyに関するApple開発者ドキュメント

• AdAttributionKitに関するApple開発者ドキュメント

• 広告アトリビューションに関するApple開発者ドキュメント

• AdAttributionKitとSKAdNetworkの相互運用性の理解

プライバシー保護アトリビューション

• Googleプライバシーサンドボックスの概要