サイトのAAM導入をClient-SideDILからServer-Side Forwardingに移行する

このチュートリアルは、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」のメソッドに切り替える手順を説明します。

Client-Side (DIL)と Server-Side

Adobe AnalyticsのデータをAAMに送り込む2つの方法を比較・対比する際には、まず次の図の違いを視覚化すると便利です。

Client-side DILの実装

この方法を使用してAdobe AnalyticsのデータをAAMに取り込む場合、ウェブページから2つのヒットがあることを意味します。1つはAnalytics、もう1つはAAM （Webページ上のAnalyticsデータをコピーした後）に移動します。 Segments がAAMからページに返され、そこでパーソナライゼーションなどに使用できます。これは「従来の」実装と見なされ、推奨されなくなりました。

これはベストプラクティスに従っていないことを除き、この方法を使用するデメリットは次のとおりです。

• 単一のヒットではなく、ページからの2つのヒット
• Server-Side Forwarding はとのAAMオーディエンスのリアルタイム共有に必要なため Analytics、 Client-side 実装ではこの機能（および将来他の機能が使用される可能性がある）を許可しません

AAM実装のServer-Side Forwardingメソッドに移行することをお勧めします。

Server-Side Forwarding 実装

上の図に示すように、WebページからAdobe Analyticsにヒットが届きます。 Analytics そのデータをリアルタイムでAAMに転送し、訪問者はAAM traits に評価され segments、ページから直接ヒットが届いたかのように見なされます。

Segments は、同じリアルタイムヒットでに返され Analytics、訪問者の個人設定などを行うためにウェブページに応答を転送します。

サーバー側転送に移動するタイミングを下げることはできません。 Audience ManagerとAnalyticsの両方を持つ人には、この実装方法を利用することを強くお勧めします。

2つの主なタスクがあります

このページにはかなり多くの情報が載っていて、もちろん重要なことです。 しかし、すべては、​する必要がある主な2つの事柄にまとめ上げます。

1. コードをClient-SideDILコードからServer-Side Forwardingコードに変更します
2. Analytics Admin Consoleのスイッチをフリップして、（report suiteごとに）実際のデータ転送を開始します。

この2つのうちどちらかをスキップすると、SSFは正しく動作しません。 このドキュメントには、これら2つの手順を正しく行うための手順と追加データが追加されています。

導入オプション

client-sideからserver-sideに移動する際、タスクの1つが、コードを新しいServer-Side Forwardingコードに変更します。 これは、次のいずれかのオプションを使用して行います。

• Adobe Experience Platform Launch- Webプロパティの推奨される実装オプション。 Launchが全ての難しい作業を行ったので、これは非常に簡単なタスクだと分かるでしょう。
• ページ —Adobe起動を使用していない（まだ使用していない）場合は、新しいSSFコードをappMeasurement.jsファイル内のdoPlugins関数に直接配置することもできます。
• 他のタグマネージャー — これらは、doPlugins内の他のタグマネージャーがAppMeasurementコードを保存している場合、常に<a0/>にSSFコードを入れるので、前の（ページ上の）オプションと同じように扱えます。

「コードの更新」セクションで以下の各項目を確認します。

実装手順

手順0:前提条件：Experience CloudIDサービス(ECID)

Server-Side Forwardingに移行する主な前提条件は、Experience CloudIDサービスを実装することです。 これは、Experience Platform Launchを使用している場合に最も簡単に行えます。この場合は、ECID拡張をインストールするだけで、その他の作業も行えます。

Adobe以外のTMSを使用している場合、またはTMSをまったく使用していない場合は、他のAdobeソリューション​の前に<a0/>を実行するようにECIDを実装してください。​詳しくは、ECIDドキュメントを参照してください。 その他の前提条件はコードバージョンに関するものです。以下の手順で最新のバージョンのコードを適用するだけなので、問題ありません。

手順1:DILコードから現在使用されているオプションを記録

Client-SideDILコードからServer-Side Forwardingに移行する準備が整ったら、まず、AAMに送信されるカスタム設定やデータなど、DILコードで行っているすべてを識別します。 次の点に注意し、考慮する必要があります。

