affiliate кампейн向け Google 拡張コンバージョン設定ガイド

作成前に: 実際に信頼するコンバージョンを確認する

最初の設定判断は技術的なものではありません。支出の判断材料として十分に信頼できるイベントを決めることです。

payout 水準の主要イベントを選ぶ

ほとんどの affiliate funnel では、最適な主要コンバージョンは確定済みの sale、承認済みの lead、または payout で確認された transaction です。lead form の送信、checkout の閲覧、trial 開始も役立つ場合はありますが、最適化の階層では通常、最終的な revenue イベントの下に置くべきです。

クリーンなイベントモデルは次のようになります。

ClickBank や Digistore24 のような network が、ユーザーがページを離れた後に payout confirmation を送る場合は、network postback が status を確認するまで、初期コンバージョンを pending のままにしてください。そうすることで、Google 広告が、最終的に支払可能な revenue にならない結果から学習するのを防げます。

ロールアウト前にベースラインを設定する

1日か2日の好調だけで設定を判断しないでください。変更前に、少なくとも1つの通常の購入サイクル分のベースラインを取ってください。

導入前後で次の数値を追跡します。

• Google 広告で報告されたコンバージョンと network 確認済みコンバージョン。
• 1日あたりの重複 order ID。
• postback 遅延の中央値と P95。
• refund または reversal の遅延。
• Google 広告と自社台帳の間の conversion value 差分。

計画上の目安として、識別子が正しく正規化されると、帰属されるコンバージョンの有意な増加を期待するチームは多いです。期待される上振れは約束ではなく仮説として扱ってください。本当の検証は、重複を膨らませたり未払いイベントを数えたりせずに、マッチ品質が改善するかどうかです。

Step 1: 同意、データ処理、保持を準備する

拡張コンバージョンはファーストパーティデータに依存するため、構築は同意とガバナンスから始める必要があります。Google は拡張コンバージョンを、コンバージョン計測を改善するためにハッシュ化された顧客データを使うものとして説明していますが、データを適法に収集・処理する責任はなくなりません。

正当化できるフィールドだけを収集する

実用的な affiliate 設定は、通常 email から始まります。これは opt-in や checkout で一般的に得られるためです。phone、name、postal code も、自然に収集されるならマッチング改善に役立ちますが、トラフィックや compliance リスクを増やすだけなら、トラッキング目的で項目を追加しないでください。

最小限のフィールドセットを使います。

1. email address.
2. 国コード付き phone number.
3. first name と last name.
4. ZIP または postal code.
5. 利用可能なら country.

各フィールドには、明確な取得元、同意状態、保持ルールが必要です。同意がない場合でも、コンバージョンを内部的に記録することはできますが、その識別子を拡張コンバージョンの field として送信してはいけません。

保持とアクセスを文書化する

何が保存され、どこに保存され、誰がアクセスでき、いつ削除されるのかを書き出してください。小規模チームなら、新しいオファー、landing page、または network 統合が公開されるたびに見直される正確な簡易データマップで十分です。

ここで server-side の経路が役立ちます。文書化された affiliate tracking と compliance のワークフロー により、同意状態、hashing、payload の署名、重複排除を、ページや script に散らさず一か所で制御できます。

Step 2: 識別子を正しく正規化してハッシュ化する

正規化は、最も静かに失敗を生みやすい部分です。あるシステムが空白、大小文字、句読点、ローカルな phone 形式を保持し、別のシステムが保持しないと、同じユーザーでも異なる hash が生成されます。

ハッシュ化前に正規化する

ハッシュ化の前に、次の一貫したルールを適用します。

• 先頭と末尾の空白を削除する。
• email address を小文字にする。
• phone number から空白と句読点を削除する。
• 可能なら国コード付きで phone number を保存する。
• first name と last name を一貫して分ける。
• postal code は国ごとに文書化された形式で保持する。

ほとんどの拡張コンバージョン実装では、顧客識別子のハッシュ化に SHA-256 が使われます。重要なのはアルゴリズムだけではなく、同じ識別子が現れるたびに、正規化後の入力が毎回まったく同じであることを保証することです。

affiliate フローでは server-side hashing を優先する

browser-side hashing も試験運用なら機能します。特に thank-you page が完全なデータをすぐ受け取る場合です。しかし affiliate funnel にはリダイレクト、pre-sell page、遅延承認、network postback が多いため、server-side hashing の方が監査しやすいのが普通です。

