広告レポートがビッダーのログと合わない理由と、誰がパイプラインを作り直せるのか

広告レポートがいつまでもビッダーのログと合わないとき、同じ差の裏には二つの問題が潜んでいることがある。イベントと呼ばれるインプレッションやクリックの記録が、多くはトラフィックのピーク時に、レポートへ届く途中で失われているか、双方がそれぞれのルールで数えているかだ。オークション ID、つまりエクスチェンジが各オークションに付けるコードによる再集計で、二つを見分けられる。誰かに依頼する前に、これを行う。新しいパイプラインだけで直るのは、一つ目の問題だけだからだ。

広告レポートがビッダーのログと合わないとき、それは何を意味するのか

ビッダーのログには、ビッダーが参加したすべてのオークション、行ったすべての入札、落札したすべてのオークションが記録されている。レポートは、ブラウザやアプリからのインプレッションやクリックのように、あとから届くイベントをもとに作られる。両者の差の原因は二つのうちのどちらか、あるいは両方だ:

• 失われたイベント。インプレッションやクリックは起きたのに、そのイベントがレポートに届かなかった。トラフィックのピーク時に広がる差は、処理しきれないものを捨ててしまう部分がパイプラインのどこかにあることを示している
• ルールの違い。双方が別のタイムゾーンで1日を締めていたり、遅れて届いたイベントを別の時間帯に入れていたりすることがある。片方が再送のあとでイベントを二重に数えたり、ビッダーが数えたままのボットのトラフィックを除外したりすることもある。アトリビューションには、クリックからどれだけ後までのコンバージョンを数えるかといった独自のルールが加わる

どちらにしても、この差は損失につながる。自社のレポートをもとに広告主へ請求しているなら、失われたインプレッションの分は少なく、二重に数えたインプレッションの分は多く請求することになる。一方で、各エクスチェンジはたいてい自分の集計にもとづいて請求してくる。これらのイベントから学習するビッダーも、誤った数字をもとに入札額を決めることになる。

失われたイベントと、別のルールで数えられたイベントは、どう見分けるのか

双方をイベントごとに突き合わせる。IAB Tech Lab のリアルタイムビディング用プロトコルである OpenRTB では、各オークションにエクスチェンジが割り当てる入札リクエスト ID が付き、リクエストの中の各インプレッションにもそれぞれ独自の ID が付く。ビッダーは、落札時にエクスチェンジが送る通知と広告そのものに、これらの ID を書き込むようエクスチェンジに求めることができる。そうすれば、各インプレッションのイベントに、ビッダーのログと同じ ID が含まれるようになる。

どちらの ID も、それだけでは足りない。OpenRTB 2.6 では、リクエスト ID は各エクスチェンジが独自に決めるので、二つのエクスチェンジが同じ ID を使うことを妨げるものはない。インプレッション ID が一意なのは自分のリクエストの内側だけで、たいていは 1 から始まる。だから、エクスチェンジ、リクエスト ID、インプレッション ID の三つの値を組み合わせて突き合わせる。

そのうえで再集計を行う:

• 混雑した1日について1時間ごとに、ビッダーのログにある落札と、レポートにあるインプレッションを、どちらも UTC で、この三つの値からなるキーで突き合わせて数える
• 翌日にもう一度数える。差が縮んでいれば、その一部は遅れて届いたイベントだった
• 依然として見つからない落札の割合が、最も混雑した時間帯に上がるなら、パイプラインはピーク時にイベントを失っている。割合が時間帯によらずほぼ同じなら、それは想定内だ。落札の一部は、インプレッションにならないからだ
• 残りを仕分ける。双方で別の時間帯に入っているイベントは、両者が異なるタイムゾーンか締め時刻を使っていることを意味する。二重計上はたいていリトライから生じる。最終レポートからだけイベントが欠けているなら、ボットのフィルタリングのような何らかのフィルタがそれを取り除いている

イベントにオークション ID が含まれていないなら、それを加えることが最初の修正になる。ID がなければ、再集計で比べられるのは合計だけだからだ。タイムスタンプと遅れて届くイベントについては、上でリンクした広告計測の技術記事が詳しく扱っている。

トラフィックのピーク時、イベントはどこで消えるのか

Kafka と ClickHouse で作ったパイプラインを例に取る。コレクタがブラウザやアプリから各イベントを受け取り、メッセージキューである Kafka に書き込む。ローダが Kafka から読み出し、レポートを支える分析用データベースである ClickHouse にイベントをバッチで書き込む。ピーク時には、どの段階でもイベントが消えうる:

