リダイレクトオファー - 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では、adobe_mc_refとadobe_mc_sdidを許可リストに加えるして、これらの値が何らかの形で変換されないようにするために、IT チームと話し合うことをお勧めします。

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

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

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