Show Menu
トピック×

リダイレクトオファー - 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 から除去されます。どうすればよいですか?

You will need to work with your IT team to have these parameters ( adobe_mc_sdid and adobe_mc_ref ) allowlisted.

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 レポートにリダイレクトの不均一な分割が表示されます。
We recommend that you talk to their IT team to ensure that adobe_mc_ref and adobe_mc_sdid are allowlisted so that these values are not transformed in any way.

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

`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 がレポートされます。

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

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