このチュートリアルは、Adobe Audience Manager(AAM) とAdobe Analyticsの両方を使用し、現在、DIL(Data Integration Library) コードで始まり、また、ページからAdobe Analyticsにヒットを送信することもできます。 これらの両方のソリューションを使用しており、両方ともAdobe Experience Cloudに含まれているので、サーバー側転送を有効にするベストプラクティスに従うことができます。これにより、 Analytics データ収集サーバーを使用して、クライアント側のコードでページからAAMに追加のヒットを送信する代わりに、リアルタイムでサイト分析データをAudience Managerに転送することができます。 このチュートリアルでは、古いクライアント側のDIL実装から新しいサーバー側転送方法に切り替える手順について説明します。
Adobe AnalyticsのデータをAAMに取り込むこれら 2 つの方法を比較および対照する場合、まず次の画像の違いを視覚化すると役に立ちます。
この方法を使用してAdobe AnalyticsデータをAAMに送信する場合、Web ページから 2 つのヒットが取得されます。1 つは Analytics(コピー後に)AAMに移動 Analytics データを Web ページに貼り付けます。 Segments はAAMからページに返され、そこでパーソナライゼーションなどに使用できます。 これはレガシー実装と見なされ、お勧めしません。
これはベストプラクティスに従っていないという点以外に、この方法を使用するデメリットには次のものがあります。
AAM実装のサーバー側転送方法に移行することをお勧めします。
上の画像に示すように、Web ページからAdobe Analyticsにヒットが届きます。 Analytics 次に、そのデータをリアルタイムでAAMに転送し、訪問者はAAMの特性と segments:ヒットがページから直接来た場合と同様です。
Segments が Analytics:パーソナライゼーション用に Web ページに応答を転送します。
サーバー側転送に移行するタイミングが下がりません。 Adobeは、Audience Managerと Analytics はこの実装方法を使用します。
このページにはかなり多くの情報があり、もちろんすべてが重要です。 しかし、 すべては、あなたがする必要がある 2 つの主な事につながる:
これらのタスクのどちらかをスキップすると、サーバー側転送は正しく機能しません。 このドキュメントに、設定に合わせてこれら 2 つの手順を正しく実行するための手順と追加データが追加されました。
クライアント側からサーバー側転送に移行する際のタスクの 1 つとして、コードを新しいサーバー側転送コードに変更します。 これは、次のいずれかのオプションを使用しておこないます。
doPlugins
関数を appMeasurement.js
ファイル ( まだAdobeLaunch を使用していない場合 )doPlugins
( 他のタグマネージャーが AppMeasurement コード以下の各項目について、 コードの更新 」セクションに入力します。
次の手順は、の実装を説明します。
サーバー側転送に移行するための主な前提条件は、Experience CloudID サービスを実装することです。 これは、Experience Platform Launchを使用している場合に最も簡単におこなえます。その場合は、ECID 拡張機能をインストールするだけで、残りの操作を実行できます。
Adobe以外の TMS を使用している場合、または TMS をまったく使用していない場合は、実行する ECID を実装してください 前 その他のAdobeソリューション 詳しくは、 ECID ドキュメント を参照してください。 その他の前提条件は、コードバージョンに関するものです。そのため、次の手順で最新バージョンのコードを適用するだけで問題ありません。
実装する前に、このドキュメント全体をお読みください。 以下の「タイミング」の項では、 when ECID を含む各要素を実装する必要があります(まだ実装されていない場合)。
クライアント側のDILコードからサーバー側の転送に移行する準備が整ったら、最初の手順は、AAMに送信されるカスタム設定やデータなど、DILコードでおこなっているすべての操作を識別することです。 注意事項と考慮事項は次のとおりです。
siteCatalyst.init
DILモジュール — このモジュールは、通常の Analytics 変数を渡す場合と、単にサーバー側転送を有効にしている場合に発生します。DIL.create
関数、 partner
パラメーター。 これは「パートナーサブドメイン」または「パートナー ID」と呼ばれ、新しいサーバー側転送コードを配置する際に必要になります。In 実装オプション (上記)サーバー側転送を実装する方法と場所に関して、複数のオプションが表示されます。 このセクションを有効にするには、このセクションに分割する必要があります(そのうち 2 つを組み合わせたセクション)。 必要に応じて、この節の方法を参照してください。
Experience Platform Launchでのクライアント側のDILコードからサーバー側転送に実装オプションを移行する方法については、以下のビデオをご覧ください。
でのクライアント側のDILコードからサーバー側転送への実装オプションの移行については、以下のビデオをご覧ください。 AppMeasurement ファイル内または非Adobeタグ管理システム内に存在するコード。
このチュートリアルでは、常に、コードをクライアント側のDILコードからサーバー側の転送に切り替えるのに時間を費やしました。 それはより難しい部分なので結構です。 この節は非常に簡単ですが、コードを更新するのと同じくらい重要です。 このビデオでは、Analytics からAudience Managerへのデータの実際の転送を可能にするスイッチの反転方法を確認します。
注意: このビデオで述べたように、転送の有効化がExperience Cloudのバックエンドで完全に実装されるまでに最大 4 時間かかることに注意してください。
クライアント側の転送からサーバー側の転送に移行する際の主なタスクは 2 つあります。
でも問題はどちらが先か? 問題なの? 申し訳ありませんが 2 つの質問でした しかし答えは…それは依存しています can 問題。 どうやって曖昧なの? 分けてみましょう。 しかし、多数のサイトを持つ大規模な組織の場合に浮上する可能性のある追加の質問が 1 つ目です。私は一度に全てを行わなければなりませんか? それは少し簡単です。 いいえ。 これは一つ一つできます
タイミングと注文が重要なのは、転送の仕組みが原因です 本当に 以下の技術的事実に要約できる。
技術的な詳細に基づき、実行するタイミングと実行するタイミングに関する推奨事項を次に示します。
スイッチをに入れます。 Analytics 各 report suite を有効にして、サーバー側転送を有効にします。
サイトごとに、コードをクライアント側DILからサーバー側転送(Platform タグに含まれる場合もあります)またはページ上で、上記の別の節で説明したように更新します。
DILからサーバー側転送へのコードの更新準備が整うよう、準備と計画をおこないます。 report suite サーバー側転送を有効にします。
スイッチをに入れます。 Analytics サーバー側転送を有効にする。
可能な限り早く、クライアント側DILからシングル側転送にコードを更新します(これは、前述の別の節で説明したように、Platform タグまたはページ上にある可能性があります)。
この 2 つの手順は、できるだけ近くにおこなうことが重要です。上記の手順 1 と 2 の間では、AAMへのデータの重複が発生するからです。 つまり、シングル側転送では、 Analytics また、AAMに移行する際に、DILコードがまだページ上にあるので、ページからAAMに直接ヒットが発生し、データが 2 倍になります。 DILからサーバー側転送にコードを更新すると、この問題は軽減されます。
データが少し重複するのではなく、データに小さな相違がある場合は、上記の手順 1 と 2 の順序を切り替えることができます。 DILからサーバー側転送にコードを移動すると、のサーバー側転送をオンにするスイッチを切り替えられるまで、AAMへのデータフローが停止します。 report suite. 通常、お客様は、訪問者を特性や segments.
このトピックでは、前の節で簡単に取り上げ、主な戦略を次のように要約できます。
サイトを 1 つ移行/report suite ( またはサイトのグループ/report suites) を一度にクリックします。
ただし、考えられるシナリオに基づいては、これは少し難しくなる可能性があります。
これらの項目のため、少し複雑になる可能性があります。 私が提案できる最善の方法は次のとおりです。
サーバー側転送がインストールおよび導入されていることを検証する主な方法は、アプリからのAdobe Analyticsヒットへの応答を確認することです。
からのデータのサーバー側転送をおこなっていない場合 Analytics Audience Managerの場合、 Analytics ビーコン(2x2 ピクセル以外)に追加します。 ただし、サーバー側転送をおこなっている場合は、 Analytics を知らせるリクエストと応答 Analytics は、Audience Managerと正しく通信し、ヒットを転送して、応答を取得しています。
誤った「Success」に注意してください。 応答があり、すべてが機能しているように見える場合は、 stuff
オブジェクトを返します。 そうしないと、次のようなメッセージが表示される場合があります。 "status":"SUCCESS"
. 変に思えますが、実際には、これは正しく機能していない証拠です。
これが表示される場合は、Platform タグでコードの更新が完了しているか、 AppMeasurementしかし Analytics Admin Console はまだ完了していません。 この場合、 Analytics Admin Console の report suite. まだ 4 時間が経過していない場合は、バックエンドで必要な変更をすべておこなうのにそれほど時間がかかる可能性があるので、しばらくお待ちください。
サーバー側転送について詳しくは、 ドキュメント.