【Yahoo!広告】サーバー発行の1st Party Cookieを使ったコンバージョン計測

2021年8月現在、GoogleやFacebookを筆頭にベンダーさんが
『ポスト Cookie時代』を掲げて色々と動きが加速していますね。

とはいえ、今のところ本当に『Cookieなし』の計測を用意しているのは
Facebookの詳細マッチングやコンバージョンAPIくらいでしょうか。（あとはGoogleのEnhanced Conversionですかね）

コンバージョンAPIについては実装方法は複数ありますが、サーバーサイドGTM(sGTM)とGoogle Cloud Platform(GCP)を活用した方法については以下も参考にしてみてください。

また、直近ですとGoogleが『サーバーサイドGTM（sGTM)』を活用した
コンバージョンタグ（及びコンバージョンリンカー）の実装をリリースし話題になりました（ただこれはまだ完全なソリューションではなさそう）。

という感じでGoogleやFacebookのソリューションについては結構話題になっている気がするのですが、実はYahoo!も対策案を用意しています。
でも全然話に上がっているのを見かけない（ような気がする）

なので、今回はその話をしていこうと思います。

そもそもCookieについて

釈迦に説法かもしれませんが、そもそもCookieについて。
Cookieの発行方法には2種類あります

こう書くと

「知ってるよ！1st Party と 3rd Partyでしょ！」

と思われるかもしれませんが、そうではありません。

『発行』方法が2種類という話です。

それが、「サーバーから発行するCookie」と「JavaScriptから発行するCookie」です。

このうちITPの規制対象になっているのが「JavaScriptから発行するCookie」です。現在主流の計測タグは通常こちらの方法で発行されたCookieを活用しています。

めちゃくちゃ余談ですが、巷の日本の記事だと

『HttpOnly属性・Secure属性のないCookieがITPの規制対象。よって、サーバーから発行されていても、HttpOnly属性・Secure属性がなければITPが適用される』

と書かれているものを見かけますがこの情報は間違っていると思います。

公式ブログのITP2.1の記述は以下です
https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/

Client-Side Cookies Capped to 7 Days of Storage
Cookies can either be set in HTTP responses or through the document.cookie API, the latter sometimes referred to as client-side cookies. With ITP 2.1, all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry.

Implementation Details
・Only cookies created through document.cookie are affected by this change.
・The change covers cookies created in first-party contexts as well as in third-party iframes.
・Session cookies are not affected, they remain session cookies.
・Persistent cookies that have an expiry shorter than seven days keep their shorter expiry.

つまり、document.cookieをJavaScriptで新たに設定した、もしくは書き換えたクライアントサイドのクッキーのみがITPの対象という記載になっています。

おそらく、HttpOnly・Secure属性が必須という話が広まったのは以下の記述があったからかなと思います。。。

Will This Change Log Users Out?
Authentication cookies should be Secure and HttpOnly to protect them against man-in-the-middle attacks, cross-site scripting attacks, and speculative execution attacks. Cookies created through document.cookie cannot be HttpOnly which means authentication cookies should not be affected by the lifetime cap. If they are, you need to set your authentication cookies in an HTTP response and mark them Secure and HttpOnly.

ここで言っているのは
1. ログインセッションにつかうCookieは当たり前のようにHttpOnly属性とSecure属性が付いているよね
2. HttpOnly属性とSecure属性のうち、HttpOnly属性についてはサーバーから発行するCookie(Set-Cookie)でないと付与できないよ
3. よって、ログインセッションに使うCookieはサーバー発行のCookieだね(HttpOnly属性が付与されているから）
4. つまりJavaScriptから発行されたCookieじゃないのでITP(2.1)の影響受けないよ。

という話であって、HttpOnly属性・Secure属性をつけないとITPの対象になるとは全く書いていません。あくまで『JavaScriptから発行されたCookieじゃない』からITP規制の対象外だよ、という話です。

と言いつつも、一方でAppleはITP2.3の発表時の公式ブログでは以下のようにも書いています。
https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/

A Note On HttpOnly Cookies
Our blog post on ITP 2.1 provided guidance on how to protect cookies. We specifically encourage the use of Secure and HttpOnly cookies.

AppleはCookieの保護方法として、『CookieにHttpOnly・Secure属性を付与することを推奨する』と言っています。

というわけで長かった余談をまとめると
現段階でITP回避にはHttpOnly属性・Secure属性は必須ではないが
AppleのCookie保護方法の推奨しては両属性付与してね、という感じです。

（※余談の余談ですが上記は、A/AAAAレコードを使用している時の話で、CNAMEレコードを用いた方法についてはiOS14.2からITPの対象になっています。）

つまり、HttpOnly・Secure属性が付与されていないCookieについては
今後さらに規制される可能性がある一方、付与していればしばらくは規制の対象にはならないのではと推測出来ます。

・HttpOnly属性
⇒Cookie属性としてこれを付与すると、JavaScriptからのアクセスできなくなる
⇒WEBブラウザ上のJavaScript経由でCookieに保存されているデータを読み出すことが不可
（※そのためHttpOnly属性を付与するとGAでクロスドメインの追跡が出来ないなどの問題もある）

・Secure属性
⇒これが付与されるとHTTPS通信の場合のみCookieをWEBサーバーに送信する

・Set-Cookie
⇒HTTPではSet-Cookieヘッダーを使用してWEBサーバーからブラウザにCookieを発行する

今回紹介するYahoo!のソリューションはHttpOnly・Secure属性を付与したCookieを用いた手法になっています。

それでは早速見ていきましょう。

本題：Yahoo!広告の対策

ここから本題です。

各社「サーバーサイドで色々やろうぜ」という動きをしていますが
Yahoo!も「サーバー発行のCookieを活用した」対策を打ち出しています。（直接利用する、というよりは、間接的に活用する、という方法です。）

実装方法は意外と単純で下記の3つの手順をやるのみです