先月ITP2.3が発表されましたね。
ITPの短い歴史では初めての事後発表になってしまい、リリースまでに対応できないサービスが多かったと思いますが、アドエビスは３月末から準備を進めていました。
3月20日に届いた、Slackに仕込んだ自動ITP仕様変更検知から始まりました。

7月に、他のブログ記事でも紹介されたように、

ITPの仕様変更はwebkitのコミット履歴やbugzillaを調査すればわかるのですが、いち早く変更を検知するために、ITP実装の心臓部であるResourceLoadStatisticsMemoryStore.cppというファイルのコミット履歴RSSをSlackに登録しています。なお、ITP2.1のdocument.cookieの制限ように、トラッカー(prevalent resource)判定に関係ない機能は別ファイルに実装されていてこの仕組みでは検知できないので注意が必要です。

そして3月20日の自動検知を受けて、計測機能のLocalStorage対応のリリース直後だったということもあり、開発チームに動揺が走り、いや、一人でパニックに陥り、意味不明の呟きがしばらく続くのですが、

その後元気を取り戻して、最新のwebkitソースコードを落とし動かしてみたりコードを確認したりして調査を進め、次第にITP2.2/3の仕様が明らかになりました。

実はこの時点で分かった仕様は、正式発表後の今でもあまり知られていないようです（ご存知だった方コメントください。あ、サポートページに記載しているのでアドエビスのお客様ならご存知のはずです）

1. LocalStorageの有効期間は最短0秒

具体的には、3月28日のslackでは仕様を以下のようにまとめていますが、

• トラッカーからパラメータ or フラグメント付きURLでアクセスしたページで、JavaScriptで設定したcookieの有効期間を1日に制限。同じドメインの別のページに遷移した後に設定したJavaScript cookieは通常の７日になります。つまりLPで設定したJavaScript cookieのみ1日になります。
• トラッカーからパラメータ or フラグメント付きURLでアクセスしたドメインのlocalstorageは最後のinteractionから7日すぎたら削除。削除された後パラメータなしで再び流入すればずっと残ります。パラメータ付き流入のたびに時限爆弾設定。逆にパラメータ付き流入して、interactionせずに離脱すれば即（1時間以内）削除されそう。

LPから遷移した後に設定されたcookieの有効期間が7日に戻る点、およびクリック・タップなどのinteractionが発生していないドメインについてLocalStorageが１時間以内に削除される点はITP2.3の発表記事では伝わりにくく、動作確認しても気づきにくいです。ちなみに「１時間以内」の理由は、ITP1からのあまり知られていない仕様で、省エネ化のために削除処理と削除処理の間に１時間以上開けるという制御が入っているためです。最悪の場合数秒で削除されます（前回のデータ削除処理から１時間以上経っていれば）。

2. LPのパラメータとリファラー制限は関係ない

さらに、ITP2.3のもう１つの機能であるリファラーの規制についても勘違いしがち点があります。例えば下記では

referrerが完全に残っていた
WebKitの公式記事のとおりではない挙動が一部見られるケースがあり、気を付けなければならない。

となっているケースは実際は仕様通りです。
具体的には、cookieとLocalStorageと違って、リファラーの制限はLPのパラメータと関係なく、リファラー自体にパラメータがある場合だけ機能する、という点です。こちらはwebkitのブログ記事に明記されています（if the referrer has link decoration）が、storage制限の発動条件（LPにパラメータあり）と混同しやすいです。アドエビスチームでも最初は混同してしまいました。

ちなみに、メージャーな検索エンジン（Google, Yahoo!）からの流入は、検索エンジン側のreferrer-policy {リンク}設定によって、どのブラウザでも昔からリファラーURLのパラメータやディレクトリが消えているので、ITP2.3のリファラー制限が発動しません（消すものはそもそもありません）。チームで確認した範囲ではITP2.3のリファラー規制を受けているのはreferrer-policyが特に設定されていなさそうなheadlines.yahoo.co.jpからの流入のみでした。

3. ITP2.3の不具合らしいものも

marketechlaboも記事では以下の不思議な記述があります。

Google検索広告からの流入でGA/GoogleAdsのcookieは影響を受けるが、Facebookからの流入ではFBのcookieは影響を受けていない。

初めて読んだ時に、気のせいだと思って、スルーしてしまったのですが、FBで動作確認したところたしかに影響を受けない結果となったため、検索エンジンのリスティング広告との違いを考えて、「別タブ」で開く点に着目しました。そしてGoogleで実験したところ、

・リスティング広告を普通にタブ内で開くとLPのcookieの
　有効期間が1日に制限（ITP2.3発動)
・別タブで開くとcookieの有効期間が7日のまま（ITP2.3機能せず）

ということがわかりました。バグの可能性が高いのでbugzillaで通報検討中です。バグのままがありがたいかもしれませんが。

何はともあれ、結論、疑似1st party cookieとLocal storageを使ってITP対策をしてきたというツールの場合でも、広告接触後1日以上経過してからコンバージョンしているというような数字は計測がとれなくなるということになります。

アドエビスチームでもこの対策として、1日以上過去の潜伏期間のあるコンバージョンまでカバーした計測方法をいくつか検討してきましたが、顧客に設定負荷をかけすぎない、次期ITPですぐ(※)に計測がとれなくなることもない、計測方法としてはCNAMEを使った計測がベストという結論になりました。

※ 以下の通り、apple.comでもCNAMEが使われているため。

最近（今月？）はCNAME先のサーバがAdobe SystemsからAWSに変わって、わかりにくくなりましたが。

アドエビスのITP対策、CNAMEの計測について詳細はアドエビスのサポートサイトにまとまっています。興味がある方はぜひお問い合わせください。