広告プラットフォームの無効トラフィックのフィルタリング：自社チームで作れるもの、検証ベンダーを買うべきとき

一般的な無効トラフィックのフィルタリングは自分たちで作り、高度な無効トラフィックの検出は、自前の不正対策チームを持てる場合を除いて、検証ベンダーから買うこと。既知のデータセンターのアドレス、申告済みのボット、目に見えない1x1の広告といった一般的な無効トラフィックは、リストとルールで捕まえられる。自社のエンジニアが、リクエストが届いたときと、ログの段階でもう一度、それを適用できる。乗っ取られたデバイスやなりすましアプリといった高度な無効トラフィックには、一つのプラットフォームが見る量をはるかに超えるトラフィックのデータと、それを研究するアナリストが必要だ。TAG のような認証プログラムも、資格のある第三者によるフィルタリングを求めている。

何が無効トラフィックにあたるのか

Media Rating Council（MRC）は、広告の測定を認定する米国の機関である。その Invalid Traffic Detection and Filtration Standards Addendum（2020年6月の改訂版。ここでのほかの資料と同じく2026年10月27日に参照）は、無効トラフィックを二種類に分けている。一般的な無効トラフィック、つまり GIVT は、「リストの適用やその他の標準化されたパラメーターのチェックによって実行される、日常的なフィルタリング手段で特定されるトラフィック」である。MRC が挙げる例には次のものがある。

• データセンターからの既知の無効トラフィック
• ボット、スパイダー、その他のクローラー
• ブラウザーではない user agent や、不明なブラウザーからのリクエスト
• 事前に読み込まれた、または事前にレンダリングされたが、その後実際のユーザーが一人も見なかったページ
• 0x0 や 1x1 ピクセルの広告のような、目に見えない掲載枠

高度な無効トラフィック、つまり SIVT は、「分析と特定のために、高度なアナリティクス、複数の地点からの裏づけや連携、相当な人手の介入などを必要とする、より検出の難しい状況」を指す。MRC が挙げる例には次のものがある。

• 自動化ソフトウェアとエミュレーター
• 感染したデバイスや乗っ取られたデバイス
• クリックファームのような、組織化された有償の人間による活動
• 強制的なクリックやリダイレクト
• 偽造された測定イベント
• なりすましのドメインやアプリ

自社のエンジニアはどのフィルターを作れるか

一般的な種類は、共有されることを前提にしている。MRC は、GIVT のフィルタリングは「ベンダー間で一貫していることを意図している」と書いており、そのため共通のリストに頼っている。社内チームは次の二つのリストを使う。

• IAB/ABC International Spiders & Bots List。IAB Tech Lab に代わって Alliance for Audited Media が管理している
• Data Center IP List。Trustworthy Accountability Group（TAG）が毎月発行している

リストに加えて、チームは user agent、広告サイズ、事前読み込みのリクエストについてのルールを書き、リクエストが届いたときと、イベントをログに記録するときにもう一度適用する。さらに、フィルタリングしたリクエストとその理由をすべて記録し、数字をパートナーに説明できるようにする。

MRC は、自らが監査する測定会社に対して、データセンターのトラフィックについての出発点を定めている。測定会社は、「既知の三大ホスティング事業者：Amazon AWS、Google、Microsoft」の IP アドレスからの無効トラフィックをフィルタリングしなければならない。それらのネットワークを通じてウェブにアクセスする実際のユーザーを誤って除外しないよう、例外も設けられている。

フィルタリングを行うタイミングは二つある。事前には、プラットフォームが広告リクエストをブロックするか、そのリクエストへの入札を見送る。事後には、ログと集計から無効なイベントを取り除く。MRC はこう書いている：「それぞれの手法には一定の長所と短所があり、どちらも、よく実行されたトラフィック保護戦略の中に居場所がある。」早い段階でブロックすれば、どのみちあとで捨てられるリクエストを処理するコストも省ける。

ブラウザーやアプリが共有するデータが減るにつれて、リストの効果は弱まる。2024年の改訂で、MRC はこう述べている：「IP アドレスが限られている、または存在しないこと、そして User Agent（UA）の文字列が粗くなることは、リストに基づく手法を損なうおそれがある。」

検証ベンダーにお金を払う価値があるのはいつか

高度なトラフィックの検出は、多くのパブリッシャー、アプリ、デバイスにまたがるパターンが見えるかどうかと、新しい手口を出てくるそばから追いかけるアナリストにかかっている。一つのプラットフォームには自分のトラフィックしか見えないので、多くのプラットフォームを横断して初めて現れるパターンを見逃す。これをうまくこなせるチームは、社内にある一つの不正対策会社に等しい。

