このチュートリアルは、Adobe Audience Manager(AAM)とAdobe Analytics()の両方をお持ちで、現在、「DIL」(Data Integration Library)コードを使用してページからAAMにヒットを送信し、ページからAdobe Analyticsにヒットを送信している場合に適用されます。 これらのソリューションは両方あり、両方ともAdobe Experience Cloudの一部なので、client-sideコードがページからAAMに別のヒットを送信する代わりに、Server-Side Forwarding (SSF)を有効にするベストプラクティスに従います。 Analyticsこのチュートリアルでは、古い「Client-Side DIL」の実装から新しい「Server-Side forwarding」のメソッドに切り替える手順を説明します。
Adobe AnalyticsのデータをAAMに送り込む2つの方法を比較・対比する際には、まず次の図の違いを視覚化すると便利です。
この方法を使用してAdobe AnalyticsのデータをAAMに取り込む場合、ウェブページから2つのヒットがあることを意味します。1つはAnalytics、もう1つはAAM (Webページ上のAnalyticsデータをコピーした後)に移動します。 Segments がAAMからページに返され、そこでパーソナライゼーションなどに使用できます。これは「従来の」実装と見なされ、推奨されなくなりました。
これはベストプラクティスに従っていないことを除き、この方法を使用するデメリットは次のとおりです。
AAM実装のServer-Side Forwardingメソッドに移行することをお勧めします。
上の図に示すように、WebページからAdobe Analyticsにヒットが届きます。 Analytics そのデータをリアルタイムでAAMに転送し、訪問者はAAM traits に評価され segments、ページから直接ヒットが届いたかのように見なされます。
Segments は、同じリアルタイムヒットでに返され Analytics、訪問者の個人設定などを行うためにウェブページに応答を転送します。
サーバー側転送に移動するタイミングを下げることはできません。 Audience ManagerとAnalyticsの両方を持つ人には、この実装方法を利用することを強くお勧めします。
このページにはかなり多くの情報が載っていて、もちろん重要なことです。 しかし、すべては、する必要がある主な2つの事柄にまとめ上げます。
この2つのうちどちらかをスキップすると、SSFは正しく動作しません。 このドキュメントには、これら2つの手順を正しく行うための手順と追加データが追加されています。
client-sideからserver-sideに移動する際、タスクの1つが、コードを新しいServer-Side Forwardingコードに変更します。 これは、次のいずれかのオプションを使用して行います。
doPlugins
関数に直接配置することもできます。doPlugins
内の他のタグマネージャーがAppMeasurementコードを保存している場合、常に<a0/>にSSFコードを入れるので、前の(ページ上の)オプションと同じように扱えます。「コードの更新」セクションで以下の各項目を確認します。
Server-Side Forwardingに移行する主な前提条件は、Experience CloudIDサービスを実装することです。 これは、Experience Platform Launchを使用している場合に最も簡単に行えます。この場合は、ECID拡張をインストールするだけで、その他の作業も行えます。
Adobe以外のTMSを使用している場合、またはTMSをまったく使用していない場合は、他のAdobeソリューションの前に<a0/>を実行するようにECIDを実装してください。詳しくは、ECIDドキュメントを参照してください。 その他の前提条件はコードバージョンに関するものです。以下の手順で最新のバージョンのコードを適用するだけなので、問題ありません。
実装する前に、このドキュメント全体をお読みください。 以下の「タイミング」の節は、**をいつ実装すべきかに関する重要な情報を持っています。ECIDを含みます(まだ実装されていない場合)。
Client-SideDILコードからServer-Side Forwardingに移行する準備が整ったら、まず、AAMに送信されるカスタム設定やデータなど、DILコードで行っているすべてを識別します。 次の点に注意し、考慮する必要があります。
partner
パラメーターをメモしておきます。 これは、「パートナーサブドメイン」または「パートナーID」と呼ばれ、新しいSSFコードを配置する際に必要になります。上記の「導入オプション」というセクションには、Server-Side Forwardingを導入する方法/場所に関する複数のオプションが表示されます。 この節を有効にするためには、この節に分ける必要があります(2つの節を組み合わせて)。 ニーズに最も適した説明をこのセクションの手法に進みます。
Experience Platform Launch内でClient-SideDILコードからServer-Side Forwardingに導入オプションを移動する方法については、以下のビデオをご覧ください。
ファイルまたはAdobe以外のタグ管理システムに存在するClient-SideDILコードからAppMeasurementコードのServer-Side Forwardingに導入オプションを移動する方法については、以下のビデオをご覧ください。
これまで、コードをClient-Side DILコードからServer-Side Forwardingに切り替えるのに時間を費やしてきました。 それはより難しい部分だから良い。 この節は、非常に簡単ですが、コードを更新するのと同じくらい重要です。 このビデオでは、AnalyticsからAudience Managerへのデータの実際の転送を可能にするスイッチの切り替え方法を見ていきます。
注意:このビデオで説明 したように、転送の有効化がExperience Cloudバックエンドで完全に実装されるまでに最大4時間かかることに注意してください。
注意喚起として、Client-Side DILからServer-Side Forwardingに移動する際には、主に次の2つのタスクがあります。
でも問題はどちらが先か? 重要か? 2つの質問です しかし答えは…それは依存しているし、は問題になるかもしれない。 どうやって曖昧なの? 分けてみよう しかし、まず、多数のサイトを持つ大きな組織では、次のような疑問が浮かび上がる可能性があります。一度に何もかもやらなきゃいけないの? あれは少し楽です。 いいえ。 一つ一つで…できます:)
タイミングと順序が重要なのは、forwarding *really *worksの仕組みが原因で、以下の技術的事実に要約できる。
これらの技術的な詳細に基づき、「何をすべきか」のタイミングに関する推奨事項を以下に示します。
Analyticsで、SSFを有効にする各report suiteのスイッチをフリップします。
サイトごとに、コードをClient-Side DILからSSFに更新します(Launchまたはページ上の、上記の別のセクションで説明したように)。
SSFを有効にするコードをDILからSSF PER report suiteに更新する準備が整うように準備し、計画を立てます。
AnalyticsでスイッチをフリップしてSSFを有効にします
できるだけ早く、Client-Side DILからSSFにコードを更新してください(Launchか、上の他のセクションで説明したように、ページ上にあります)
注1: この2つの手順をできるだけ近くに行うことが重要です。上の手順1と2の間には、AAMにデータが複製されるからです。つまり、SSFはAnalyticsからAAMへのデータの送信を開始し、DILコードがまだページ上にあるので、ページからAAMに直接ヒットすることもあり、データが2倍になります。 コードをDILからSSFに更新すると、この問題は緩和されます。
注2:データの重複が少なくても、データに小さな相違が生じたい 場合は、上記の手順1と2の順序を切り替えることができます。コードをDILからSSFに移動すると、report suiteのSSFをオンにするスイッチを入れるまで、AAMへのデータフローが停止します。 訪問者をtraitsやsegmentsに連絡し損ねるよりも、通常、お客様のデータが少し倍増する方がよいでしょう。
このトピックでは、前の節で、主な戦略を以下にまとめて簡単に取り上げます。
一度に1つのサイト/report suite(またはサイトのグループ/report suites)を移行します。
ただし、考えられるシナリオに基づいては、少し難しくなる場合があります。
これらの項目があるので、少し複雑になる可能性があります。 私が提案できる最善の方法は次のとおりです。
Server-Side Forwardingが起動して実行されていることを検証する主な方法は、アプリから来た任意のAdobe Analyticsヒットに対する応答を調べることです。
AnalyticsからAudience Managerへのデータのserver-side forwardingを行わない場合、Analyticsビーコン(2x2ピクセル以外)には実際には応答しません。 ただし、SSFを実行している場合は、Analyticsのリクエストと応答を検証できる項目があります。この項目を使用すると、AnalyticsがAudience Managerと正しく通信し、ヒットを転送し、応答を受け取っていることを知ることができます。
警告: Falseの「成功」に気を付けてください。応答があり、すべてが機能しているように見える場合は、応答に「stuff」オブジェクトが含まれていることを確認してください。そうしないと、“status”:"SUCCESS"というメッセージが表示されるかもしれません。 これは正しく機能していない配達確認です これが見える場合は、LaunchまたはAppMeasurementでのコードの更新が完了したが、Analytics Admin Consoleでの転送がまだ完了していないことを意味します。 この場合は、report suiteのAnalytics Admin ConsoleでSSFが有効になっていることを確認する必要があります。 バックエンドで必要な変更を行うのにそれほど時間がかかる場合があるので、まだ4時間も経っていない場合は、忍耐強くお願いします。
Server-Side Forwardingについて詳しくは、ドキュメントを参照してください。