server-side 実装なら、hash が生成されたか、同意があったか、order ID が既に存在していたかをログに残せます。これらのログは、Google 広告が affiliate network より少ないコンバージョンを報告したときや、network が重複 webhook を送るときに有用です。

Step 3: Google 広告の conversion action を設定する

すべてのイベントを1つの汎用 action に押し込めるのではなく、funnel の段階に合った conversion action を作成してください。混在したイベントは、入札データの解釈を難しくします。

action 名と value を具体的にする

Lead Submitted、Purchase Confirmed、Payout Verified Sale のように、実際のイベントを表す名前を使ってください。payout や order の value が分かっている場合は、value と currency を渡します。commission が product、tier、network によって変わるなら、その value が明確に推定値として文書化されていない限り、固定値を送らないでください。

Google の拡張コンバージョンのドキュメントと Google 広告のヘルプは、現在の設定画面、必須フィールド、アカウントレベルの設定に関する正しい情報源です。インターフェースが変わっても戦略的なルールは変わりません。各 conversion action には、決定論的なイベント名、value ルール、重複排除キーが必要です。

システム全体で1つの order ID を使う

Google 広告、landing stack、affiliate network、レポート用データベースのすべてで、同じ内部 order ID か transaction ID を使ってください。一時的な click ID に order ID を置き換えさせないでください。

良い重複排除ロジックは、次の3つの質問に答えます。

• この order ID はすでに計上されているか。
• その後 network はこれを reversal、refund、reject のどれかにしたか。
• 最初のイベント以降に conversion value は変わったか。

答えが変わるなら、レポートから reversal を隠すのではなく、プラットフォームがサポートする方法で適切な調整を送ってください。よりクリーンなアトリビューションは、財務的に正直である場合にのみ有用です。

Step 4: thank-you page と postback からイベントを送る

持続性のある affiliate 設定は、通常ページレベルのシグナルと server-side シグナルの両方を使います。ページイベントはユーザー行動に近い場所でコンバージョンを捉え、network postback はそれが支払い対象になったかを確認します。

まず thank-you page を検証する

管理されたテスト経路から始めてください。テスト lead か購入を送信し、thank-you page が1回だけ発火し、期待した conversion action を含み、placeholder 識別子を送っていないことを確認します。

各テストコンバージョンについて、次をログに残します。

• タイムスタンプ。
• conversion action 名。
• 内部 order ID.
• 同意状態。
• 識別子フィールドの有無。
• hash 生成ステータス。
• 利用可能なら Google 広告への取り込みステータス。

ログに欠落した order ID、不一致の hashing、重複した thank-you page 発火があるなら scale しないでください。これらの問題は、量が増えるほど高くつきます。

network postback で補強する

network webhook は、2つ目のコンバージョンを無条件に作成するのではなく、transaction の状態を更新すべきです。ClickBank、Digistore24、その他の類似 network では、postback が初期イベントの後に approval、payout value、refund、chargeback、cancellation を確認できます。

実用的なパターンは次の通りです。

1. page イベントを pending として記録する。
2. webhook を同じ order ID に一致させる。
3. payout status と value を更新する。
4. 最終的な confirmed イベントか調整を1回だけ送る。

これにより、Google 広告は経済的な真実により近づきつつ、キャンペーン管理に必要なタイムリーなコンバージョンシグナルも維持できます。

Step 5: 入札を変える前にマッチ品質を検証する

ロールアウトは、新しいシグナルが単に大きいだけでなく、よりクリーンであることを証明すべきです。報告上のコンバージョンが増えても、それが支払い結果と一致していなければ意味はありません。

管理された比較を行う

1つの安定したオファー、1つの traffic source、1つの学習ウィンドウを選びます。クリエイティブ、オファーページ、入札戦略を同時に変えずに、元の pixel-only またはベースライン action と、拡張コンバージョン action を比較します。

低〜中ボリュームのキャンペーンには 7-14 日の検証ウィンドウを使ってください。高ボリュームのアカウントではシグナルが早く見えることがありますが、それでも postback の遅延と重複挙動を観察する時間は必要です。

毎日の診断チェックリストを作る

ロールアウト中は毎日、次の項目を確認します。

• Google 広告のコンバージョンと network 確認済みコンバージョン。
• Google 広告内のマッチステータスまたは診断警告。
• hash 生成の失敗。
• 重複 transaction ID.
• 照合されていない network postback.
• refund と reversal の調整。
• ラグを反映した後の CPA と ROAS の推移。

