ホーム
Adobe Analytics, Google Cloud Platform, Web解析
【実験してみた】CNAMEを使わずにAdobeAnalyticsを1stパーティクッキーで計測する

2020.09.1

【実験してみた】CNAMEを使わずにAdobeAnalyticsを1stパーティクッキーで計測する

こんにちは、エクスチュアの権泳東(權泳東/コン・ヨンドン)です。

SafariのITPがついにCNAMEによってセットされたクッキーもターゲットにしましたね。

215201 – Experimental: Cap the expiry of persistent cookies set in 3rd-party CNAME cloaked HTTP responses

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サービスを利用してるサイトのみ

Experience Cloud cookies

ですがこの方法ならば既に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などのパブリッククラウドを使ったデータ分析基盤構築コンサルティングサービスを提供しております。

お問い合わせはこちらからどうぞ。