ChronometricaとFortuitous Pirateの比較：Google広告の結果が空の場合の確認方法

業務に必要な結果報告の仕様を選ぶ

主な判断点は、対象ごとに明示された結果が業務手順で必要かどうかです。ここでいう結果報告の仕様とは、確認中に何が起きたかについて、プログラムが提供すると文書に明記している情報を指します。

Chronometricaは`targetOutcomes`を仕様に明記し、`no_results`と公開ソースを利用できない状態を区別しています。また、保存した有用なクリエイティブ、重複または収集に使えないためにスキップしたクリエイティブ、最終的な停止理由も明記しています。0行という結果を確認するために、これらの記録が必要なら選んでください。この推奨は、文書に明記された仕様に基づきます。ChronometricaのActor

Fortuitous Pirateの単一クエリ入力と、`advertiserId`、`proxyConfiguration`の設定が作業手順に合うなら、そのまま使ってください。確認したスキーマでは、過去のドイツ向けクエリと、プラットフォームと形式の両方が空欄の値を受け付けます。切り替えを決める前に、現在の実際のログと出力を確認してください。短いREADMEだけでは、ログや対象ごとの結果がないとは判断できません。Fortuitous PirateのActor

これらは選択の基準であり、性能を測定した結果ではありません。速度、価格、精度、収集範囲、信頼性の優位性を示す根拠はありません。

保存行数と公開ソースの状態を分けて確認する

空のデータセットが答えるのは、「クリエイティブの行を何行保存したか」という限られた問いです。公開ソースの状態が答えるのは、「プログラムが何にアクセスでき、何を利用できたか」という別の問いです。

確認時には、考えられる3つの説明を区別してください。

第1に、公開ソースにはアクセスできたものの、指定した対象とフィルターで有用な結果が見つからなかった可能性があります。次に行うのは、対象の識別情報と検索範囲の確認です。ドメイン、広告主、地域、日付が想定と異なると、見つかると考えていた内容も変わります。根拠が得られるまでは、原因を決めないでください。

第2に、確認時に公開ソースを利用できなかった可能性があります。その場合、0行のデータセットは広告主の広告活動を示しません。検索範囲について結論を出す前に、公開ソースへのアクセスを確認してください。

第3に、クリエイティブのページは表示できても、公開アセットを収集に使えない可能性があります。Chronometricaの結果判定ルールでは、利用可能な公開メディアまたはプレビューがないクリエイティブをスキップする場合があります。そのため、表示できるページと保存されたクリエイティブの行が、必ずしも1対1で対応するとは限りません。ChronometricaのActor

この区別によって、結果の報告方法も変わります。分かっていることがそれだけなら、「この設定で保存された有用な行は0行」と書いてください。「この広告主には広告がない」と省略しないでください。短くした表現では、結果の意味を決めるフィルター、公開ソースの条件、アセットの制限が抜け落ちます。

設定した上限も、別の事実として扱います。最大1行の要求は、1行が返るという約束ではありません。最大数を設定するものです。保存結果が0行なら、上限を上げるだけでは、それまでの結果の説明にはなりません。

実行前にドイツ向けの入力を準備する

Taskは、Actor用に保存された入力プリセットです。リンク先の地域別調査TaskのタイトルにはCanadaとあります。これを出発点として使い、実際に保存されている入力を確認してください。確認時には公開ページを利用できましたが、そのページの確認では、保存された各フィールドの値までは検証していません。地域別調査Task

サポートへの問い合わせにあるドイツの事例では、次の入力を使ってください。

{
  "targets": [
    "ritzenberger.de"
  ],
  "region": "DE",
  "platform": "ALL",
  "adFormat": "ALL",
  "includeDeliveryDetails": false,
  "maxItems": 1
}

この入力は、保存済みの公開JSON Schemaとの照合に合格しました。JSON Schemaは、使用できる入力フィールド、型、値を定義します。上記のすべてのフィールドは、確認したスキーマに存在します。これで確認できるのは入力形式です。実際に公開ソースへアクセスできることを確認したわけではなく、結果を保証するものでもありません。ChronometricaのActorの入力仕様

少量での確認を行う前に、次の手順を実施してください。

1. 報告されたドメインを、そのまま保持します。別途分かっている広告主の識別情報があれば、確認メモに残します。
2. Taskの入力を開き、地域を`DE`に変更します。Taskのタイトルに頼らず、保存済みの地域がすでに一致しているとも考えないでください。
3. この確認では、`platform`と`adFormat`を`ALL`に設定します。
4. 保存されたすべてのフィールドを確認します。出力とブラウザー上の表示を比較する前に、フィルターに関する不明点を解消します。
5. ここに示す最初の確認では、`maxItems`を`1`に保ちます。

公開ソースとの比較で使った日付範囲を記録してください。確認した根拠資料にActorの日付範囲が示されていなければ、不明と記録します。スキーマと照合していない入力フィールドを追加しないでください。

確認したスキーマでは、`targets`に1–100件の項目、`maxItems`に1–5,000の整数を指定できます。元の要件が、1回の実行で5,000件を超える結果を返す設定であるなら、このActorはその要件を満たしません。少量での確認を行っても、それより大きい範囲の全件取得という要求を満たしたことにはなりません。ChronometricaのActorの入力仕様

データセットと結果記録を併せて確認する

予定した少量での確認を実行したら、保存された行と結果記録を併せて確認してください。まず対象を確認します。次に、フィルター、公開ソースの状態、スキップされたクリエイティブ、停止理由を確認します。Chronometricaは、対象情報と結果の集計を通じて、これらを提供すると仕様に明記しています。ChronometricaのActor

簡潔な確認台帳を使ってください。ここでいう台帳とは、1つの対象について根拠を書き留めた記録です。

