こんにちは、エクスチュアの権泳東(權泳東/コン・ヨンドン)です。
SafariのITPがついにCNAMEによってセットされたクッキーもターゲットにしましたね。
Adobe Analyticsを利用しているサイトでは、計測サイトのサブドメインにAdobeのサーバーをCNAMEとして割り当てて計測する方法が進んでますが、ITPのCNAMEブロック機能がリリースされるとAdobeのクッキーにも無慈悲な鉄槌が振り下ろされる事になります。
一方、GoogleAnalyticsでは、先日Server-Side GTM(以下SSGTM)がリリースされました。
SSGTMを使えばFPIDという従来の_gaクッキーに置き換わるサーバーサイドクッキーがセットされます。
これによって、
・CNAMEを使わない
・1stパーティドメインからセットされるhttp-onlyのクッキー
という計測が出来るようになるので、SSGTM+GoogleAnalyticsなら当面はITPによって消されないクッキーになります。
じゃ、Adobeはどうすんの？と思ってますがまだアナウンスがない。
という訳で自衛すべく、回避策を考案して実験しました。
何をどうするかというと、
計測サイトのサブドメインをAレコードを持ったサーバーに割り当てて、そのサーバーからリバースプロキシを使ってAdobeにデータを転送する。
という方法です。
構成図
今回は弊社のテスト用サイトを使って検証しました。
https://devstg-1.gcp.ex-ture.jp/
1. リバースプロキシサーバーを立てる
私はGCPが大好きなので、今回もGCPのCompute Engine(GCE)を使ってLinuxサーバーを立てます。
OSはUbuntu20.04です。
インスタンス起動後、SSHでログインしてnginxをインストールします。
LetsEncryptのSSL証明書も使うので、certbotもインストールしておきます。
$ sudo apt update -y $ sudo apt upgrade -y $ sudo apt install nginx certbot python3-certbot-nginx -y
2. DNSにAレコードを登録する
GCEのLinuxサーバーのIPアドレスを固定して、DNSにサーバーIPに対するAレコードを追加します。
今回は stats.ex-ture.jp というホスト名を使う事にしました。
Aレコードを登録したので、digを使うとこのようにIPアドレスが返ってきます。
$ dig stats.ex-ture.jp #中略 ;; ANSWER SECTION: stats.ex-ture.jp. 425 IN A 35.243.125.37
3. SSL証明書の取得と自動更新設定
今回のお題とは直接関係ないのですが、SSLを使うのでcertbotを設定します。
$ sudo certbot --nginx -d stats.ex-ture.jp
このあと適宜質問に答えて設定を進めます。
最後の「リダイレクト設定をするか？」という問いには「2.Redirect」を選びます。
SSL証明書をインストール後、一回nginxを再起動しておきます。
$ sudo systemctl restart nginx
ここで一旦ブラウザでSSL通信が可能か確認しておきます。
https でアクセス出来ればOK。
4. リバースプロキシ設定
さてこれが本題です。
リバースプロキシの転送設定と、あとはクッキードメインの書き換え設定を /etc/nginx/sites-available/default に書きます。
Certbotによって証明書ドメインのホスト名が追加されたserverセクションがあるので、そのlocationセクションにリバースプロキシ設定を追加します。
server {
#中略
server_name stats.ex-ture.jp; # managed by Certbot
location / {
#以下4行を追加
proxy_pass https://exture.sc.omtrdc.net;
proxy_pass_request_headers on;
proxy_cookie_domain exture.sc.omtrdc.net .ex-ture.jp;
proxy_cookie_domain sc.omtrdc.net .ex-ture.jp;
}
#省略。以下SSL設定など
}
何をやってるかというと、stats.ex-ture.jp 宛のリクエストを全てAdobeAnalyticsのサーバーであるexture.sc.omtrdc.netに転送してる訳です。
そして、Adobeのサーバーが返すクッキーのドメインを.ex-ture.jpドメインに書き換えてブラウザに戻してます。
変更を保存後、nginxをまた再起動します。
$ sudo systemctl restart nginx
5. Adobe Analyticsタグ(Adobe Launch)の設定
タグ設定といえば、ビーコンの送り先をstats.ex-ture.jpに変えるだけです。
trackingServerを変更
設定を反映してLaunchをパブリッシュすると、nginxのリバースプロキシ経由での計測が始まります。
ビーコンを見るといずれも stats.ex-ture.jp 宛に発生しています。
サブドメイン宛にビーコンが発生
そしてセットされるクッキーを見ると、ちゃんと .ex-ture.jpでセットされてます。
.ex-ture.jp ドメインでクッキーがセットされる
で、ここで鋭い方は気がつくはずです。
s_ecidクッキーがセットされてません。
実は弊社はAdobeAnalyticsをCNAME実装してないため、Adobe側がhttp-onlyでs_ecidクッキーをセットしてくれません。
※s_ecidクッキーがが配信されるのはCNAMEサービスを利用してるサイトのみ
ですがこの方法ならば既にCNAME実装しているサイトのs_ecidクッキーもnginxによってセットされるようになります。
なるはずです。
以上、やや歯切れが悪いのですが実験結果でした。
TL;DR
今回はCNAMEを使わずにAdobeAnalyticsを1stパーティクッキーで計測する方法を実験してみました。
サイトのサブドメインでDNSのAレコードを割り当てたnginxサーバーを立てて、そこでリバースプロキシを稼働させます。
そしてそのリバースプロキシ経由でAdobeの1stパーティクッキーをセットしました。
私の希望的観測ですが、Safari ITPのCNAMEブロックがリリースされるよりも前にAdobeがSSGTMのようなソリューションをAWSかAzureを使って実現してくれるんじゃないかと期待してます。
ただの期待で終わるかも知れませんが。
弊社では、Adobe Analytics認定エキスパート資格・Google Cloud認定プロフェショナルデータエンジニア資格・Linux Professional Institute認定レベル3資格を持ったエンジニア達が各種マーテックツールの導入実装コンサルティングサービスや、GCP/AWSなどのパブリッククラウドを使ったデータ分析基盤構築コンサルティングサービスを提供しております。
お問い合わせはこちらからどうぞ。
