すべての記事

大規模な広告検証:地理的真正性の問題

2025年、米国のプログラマティック広告は無効なトラフィックにより370億ドルの損失を出しました。この支出を検証するには、米国のデータセンターだけでなく、広告を購入する全市場でのローカルな視点が必要です。

Fraudlogixは、2025年の米国のプログラマティック無効トラフィックを20.64%と推計している。これは1,800億ドルの支出のうち約370億ドルが、ボット、偽装インベントリ、または広告目的のみのサイト(MFA)に配信されたことを意味する。DoubleVerify、IAS、Peer39などの検証ベンダーは、インプレッションの一部をサンプリングし、残りを評価する。ブランドは内部監査でギャップが判明するまで、その評価を信頼している。

そのギャップはここにある。米国のデータセンターIPからブラジルのキャンペーンをチェックしても、サンパウロのモバイルユーザーが見るものは表示されない。フォールバッククリエイティブか、別の落札者が表示されるか、何も表示されないかのいずれかである。現地の視点を持たない検証では、数値が現実と一致するかどうかはコイントスのようなものだ。

不正の割合も市場によって均一ではない。Fraudlogixの国別内訳によれば、韓国は23.47%、メキシコは22.81%、ブラジルは22.33%である。メディアプランが多数の国にまたがる場合、正確に評価するにはそれと同数の視点が必要になる。

アプローチ

プログラマティック広告の検証は、地理的に真正なレンダリングを必要とする3つの問題に分類される。

  1. プレースメント監査。 DSPが報告したURLのファーストビューに、安全なコンテンツと並んで広告が表示されたか。
  2. クリエイティブ確認。 意図したクリエイティブがレンダリングされたか、それとも悪意あるパブリッシャーがブランドにそぐわないものにすり替えたか。
  3. 遷移先検証。 クリック後の実際のランディングページはどこか。ランディングURLは国やデバイス、さらにはISPによって異なる場合がある。

これらは単一の視点からは機能しない。ヘッダー入札は閲覧者のブラウザ内でライブオークションを実行し、落札者はIP、cookie、デバイスプロファイルに依存する。フランクフルトとサンパウロから同じパブリッシャーのURLを同時にフェッチすると、2つの異なるHTMLドキュメントが取得される。これはサイトのバグではない。広告スタックが設計通りに機能している証拠だ。

一部の検証セットアップでは、User-Agentをpt-BRに固定し、Accept-Languageヘッダーを設定することで、ローカルビューを偽装しようとする。アドエクスチェンジはそんなこと気にしない。入札者はクライアントが主張するヘッダーではなく、報告されたIPの地理情報に基づいてルーティングする。IPがバージニア州のデータセンターとして解決されれば、ヘッダーでブラジルを主張していても米国のインベントリが提供される。ネットワークパスを回避する近道はない。

キャンペーンのターゲティングが厳密になるほど、この傾向は顕著になる。郵便番号とモバイルキャリアで定義されたリターゲティングプールは、フランクフルトのデータセンターからのアクセスでは広告なしと表示され、Deutsche TelekomのモバイルサブスクライバーIPからのアクセスでは実際のインプレッションとして表示される。どちらの結果も、それぞれが見たものとしては正しい。しかし、バイヤーが実際に見たものを教えてくれるのは後者だけだ。

したがって、インフラは同時に3つのことをこなす必要がある。ターゲット国の実際のISPからアクセスすること。広告枠が必要とする場合はJavaScriptをレンダリングすること。そして、オーディエンスではなくスクレイパーに見えるほど頻繁に、同じIPから同じパブリッシャーにアクセスするのを避けることである。

FourAのAPIを活用した実用的なパターンは以下の通りだ。

import requests

# Fetch the placement page from a Brazilian exit
r = requests.post(
    "https://api.foura.ai/api/proxy",
    headers={"Authorization": "Bearer pk_live_..."},
    json={
        "exitCountries": ["BR"],
        "maxTries": 5,
        "request": {
            "url": "https://publisher.example.com/article/1234",
            "validate": {
                "status": {"accept": [200]},
                "data":   {"fail":   ["captcha", "Just a moment"]}
            }
        }
    }
).json()

# r["data"] holds the HTML; the response also echoes the country that
# served the request, so you can log the market you observed from.
html = r.get("data")

JavaScriptの実行後にのみ広告枠が解決されるパブリッシャーの場合、URLを/api/autoに渡し、レンダリングパスを選択させます。Auto機能は、そのホストに対して実際にコンテンツを配信する国を学習し、将来の呼び出しをそれらの国経由でルーティングします。そのため、学習済みセッションのプールが増えるにつれて、1000件のURLに対するブランドセーフティスイープがより速く、より安価になります。不動産業界に関する記事では、別の業界における同様の地理的多様性のパターンについて解説しています。

結果

代表的なブランド側の構成: 12か国にわたる800の監視対象プレースメントURLを毎日2回チェックします。1日あたり19,200回のチェックとなり、それぞれ1回のAPI呼び出しで行われます。ホストごとにセッションがキャッシュされるため、後続の呼び出しの大半はブラウザのレンダリングをスキップします。チームが最終的に得られる結果は以下の通りです。

  • 月次サンプリングではなく、全市場を毎日監査。 検証ベンダーの1桁のサンプルレートを、最も予算を費やしているURLの完全なスイープで補完します。
  • 数時間での不一致検出。 クリエイティブの差し替えやプレースメントの変更は、キャンペーンが予算をさらに1日分消費する前にフラグが立てられます。
  • 自社クラウドのheadless環境より安価。 すべてのリージョンでブラウザファームを運用するコストや、さらに追加される住宅用proxyの契約コストが不要になります。チェックごとに1つのendpointを呼び出し、レンダリングされたページを取得するだけです。
  • チェックごとの監査証跡。 各レスポンスには、レンダリングされたHTML、それを配信した国、記録可能な不透明proxy IDが含まれます。不一致が生じた場合、ブランドチーム、代理店、またはパブリッシャーに提示できる正確な証拠が得られます。

実際の費用は、URLの数、頻度、フルブラウザレンダリングが必要な数によって異なります。しかし基本的な構造は同じです。周辺のインフラではなく、配信された結果に対して支払います。

重要なポイント

検証は測定の問題です。単一の視点を強く信頼しても精度は上がりません。視点を追加することで精度が上がります。12の市場は12の出口を意味します。それ以下は、レポート付きの推測に過ぎません。