運用上の有効な目標は、普遍的な match-rate の数字ではありません。payable revenue、order ID、conversion value を一致させたまま、説明できない不一致の原因を減らすことです。

Step 6: 計測品質をオファーの現実に結びつける

拡張コンバージョンは計測を改善します。affiliate offer がまだ新鮮か、compliance に適合しているか、利益を出しながら scale できるかを証明するものではありません。

tracking の伸びと市場の伸びを分けて考える

アトリビューションが改善し、CPA が下がったように見える場合でも、そのオファーが市場で持ちこたえているか確認してください。クリエイティブ疲労、競合の新しい angle、payout 変更、landing page 変更は、クリーンな tracking を実際より良く見せることがあります。

Daily Intel Service は、アクティブなオファーの動き、VSL の変更、クリエイティブの変化、funnel の挙動を監視することで、この2つ目の問いに役立ちます。これらの情報は、アトリビューションデータの代わりではなく、併用してください。

より規律ある運用ループのために、日次予算を増やす前に、tracking の結果を Daily Intel methodology と比較してください。そうすることで、判断は計測品質と現在の市場証拠の両方に結びつきます。

フル server-side pipeline が必要なタイミングを知る

拡張コンバージョンは、中程度の volume と扱いやすい postback 複雑性を持つ affiliate には十分なことが多いです。高い spend、複数 network、厳格な consent segmentation、refund、upsell、recurring billing がある場合は、フル server-side conversion pipeline の重要性が増します。

ベースラインデータがきれいなら、過剰に作り込まないでください。不一致が継続的かつ金銭的に重要なら、server-side 照合が通常次のステップです。

実装チェックリスト

設定完了と呼ぶ前に、このチェックリストを使ってください。

• 主要な conversion event が、支払い対象または高い確度の結果を反映している。
• 識別子を処理する前に consent status が取得されている。
• email、phone、name、postal フィールドが一貫して正規化されている。
• 必要な場合、正規化後に SHA-256 hashing が適用されている。
• 1つの transaction ID が Google 広告、network postback、台帳全体を通して使われている。
• 重複、refund、reversal、value 調整のルールが文書化されている。
• 7-14 日のテストで新しい設定をベースラインと比較している。
• budget の変更は、マッチ品質と payout 照合が一致するまで保留している。

Daily Intel Service は、tracking が信頼できるようになってからワークフローに入れるべきです。オファーと funnel が scale するのに十分な live momentum をまだ示しているかを判断するために使ってください。

よくある質問

Q: Google 拡張コンバージョンはすべての affiliate кампейнで必須ですか?
A: いいえ。リダイレクト、cookie 失効、iOS traffic、遅延 postback、クロスデバイス行動によって pixel のみのレポートが信頼できない場合に最も有用です。アトリビューションが安定しているシンプルな funnel では、すぐには不要かもしれません。

Q: affiliate はどの顧客データを送るべきですか?
A: あなたの funnel がすでに収集している、同意済みで正規化された識別子だけを送ってください。たとえば email、phone、name、postal code、country です。生の値は内部で管理し、外部に送る拡張コンバージョンの field は Google の必須ハッシュ化とフォーマット規則に従う必要があります。

Q: hashing は browser と server のどちらで行うべきですか?
A: server-side hashing の方が、監査しやすく、network postback と照合しやすく、page-level script failure から保護しやすいため、affiliate кампейнでは通常より適しています。browser-side hashing は限定的な pilot では許容される場合があります。

Q: 入札変更の前にどれくらいテストすべきですか?
A: ほとんどの低〜中ボリューム кампейн では 7-14 日の検証ウィンドウを使ってください。spend を増やす前に、マッチ品質、重複率、コンバージョンの遅延、CPA、payout 確認済み revenue を比較します。

Q: 拡張コンバージョンは ClickBank、Digistore24、その他の affiliate network で使えますか?
A: はい。ただし、各 network postback が同じ内部 transaction ID と照合ルールにマップされる必要があります。network は重複コンバージョンを作るのではなく、payout status、value、refund、reject state を更新すべきです。

Q: より良いアトリビューションは、そのオファーが scale 準備完了という意味ですか?
A: いいえ。より良いアトリビューションは何が起きたかをより正確に示すだけで、オファーがまだ競争力を持つことを証明するものではありません。予算を増やす前に、現在の creative、funnel、payout、market のシグナルを検証してください。