3月になり花粉症を罹患されている方にとっては、辛い季節になってきましたが、皆様はいかがお過ごしでしょうか。
かく言う私も、最近、花粉症がひどくなってきて、この季節が嫌いになってきました。
SBテクノロジーにて、Adobe Experience Cloud 製品に対するコンサルティングを行っているチームに所属している長沼です。
最近、Adobe 社の「 Web SDK 」に関するお問い合わせを頂くことが多くなってきました。そこで、「そもそも Web SDK とは何？」といった部分をご説明していきたいと思います。
Adobe Experience Cloud を使った計測やパーソナライゼーションを行われている方々にぜひともご検討頂きたい内容を記載しています。
Adobe Marketing Cloud の進化は日々続いております。
計測のために使用する JavaScript ライブラリも例にもれず、常にバージョンアップが繰り返されております。
その最新のテクノロジー成果としてAdobe社より提供されているのが、「 Web SDK 」という名の JavaScript ライブラリとなります。
端的に言ってしまえば、これまでの AppMeasurement.js（ s_code.js ）や at.js（ mbox.js ）に変わるものです。
これまでは、Adobe Analytics 用の JavaScript ライブラリ、Adobe Target 用の JavaScript ライブラリといった具合に使用する Adobe 製品ごとにライブラリが分かれていましたが、Web SDK ではこれらが全て統合されています。
かつ、完全に書き直しされた、全く新しい JavaScript ライブラリとして登場しています。
また、Adobe 製品ごと個別に行われていた通信も統合化され、例えば一回の通信で、ECID の取得や、Adobe Analytics への計測内容の送信、Adobe Target からのオファーの取得が行なえるようになっています。
この通信の統合化を実現するため、リクエストを受け取るサーバー側の統合が行なわれています。
新しく「 Edge Network 」という名前のエンドポイントが設置され、このサーバー向けに通信を行うようになります。
Adobe 社のヘルプサイトなどを確認すると、これまで以下のような課題があったものが、この Web SDK を使用することで解決できるものと記載されています。
今後は、Adobe 社もこの Web SDK に注力していくことになると思います。徐々に現状使用している JavaScript ライブラリはレガシー化されていくことでしょう。
事実、Adobe Journey Optimizer など一部ソリューションにおいては、この Web SDK を使用していることが前提となっています。
皆様のサイト計測やパーソナライゼーション、Marketing Automation 対応のためにも、イノベーションに追随すべく、Web SDK 移行への検討を行っていただいたほうがよい時期にきております。
また、この後、ご説明しますが、実装においては、かなりのパラダイムシフトが起きております。移行する場合、かなり計画的に実施する必要があり、準備なども含めて時間を要することになります。
Web SDK の特徴としてもう一つ忘れてはならない技術があります。
Web SDK から、特に iOS における ITP ( Intelligent Tracking Prevention ) 対策のために、「 FPID 」という名の新しい訪問者 ID が導入されています。
個人情報保護の観点などから、ブラウザにおける Cookie 規制が厳しくなってきています。現状においてその最たるものが iOS による ITP ではないでしょうか。
Adobe マーケティングソリューションでは、現在、ECID ( Experience Cloud ID ) という訪問者管理の仕組みがあります。こちらは First Party Cookie として保持されますが、JavaScript による生成のため、ITP により１日程度で消去されてしまいます。
そこで、その対策として、CNAME 対応という、Adobe 社サーバーとの送信先を、DNS 設定を駆使して、あたかも自社サーバーに送信しているかのように見せかける技術を使い、サーバーサイド（実態は Adobe のサーバー）から Cookie を書き出してもらうことにより、Cookie の延命措置を図ってきました。
ただ、こちらも ITP の影響で、７日程度で Cookie から消去されてしまいます。
この結果、新規訪問者が水増しして計測されていることになります。
この対策として生まれた技術が FPID となります。
ITP の特性上、DNS の A レコードに登録されているサイトから発行された Cookie は削除対象になりません。
この特性を利用して、任意の名称の Cookie（ただし First Party Cookie として）をサーバーサイドから発行し、その Cookie にある一定のフォーマットで ID を設定します。
Edge Network では、送信された Cookie をもとに、ECID を発行します。ただし、FPID が変わらない限り同じ ECID が発行されます。
ご注意頂きたいのは、実のところ、訪問者管理で ECID を使うという点は、これまでと同様のままです。
FPID は、ECID のシーズ（種）となる値を提供するだけになります。Edge Network から発行された ECID Cookie が ITP の影響で削除されてしまったとしても、自社サーバーから発行された FPID を格納した Cookie が残っていれば、同じ ECID が発行されるため、訪問者の識別が継続されるという仕組みになっています。
さて、もう一つ訪問者管理に関しては重要な点があります。
vid とよばれる独自生成の訪問者 ID が Web SDK では使用できません。救う手立てはなくもないのですが、できる限り、Adobe 社が推奨している ECID への移行をご検討頂いたほうがいいでしょう。
Adobe Analytics に対する計測実装上、一番留意しないといけないのがこの点になります。
Web SDK を導入すると、これまでのような s オブジェクトに対して計測値を設定するという手法が使えなくなります。
Web SDK から導入された、XDM ( eXperience Data Model ) というスキーマ(データ構造)に沿って、計測値を設定していくことになります。
上記の図の通り、これまではある意味フラットなデータ構造でしたが、XDM においては階層化されたデータ構造になりますので、これまでの常識が通用しません。
ですので、計測実装も実装の方法によっては大きく見直す必要が出てきます。
簡単ではありますが、これまでご説明した通り、移行においては s_code.js から AppMeasurement.js への移行や、mbox.js から at.js への移行といったレベルではないほどのインパクトがあるものとなります。
Adobe Experience Platform Launch 側での実装変更もさることながら、ページ内に埋め込まれている各種計測のための実装も大きく変わることになります。
よって、今からでも移行計画を立てながら、移行を徐々にでも進めて頂いたほうがよいかと思われます。
SBテクノロジーでは、長年の Adobe 製品に対するコンサルティング実績もあり、また、今回ご紹介した Web SDK 移行におけるご支援も実施しております。
これまでの経験も活かし、最適化された移行プランをご提示できますので、ご検討やご相談などございましたら、お気軽に以下リンクよりお問い合わせください。
お問い合わせはこちら：SIGNAL コンサルティングサービス
関連ブログ記事
アクセス解析ツール『Adobe Analytics』って何ができるの？
|
