このガイドは、検索アービトラージプロバイダーのSystem1向けです。彼らのドキュメントはこちらをご覧ください。
一般的に、キーワードや様々な必要なデータパラメータの存在により、検索アービトラージのトラッキングはかなり難しい場合があります。
System1は、より複雑なデータ受け渡し設定の1つを持っています。IDを渡してポストバックで発火するのではなく、呼び出すべき事前に計算されたURL文字列を渡すことを期待しています。
そのため、click_id=xxxのようなものを渡す代わりに、postback_to_fire=https%3A%2F%2Fmydomain.com%2Fpb%3Fhit%3Dxxxのようなものを渡すことを期待しています。
もう混乱していますか？以下のガイドに従い、データ受け渡しの設定に十分注意を払ってください。
System1オファーソースの作成
まず、新しいオファーソースを作成し、System1テンプレートを使用します。
データ受け渡しセクションに注目してください：
ここには、考慮すべき非常に重要な点がいくつかあります：
- compkeyとrskeyを
{data-xxx}トークンを使用して渡しています。これは、値がトラフィックソースから使用するリンクを通じて来ることを意味します。そのため、トラフィックソースに対応するad_titleとkeywordのURLトラッキングフィールドがあり、これらが常にSystem1に適切な値を渡すことが重要です。 click_track_urlの下にポストバックURLを渡しています - これは後でSystem1によって発火されます。- この場合、アクションリンクである別のURLを
search_track_urlの下に渡しています - これは完全にオプションであり、ファネルにダミーランダーを追加する必要があります。これにより、検索アービトラージページでのCTRをシミュレートできますが、特に必要ではありません。結局のところ、検索アービトラージでは表示から変換への高いレートがあるため、中間のクリックはそれほど重要ではありません。これを追加するかどうかはあなたの選択です。追加する場合は、初期CTRのトラッキングに関する後のセクションを参照してください。 - 上記の特定の文字列は
https://{tracking-domain}/action/1?vid={visitor}&rn={current-node-id}です。
System1に事前に計算されたURLを渡すため、コンバージョントラッキングタブで行うことは何もなく、System1側でポストバックを設定する必要もありません。
使用するトラフィックソースの設定
前述のとおり、トラフィックソースからカスタムデータ（広告タイトルとキーワード）を渡す必要があり、これらの値がSystem1に渡されます。
先ほどの画像を確認してください - {data-ad_title}と{data-keyword}トークンを使用しています。
そのため、System1を通じた検索アービトラージ専用の新しいトラフィックソースを作成することをお勧めします。例えば、TikTok（System1）などです。適切なテンプレートを使用し、パラメータを追加または調整できます。TikTokテンプレートを例にとると：
ここでad_titleを追加してREPLACEに設定し、keyword トラッキングフィールドも追加して値をREPLACEに設定しました。
TikTokには広告タイトル/キーワードがないため、適切なタイトルパラメータを渡すために、URLを手動で広告ごとに置き換える必要があります。
Taboolaの例を見てみましょう：
ここでは、Taboolaにはタイトルのデータ受け渡しがあるため、そのまま使用できます。しかし、ここでもキーワードがないため、新しいkeywordフィールドを追加し、その値をREPLACEに設定する必要があります。
ここでの目標は、広告URLを生成し、それらのURLでREPLACEからそれ以外のものにデータを変更することです。ただし、以下のように、後でオファーレベルでオーバーライドすることもできます。
オファーへのキーワードデータの受け渡し
System1オファーの場合、オファーを作成し、アービトラージドメインをベースページURLとして使用します。URLの残りの構造はデータ受け渡しセクションで処理されます。
実行する各広告に対して、広告タイトルとキーワードの値を渡すことになります。これらの広告タイトル/キーワード値を変更する方法は2つあります。
オプション1：トラフィックソースからURLで渡す
これは上記で使用している設定です。
これにより、オファーは単一のオファー（検索アービトラージドメインURL）となり、異なる広告を作成して異なる値を渡し、異なる検索アービトラージページの結果を生成することができます。
レポートでは、このad titleトラッキングフィールドで分類してパフォーマンスを分析します。
オプション2：オファーレベルで渡す
これはすべてオファーソース/オファーによって設定されたデータ受け渡しなので、代わりにオファーレベルでハードコードすることもできます。
つまり、オファーを作成し、System1をオファーソースとして選択し、データ受け渡しに移動して、カスタム文字列オプションを使用してcompkeyまたはrskeyフィールドにオファーレベルのオーバーライドを追加できます。
この方法で、異なるキーワードに対して複数のオファーを作成し、これらを任意のオファーのようにファネルでローテーションさせることができます。
これにより、値はトラフィックソースの広告に依存せず、FunnelFlux内で制御されます：
これにより、レポートでキーワードを異なるオファーに分離できます。
この方法の利点は、FunnelFlux内でより多くの制御が可能で、広告に触れることなく、いつでもこれらを変更したり、ページをローテーションに追加/削除したりできることです。
欠点は、オファーの作成とファネルの設定に関するより多くの手作業が必要であり、広告と検索アービトラージページの間の一貫性が欠ける可能性があることです。
また、コンプライアンスを考慮し、広告タイトルがあるソースの場合、検索アービトラージパートナーが、ユーザーに表示される広告と一致しない可能性のある様々なキーワードを渡すことを許可するかどうかを検討する必要があります。
初期CTRのトラッキング
この部分はオプションです。
必要に応じて、初期検索アービトラージページのCTRを追跡しようとすることができます。これを行わない場合は、System1オファーソースからsearch_track_urlパラメータを削除できます。
したがって、ファネルでは、トラフィックノード --> オファーノード（System1オファー）--> ダミーランダーを次のように設定できます：
これの目的は、アクションを作成することだけです。そうすることで、オファーページでクリックが実際に発生する可能性があります - そうしないと、クリックスルーをトリガーする方法がありません。
ダミーランダーは何でも構いませんが、「Dummy CTR Page」のような新しいページを作成し、そのURLをhttps://mylanderdomain.com/non-existent-pageのようなものに設定することをお勧めします。
ページ自体はブラウザにロードされませんが、System1のサーバーがリダイレクトチェーンをたどる可能性がある場合、google.comやtest.comなどの実際のウェブサイトに多数のランダムなサーバーサイドURLリクエストをスパムしたくないためです。
これで、ユーザーが広告 > FunnelFlux URL > System1オファーページに移動すると、通常、クリックする様々なボタンが表示されます。クリック時に、FunnelFluxにアクションイベントが発火され、クリックスルーが追跡されます。次のページで何かをクリックすると、コンバージョンが送信されます。
これにより、初期ページのCTRについての洞察が得られ、アングル/一貫性を理解する上で重要になる可能性があります。
これは追加の手順/複雑さを伴うため、本当にデータが必要な場合にのみ行うことをお勧めします。そうでなければ、避けることができます。