認証が答えを決めることもある。TAG の Certified Against Fraud プログラムは、主要な要件の一つとして、「収益化可能な取引の100%が、資格のある第三者によって IVT の検出と除去のためにフィルタリングされること」を挙げている。TAG は、有効な認証シールを持つサプライサイドプラットフォームを通じて、パブリッシャーがこの要件を満たすことを認めている。買い手やパートナーが TAG の認証を求めるなら、自社で作ったフィルターだけではこの要件を満たせない。

MRC は、自らが認定するサービスの一覧を公表している。そのデジタル分野の一覧には、DoubleVerify、HUMAN、Integral Ad Science、Pixalate、Protected Media といった検証会社が含まれている。認定の対象は特定のサービスと指標なので、ベンダーには、どのサービスが認定を受けているのか、そこに高度な無効トラフィックが含まれるのかを聞くこと。

自作、購入、またはその両方：それぞれの道で何がカバーされるか

• 自社だけ：エンジニアの時間と、必要ならリストの購読料を費用として、一般的な無効トラフィックを捕まえられる。ルールとデータは自社のものになる。高度な手口はすり抜け、第三者によるフィルタリングの要件は満たされないままになる。
• ベンダーだけ：両方の種類が検出されるが、あらゆる判断がベンダーのシステムと料金に左右され、入札経路の中に置いたベンダーのチェックはリクエストごとに時間を増やす。
• 両方：自社のフィルターが明らかなトラフィックを早く安く取り除き、ベンダーはそれを通過したトラフィックだけを見る。

どの道を選んでも、プラットフォームは何をログに残す必要があるか

検出を担う側は、広告取引ごとの詳細を必要とする。MRC は、測定会社が可能な限り取得しなければならない項目を挙げている。たとえば次のものだ。

• イベントの種類、取引 ID、タイムスタンプ
• IP アドレス。トラフィックがプロキシを経由する場合は X-Forwarded-For ヘッダーも含む
• 完全な user agent の文字列とデバイスの種類
• アプリの識別子、または広告が表示されたページの完全な URL
• パブリッシャー、サイト、掲載枠の ID と、パブリッシャーの ads.txt または app-ads.txt の情報
• 入札リクエストに含まれる OpenRTB の属性

レポートでは、生の数字とフィルタリング後の数字を分けておくべきだ。キャンペーンのレポートについて、MRC の基準は「Gross Metrics (Completely Unfiltered)」と「Net Metrics (Filtered for GIVT Requirements)」を挙げている。該当する場合は、高度な無効トラフィックをフィルタリングした数字が別の段階として示される。イベントパイプラインがすでにイベントを取りこぼしたり二重に数えたりしているなら、先にそれを直すこと。フィルタリングは、それ以前から間違っていた数字を直せない。

フィルタリングを自社プラットフォームに組み込む会社に何を聞くべきか

• 各フィルターは入札経路のどこで動き、リクエストにどれだけの時間を加えるのか
• ベンダーのチェックが時間内に応答しなかった場合、リクエストは通すのか、捨てるのか
• リストはどう更新され、実際のユーザーが誤って除外されていないことを誰が確認するのか
• 自社のレポートとパートナーのレポートに、総数とフィルタリング後の数字はどう表示されるのか
• 各リクエストのどの項目を、どれだけの期間、どのプライバシールールのもとで保存するのか

最後の質問は MRC にとっても重要だ。2024年の改訂は、「プライバシー規制は、エンジニアリングで回避すべき障壁ではなく、遵守しなければならない厳格な要件である」と述べている。

amBrain はどこに位置づけられるか

このブログを発行する amBrain は、フィルタリングの組み込み先となるシステムを構築している。その一行はこうだ：「amBrainはアドサーバーを構築します：ターゲティング、フリークエンシーキャップ、レポーティング。」もう一行はこうだ：「amBrain はアドテク向けのイベント分析パイプラインを構築する。インプレッションとクリックのイベントの収集、処理、レポーティングである。」AdTech での仕事には、ある顧客のために構築したデマンドサイドプラットフォームである RTBBidder がある。

amBrain は2019年からソフトウェアを作っており、働き方には三つの形態がある：フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。所有権についての一文はこうだ：「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」

この記事は事例紹介ではない。amBrain がどの顧客のためにも不正検出を構築したとは述べておらず、検証サービスを提供しているとも述べていない。amBrain が候補リストに入っているなら、ほかのどの会社とも同じ質問を渡すこと。