AppsFlyer Protect360の使い方|
不正インストール検知・ポストアトリビューション分析
アプリ広告の運用において、アドフラウド(広告不正)は広告費を無駄にする深刻な問題です。AppsFlyerが提供する不正検知ソリューション「Protect360」を活用すれば、不正インストールをリアルタイムでブロックし、事後分析で見逃しも回収できます。本記事では、Protect360の主要機能から実務での活用方法まで体系的に解説します。
この記事のポイント
- Protect360はリアルタイムブロックとポストアトリビューション分析の二段構えで不正を検知する
- Validation Rulesを設定することで、自社の基準に合わせたカスタム不正検知が可能
- 不正検知後は証拠を整理して媒体に報告し、リファンド交渉につなげるフローが重要
Protect360とは
Protect360は、モバイル計測ツール(MMP)大手のAppsFlyerが提供するアドフラウド検知・防止ソリューションです。アプリ広告における不正なインストールやアプリ内イベントを検知し、広告主の広告費を守ることを目的としています。
アドフラウドの手口は年々巧妙化しており、クリックスパム、クリックインジェクション、デバイスファーム、SDKスプーフィングなど多岐にわたります。Protect360は機械学習ベースのアルゴリズムと行動分析エンジンを組み合わせることで、これらの不正パターンを高精度で検知します。
主な検知対象は以下の通りです。
- クリックフラッディング(Click Flooding):大量のクリックを送信し、オーガニックインストールの成果を横取りする手口
- クリックインジェクション(Click Injection):アプリのインストール完了直前にクリックを差し込み、アトリビューションを奪う手口
- デバイスファーム(Device Farm):大量の実機やエミュレータを使って偽のインストールを生成する手口
- SDKスプーフィング(SDK Spoofing):実際のインストールなしにSDK通信を偽装してインストールをでっちあげる手口
- ボット/エミュレータ:自動化プログラムや仮想端末による偽トラフィック
リアルタイムブロック機能
Protect360の最大の特徴は、インストールが発生した瞬間に不正を判定し、アトリビューションから除外するリアルタイムブロック機能です。不正と判定されたインストールはAppsFlyerのダッシュボードおよびレポートにおいて「ブロック済み」として記録され、メディアソースへの成果としてカウントされません。
リアルタイムブロックの判定ロジック
リアルタイムブロックでは、主に以下の観点でインストールの正当性を評価します。
- CTIT(Click-To-Install Time)異常:クリックからインストールまでの時間が極端に短い(クリックインジェクションの兆候)または極端に長い(クリックフラッディングの兆候)場合にブロック
- デバイスパラメータ異常:エミュレータ特有のデバイス情報、改ざんされたデバイスID、異常なOSバージョンなどを検知
- 行動パターン異常:同一IPアドレスからの大量インストール、非人間的なクリックパターンなどを統計的に判定
- 既知の不正リスト:過去に不正と確認されたデバイスID、IPアドレス、サイトIDのブラックリストと照合
リアルタイムブロックの結果は、AppsFlyerの管理画面で即座に確認できます。ブロックされたインストールは「Blocked Installs」として専用レポートに集計されるため、どのメディアソースからどの程度の不正が発生しているかをリアルタイムに把握できます。
ポストアトリビューション分析
リアルタイムブロックだけでは検知しきれない巧妙な不正も存在します。ポストアトリビューション分析は、一度アトリビューションされたインストールを事後的に再評価し、不正の疑いがあるものを特定する機能です。
リアルタイムではデータが不十分で判定できなかったケースでも、一定期間のデータが蓄積されると統計的な異常が浮かび上がります。例えば以下のような不正パターンは、ポストアトリビューションで検知されやすいです。
- 異常なアプリ内行動:インストール後にアプリを一度も起動しない、あるいは全ユーザーが同一の行動パターンを示す
- 異常なリテンション率:特定メディアソースからのインストールのリテンション率が極端に低い(デバイスファームの兆候)
- 時系列の異常:特定の時間帯にインストールが集中するなど、人間の行動として不自然な分布
ポストアトリビューションで不正と判定されたインストールは「Post-Attribution Fraud」レポートに表示されます。このレポートは媒体へのリファンド交渉における最も重要なエビデンスになるため、定期的な確認が不可欠です。
Validation Rulesの設定
Protect360の標準的な不正検知に加えて、Validation Rulesを設定することで、自社独自の基準に基づいたカスタムルールを追加できます。AppsFlyerの管理画面からGUIで設定可能で、プログラミングの知識は不要です。
代表的なValidation Rulesの設定例
- CTIT閾値の設定:クリックからインストールまでの時間が10秒未満のインストールをブロック(クリックインジェクション対策)。アプリのダウンロードサイズに応じて閾値を調整
- 地域フィルター:配信対象外の国や地域からのインストールをブロック。日本向けのキャンペーンに海外からの大量インストールが入る場合に有効
- OSバージョン制限:古すぎるOSバージョンやサポート外のバージョンからのインストールをブロック
- サイトID(Sub Publisher)フィルター:不正率の高い特定のサイトIDをブラックリスト登録
Validation Rulesは設定後すぐに適用され、条件に合致したインストールはリアルタイムでブロックされます。ただし、閾値を厳しくしすぎると正規のインストールまでブロックしてしまうリスクがあるため、設定後はブロック率の推移を注視し、必要に応じて調整してください。
ダッシュボードの見方
Protect360のダッシュボードでは、不正検知に関する主要な指標を一覧で確認できます。運用で注目すべき項目を解説します。
主要指標
- 不正率(Fraud Rate):全インストールに占める不正インストールの割合。業界平均は10〜15%程度ですが、ネットワーク広告やリワード広告では20〜30%に達するケースもあります
- ブロック数(Blocked Installs):リアルタイムブロックで防いだインストール数。日別・週別の推移で異常な増加を検知
- ポストアトリビューション不正数:事後分析で検知された不正インストール数。こちらはリファンド対象の根拠になります
- メディアソース別不正分布:どのメディアソース(アドネットワーク)から不正が多いかを可視化。不正率が高いソースは出稿停止や交渉の対象
サイトID別の分析
メディアソースの中でも、特にサイトID(Sub Publisher)単位での不正率を確認することが重要です。同じアドネットワーク内でも、不正率が0%のサイトIDと50%以上のサイトIDが混在していることは珍しくありません。サイトID単位でブラックリスト登録することで、ネットワーク全体を停止せずに不正を排除できます。
TikTok/Pangle経由の不正パターンと対策
TikTok広告はSRN(Self-Reporting Network)としてAppsFlyerと直接連携しており、TikTok本体の広告在庫における不正率は比較的低い傾向にあります。一方、Pangle(TikTokのオーディエンスネットワーク)経由のトラフィックでは注意が必要です。
Pangleで発生しやすい不正パターン
- クリックフラッディング:Pangleに接続している一部のパブリッシャーが、バックグラウンドで大量のクリックを発生させるケース
- 低品質トラフィック:リワード動画広告枠経由で、ユーザーの意図しないインストールが発生するケース
- CTIT異常:クリックからインストールまでの時間が不自然に短い、または長いインストールの割合が高いケース
TikTok/Pangle向けの推奨対策
- Pangleのサイトレポートを定期確認:TikTok Ads Managerの「サイトレポート」で、パブリッシャー単位のパフォーマンスと不正率を確認
- ブラックリスト運用:不正率の高いサイトIDをTikTok Ads Manager側でブロック設定
- Validation RulesでCTIT閾値を設定:アプリのサイズに応じた適切なCTIT下限値を設定し、クリックインジェクションを排除
- TikTokとPangleを別キャンペーンで管理:不正率の分析を容易にするため、TikTok本体とPangleの配信を分離
不正検知後の対応フロー
Protect360で不正を検知した後の対応は、大きく3つのステップに分かれます。
STEP 1:証拠の収集と整理
Protect360のダッシュボードおよびローデータレポートから、以下の情報を整理します。
- 不正と判定されたインストールの一覧(デバイスID、タイムスタンプ、メディアソース、サイトID)
- 不正の種類別の内訳(クリックフラッディング、デバイスファーム等)
- 対象期間における不正率の推移
- 正規インストールとの行動データの比較(リテンション率、アプリ内イベント発生率など)
STEP 2:媒体への報告
収集した証拠をもとに、該当するアドネットワークやメディアパートナーに不正レポートを送付します。報告時のポイントは以下の通りです。
- Protect360のレポートをそのままエビデンスとして添付する(多くの媒体がAppsFlyerのレポートを正式なエビデンスとして受け入れています)
- 不正の種類と件数を明確に記載する
- 対象期間と対象キャンペーンを特定する
- 要望(リファンド、サイトIDのブロック、再発防止策)を具体的に伝える
STEP 3:リファンド交渉と再発防止
媒体からの回答をもとに、リファンド(返金)の交渉を進めます。リファンド交渉は以下の点に注意してください。
- 報告のタイミング:ポストアトリビューションレポートは月次で確定するため、翌月初に前月分をまとめて報告するのが効率的
- 契約条件の確認:アドネットワークとの契約書にフラウド関連の条項がある場合、それに準拠した手続きを踏む
- 再発防止:不正率の高いサイトIDのブラックリスト登録、Validation Rulesの追加、場合によっては媒体自体の停止を検討
不正対策も含めた運用を:アドフラウド対策は広告運用の重要な一部です。ZVAでは成果報酬型で縦型動画広告を運用しており、不正インストールは成果としてカウントしません。Protect360を活用した不正検知・排除の運用ノウハウを蓄積し、広告主の費用対効果を最大化する体制を整えています。
まとめ
AppsFlyer Protect360は、リアルタイムブロックとポストアトリビューション分析の二段構えでアドフラウドからアプリ広告を守る強力なソリューションです。Validation Rulesによるカスタムルール設定や、サイトID単位での詳細な不正分析も可能で、運用者が主体的に不正対策を行うための基盤を提供します。
特にTikTok/Pangle経由の広告配信では、Pangleのパブリッシャー品質のばらつきに注意が必要です。Protect360のデータを活用してブラックリスト運用やCTIT閾値の調整を行い、不正トラフィックを排除しながら健全なスケーリングを目指しましょう。不正検知後の媒体への報告とリファンド交渉まで一貫して実行することが、広告費の無駄を防ぐ鍵です。