• siteCatalyst.initDILモジュールを使用した通常のAnalytics変数 — この変数の扱いは、通常のAnalytics変数を送り返すだけで、単にSSFを有効にするだけで済むので、心配する必要はありません。
• パートナーサブドメイン —DIL.create関数で、partnerパラメーターをメモしておきます。 これは、「パートナーサブドメイン」または「パートナーID」と呼ばれ、新しいSSFコードを配置する際に必要になります。
• Visitor Service Namespace - 「Org ID」または「IMS Org ID」とも呼ばれ、新しいSSFコードを設定する場合も同様に必要です。書き留めておけ。
• containerNSID、uuidCookie、およびその他の高度なオプション — 使用しているその他の高度なオプションをメモしておくと、SSFコードでも設定できるようになります。
• 追加のページ変数 — AAMに他の変数を（siteCatalyst.initで処理される通常のAnalytics変数に加えて）ページから送信する場合、SSF経由で送信できるように、それらの変数をメモしておく必要があります(スポイラーの警告：（contextData変数を使用）。

手順2:コードの更新

上記の「導入オプション」というセクションには、Server-Side Forwardingを導入する方法/場所に関する複数のオプションが表示されます。 この節を有効にするためには、この節に分ける必要があります（2つの節を組み合わせて）。 ニーズに最も適した説明をこのセクションの手法に進みます。

Adobe Experience Platform Launch

Experience Platform Launch内でClient-SideDILコードからServer-Side Forwardingに導入オプションを移動する方法については、以下のビデオをご覧ください。

「ページ上」またはAdobe Tag Manager以外

ファイルまたはAdobe以外のタグ管理システムに存在するClient-SideDILコードからAppMeasurementコードのServer-Side Forwardingに導入オプションを移動する方法については、以下のビデオをご覧ください。

手順3:転送を有効にする（Report Suiteごと）

これまで、コードをClient-Side DILコードからServer-Side Forwardingに切り替えるのに時間を費やしてきました。 それはより難しい部分だから良い。 この節は、非常に簡単ですが、コードを更新するのと同じくらい重要です。 このビデオでは、AnalyticsからAudience Managerへのデータの実際の転送を可能にするスイッチの切り替え方法を見ていきます。

注意：このビデオで説明 したように、転送の有効化がExperience Cloudバックエンドで完全に実装されるまでに最大4時間かかることに注意してください。

タイミング

注意喚起として、Client-Side DILからServer-Side Forwardingに移動する際には、主に次の2つのタスクがあります。

1. コードの更新
2. Analytics Admin Consoleのスイッチの反転

でも問題はどちらが先か？ 重要か？ 2つの質問です しかし答えは…それは依存しているし、は​問題になるかもしれない。 どうやって曖昧なの？ 分けてみよう しかし、まず、多数のサイトを持つ大きな組織では、次のような疑問が浮かび上がる可能性があります。一度に何もかもやらなきゃいけないの？ あれは少し楽です。 いいえ。 一つ一つで…できます:)

もう少し深い潜水

タイミングと順序が重要なのは、forwarding *really *worksの仕組みが原因で、以下の技術的事実に要約できる。

• Experience CloudIDサービス(ECID)を実装していて、Analytics Admin Consoleのスイッチ(「the switch」)がオンの場合、コードをまだ更新していなくても、データはAnalyticsからAAMに転送されます。
• ECIDを実装していない場合、スイッチがオンになっていて、SSFコードを持っていても、データは転送されません。
• SSFコード（Launch内かページ上かにかかわらず）は、応答を実際に処理し、もちろん移行を完了するのに必要です。
• SSFスイッチはReport Suiteによって有効にされていますが、コードはLaunchのプロパティで処理されます。Launchを使用しない場合はAppMeasurementファイルで処理されます。

ベストプラクティス

これらの技術的な詳細に基づき、「何をすべきか」のタイミングに関する推奨事項を以下に示します。

ECIDをまだ実装していない場合

1. Analyticsで、SSFを有効にする各report suiteのスイッチをフリップします。

   1. ECIDがないので、転送はまだ開始されません

2. サイトごとに、コードをClient-Side DILからSSFに更新します（Launchまたはページ上の、上記の別のセクションで説明したように）。

   1. 転送は、（ECIDを追加したので）フローするようになり、また、Analyticsビーコンに対する適切なJSON応答も受け取るはずです（詳しくは、以下の「検証とトラブルシューティング」の節を参照）

ECIDを実装している場合

1. SSFを有効にするコードをDILからSSF PER report suiteに更新する準備が整うように準備し、計画を立てます。

   1. AnalyticsでスイッチをフリップしてSSFを有効にします

      1. ECIDが有効になっているため、転送WILL開始が発生する

   2. できるだけ早く、Client-Side DILからSSFにコードを更新してください（Launchか、上の他のセクションで説明したように、ページ上にあります）

      1. Analyticsビーコンに対する適切なJSON応答が返されます（詳しくは、以下の「検証とトラブルシューティング」の節を参照）

注1: この2つの手順をできるだけ近くに行うことが重要です。上の手順1と2の間には、AAMにデータが複製されるからです。つまり、SSFはAnalyticsからAAMへのデータの送信を開始し、DILコードがまだページ上にあるので、ページからAAMに直接ヒットすることもあり、データが2倍になります。 コードをDILからSSFに更新すると、この問題は緩和されます。

注2：データの重複が少なくても、データに小さな相違が生じたい 場合は、上記の手順1と2の順序を切り替えることができます。コードをDILからSSFに移動すると、report suiteのSSFをオンにするスイッチを入れるまで、AAMへのデータフローが停止します。 訪問者をtraitsやsegmentsに連絡し損ねるよりも、通常、お客様のデータが少し倍増する方がよいでしょう。

多数のサイトとReport Suitesがある場合の移行タイミング

このトピックでは、前の節で、主な戦略を以下にまとめて簡単に取り上げます。

一度に1つのサイト/report suite（またはサイトのグループ/report suites）を移行します。

ただし、考えられるシナリオに基づいては、少し難しくなる場合があります。

• 複数の異なるreport suitesを含むサイトがあります
• report suiteに複数のサイト（グローバルreport suiteなど）が含まれている
• 1つのLaunchプロパティを使用して複数のサイトをカバーします
• 異なるサイト用に異なる開発チームがある

これらの項目があるので、少し複雑になる可能性があります。 私が提案できる最善の方法は次のとおりです。

• 上で説明した内容に基づいて、SSFへの移行の戦略を立てるのに時間がかかります。
• Launch（または1つのAppMeasurementファイル）の1つのプロパティが1つまたは2つの異なるreport suitesに対応していることに基づき、これらの異なるグループに対して1つずつ機能する計画を立て、企業をSSFに更新できるでしょう
• Adobeコンサルティングと連携している場合は、移行計画に関する相談を受け、必要に応じてコンサルティングの支援を受けるようにしてください

検証とトラブルシューティング

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について詳しくは、ドキュメントを参照してください。