• コレクタが過負荷になる。コレクタが拒否したリクエストや応答が遅すぎたリクエストは、ブラウザやアプリが送り直さない限り消える。イベントが Kafka に入る前に「受信した」と応答するコレクタは、クラッシュしたときに抱えていたものもすべて失う
• Kafka がイベントを十分な速さで受け取れない。Kafka のドキュメントは、イベントが受け渡せる速さを超えて届いたときに何が起きるかを説明している。Kafka に書き込むコードは決められた時間だけ待ち、それからエラーを出して諦める。そのエラーを無視するコレクタは、跡形もなくイベントを失う
• リトライが重複を生む。Kafka には、自身のリトライが2つ目のコピーを書き込まないようにする設定がある。Kafka の Java クライアントでは既定で有効になっているが、ほかの言語のクライアントライブラリはそれぞれ独自の既定値を持ち、無効のままにしているものもある。この設定は、再起動後に再送されたバッチや2回発火したピクセルのように、自社のコードが生む重複は捕まえない
• バッチ挿入は丸ごと失敗する。ClickHouse のドキュメントは、イベントを大きなバッチでロードするよう勧めている。ロード方式の一つでは、不正な形式の行が一つあるだけでバッチ全体が拒否される。そこで諦めるローダはバッチ内のイベントをすべて失い、そのまま再送するローダは同じ不正な行にまたぶつかる。だから不正な行は脇によけて数えておく必要がある。書き込みがタイムアウトし、保存されたのかどうか誰にもわからないとき、まったく同じバッチを再送して安全なのは、繰り返し届いたバッチを捨てるようにテーブルが設定されている場合だけだ。自前で運用する基本的な ClickHouse のテーブルは、既定ではそうなっていない

問題が起きた日の最も混雑した1時間について、次の記録をエンジニアに出してもらう:

• ロードバランサーとコレクタでのエラーとタイムアウト、そしてコレクタのログにある Kafka への書き込み失敗
• コンシューマラグ、つまりローダがどれだけ遅れたか。そして、Kafka のデータ保持期間より長く待たされたために、読まれないまま Kafka が削除したイベント
• ClickHouse への書き込み失敗と、そのエラーメッセージ
• すべての段階での1時間ごとの件数:コレクタが受信した数、Kafka に書き込まれた数、ローダが読み出した数、ClickHouse に保存された数

いちばん役に立つのは最後の記録だ。ピーク時に、ある段階の件数が落ちる一方で、その一つ前の段階の件数が保たれているなら、イベントはその二つの段階のあいだで消えている。

パイプラインを直すか、マネージドサービスに移るか、作り直すか

現在のパイプラインを直す:

• 向いているケース:再集計で見つかるのが主にルールの違いか、名指しできる少数の漏れで、修正後のパイプラインが最も混雑した1時間に追いつける
• コスト:開発の時間と、より大きなピークが次の弱点をあぶり出すリスク
• コードの所有者:自社。知識も自社のエンジニアに残る

Kafka なら Amazon MSK、ClickHouse なら ClickHouse Cloud のように、プロバイダーがサーバーを運用するマネージドサービスに移る:

• 向いているケース:エンジニアが集計ロジックよりも Kafka と ClickHouse のサーバーを動かし続けることに多くの時間を使っていて、損失がピーク時にそれらのサーバーの容量が尽きることから生じている
• コスト:トラフィックに応じて増える月々の請求。2026年10月7日に閲覧した両サービスの料金ページによれば、どちらもコンピューティングとストレージに課金し、ClickHouse Cloud は外向きのデータ転送と独自の取り込みサービスを別項目として挙げている。最も混雑した月の請求額と、あとで別の環境に移るときのコストを見積もっておく
• 解決しないこと:引き続き自社で運用するコレクタとローダ、重複、遅れて届くイベント、そしてビッダーのログとの突合。このサービスは送られたものを保存するだけで、ビッダーが何を数えたかについては何も知らない
• コードの所有者:自社。ただしサービスはプロバイダーの条件で運用される

パイプラインを作り直す:

• 向いているケース:再集計で複数の段階での損失が見つかる、あるいは設計がトラフィックの伸びについていけない。オークション ID が欠けていることが作り直しの理由になるのは、それを加えるためにすべての段階を変えなければならない場合だけだ
• コスト:三つの道のうちで最も多い開発作業に加え、古いパイプラインと新しいパイプラインを並行して動かす期間

Kafka と ClickHouse で広告イベントのパイプラインを作り直せるのは、どんな会社か

