FunnelFlux Proには、ファネルを構築し、フル機能のキャンペーンを実行するために必要な前提条件となるリソースがいくつかあります。
それらは以下の通りです：
- トラフィックソース
- オファーソース
- オファー
- ランダー
- カスタムドメイン（リソースではありませんが、必要です）
以下は、これらの項目の設定と、それらがトラッキングプロセスにどのように影響するかの内訳です。
トラフィックソース
トラフィックソースは、訪問者の来訪元を定義し、キャンペーンURLを生成する際に選択する必要があります。
トラフィックソースの設定には、主に2つの要素があります：
- URLトラッキングフィールド
- コンバージョントラッキング
URLトラッキングフィールドの設定
以下の画像を参照してください：
FunnelFluxでは20個のカスタムトラッキングフィールドを設定でき、それぞれに名前（エイリアス）とオプションのプレースホルダー値を設定する必要があります。左側の数字はデータベースの列番号を表しています。つまり、この設定は名前→列IDのマッピングのためのエイリアスを作成しています。
トラッキングフィールドの設定は、リダイレクト/ダイレクトリンクを生成する際に使用されます - これらのフィールドはURLに追加されるトラフィックソース固有のクエリ文字列データを決定します。
削除できない予約フィールドが2つありますが、エイリアス化することはできます - キャンペーンとexternalです。
これらはそれぞれキャンペーンID値（またはキャンペーン名）とクリックトラッキングIDのために予約されています。
プレースホルダーはすべて、トラフィックソースが解析するトークン/マクロであるべきです（これらはトラフィックソースで使用されることが期待されるURLにあるため）、FunnelFluxトークンはランダー/オファーURLでトラフィックソースデータを転送するために使用可能なトークン形式です。
役立つメモ
- トラフィックソースは広告プラットフォームである必要はありません - メールのトラフィックソースを作成し、メールのマージタグをトークンとして使用することもできます。また、特定のアフィリエイト用にトラフィックソースを作成し、手動で作成されたフィールドを使用してユーザーに静的データを渡すこともできます。その場合、リンクを使用する際のヒューマンエラーを減らすため、プレースホルダーをREPLACEに設定するのがベストプラクティスです。
- トラッキングフィールドのプレースホルダーが空白の場合、生成されるURLからは省略されますが、URLデータが存在する場合はそのフィールドは依然としてキャプチャされます。
- 場合によっては、予約フィールドのロックを解除して名前を変更することが適切な場合があります。例えば、Facebookが自動的に「FBCLID」を追加する場合などです。テンプレートでは、externalフィールドをFBCLIDに名前変更し、プレースホルダーを空白にしています。このため、システムは生成されるURLにFBCLID=を追加しませんが、受信するFBCLIDクエリ文字列パラメータ値をキャプチャし、外部クリックIDとして保存します。
- ユーザーはいつでもフィールドの名前を変更できますが、これにより番号付けされた列にログインするデータが突然変更される可能性があるため、セットアップ後に各列番号に入ってくるデータを大幅に変更しないように注意する必要があります。むしろ、その番号付けされた行をアーカイブして新しいフィールドを作成するか、新しいトラフィックソースを使用する方が良いでしょう。
- アーカイブされたトラッキングフィールドは表示や報告のドロップダウンからは非表示になりますが、データには引き続き表示されます。アーカイブされたフィールドと同じ名前で新しい行を作成すると、重複するフィールドを作成するのではなく、そのフィールドがアーカイブ解除されます。アーカイブされたフィールドは、URLがそれを使用している場合、依然としてデータをキャプチャして保存するためです。
- フィールドの名前を変更する際、古いリンクURLデータを名前変更された値にマッピングするために、previousNameの値が保存されます。
コンバージョントラッキングの設定
ここでは、ユーザーがトラフィックソースにコンバージョンデータを返すための方法を設定できます。
ポストバックURLは、ソースへの単純なGETリクエストで、必要なデータと利用可能なクリックIDのための{external}トークンを渡します。
HTMLはJSまたは画像ピクセルを許可します。これを機能させるには、ユーザーは当社のJavaScriptトラッキングでコンバージョンをトラッキングする必要があり、設定されている場合、HTMLコードをページに同時に送信します。
カスタムシナリオは、様々なトラフィックソース用に作成したカスタム統合で、通常APIを含みます。
ユーザーは設定の詳細についてヘルプドキュメントを参照する必要があります。これらは利用可能な場合に活用すべきです。より信頼性の高いトラッキングを提供するためです。これらはすべてサーバー間ベースなので、コンバージョンがポストバックURLでFunnelFluxに渡される場合でも、JSでトリガーされる場合でも機能します。
オファーソース
これらはオファーの出所を定義し、通常はアフィリエイトネットワークです。ただし、ユーザーは「自社製品」やウェブサイト名などのソースを作成することもできます。
これらには3つの目的があります：
- データ受け渡しのテンプレート化。オファーがこのソースを使用する際、データ受け渡しの設定を継承するため。
- ポストバックURLのテンプレート化。ユーザーがネットワークにURLをコピー/ペーストしやすくするため。
- レポートの一般的なカテゴリとして。
注意：近い将来、データ受け渡しのパラダイムを更新する予定です。現在、オファーソースの設定は、オファー設定で選択された時点で一方向に継承されます。ユーザーがオファーソースを更新しても、オファーには変更が加えられません。将来的には、オファーがまずソースからデータ受け渡しの設定（およびその他の設定）を厳密に継承し、その後オファーレベルで追加のフィールドを設定したり、上書きしたりできるようにする予定です。
データ受け渡し
ここでは、ユーザーはフォームベースのアプローチを使用して、一般設定のベースページURLに追加されるクエリ文字列を構築できます。
このアプローチにより、ヒューマンエラーが減少し、データ受け渡しをより良くテンプレート化できます。
ベストプラクティスとして、ベースページURLには変更されることのない静的なURLデータをすべて含める必要があります。アフィリエイトURLの場合、これはしばしばアフィリエイト/オファーIDを含むことを意味します。
理想的には、すべての動的データはデータ受け渡しセクションで設定する必要があります。
役立つメモ
- vid、n、c、tsなど、FunnelFluxまたは当社のJavascriptによって渡される予約パラメータに使用されるいくつかのフィールド名は制限されています
- URLデータを渡すには、そのオプションを選択して、クエリ文字列のキー名のみを入力します。保存時に項目は
{data-url_key_name}に縮小されます - 後でこれを改善する予定です。 - トラッキングリンクで渡されるデータは、このトークンでアクセスできます。また、URLバッファに渡されるクエリ文字列データも同様です。つまり、定義されたトラッキングフィールドではないリダイレクトまたはアクションリンクに渡されるURLクエリ文字列データは、セッションデータに保存され、
{data-url_key_name}でアクセスできます。ただし、レポートでは利用できません。 - 複合データやその他のデータを渡す場合は、カスタム文字列を選択します。ここでは通常のようにトークンを使用できるので、例えば
{funnel-id}-{campaign}-{trafficsource-id}のようにできます。URL文字列のような複雑なデータを渡す場合、システムが保存時に自動的にURLエンコードするため、エンコードする必要はありません。
コンバージョントラッキング
このセクションはかなり自明です。
ポストバックURLのテンプレート化には、オファーソースのプラットフォームが解析して置き換える収益/オプションのトランザクションIDトークンを入力します。
ヒットIDについては、データ受け渡しで{hit}値を渡すフィールドをチェックします。例えば「aff_sub5」の場合、コンバージョントラッキングページでは、保存されたaff_sub5値を表すオファーソースの対応するトークン、例えば{aff_sub5}を入力する必要があります。
役立つメモ
- 同一のヒットIDとTxID値を持つFunnelFluxに渡されたコンバージョンは、現在、既存のコンバージョンを置き換えますが、重複を引き起こすことはありません。現在、これはコンバージョンのタイムスタンプを更新します。この機能を、元のタイムスタンプを更新しないように変更する予定です。つまり、新しいイベントが重複の場合、実質的に無視されます。
- 現在、コンバージョントラッキングは、トラフィックソースにイベントを発火させる際に重複排除されていません。したがって、FunnelFluxが内部でコンバージョンを重複排除しても、トラフィックソースにイベントが送信されます。この動作も更新し、重複イベントを送信しないようにする予定です。
- したがって、ユーザーが複数の正当なコンバージョンを発火させたい場合は、常にポストバックURL/JSの「tx」パラメータを介して一意のトランザクションID値を指定する必要があります。
オファー
オファーは、まず重要な設定を継承するためにオファーソースを選択する必要があります。これにより時間を節約し、ヒューマンエラーを減らすことができます。
オファーにはベースURLがあり、すべての静的データを含める必要があります。すべての動的データはデータ受け渡しセクションを通じて渡されます。
FunnelFluxがオファーにリダイレクトする際、ベースURL + データ受け渡し設定 = 最終オファーURLにリダイレクトします。
オファーカテゴリはレポートでのグループ化のためだけのものであり、機能的な影響はありません。
ページアクションリンク
これらはページで使用されるアクション（CTA）URLです。以下の形式の一般的なものです：
https://DOMAIN/action/number
FunnelFluxでは、ページ上のクリックスルーURL（アクションリンク）は目的地を指定しません。実行する「アクション」を参照します。クリック時に、FunnelFluxは現在のユーザーのファネル設定を処理し、現在の既知のノード位置に基づいて、そのノードからアクションXを実行します。
このように、FunnelFluxはユーザーの次の目的地を予測せず、ページ上にクリックスルー/アクションを作成しつつ特定のノードへのリダイレクトを強制するリンクを作成することはできません。
もちろん、条件ノードを使用して、アクションURLに渡されたURLデータに基づいてルーティングすることはできますが、これは別の機能です - ランダーからのアクションは依然として自然に次の予期されるノード（この場合は条件）に進みます。
アクションリンクは一般的であり、ページ、ファネル、ソースに特化する必要はないことに注意してください。ファネルビルダー内では、これらのアクションにデフォルトのパラメータを追加して取得することもできます。これについては、ファネルの技術文書で説明します。
統合製品ID
これはベータ版のセクションです - 特に、製品IDと訪問者IDを渡す予定のウェブフック統合のためのものです。オファーに製品IDが設定されている場合、X製品IDがYオファーでなければならないという相互参照が可能になります - つまり、それが変換されたオファーです。現在、使用は限定的です。
ランダー
オファーと同様に、ランダーは単なるページです。
アイコン/名前以外の主な違いは、ランダーには設定を継承する「ソース」がないことです
ランダーは、そのページ上のユーザーアクションから直接収益を生み出さない、またはそこから派生しないページに使用する必要があります。
例えば、チェックアウトページはおそらくオファーページになりますが、その前の商品販売ページはランダーになります。チェックアウトページがユーザーが最終的に変換する場所だからです。
訪問者が第三者、例えばアフィリエイトネットワークにリダイレクトされる終点となるページは、確実にランダーではなくオファーになります。
ランダーは変換しませんが、レポートでは後のユーザーの旅程で生成された収益と変換を継承することに注意してください。