AppsFlyerモバイルアトリビューションとCookieの同意：アプリパブリッシャー向け2026年統合ガイド
アプリ開発者にとって、モバイル計測はウェブ計測とは根本的に異なる課題です。ウェブパブリッシャーが気にするCookieはネイティブアプリ内には存在しませんが、それに代わる識別子——IDFA、GAID、IDFV、インストールID、ハッシュ化されたメールアドレス、IPベースのデバイスフィンガープリント——は同じ法的問題を提起し、同じ規制当局の管轄下にあります。モバイルゲーム、フィンテック、コンシューマーアプリにおいて最も広く導入されているモバイル計測パートナーであるAppsFlyerは、このパイプラインの中心に位置しています。そのSDKはアトリビューションレベルの識別子を収集し、サーバーはそれらを広告ネットワークのポストバックと照合し、その結果得られるアトリビューションデータがすべての主要チャネルにわたるユーザー獲得予算を左右します。この処理はすべて適法な根拠なしには行えず、GDPRおよびePrivacy指令が実際に要求する適法根拠は同意です——SDKが初期化される前に収集され、証拠として記録され、すべての下流統合に伝播される同意です。本ガイドでは、AppsFlyerが何を収集するか、iOS、Android、モバイルウェブにおいて同意管理フレームワークとどのように統合するか、そしてプラットフォーム独自のプライバシー機能（Start SDK API、ATTシグナル、Data Privacy Framework）がどのように全体像に組み込まれるかを解説します。
AppsFlyerが収集するもの
AppsFlyer SDKはホストアプリが起動するとすぐにセッションを初期化し、デフォルトで一連の識別子とコンテキストシグナルを収集します：デバイスレベルの広告識別子（iOSではIDFA、AndroidではGAID）、iOS上のベンダースコープのIDFV、セッション間で永続する生成されたAppsFlyerインストールID、IPアドレス（ジオIP照合およびフィンガープリント方式の確率的マッチングに使用）、ユーザーエージェント、デバイスモデル、OSバージョン、キャリア、タイムゾーンです。インストール後、SDKはインストールイベントをAppsFlyerのサーバーに報告し、そこで広告ネットワークが転送したクリックデータと照合されます。その後のアプリ内イベント——購入、登録完了、チュートリアル完了、カスタムイベント——は同じSDKを通じて発火し、同じ識別子セットを継承します。
規制当局は、これがGDPRにおける個人データの処理であることを明確にしています。IDFAとGAIDは永続的なデバイスレベルの識別子であるため、個人データに該当します。それと並行して実行される確率的フィンガープリントマッチングは、定義上、ユーザーの明示的な協力なしにユーザーを識別する試みであるため、同意なしに正当化するのはさらに困難です。CNIL、イタリアのGarante、スペインのAEPDはいずれも、同意取得前にアトリビューションスタックを発火させたパブリッシャーに対する調査を開始しています。
AppsFlyerネイティブプライバシーコントロール
AppsFlyerは有意義なネイティブプライバシー機能のセットを公開しています。これらは真の同意フレームワークの代替にはなりませんが、CMPがSDKの動作を制御するためのレバーであるため、理解することが不可欠です。
Start SDK API
SDKは、設定されるがstart()が明示的に呼び出されるまでデータを送信しない初期化モードをサポートしています。これは同意ゲーティングにおける最も重要なフックです——デフォルトではSDKはアプリ起動時に自動的に開始されますが、これは事前同意要件のあるすべての法域にとって誤った動作です。初期化時にisStoppedをtrueに設定するか、遅延開始APIを使用し、同意シグナルが記録された場合にのみstart()を呼び出してください。
Stop API
セッション中に同意が撤回された場合、stop()を呼び出すとそれ以降のすべての送信が停止します。既に送信されたデータを遡って削除することはありません。完全な削除には、AppsFlyerのプライバシーポータルを通じてデータ主体削除リクエストを提出する必要があります——これは手動ワークフローではなく、AppsFlyer APIを介して自動化すべき統合です。
setSharingFilter
これは、どの下流広告ネットワークがポストバックデータを受信するかをフィルタリングします。粒度の細いパートナーごとの同意に適した機能です——例えば、一般的にアトリビューションを許可しつつ、ユーザーが拒否した特定のネットワークへの転送をブロックする場合に使用します。
Apple App Tracking Transparency統合
iOS上では、AppsFlyerはATT認可ステータスを読み取り、自動的に動作を調整します——ユーザーがATTを拒否した場合、IDFAは送信されません。ATTはGDPR同意とは独立しており、多くのパブリッシャーがこれらを混同しています。ATTはiOSレベルの単一シグナルを制御し、GDPR同意はそれ以外のすべてを制御します。
iOSでの統合
iOS上での信頼性の高いパターンは、AppsFlyer SDKをインストールするがATTとアプリ内同意フローの両方が完了するまで初期化を遅延させることです。最小シーケンスは次のとおりです：アプリが起動し、SDKがisStopped = trueで設定され、アプリ内同意バナーが表示され、ユーザーが該当カテゴリを承諾し、SDKのisStoppedフラグがクリアされてstart()が呼び出されます。アプリがATTも必要とする場合（IDFAが意味を持つすべてのユーザーに該当）、ATTプロンプトはアプリ内バナーと同時またはその後に表示されます。モバイルをサポートするほとんどのCMPは、同意決定を配信するコールバックベースのAPIを持っています。そのコールバックがstart()を呼び出す適切な場所です。
Androidでの統合
Androidの実装はiOSと並行しますが、2つの違いがあります。第一に、ATTに相当するものがありません——GAIDはユーザーがデバイスレベルの「広告IDを削除」設定を実行しない限り利用可能であり、ほとんどのユーザーはこれを行いません。第二に、Androidのライフサイクルはバックグラウンド化がより積極的であるため、SDK初期化は永続的に保存された同意状態に紐付ける必要があります。アプリ起動時にローカルストレージから同意状態を読み取り、それに応じてSDKを設定し、アプリがバックグラウンドにあった間にユーザーが選択を更新した場合に備えて、レジューム時に再確認してください。
モバイルウェブでの統合
AppsFlyerはスマートバナーおよびOneLink製品を通じてモバイルウェブでも動作します。これらは基本的にウェブサイド分析およびディープリンクツールであり、Cookieを設定しブラウザからAppsFlyerサーバーを呼び出します。他のウェブトラッキングサーフェスと同じルールに従います：CMPのマーケティングカテゴリの背後にゲートし、同意が付与される前にスマートバナースクリプトを実行させず、メールやプッシュキャンペーンからのOneLink起動イベントがユーザーの同意状態を尊重することを確認してください。
よくある落とし穴
AppsFlyerデプロイメントの監査で繰り返し見られる4つの統合ミスがあります。
ATTをGDPR同意として扱う
ATTとGDPR同意は、スコープの異なる異なるシグナルです。ATTを承諾したユーザーはクロスアプリトラッキングのためのIDFA使用を認可していますが、SDKが行うその他すべてを認可したわけではありません。EUおよびUKトラフィックでは両方のシグナルが必要であり、アプリ内バナーが拘束力のあるものであり、ATTはその上のiOS固有のレイヤーです。
SDKを起動時に初期化させる
これは最も一般的な単一の欠陥です。デフォルトの統合はstart()を即座に呼び出し、ユーザーが同意バナーを見る前に完全な識別子ペイロードを含むインストールイベントを発火します。修正は簡単です：統合時にisStopped = trueを設定し、同意コールバックからのみstart()を呼び出してください。
同意撤回の処理を忘れる
ユーザーが承諾した後に撤回した場合、SDKに送信停止を指示する必要があります。stop() APIを使用し、永続化された同意状態を更新して、次回のアプリ起動時に新しい決定が尊重されるようにしてください。
サーバー間ポストバックを無視する
AppsFlyerはサーバーサイドポストバックを介して、統合された広告ネットワークのロングテールにコンバージョンイベントを転送します。各転送は個人データを含み、元のイベントの同意スコープを継承します。setSharingFilterを使用して、転送がAppsFlyerダッシュボードのすべてのパートナーではなく、ユーザーの同意選択によってカバーされたパートナーにのみ送られるようにしてください。
監査チェックリスト
EU、UK、またはカリフォルニアのトラフィックに関わるすべてのAppsFlyerデプロイメントに対して回答すべき6つの具体的な質問です。
- SDKは同意を待っているか？ EU所在のテストデバイスでの新規インストール時に、ユーザーがバナーを承諾する前にAppsFlyerエンドポイントがリクエストを受信していないことを確認してください。
- ATTはアプリ内同意と分離されているか？ アプリ内バナーが制御する同意シグナルであり、ATTは追加のiOS固有レイヤーとして扱われていることを確認してください。
- パートナー転送は同意にスコープされているか？ setSharingFilterがユーザーが認可していないパートナーを除外するよう設定されていることを確認してください。
- 撤回はSDKを停止するか？ 同意撤回時にstop()が機能し、新しい状態が起動をまたいで永続することを確認してください。
- サーバーポストバックは監査されているか？ AppsFlyerダッシュボードの「設定済み統合」リストが、バナーで開示されたマーケティングパートナーと正確に対応していることを確認してください。
- データ削除は自動化されているか？ DSARリクエストが手動チケットではなく、AppsFlyerの削除APIをトリガーしていることを確認してください。
同意ファーストスタックにおけるAppsFlyerの位置づけ
モバイルアトリビューションはマーケティングスタックにおいて最も識別子集約的なサーフェスの一つであり、AppsFlyerのSDKはその中で最も影響力のある単一統合の一つです。良いニュースは、プラットフォームが同意適用をクリーンかつ検証可能にするために必要な機能——Start SDK、Stop、共有フィルター、削除API——を公開していることです。パブリッシャーに求められる作業は、これらの機能を拘束力のある同意決定を所有するCMPに接続し、ATTを代替ではなく補完的なシグナルとして扱い、サーバーサイドのパートナー転送がバナーに記録された同意エンベロープから逸脱できないようにすることです。正しく実装すれば、ユーザー獲得チームが依存するインストールおよびイベントデータを保持しながら、規制当局を満足させるアトリビューションスタックが実現します。