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

このトピックには、Analytics を Target のレポートソースとして使用する（A4T）場合のリダイレクトオファーの使用に関するよくある質問に対する回答が含まれています。

Analytics for Target（A4T）ではリダイレクトオファーがサポートされますか？

はい。実装で at.js が使用されている場合にサポートされます。ただし、Analytics をレポートソースとして使用するアクティビティでリダイレクトオファーを使用するには、実装がいくつかの最小要件を満たす必要があります。

メモ

A4T によるリダイレクトを使用するお客様の数に制限があることにより、未関連付けヒット率の割合が高く表示されるという既知の問題があります。既知の問題と解決された問題を参照してください。

A4T でリダイレクトオファーを使用するために必要な最小要件を教えてください。

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

  • Experience Cloud 訪問者 ID サービス：visitorAPI.js バージョン 2.3.0 以降。

  • Adobe Analytics：appMeasurement.js バージョン 2.1。

  • Adobe Target：at.js バージョン 1.6.2 以降。

    mbox.js ライブラリを使用している場合、A4T によるリダイレクトオファーはサポートされません。実装では at.js を使用する必要があります。

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

場合により A4T と Analytics の間でデータに相違があるのはなぜですか。

データに多少相違があることが予想されます。詳しくは、A4T を使用する場合と使用しない場合とでの Target と Analytics 間での予想されるデータの相違を参照してください。

元のページとリダイレクトページでページビュー数がカウントされることがあるのはなぜですか？

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

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

リダイレクトアクティビティを作成する際は、ページのリダイレクトを高速化するために、フォームベースのコンポーザーを使用することをお勧めします。これは、コードがページ上で実行されるためです。また、デフォルトのエクスペリエンスも含め、リダイレクトによって元のページが返されるすべてのエクスペリエンスで、リダイレクトオファーを作成することもお勧めします。これにより、ページビューが余分にカウントされても、すべてのエクスペリエンスで同様にカウントされるので、テスト用のレポートや分析には問題ありません。

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

この問題について詳しくは、既知の問題の「リダイレクトオファー」情報を参照してください。

mbox.js JavaScript ライブラリを使用している場合に、A4T でリダイレクトオファーを使用できますか？

mbox.js ライブラリを使用している場合、A4T によるリダイレクトオファーはサポートされません。実装では at.js を使用する必要があります。

Visual Experience Composer（VEC）とフォームベースの Experience Composer の両方がサポートされていますか？

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

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

リダイレクト URL に追加される新しいクエリ文字列パラメーターは何ですか？

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

パラメーター 説明
adobe_mc_sdid adobe_mc_sdid パラメーターは、追加のデータ ID（SDID）と Experience Cloud 組織 ID をデフォルトのページから新しいページに渡します。これにより、A4T によって、デフォルトのページの Target リクエストが新しいページの Analytic リクエストに「関連付け」られます。
adobe_mc_ref adobe_mc_ref パラメーターは、デフォルトのページの参照 URL を新しいページに渡します。AppMeasurement.js バージョン 2.1（またはそれ以降）を使用した場合、このパラメーター値は Analytics によって新しいページの参照 URL として使用されます。

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

Web サーバーで、これらのパラメーターが URL から除去されます。どうすればよいですか？

これらのパラメーター（adobe_mc_sdidとadobe_mc_ref）を許可するには、ITチームと協力する必要があります。

A4T でリダイレクトアクティビティを使用しておらず、URL に追加されるこれらの追加のパラメーターが必要ない場合、どうすればよいですか？

A4T でリダイレクトアクティビティを使用していない場合、訪問者 ID サービスを実装します。これらのパラメーターが URL に自動的に追加されないようにするには、カスタムコーディングされたリダイレクトを使用する必要があります。

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

実装で URL が adobe_mc_ref パラメーターと adobe_mc_sdid パラメーターによって二重エンコードされるのはなぜですか？

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

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

adobe_mc_refとadobe_mc_sdidが許可され、これらの値がいかなる形でも変換されないように、ITチームに相談することをお勧めします。

参照 URL を新しいページに渡す必要があるのはなぜですか？

例えば、訪問者がwww.google.com上のリンクをクリックして、リダイレクトアクティビティがライブで、その後新しいページ(www.mysite.com/index2.html)にリダイレクトされるホームページ(www.mysite.com/index.html)を作成します。

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

at.js バージョン 0.9.6（またはそれ以降）と AppMeasurement.js 2.1（またはそれ以降）では、新しいページの Analytics リクエストによって、[!DNL www.google.com] の参照 URL がレポートされます。

カスタム／HTML リダイレクトオファーを使用することはできますか？

いいえ。Analytics をレポートソースとして使用するアクティビティでは（A4T）、組み込みのリダイレクトオファーを使用する必要があります。Target からは、HTML オファーは不明瞭です。Target は、リダイレクトをインスタンス化する JavaScript を含む HTML の特定部分を認識することができません。

このページ