After ITP時代とは？何が問題か？

ここ数年、Webkit(Safari)陣営によるTrackingに関するさまざまな技術的制約がかかり、ここ1−2年で今までのオウンドメディアに関するデジタルマーケティングの考え方を変えざるを得ない状況になってきましたよね。

ITP まとめ「3rd フルブロックの次はCNAME対策もターゲットに😱」随時更新！

もちろんWebkit(Safari)陣営だけではなく、Chrome(Google)陣営もさまざまな対応は進んでいます。

個人的には、この状況については「今までが無法地帯」に近かったので、ある程度は正しい姿であるとは思います。特に広告系のソリューションについて大打撃を受けており、各社対応を考えて進めている状況であるともいますが…

私が問題だと感じているのは広告などの第三者とデータをやり取りする方ではなく…パーソナライズやWebサイトの効果を測る効果計測、分析周りの領域です。ここの仕組みもITPの影響を受けており、課題になっている状態です。この領域については広告と異なり、収集するのは自社ですし活用も自社、そして活用することで利便性を享受することができるのは利用者…と言う本来であればシンプルな話でここに制約がかかってしまうことで、何が問題かというと「利用者の利便性向上ができない」と言うことです。

具体的に言うと、既存の多くの行動分析・パーソナライゼーションツールにこのような制限がかかっており正しくデータをとらえられない状況です。

訪問者IDの付与判定が1日 or 1週間となってしまい、経過して再訪問した人は新規訪問者扱いとなってしまう
- 過度に新規の扱いになってしまい過去にWebサイトを見ていたとしてもその事をデータで知ることはできない。
- もちろんパーソナライゼーション観点でも同様に制約がかかる

ちなみに、上記の条件の差異はこちらです。
1日になる条件＝ IDの発行がJavaScriptでCookie発行を行っている場合
1週間になる条件 = IDの発行がCNAMEで設定されたサーバーサイドで行っている場合

これは頻度良くアクセスするようなソーシャルメディア系等のサービスを提供している企業であったり、もはやCookieを活用した訪問者特定をする必要がなく、ログインIDをベースにした情報収集のみで問題がないECサイト等であれば、良いのかもしれませんが…そんな業態ばかりではないとも思います。実際に自分のことを振り返ると、銀行系のサービスは月に1回ですし…なんか買う時に色々調べてタブ放置して数日経って…みたいな事ありますし。

そもそも、初めてのお客さんでいきなりログインさせるってレベル高いですよね。買う前に色々調べたり比較したりしてるお客さん、大事じゃないですか…！？

After ITPのオウンドメディア生存戦略

ここからが本題です。ではどうするべきか？
今回の課題は「訪問者を特定するID情報が最大でも1週間になってしまう」ことが問題です。なので結論はこれを伸ばせばいいんです。どうやって伸ばすか？

自社のサーバーサイドでブラウザごとに発番するIDを発行する仕組みを作る

しかないんです。昔からJavaなどであるSession IDの発行管理とかの考えと同じです。自前で持ちましょう。ただ、ちょっとだけ異なるのは…全部自前で管理する必要はないと思っています。

と言うのも、IDをブラウザCookieで1週間以上の期限をもって維持するためにはITPの制約上「自社サーバー側で発行し付与した」Cookieではないといけないのですが、そのIDに対する行動データや属性データなどは自社で必ずしももつ必要はないです。

IDの発行は自分たちのサーバーサイドで発行。それに紐づくデータはどこでも格納というイメージですね。

各マーケティングシステムの対応について

上の理論は分かりましたが、各マーケティングシステムがどうなってるのかって話が多分つきまといますよね。そこについても話をしたいと思います。

Google Analytics(GA4)

Google AnalyticsではAfter ITPでの問題を、Googleが持つあるGCPの機能を持ってクリアすることにしました。それがServer-Side Google Tag Manager(以下SSGTMと略称) です。

これは何かというと、このSSGTMで作るGoogle Tag Managerのコンテナは「Googleのサーバーではなく、自社のサーバーとして認識」してもらう事でクリアするという方法です。

