リダイレクトオファー - A4T FAQ

実装が次の最小要件を満たしている必要があります。

• Experience Cloud 訪問者 ID サービス：visitorAPI.js バージョン 2.3.0 以降。
• Adobe Analytics：appMeasurement.js バージョン 2.1。
• Adobe Target：at.js バージョン 1.6.2 以降。

これら 3 つのライブラリを、リダイレクトオファーを使用するページと訪問者のリダイレクト先となるページの両方に含める必要があります。

Analytics for Target （A4T）で設定されたアクティビティのリダイレクトオファーを使用すると、限られた数の顧客で、トラフィック配分の平方偏差の比率が高く報告されていました。

次の点に留意してください。

• Target と Analytics の呼び出しの順序が正しくないと、分散の度合いが高くなる場合があります。

  Target 呼び出しは、ソースページ（リダイレクトが発生する場所）および宛先ページ（リダイレクトが終了する場所）の Analytics 呼び出しの前に行う必要があります。

• A4T のリダイレクトアクティビティでリダイレクトオファーを使用してください。

• ソースページ（リダイレクトが発生するページ）に複数の Target ロケーションリクエストがある場合、Adobe では、最初の Target ロケーションリクエストでリダイレクトアクティビティを実行することをお勧めします。

  最初の Target 場所リクエストでリダイレクトアクティビティを実行すると、他の Target 場所リクエストでアクティビティの選定が発生し、レポートにカウントされる可能性が低くなります。 リダイレクトされた訪問者は、エクスペリエンスが表示されないので、他のアクティビティのレポートでカウントされる必要はありません。

at.js バージョン 1.6.3 以降を使用している場合、両方のページでページビューをカウントしても問題ありません。 この競合条件は、それ以前のバージョンを使用している場合にのみ影響します。Target チームがサポートを提供しているのは、at.js の最新バージョンとその 1 つ前のバージョンの 2 つです。必要に応じて at.js をアップグレードし、サポート対象のバージョンを実行していることを確認してください。

at.js の以前のサポートされていないバージョンを使用している場合、最初のページでリダイレクトが実行される前に競合条件が生じ、Analytics の呼び出しが実行されることがあります。元のページとリダイレクトページのページビューがすべてカウントされる可能性があります。 こうしたケースでは、訪問者が最初のページを実際に閲覧しなくても、そのページでページビューが余分にカウントされます。

ページ上でコードが実行される場所により、ページのリダイレクトの速度を速めるには、フォームベースのコンポーザーを使用してリダイレクトアクティビティを作成することをお勧めします。 また、デフォルトのエクスペリエンスも含め、リダイレクトによって元のページが返されるすべてのエクスペリエンスで、リダイレクトオファーを作成することもお勧めします。各エクスペリエンスにリダイレクトオファーを作成すると、誤ったカウントが発生した場合にすべてのエクスペリエンスで発生します。 レポートと分析は、テストに対して引き続き有効です。

デフォルト（コントロール）エクスペリエンスを含む、アクティビティのすべてのエクスペリエンスにリダイレクトオファーを使用したい理由の 1 つは、すべてのエクスペリエンスに同じ条件を課すことです。例えば、デフォルトエクスペリエンスにリダイレクトオファーがなく、他のエクスペリエンスリダイレクトオファーがある場合、リダイレクトオファーのないエクスペリエンスは、速度の点で有利です。リダイレクトオファーは、一時的なシナリオ（テストなど）にのみ推奨されます。リダイレクトオファーは、恒常的なシナリオ（パーソナライゼーションなど）には推奨されません。「勝者」を決定した後、ページ読み込みのパフォーマンスを向上させるために、リダイレクトを削除する必要があります。

はい。ビルトインのリダイレクトオファーを使用するのであれば、どちらのコンポーザーもサポートされます。

リダイレクトに独自のカスタムコードを使用する場合、リダイレクト URL に関連付けられた 2 つの新しいパラメーター（以下で説明する adobe_mc_sdid と adobe_mc_ref）を必ず設定する必要があります。

次のクエリ文字列パラメーターが、リダイレクトオファーに関連付けられます。

訪問者 ID サービスがページに実装されていると、VEC とフォームベースの Experience Composer で組み込みのリダイレクトオファーを使用する場合に、これらのパラメーターがリダイレクト URL に自動的に追加されます。VEC またはフォームベースのコンポーザーでリダイレクトに独自のカスタムコードを使用している場合、必ずこれらのパラメーターをカスタムコードとともに渡す必要があります。

次の場合は、カスタムコーディングリダイレクトを使用します。

• リダイレクトアクティビティで A4T を使用していません
• 訪問者 ID サービスが実装されている
• これらのパラメーターを URL に自動的に追加しないようにする必要があります

しかし、ベストプラクティスとして、リファラー情報を adobe_mc_ref に正しくレポートするために、URL の Analytics パラメーターを保持することもできます。

A4T とリダイレクトオファーを使用する場合、Target によって adobe_mc_ref パラメーターと adobe_mc_sdid パラメーターが URL に追加されます。これらの値は既に URL エンコードされています。ほとんどの場合は、すべてが期待どおりに動作します。しかし、お客様によっては、クエリ文字列パラメーターを再度エンコードしようとするロードバランサーまたは Web サーバーが配置されている場合があります。

訪問者 API は、adobe_mc_sdid 値をデコードしようとしたときにこの二重エンコードが原因で SDID 値を抽出できないので、新しい SDID を生成します。このプロセスにより、Target と Analytics に間違った SDID 値が送信され、Analytics レポートでリダイレクトに不均等な分割が見られます。

Adobeでは、IT チームに問い合わせて、これらの値が変換されないように adobe_mc_ref と adobe_mc_sdid を許可リストに加えるすることをお勧めします。

訪問者が、リダイレクトアクティビティがライブであるホームページ（www.google.com）へのリンクを www.mysite.com/index.html クリックし、新しいページ（www.mysite.com/index2.html）にリダイレクトされたとします。

以前は、新しいページの Analytics リクエストで、www.mysite.com/index.html ではなく www.google.com の参照 URL がレポートされていました。 そのため、参照 URL に関連付けられた Analytics のレポート（例えば、マーケティングチャネルレポート）が不正確になっており、報告書には、あなたが www.google.com からサイトに来たという事実を失っていました。

at.js バージョン 0.9.6 （以降）および AppMeasurement.js 2.1 （以降）では、新しいページの Analytics リクエストは www.google.com の参照 URL をレポートします。