FunnelFluxには2つの固有の識別子があり、以下に詳細を説明します。
ヒットID
ヒットIDは、訪問者がノードを閲覧するたびに生成されます。
これらは当社システムで最も一意なIDです。訪問されたすべてのノード(ローテーターも含む)がヒットIDを生成し、これらは分析データベースに保存される生のイベントです。URLで{hit}
トークンを使用して渡すことができます。
レポーティング
ヒットIDは生イベントページでのみ利用可能です
生イベントページでは「Hit ID」列に表示され、通常のレポーティングでは高いカーディナリティ(つまり、分析データベースがこれらで集計するのは非常にパフォーマンスの悪いクエリであり、避けるべきです)のため利用できません。
生イベントページは、どのクエリでも最新の1000行のみを返すことに注意してください - 上記のパフォーマンスの問題を避けるためです。
「訪問者の旅」レポーティング属性を使用する場合、これらのヒットIDによってファネルを通じたユーザーの旅のノードツリーを作成することができます。
コンバージョントラッキング
最も一般的なコンバージョントラッキングの形式は、ヒットIDを使用したポストバックURLです:
https://USER_DOMAIN/pb/?hit=HIT_ID&rev=REVENUE&tx=OPTIONAL
ヒットIDはページの表示時に生成されるので、オファーにリダイレクトする場合、そのオファーURLで{hit}
で渡されるヒットIDがそのページの表示を表し、したがってコンバートするIDとなります。
コンバートの対象となるすべてのオファーヒットIDは「h」で終わります。
JavaScriptでのコンバージョンではヒットIDを指定でき、これは正確で他のデータは必要ありません。ただし、クライアントサイドJSに正しいヒットIDをキャプチャして押し込むことは unlikely です。なぜなら、コンバートすべきヒットは通常前のページからのものだからです。
あるページから次のページへヒットを渡せる場合、JSを使用するよりも、そのヒットIDでポストバックURLへのGETリクエストを使用してヒットをコンバートする方が良いかもしれません。
訪問者ID
これらは{visitor}
トークンを持ち、ユーザーのセッションレベルの識別子です。
当社のシステムは、新しく到着した訪問者に対してこれらを作成し、すべてのリダイレクト先に自動的に&vid={visitor}
を追加して、結果のページ(多くの場合、当社のJSが付いたランダー/オファー)がユーザーをシームレスにトラッキングできるようにします。
当社のクッキーはこのVID値を保存し、これはユーザーの信頼性の高いトラッキングを確保するための最も重要な値です。これが、当社のJSヘルパー関数がURLを書き換えてこれを含め、アクションURLに挿入する理由です。
キャッシングとストレージ
ユーザーセッションデータは、リダイレクト処理中に地域のエッジサーバーがアクセスする中央集中型キャッシュに保存されます。セッションオブジェクトは、ユーザーのファネルナビゲーションの全履歴と、トラフィックソースから付随するすべてのURLパラメータ、またはアクション/エントランスURLに手動で挿入されたパラメータを保存します。
これらの訪問者IDは、アジア、ヨーロッパ、米国に位置する訪問に対してそれぞれa、e、uのプレフィックスが付きます。これにより、他のエッジが地域外のIDを受け取った場合に正しいキャッシュから検索できます。これは、ユーザーが位置を変更したり、旅の途中でVPNを使用したり、サードパーティシステムがVID値を使用してサーバーサイドのコンバージョンイベントを送信したりする場合に重要です。
セッションは、ファネル設定でリンクされたファネルが宣言されていない限り、デフォルトで7日後に有効期限が切れます。
URLデータ
特筆すべきは、すべてのURLデータがセッションオブジェクトに保存されますが、トラフィックソース設定で指定された名前付きフィールドのみが分析データベースにコミットされることです。したがって、このセッションオブジェクトを使用して一時的なデータをURLに渡し、ページ/オファーに転送することが可能です。
ファネルビルダー > ページノード > 追加設定では、蓄積されたURLパラメータトグルがこのセッションオブジェクトのURLデータを宛先ページURLにダンプします。
コンバージョントラッキング
コンバージョンは、訪問者IDまたはヒットIDを使用して当社のポストバックURLを介して送信できます。
ヒットIDは当社システムで最も特定のIDであり、単一の訪問者による特定のノードの特定の表示を参照します - したがってヒットIDのみが必要です。
訪問者IDの場合、彼らが閲覧したページも重要な情報です。なぜなら、訪問者IDはユーザーセッションのみを識別し、どのオファーをコンバートするかは識別しないからです。
したがって、これはポストバックURLとして機能します:
https://USER_DOMAIN/pb/?vid=VISITOR_ID&p=PAGE_ID&rev=REVENUE&tx=OPTIONAL
ページIDが提供されない場合、その訪問者の最新のオファービューがコンバートされます(これが望ましい結果でない可能性があります)。
JavaScriptでのコンバージョンは、JSが最終的に一貫したVIDトラッキングに依存しているため、理想的にはコードにvidも含める必要があります。
これは手動で挿入できますが、JSは現在のURL、クッキー、リファラーから容易にこの情報を取得します(利用可能な場合)。動的に挿入できる場合は、そうすることが最善です。
VIDが使用される場合、ページID(p属性)も押し込むのが理想的で、VIDと組み合わせてヒットIDを送信することは避けてください。これらは競合する方法であり、後者がより具体的です。
レポーティング
生イベントページでは「session ID」列に表示され、通常のレポーティングでは高いカーディナリティ(つまり、分析データベースがこれらで集計するのは非常にパフォーマンスの悪いクエリであり、避けるべきです)のため利用できません
リンクされたファネルと間接的なコンバージョン
FunnelFluxの1つの機能は、以前のファネルに間接的に収益/コンバージョンを帰属させる能力です。
これは、最初のファネルが2番目のファネルを高度な設定で「リンクされたファネル」として宣言することで実現されます。
リンクされたファネルが存在する場合、セッションの有効期限は30日に延長されます。
ファネルBでコンバージョンが発生すると、コンバージョンプロセッサーはユーザーのセッションデータを検査し、ファネルBに「リンク」されている元のファネルAを確認し、さらに間接的なコンバージョンを戻します。
このコンバージョン/収益データはレポーティングで表示でき、ユーザーは後のファネルから来るユーザーの拡張された価値を見ることができます。
良い例は、ユーザーが広告キャンペーンからのリードのコストを追跡しているオプトインファネルです。そのファネルは、ユーザーがメールシーケンスで使用するリンクを生成しているメールファネルにリンクする可能性があります。メールはコンバージョンを作成し、メールファネル内で独立して追跡されますが、元のオプトインファネルに間接的な収益を通知します。
この機能が機能するためには、ユーザーのVID値をファネルBで使用されるエントランスURLに渡す必要があります。通常、..&vid=%SUBSCRIBER_FF_VID%
のようなものをURLに手動で追加します。ここで、ユーザーはオプトイン時に当社のVIDをキャプチャし、CRMプロファイル属性に保存しています。