上記を満たすには、SSGTMだけしても駄目です。厳密にはSSGTMを自社ドメインのサーバーとして動かすように設定するのが条件です。(この後説明)

SSGTMの設定等はこちらを見ると参考になります。(リリース当初と現在の設定方法がだいぶ異なりますので…最新を参考にしましょう。)

先程も書きましたが、SSGTM自体では今回の問題は解決しません。SSGTM自体はトラッキングなどのデータ送付自体をブラウザが処理するのではなく、サーバーサイドで行うことによるデータ送付の集中管理がメリットでして…(今回は割愛。詳しくはこちらを)

前述の通り、今回はやらなければいけないのは「自社のサーバーサイドでブラウザごとに発番するユーザー特定IDを発行する」ことです。ということは計測処理を行うトラッキングサーバーが自社である必要があります。そこでGoogleの対応方法として、GCPを活用し簡単にトラッキングデータを受け止める＋ブラウザごとのIDを発行管理しますよというアプローチです。Googleの強みであるCloud Computing領域の技術や資源をうまく活用したアプローチですよね。

よってこのSSGTMを立ち上げるとそこで1台GCPでサーバーがデプロイされます。サーバーの利用費は払うことになりますが、最低でも立ち上げてるだけで月2円程度… 受けるデータ量でも変わりますが、そこまで大きい額にはなりません。

このGoogle Analytics側の対応例を図解してみました。

Adobe Analytics

Adobe Analyticsでは先程のGoogleと異なるアプローチでクリアするようにしています。
それは自社でブラウザごとに発番するIDの仕組みを自社で持ってもらうという方法です。

ちょっと技術的な敷居が高いようにも聞こえますが、実際はそんなに複雑なことではないです。(後述)

各企業が持つサイト自身でブラウザごとに発番するIDを生成・管理してもらい、その値を受け取って計測処理をしていくことで、最大1週間という制限が開放されて、Cookie本来の有効期限を利用することが出来ます。

First-party device IDs in the Platform Web SDK

こちら方式の対応例も図解してみました。

おまけ)サーバーサイドで発番する IDの具体例

これは各自が運用しているウェブアプリケーションの仕組みなどに引っ張られるので、あくまで参考例ですが…例えばPythonとかで書くなら、UUIDの生成ロジックを使ってCookieに書き出せば一発です。

## レスポンスを返す前にこんな感じでCookieの判定処理を書けばOK。
## 訪問者文字列はuuidを使えば簡単。

    ## if already set "fpid" cookie, then use cookie value
    fpid = request.cookies.get('fpid', None)

    if(fpid == None):

        ## generate a unique id
        fpid = str(uuid.uuid4())

## ここでCookieのセットを行う(有効期限更新も込めて)
    resp = make_response(render_template('index.html'))
    resp.set_cookie('fpid',
        value=fpid,
        max_age=60*60*24*30*13,
        domain=request.host,
        path='/',
        secure=True,
        httponly=False,
        samesite='lax'
        )

    return resp

なお、このIDについては任意の文字列ではなく、UUIDv4フォーマットであることが必須です。
UUIDv4フォーマットは以下を参照ください。
https://datatracker.ietf.org/doc/html/rfc4122

まとめ

ということで簡単にまとめてみました。

もっと各製品ごとに対応が色々と異なる所もありますし、これだけでは問題解決しないところもあります。(例えば広告周りとかそうですよね。今までドメインまたいで属性情報を収集してた所をどうするか…など。)これはこれで、推計モデルなどを使ってマッチさせるような手法を利用しているところもあります。

個人的には、このデジタルマーケティング界隈の動きは悪いことではないと思っていますし、だからこそMarTechについてちゃんと本気で取り組むような企業が増える＋MarTech人材が増えないかなと思っております。

久しぶりに投稿したネタが若干古い(すでにITPのこの対応は2020年3月ぐらい…)ですが、ご了承を…。