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

このトピックには、 Adobe Analytics レポートソースとして Adobe Target (A4T)。

Analytics for Adobe 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 以降。

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

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

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

A4T アクティビティでリダイレクトオファーを使用する際に、トラフィック配分の不一致を最小限に抑えるには、どうすればよいですか?

限られた数のお客様が、 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 つは、すべてのエクスペリエンスに同じ条件を課すことです。例えば、デフォルトエクスペリエンスにリダイレクトオファーがなく、他のエクスペリエンスリダイレクトオファーがある場合、リダイレクトオファーのないエクスペリエンスは、速度の点で有利です。リダイレクトオファーは、一時的なシナリオ(テストなど)にのみ推奨されます。リダイレクトオファーは、恒常的なシナリオ(パーソナライゼーションなど)には推奨されません。「勝者」を決定したら、ページ読み込みのパフォーマンスを向上させるために、リダイレクトを削除する必要があります。

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

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

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

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

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

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

パラメーター 説明
adobe_mc_sdid この adobe_mc_sdid パラメーターは、追加データ ID(SDID) およびExperience Cloud組織 ID をデフォルトページから新しいページに渡します。 これらの 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 から除去されます。どうすればよいですか?

IT チームと協力して、次のパラメータ ( adobe_mc_sdid および adobe_mc_ref)許可リストに加える

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は、IT チームに問い合わせて、 adobe_mc_ref および adobe_mc_sdid これらの値が変換されないように許可リストに加えるされます。

参照 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.

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

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

Adobe Experience Platform Web SDK バッジ を実行します。 Adobe Experience Platform Web SDK A4T のリダイレクトオファーをサポートしますか?

次の FAQ では、A4T の使用に関する詳細と、 Platform Web SDK.

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

はい、Platform Web SDK 経由での A4T では、 リダイレクトオファー.

は Visual Experience Composer (VEC) および フォームベースの Experience Composer サポート対象?

はい、 Visual Experience Composer (VEC) および フォームベースの Experience Composer は、組み込みのリダイレクトオファーを使用する場合にサポートされます。

カスタム/HTMLリダイレクトオファーを Platform Web SDK?

いいえ。A4T を使用するアクティビティでは、組み込みのリダイレクトオファーを使用する必要があります。 次の Target パースペクティブ、HTMLオファーは不透明です。 Target は、リダイレクトをインスタンス化する JavaScript が含まれているHTMLを特定できない。

このページ