この仕事を手がける会社には二種類あり、この記事はどちらも順位付けしない。アドテクのエンジニアリング会社は、ビッダー、エクスチェンジ、アドサーバーを構築しているので、オークション ID がどこから来るかを知っている。ただし、自社と同じ規模のイベントパイプラインを運用したことがあるかは尋ねる。データエンジニアリング会社は、多くの業界向けにイベントパイプラインを構築しているが、アドテク向けとは限らない。OpenRTB を扱ったことがあるか、エクスチェンジと件数を突き合わせたことがあるかを尋ねる。

会社に依頼する前に、何を尋ねるべきか

候補リストのすべての会社に、同じ五つの質問をする。

重複をどう取り除くのか。期待すべき答えは、オークション ID とイベントの種類から作る ID を、どのリトライよりも前、イベントが生成された時点で各イベントに付ける、というものだ。パイプラインは重複を2回取り除く。イベントを保存するときに1回、レポートがそれを読むときにもう1回だ。2回目が重要なのは、ClickHouse がバックグラウンドで、予定の立てられないタイミングで重複を取り除くからだ。そのドキュメントは、この処理は「重複がないことを保証しない」と述べている。

遅れて届くイベントをどう扱うのか。期待すべき答えは、イベントの種類ごとに数字がまだ変わりうる期間が決まっていて、それを過ぎると数字が確定する時点がある、というものだ。それより遅れて届いたイベントも、捨てずに数え、遅延の印を付けるべきである。

自社のビッダーのログやパートナーのレポートと、数字をどう照らし合わせるのか。期待すべき答えは、オークション ID による毎日の再集計と、差ごとに書面で示す理由だ。差がどれだけの大きさになったら誰かがエクスチェンジに問題を提起するのかも、取り決めておく。

自社のピークを超える負荷でどうテストするのか。記録しておいた混雑した1日を、最も混雑した1時間より高いレートで再生してもらう。再生の途中で、コレクタを1台とデータベースサーバーを1台止めてもらう。終わったあと、すべてのイベントが、保存されているか、破棄されたものとして数えられているかのどちらかでなければならない。

コードは誰が所有するのか。自社であり、そのことを書面で定め、コードは初日から自社のリポジトリに置く。会社が手元に残すものは名前で列挙し、作業が終わったあとも使い、変更できるライセンスを付けるべきだ。

危険信号は何か

• 誰も再集計を行わず、ビッダーのログも開かないうちに、作り直しが提案される
• 新しいレポートはビッダーと完全に一致すると、会社が約束する
• 重複についての答えが、各イベントは「ちょうど1回」届けられるという約束だけで、2回発火するピクセルのように自社のコードが生む重複については何も語られない
• 証拠として示されるのが、自社のトラフィックの再生ではなく、作り物のイベントを使った負荷テストだけである

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

AdTech の分野では、amBrain は DSP 開発、リアルタイムビディングのプラットフォーム、アドエクスチェンジのエンジニアリングに取り組んでいる。その仕事には、amBrain がある顧客のために構築したデマンドサイドプラットフォームである RTBBidder も含まれる。

amBrain は、トレーディングとアドテクの遅いシステムを診断する。稼働中のプラットフォームをエンドツーエンドで計測し、時間がどこで費やされているかをレポートで特定する。

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

この記事は事例紹介ではない。どの顧客のイベントパイプラインについても述べておらず、RTBBidder は amBrain が構築した DSP として名前を挙げているだけだ。Kafka と ClickHouse はここでは例として挙げた技術スタックであり、amBrain のプロジェクトや amBrain が使うツールを説明するものではない。価格や期間も示さない。

レポートとビッダーのログが食い違っているなら、まず再集計を行う。そのうえで、その結果と同じ五つの質問を、amBrain を含め、候補リストのすべての会社に持ち込む。

よくある質問

• レポートとビッダーのログが100%一致することはあるのか。ない。OpenRTB は、落札を伝えるエクスチェンジのメッセージは「配信された広告、閲覧された広告、あるいは課金対象の広告であることを必ずしも示すものではない」としており、ボットのトラフィックとして除外されるイベントもある。目指すのは、差の内訳それぞれに書面の理由が付いた、安定した差だ。そして、どの集計にもとづいて請求するかを、パートナーごとに取り決めておく
• Kafka と ClickHouse を使わなければならないのか。そうではない。ほかのキューや分析用データベースでも同じ仕事はでき、再集計も五つの質問も、そのどれにでも当てはまる
• 新しいパイプラインを作るあいだ、古いレポートをどう動かし続けるのか。両方のパイプラインに同じイベントを流し、毎日それぞれをビッダーのログと比べる。請求のもとになるレポートの切り替えは最後に回し、請求期間をまるごと一つ通して、すべての差に説明がついてから行う