1. 特定された対象：確認処理が特定した広告主の識別情報を記録します。意図した広告主と異なる場合は、その違いを明示します。
2. 要求したフィルター：地域、プラットフォーム、形式、分かっている場合は日付範囲、要求した上限を記録します。
3. 公開ソースの状態：有用な結果がなかったことを結果記録が裏付けているのか、公開ソースを利用できなかったことを裏付けているのかを記録します。
4. 有用な行：実際に保存された行数を記録します。出力が0と報告している場合、または0であると確認できる場合だけ、0を使います。
5. スキップされたクリエイティブ：重複したクリエイティブと収集に使えないクリエイティブの件数を、出力どおりに記録します。不明な値や欠損値はそのまま保持します。
6. 最終的な停止理由：確認処理が終了した理由を記録します。データセットの件数だけから、その理由を推測しないでください。
7. 未解明の原因：得られた根拠では、まだ何を説明できないのかを記載します。

台帳は、1つの対象と1組の設定に対応させてください。そうしないと、後でフィルターを変更した際に、異なる条件で行った2回の確認を比べ、以前の結果と矛盾しているように見えることがあります。

スキップ件数は注意して読んでください。重複によるスキップと、アセットを利用できないことによるスキップでは、解釈が異なります。重複は、同じ素材が繰り返し現れることに関係します。アセットを利用できない場合は、そのクリエイティブを有用な行として保存できるかどうかに関係します。出力が実際に提供する詳細だけを使ってください。合計件数しか示されていない場合に、内訳を作らないでください。

値が欠けている場合は「不明」と書いてください。公開ソースの状態を示す根拠がないことと、公開ソースの障害が確認されたことは同じではありません。スキップ件数が欠けていても、スキップが0件だったと確認されたわけではありません。この区別を保つことで、後の確認にも使える記録になります。

架空の例：行数が同じでも、次の手順は異なる

次の例は架空です。Actorのテスト、実際のデータセット、顧客の結果ではありません。

分析担当者が、1つの対象を2回確認します。どちらの確認でも、保存されたクリエイティブは0行です。

確認Aでは、公開ソースにアクセスできます。結果記録には、明示されたフィルターの条件では有用な結果がなかったと報告されます。分析担当者は次に、特定された広告主とフィルターを、広告があると考える根拠になった公開画面と比較します。地域、プラットフォーム、形式、日付、公開ソースを確認した時刻を調べます。

確認Bでは、公開ソースを利用できません。分析担当者は、まず公開ソースへのアクセスを調べます。公開ソースを利用できなかったため、この確認から広告主の広告について結論を出すことはできません。

計算は単純です。確認Aで保存した行数は0行、確認Bで保存した行数も0行です。行数は同じです。公開ソースの状態は異なるため、次の手順も異なります。

どちらの確認でも、上限は1行でした。この上限は、どちらの確認にも1行を返すよう求めるものではありません。上限が制限したのは結果の最大件数であり、結果を保証したわけではありません。

どちらの結果も、広告主に広告がないことを証明しません。確認Aには、対象、フィルター、有用な結果の判定ルールによる制限が残ります。確認Bには、公開ソースへのアクセスによる制限が残ります。この例が示すのは確認方法であり、料金の見積もりや信頼性に関する主張ではありません。

小規模な受け入れテストで判断する

受け入れ確認とは、合格条件を文書にした小規模なテストです。ここでの目的は、結果が空になった理由について、出力から答えを得られるかを判断することです。

実行前に合格条件を決めてください。「この対象について、特定された広告主、要求したフィルター、公開ソースの状態、保存された行、スキップされたクリエイティブ、最終的な停止理由を確認できる」。この確認に合格するために、行数が1以上である必要はありません。結果が空でも、説明できれば有用な根拠になります。

次の手順に従ってください。

1. 期待する結果の根拠となる公開情報を書き留めます。ドメインまたは広告主、地域、表示されたクリエイティブの参照情報、確認した日時を記録します。元の入力は変更せず、メモに残します。
2. 入力形式を検証します。使用できるフィールドと値を、Actorの現在のスキーマと照合します。スキーマのエラーと、入力は有効でも有用な行が得られない検索を区別します。
3. 予定した少量での確認を実行します。確認済みの明示的な設定を使います。1件以上の結果を得ることだけを目的に、複数のフィルターを変更しないでください。
4. 台帳を完成させます。データセットと併せて、結果の根拠を読みます。未確認の値はすべて不明と記録します。
5. 次の行動を選びます。有用な結果がなければ識別情報とフィルターを確認します。公開ソースを利用できなければアクセスを確認します。収集に使えないクリエイティブがあれば、アセットの制限を確認します。

さらに確認する必要があれば、関連する設定を1つ変更し、その理由を記録してください。これにより、新しい結果を解釈しやすくなります。データセットが大きくなっても、説明が良くなるとは限りません。

解決しない場合は、非公開情報や機密情報を除いた入力、期待する結果の根拠となる公開情報、実際に得られた結果、残っている疑問を含むサポート報告を用意してください。入力から非公開情報や機密情報を取り除く処理を、サニタイズといいます。プロキシの認証情報や、その他の秘密情報を含めないでください。

この手順は、既存ツールを使い続けるかどうかを公平に判断する根拠にもなります。実際に得られる根拠が、設定した受け入れ条件を満たすかを判断してください。過去のサポート報告だけでは、現在の実行について判断できません。

空の結果に関する疑問が解消したら、地域別クリエイティブ比較ガイドを使い、保存したクリエイティブ群を地域間で比較してください。これは別の分析です。地域差の根拠として使う前に、空の結果が何を意味するのかを確認してください。