FunnelFluxには、主に3つのナビゲーション関連のアクションがあります：
- 入口リンクのロード:
/fts/ - アクションリンクのロード:
/action/x - JSによるページビューのトラッキング: POSTを
/js/funnelへ
入口リンクは非常に厳密で、目的地へのルーティングに必要なすべてのデータを含んでいます（UIで生成したものなので）。機能すれば、他の文脈的な履歴を無視して、指定された場所に正確に移動します。入口リンクはファネルへの新しい独立した入口だからです。
後者の2つのケースでは、FunnelFlux Proのエッジは利用可能な情報を使用して、ユーザーがどのノード/ページにいるかを判断し、アクションの場合はどの接続を進むかを決定します。
これらは正しく設定されていないと問題が発生する可能性があるため、このセクションではJavaScriptとアクションリンクが現在のページと、それぞれ発信元のページ/ノードをどのように判断するかをまとめます。
アクションリンクのロジック
アクションリンクは常に、訪問者が「いると思われる」ノードから延びる番号付きのアクションを実行します。
ファネルをテストして移動する際は、ファネル図を考慮し、各アクションによってどのようにノードから次のノードへ移動するかを考え、自分がどのノードにいるか（つまり、トラッカーがあなたがどこにいると知っているか）を把握することが有用です。
ページに移動し、アクションリンクをクリックすると新しいタブで開く状況を考えてみてください。元のタブに戻ってリンクを再度クリックします。これで、現在知られているノードの位置より前の以前のノードからアクションを開始することになります。
2つ目のシナリオでは、アクションリンクが新しいタブで開かない場合を考えてみましょう。ブラウザの戻るボタンをクリックすると、前のページがロードされます。このページにビュートラッキングJSがない場合、トラッカーはあなたがそこに戻ったことを認識しません。ここでアクションリンクをクリックすると、再び以前のノードからアクションを開始することになります。
両方のケースで、トラッカーはクリックの発信元ノードを判断することで、これらの繰り返しクリックを判断するメカニズムが必要です。
リファラーの処理
アクションリンクをロードする際、エッジはリファラーをチェックします。
このリファラーにVIDが含まれている場合、エッジは（クッキーを必要とせずに）訪問者セッションを認識できます。
このリファラーに完全なページURLが含まれている場合、トラッカーはそのURLをファネル内の既知のノード/ページと照合し、またすでに訪問したページと照合して、クリックが既に訪問したページから来たことを判断できます（クリックスルーが存在するために必要なイベント）。
リファラーのURLにn=NODE_IDパラメータが含まれている場合、トラッカーはページURLの照合に頼ることなく、発信元ノードを正確に判断できます。これはより具体的です。同じページが同じファネル内で複数回使用される可能性があり（異なるノードIDで）、またはページがiFrameに埋め込まれている場合、親URLとそのリファラーがロードされたページを表していない可能性があるためです。
これが、私たちのJavaScriptに2つのヘルパー関数がある理由です：
1つはページの<meta name="referrer">タグをチェックし、存在する場合はその値をno-referrer-when-downgradeに更新し、存在しない場合は作成します。
2つ目の関数は、現在のページの場所を書き換えて、URLに訪問者IDと現在のノードIDを含めることで、アクションリンクハンドラにとって非常に有益な完全なリファラー値を作成します。
これを考慮すると、リンクにrel="noreferrer"属性を追加することは避けるべきです。これは無意味なことです - 自分のトラッキングシステムから情報を隠すことになります！
ルートドメインでホストされているページの微妙な点
完全なリファラーが渡されない場合、興味深い微妙な点が生じる可能性があります。
https://domain.com（つまりルートドメイン/ホームページ）にある初期ランディングページAから、URLがhttps://domain.com/some-page/の2番目のページBに接続するファネルを考えてみてください。
ブラウザでは、ユーザーはページAをロードし、ページBに正常に移動します。
しかし、ページBで完全なリファラーが渡されない場合、次のアクションクリックで切り詰められたリファラー（ホスト名のみ）が渡される可能性があります。エッジは"domain.com"から明らかに発生したクリックを見ることになります。
ユーザーがルートドメインをページとして使用しているため、このリファラーは前のランダーの既知のURL/パスであるため、トラッカーは与えられた情報から、これが実際にページAからの繰り返しクリックであると正当に判断します。
これにより、ページA > クリック > ページB > クリック > ページB > クリック ページBのリダイレクトループが発生します。
直接のURLパラメータ注入
私たちのJSヘルパー関数のもう1つは、ページ上でhrefに/actionを含む<a>要素を検出し、以下を注入します：
...&vid=VISITOR_ID&rn=CURRENT_NODE_ID
これが発生する場合、直接指定されたURLパラメータが優先されるため、リファラー情報は使用されません。
リファラーとURL書き換え関数が有用であると主張する人もいるかもしれませんが、そうではありません。
ユーザーがページにJSコードを追加できるが、次のページにリダイレクトするために単純な<a>要素を使用しない状況が多くあります。<a>要素はあっても、他のページに直接リンクし、それらのURLにパラメータを注入できない場合があります。アクションURLへのリダイレクトもJavaScriptで管理される可能性があり、ユーザーにはほとんど入力や動的な制御ができません。
いずれにせよ、"rn"パラメータは、対応する訪問者の特定のノードからクリックが来ていることを明示的にエッジに指定します。これは確実なトラッキングを保証する最も堅牢な方法です。
アクションリンクへのリダイレクトが単純な<a>要素を含まず、JavaScript操作を含む高度なケースでは、ビュートラッキングJSのonDone()関数を使用することをお勧めします。
これを使用して現在のノードIDと訪問者IDを取得し、リダイレクトを制御する関数に注入し、前述のURLパラメータをアクションURLに手動で追加することで、同じ利点を得ることができます。
デフォルトのアクションパラメータ
これらは、ファネルビルダーの「アクションリンクを取得」コンテキストメニュー項目を使用する際にトグルできます。
これらはファネルとノードに特有でなければならないため、ここでのみ利用可能です。
このトグルは生成のためだけのものであり、ファネル/ノード自体に特定の効果を適用するものではありません。
これらのURLはデフォルトのファネルとノードIDを次のように宣言します：
https://USER_DOMAIN/FUNNEL_ID/ORIGINATING_NODE_ID/action/number
重要な点は、これらの値は上書きではなく、VID値が不明なアクションリンクリクエスト、つまり新規または未知の訪問者に対してのみ使用されるということです。
したがって、シークレットウィンドウでは機能しますが、コンテキストのない一般的/普遍的なアクションリンクは機能しません。
99%のケースでは、これらのフォールバックパラメータは使用されませんが、重要でないにしても有用ないくつかのシナリオがあります：
- 制御できないランダムな第三者システムを経由してからリダイレクトURLに戻るようなフォーム送信を行う場合。ここでは、一般的なアクションリンクを使用すると、ロードされても有用なリファラー情報がない可能性が高いです（ランダムな第三者システムからの情報のみ）。エッジはVIDを判断するためにクッキーのみを使用できます（信頼性が低い！）ので、デフォルトのパラメータは少なくともユーザーを期待される目的地に到達させるために重要です。たとえセッションが失われ、元のファネル入口から切断されたとしても。第三者がURLパラメータを取り込んで転送できれば素晴らしいですが、多くの場合これは利用できません...
- ユーザーをアクションリンクをクリックスルーする必要があるページに送る必要があるが、何らかの理由でリファラー/データ渡しを助けるJSを注入するためのページコードを制御できない場合
- ユーザーが既知のトラッキングされたページから他のページに飛び、その後既知のページに戻ってくる場合 - 例えば、セッショントラッキングを失う可能性が高いが、最終的なアクション/クリックを追跡し、訪問者が意図した目的地にリダイレクトされることを確実にしたいウェビナーフローを通じてなど
言い換えれば、これらのアクションリンクは、トラッキングを堅牢にするための制御がなく、リファラー/クッキー/データ渡しの信頼性がゼロになると予想される厄介な状況で役立ちますが、後の時点で制御するリンクをロードしたい場合に有用です。
JavaScriptのページビュートラッキングロジック
JSを介したページビュートラッキングイベントには、現在のURL（およびそのクエリ文字列）と埋め込まれた属性の2つのデータソースしかありません。
URLパラメータは常に優先されます。これにより、ページは選択されたデフォルトIDを持つJSを埋め込むことができますが、UIで生成された入口リンクは常にそれらの値を上書きして期待通りにトラッキングされます。
直接リンクの場合、クエリ文字列URLパラメータがJSのデフォルトを上書きします。
リダイレクトリンクの場合、結果のページはそのようなパラメータなしでロードされますが、vid=VISITOR_ID値が注入されます。
このVIDはJS POSTリクエストで渡されるため、ユーザーが移動している既知のノードIDを返し、それがJSのデフォルトを上書きします。
以下は他のシナリオと結果の動作です：
- リダイレクトリンクがページをロードし、そのページにはJSがありますが埋め込まれたデフォルトがありません。ここではVIDがURLに存在し使用され、ページのURLが現在のページを判断するために使用されます。これはおそらくリダイレクトが向かった目的地と一致し、追加のページビューが生成されません（重複排除）
- URLパラメータがなく、埋め込まれたパラメータも設定されていないJSを持つページがロードされます。ファネルIDは常に渡される必要があるため、ビュートラッキングは失敗します - セッションを判断するためのVIDが存在する場合にのみ機能し、その場合は現在のファネルIDが含まれます。
- リダイレクトリンクが、現在のセッション/ファネルと一致しない埋め込みパラメータを含むJSを持つページをロードします。この場合、VIDが知られており優先されるため、ファネルは変更されません。リダイレクトによって期待されるページへのビューがすでに生成されており、JSビューイベントはURL照合で自動的にトラッキングされます。JSがリダイレクトが提供したページと一致しないページIDを指定している場合、現在のファネルに存在するページIDであれば、別の異常なビューを引き起こす可能性があります（存在しない場合はエラーになります）
- URLパラメータがありません。埋め込まれたパラメータが使用されていますが、現在のファネルに存在しないページIDが指定されています。ビューはトラッキングに失敗します。
- URLパラメータがありません。埋め込まれたパラメータが宣言されたファネルIDに存在しないノードIDを使用しています。ビューはトラッキングに失敗します。
- URLパラメータがありません。ページIDが存在しますが、現在のURLがそのページIDと一致しません。エッジはURL照合を無視し、ページIDを尊重します。これによりiframing/埋め込みが期待通りに機能します。