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

このチュートリアルは、Adobe Audience Manager(AAM)とAdobe Analyticsの両方を使用し、現在、「DIL」(Data Integration Library)コードを使用してページからAAMにヒットを送信し、さらにページからAdobe Analyticsにヒットを送信している場合に適用されます。 これらのソリューションは両方ともAdobe Experience Cloudに含まれているので、ベストプラクティスに従う機会があります。「Server-Side Forwarding (SSF)」をオンにすると、client-sideコードでページからAAMに追加のヒットを送信する代わりに、Analyticsデータ収集サーバーがリアルタイムでサイト分析データをAudience Managerに転送できます。 このチュートリアルでは、古い「Client-Side DIL」実装から新しい「Server-Side forwarding」メソッドへの切り替えの手順を説明します。

Client-Side (DIL)と Server-Side

Adobe AnalyticsのデータをAAMに送信するこれら2つの方法を比較および対比する場合、まず次の画像の違いを視覚化すると役に立ちます。

Client-side DIL の実装

この方法を使用してAdobe AnalyticsデータをAAMに送信する場合、Webページから2つのヒットが得られます。1つはAnalyticsに移動し、もう1つはWebページ上のAnalyticsデータをコピーした後にAAMに移動します。 Segments はAAMからページに返され、そこでパーソナライゼーションなどに使用できます。これは「レガシー」実装と見なされ、お勧めしません。

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

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

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

Server-Side Forwarding 実装

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

Segments は、同じリアルタイムヒットでに返されま Analyticsす。これは、パーソナライゼーション用にWebページに応答を転送します。

サーバー側転送に移行するタイミングを下げることはできません。 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が全ての難しい作業を行ったので、これは非常に簡単な作業です。
• ページ —AdobeLaunchを使用していない（まだ使用していない）場合は、新しいSSFコードをappMeasurement.jsファイル内のdoPlugins関数に直接配置することもできます
• 他のタグマネージャー — これらは、他のタグマネージャーがAppMeasurementコードを保存している場所にSSFコードをdoPluginsに配置するので、前の（ページ上の）オプションと同じように扱うことができます

コードの更新の節で以下の各項目を確認します。

導入手順

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

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

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

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

Client-SideDILコードからServer-Side Forwardingに移行する準備が整ったら、最初の手順は、AAMに送信されるカスタム設定やデータなど、DILコードでおこなっているすべての操作を特定することです。 注意事項と考慮事項は次のとおりです。

• siteCatalyst.initDILモジュールを使用した通常のAnalytics変数 — この変数について心配する必要はありません。これは、通常のAnalytics変数を送り返すだけで、SSFが有効になっているだけで発生するからです。
• Partnerサブドメイン —DIL.create関数で、partnerパラメーターをメモします。 これは「パートナーサブドメイン」または「パートナーID」と呼ばれ、新しいSSFコードを配置する際に必要になります。
• Visitor Service Namespace - 「Org ID」や「IMS Org ID」とも呼ばれ、新しいSSFコードを設定する際にもこれが必要です。書き留めておけ。
• containerNSID、uuidCookie、およびその他の高度なオプション — 使用しているその他の高度なオプションをメモしておき、SSFコードでも設定できるようにします。
• 追加のページ変数 — （siteCatalyst.initで処理される通常のAnalytics変数に加えて）ページからAAMに他の変数が送信される場合、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つの質問です しかし、答えは…に依存しているし、**​問題になる。 どうです？ 分けてみよう。 しかし、まず、多くのサイトを持つ大規模な組織の場合に出る可能性のある追加の質問を次に示します。私は一度に全てを行わなければなりませんか？ それは少し簡単です。 いいえ。 一つ一つで…:)

もう少し深い潜り込み

タイミングと注文が重要な理由は、次の技術的事実に要約できる、転送の仕組みが原因です。

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

ベストプラクティス

これらの技術的な詳細に基づき、次に「どのようなタイミングで」をおこなうかを推奨します。

ECIDがまだ実装されていない場合

1. SSFに対して有効にするreport suiteごとにAnalyticsでスイッチを入れます。

   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が有効になっているので、転送が開始されます

   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にマッピングされるので、エンタープライズをSSFに更新し、これらの個別のグループで1つずつ動作する計画を立てることができます
• Adobeコンサルティングと連携している場合は、移行計画について相談し、必要に応じてサポートを提供してください

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

Server-Side Forwardingが起動および実行されていることを検証する主な方法は、アプリからのAdobe Analyticsヒットへの応答を調べることです。

AnalyticsからAudience Managerに対してserver-side forwardingデータを実行していない場合、（2x2ピクセル以外に）Analyticsビーコンに対する応答はありません。 ただし、SSFを実行している場合は、Analyticsリクエストと応答で確認できる項目があり、AnalyticsがAudience Managerと正しく通信していること、ヒットを転送して応答を取得していることを確認できます。

警告： 偽の「成功」に注意してください — 応答があり、すべてが機能しているように見える場合は、応答に「stuff」オブジェクトがあることを確認してください。そうしないと、“status”:"SUCCESS"というメッセージが表示される場合があります。 変に思えますが、これは実際には正しく機能していない証拠です。 これが表示された場合、LaunchまたはAppMeasurementのコード更新は完了していますが、Analytics Admin Consoleの転送はまだ完了していません。 この場合は、report suiteのAnalytics Admin ConsoleでSSFを有効にしていることを確認する必要があります。 バックエンドで必要な変更をすべておこなうのにそれほど時間がかかる場合があり、まだ4時間が経過していない場合は、しばらくお待ちください。

Server-Side Forwardingについて詳しくは、ドキュメントを参照してください。