オルタナティブ・ブログ > 秋山大志のそれとりあえず作ってみようか。 >
RSS
秋山大志のそれとりあえず作ってみようか。

あれこれ考えるよりも作ってしまった方が早いんじゃね？と思う、ギークなサラリーマンのアジャイルな日々。

【ITP2.1対策】Google Analytics（グーグルアナリティクス/GA）サーバーサイドCookie期限延長にSecure / HttpOnly属性はいらない

»

GW前（4月24日）に、WebKit（ウエブキット：アップルが中心となって開発されているオープンソースのHTMLレンダリングエンジン群の総称）の開発者ブログでSafariのユーザートラッキング防止機能であるITP2.2の詳細が発表されました。

公式：Intelligent Tracking Prevention 2.2
https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/

え？ITP2.1対応も業界的にままなっていないのにもう次かよ？！

早すぎる・・・。

ITP2.1が発表されたのが、今年（2019年）の2月21日だったので2か月強でのユーザートラッキング防止に対する仕様が追加されたことになります。ちなみにITP2.0は2018年6月4日。

参考：ITP（ユーザーのPrivacy保護に関わるWebKit開発者ブログエントリーの一覧）
https://webkit.org/blog/category/privacy/

2017年6月5日のITP1.0の発表以来、主に3rd Party Cookieを使ってきたSSPやDSPなどアドネットワーク広告周りの事業者やプラットフォーマー、アフィリエイトベンダーはITPを乗り越えるために様々な対応をしてきました。

そのひとつが、ITP2.0までは制限の対象になっていなかった1st Party Cookieを活用する迂回方法です。今回ITP2.2で制限されたリンクデコレーション（URLパラメタとしてユーザーIDなどのセッションをつける方法）等と組み合わせて、クロスサイト（クロスドメイン）でユーザーを永続的に追跡する、つまりITP越えをする仕組みでした。

ITPを実装する側としては、制限したつもりが抜け道を通るイタチがたくさんいたということで、当然そちらの抜け道も塞いでいくこととなる、それが今回ITP2.1でブラウザサイドのJavaScriptでdocument.cookieを用いて設定した、1st Party Cookieの期限を最大1週間にするという衝撃的な内容となりました。

公式：Intelligent Tracking Prevention 2.1
https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/

ITP2.1の何が衝撃的だったかというと、とうとう1st Party Cookieというある意味聖域として守られていた領域にまでITPが踏み込んできたということです。

特に私が発表時にまっ先に気になったのが、Google Analytics（グーグルアナリティクス／通称 GA）のトラッカーが発行するCookieです。

ITP2.0までは、GAの測定用クッキー（_ga）は1st Party Cookieということで自社サイトの分析についてはITPの影響をほぼうけなかったが、ITP2.1ではクライアント（ブラウザ）サイドで設定したCookieということで、今まで有効期限が2年間あったGAの測定用クッキー（_ga）がSafari12.1以降では最大1週間に詰められてしまいます。

つまり、前回訪問から8日以上経ってから訪問したユーザーは再訪問者（リピーター）ではなく、初訪問者（新規ユーザー）として認識されてしまう。これは、ユーザーとのWEB上での長期的なコミュニケーションを分析することによって、ユーザーとサイト運営者、双方のLTV（Life Time Value／ライフタイムバリュー）を高めることを考えてきた私にとっては限定的な影響とはいえ衝撃的なことでした。

ただ、2月にITP2.1が発表され、それから約1か月後の日本時間3月26日にiOS12.2／macOS Mojave 10.14.4と共にITP2.1を実装したSafari12.1が正式にリリースされて1か月が経った今も、自分の周りのGoogle Analytics周りの界隈ではあまり大騒ぎになっていないですね。

その理由をいくつか考えてみると、

  1. そもそもITPを知らない
  2. PVやセッションが重要な指標であり、ユーザー視点での長期的な分析はしていない
  3. Google Analytics（リセラー）側で対応してくれるだろうという希望的観測
  4. サクッとlocalStorageやサーバーサイドCookieで対応した
  5. 対応をしたいが、対応の仕方がわからない
  6. 対応の方法は大体分かっているが、サイト修正まで手が回らない。
  7. 上記以外（例えばUserIDを使っている 等）

１のような方に関しては、ぜひこの機会にITPやクロスサイトトラッキングについていろいろ調べてみてください。

２のような方は、それで事業や業務が回るのであれば良いが、PVやセッションはユーザーとのコミュニケーションの結果であり、ユーザーとのコミュニケーションを分析する上で、新規のユーザーなのか、過去に接点があったユーザーなのかなど、ユーザーとの関係を長期的に分析することが今後重要になってくると申し上げたい。

３は残念ながら、5月4日現在GoogleからはITP2.1にフォーカスした対応は発表されておらず、実際にGoogle AnalyticsのCookieの有効期限は実際1週間に詰められてしまっていました。ただ、ITPが発表される前から、GAの測定のためにCookie以外の方法、例えばlocalStorageを使う方法がヘルプには書かれていて、サクッとそれを導入した４のような方もいるかなと思います。

Cookie とユーザーの識別 ー Cookie を無効にする
https://developers.google.com/analytics/devguides/collection/analyticsjs/cookies-user-id?hl=ja#disabling_cookies

ただし、上記ヘルプにも以下のように書いてある通り、localStorageも様々な制約がある。特にサブドメインの問題は結構頭が痛いんじゃないかな。

注: Cookie と異なり、localStorage は同一生成元ポリシーの制限を受けます。サイトの一部が別のサブドメインに属する場合や、http を使用するページと https を使用するページが混在する場合は、それらのページの間で localStorage を使用してユーザーをトラッキングすることはできません。このような理由で、Cookie がクライアント ID を保存する公式の推奨方法となっています。

私がおススメするITP2.1対応は、今回制限の対象には入っていないサーバーサイドCookie、つまりHTTPヘッダのSet-Cookieでクライアントサイドで設定した_ga Cookieの有効期限をGAの通常設定の2年間、もしくは10年などユーザーがリセット等をしない限りほぼ永続するCookieとしてセットし直すことを軸とする対応です。

ただ、上記の方法をGoogle Analytics周りの会でとある会社の方にお話したところ、サーバーサイドCookieでITP2.1の1週間制限を迂回するためには、そのCookieにSecureとHttpOnly属性（オプション）を付けないといけないという情報がネット上にあり、やはりGAの対応には使えないのではないかと考えていると言われました。

いや、その情報間違っています。

以下、公式ブログにもあるように、ITP2.1の1st Party Cookie有効期限7日間制限を受けるのは、"client-side cookies, i.e. persistent cookies created through document.cookie" つまり、document.cookieをJavaScriptで新たに設定した、もしくは書き換えたクライアントサイドクッキーのみになります。

公式：Intelligent Tracking Prevention 2.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.

おそらく、その情報をの元ネタは、以下のセクションの勘違いかと思いますが、

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.

上記は、そもそもログインセッション用に使うCookieってサーバーサイドCookieで、当然ながらSecureとHttpOnly属性もつけているだろうから、今回のITP2.1の影響は受けないよって言っているだけで、SecureとHttpOnly属性をつけないとサーバーサイドCookieも7日間の有効期限制限を受けるとは、全く書いていません。

実際に、以下のような確認ページを作って検証してみましたが、SecureとHttpOnlyオプションをつけなくても、有効期限が詰められることはありませんでした。

ITP2.1確認ページ
https://abc.go2020.tokyo/itp21/checkcookie.html

ちなみに、上記でサーバー発行CookieによるCookie書き換えはAjaxで行っていますが、Apacheであれば、mod_rewriteなどを使ってGA用のCookieの有効期限を延ばしたSet-Cookieレスポンスをオウム返しで応えるのは結構簡単にできますので、サーバーサイドの設定を弄れる方は参考にしてみてください。もちろん、Perl、PHPやRubyなどのCGIを使ってオウム返しのCookieヘッダをつけることも簡単にできます。

RewriteEngine on
RewriteCond %{HTTP_HOST} (([a-zA-Z0-9\-]{3,61}\.[a-zA-Z]+$|[a-zA-Z0-9\-]{1,61}\.[a-zA-Z]{2}\.[a-zA-Z]{2}$))
RewriteRule .* - [E=CODOM:%1]
RewriteCond %{HTTP_COOKIE} _ga=([^;]+)
RewriteRule .* - [CO=_ga:%1:%{ENV:CODOM}:5256000:/]
※上記のケースではHTTP_HOSTはサブドメインではなくドメインで返すようにしている

ただ、注意が必要なのがサーバーサイドで設定したCookieもドメインやパスが同じ場合、クライアントサイド（JavaScript）のdocument.cookieで上書きされてしまうということです。なので、サーバーサイドで設定した10年間有効にしたCookieも、Google Analyticsがトラッカーを作るたびに有効期限が1週間に詰められてしまうことになります。

これに対応するためには、

Ａ．常にGAがトラッカーを作る（つまりCookieを操作する）度にサーバーサイドで_gaを設定し直す
Ｂ．サーバーサイドで有効期限を延長したというフラグを作り、以降はGAがトラッカーを作成する際にはクライアントサイドではCookieは更新しないようにする
Ｃ．サーバーサイドで設定し直すCookieの名前を_ga2のように変更して、_gaが無い場合は、_ga2で保持しているClientIDを使うようにする

既存のコードをなるべく弄らないようにするのであればＡ、サーバーやクライアントサイドの負荷を少しでも下げたければＢですが、Ｂの場合はすべてのGAスニペットが挿入されているページで対応しなければ矛盾が発生します。それを考えるとlocalStorageに退避させるように、名前を変えてサーバーサイド側のCookieに退避させるＣの方法が最も良いかもしれません。

ただ、ITPを迂回しようとすればするほどITP側の制限が大きくなっていくことを考えると、付け焼刃で対症療法的な対策ではなく、例えば、匿名のユーザーではなく、ソーシャルログインのような簡易的でもいいからユーザーを特定できるようなログイン機能を作り、それを元にGAなどの分析をUserIDベースで行う、匿名ユーザーの8日以上の追跡は諦めるなど、７のそれ以外の対応を考えなくてはいけないところに差し掛かってきているのかもしれません。

あと余談ですが、ITP2.2の解説記事でも、Google Analyticsのクロスドメイントラッキングに影響が出るよーって書いている人がいますが、こちらも裏を取っているんですかね？

リンクURL中のID（ハッシュ）がクライアントCookieに設定された場合に有効期限が1日になる条件ですが、次の2つの条件が必要です。

  1. A domain classified with cross-site tracking capabilities was responsible for navigating the user to the current webpage.
  2. The final URL of the navigation mentioned above has a query string and/or a fragment identifier.

ひとつめの条件の「クロスサイトトラッキングをするものとして分類されたドメイン」というのが肝でして、自分が管理しているABC.COMとXYZ.COMが通常のサイトとして機能しているようだったら、ABC.COMドメインはクロスサイトトラッキングをするものとして分類されないので、ITP2.2の影響はないのではないかと思います。同じくgclidなども微妙なところですが、2018年10月30日以降にGoogle広告のデフォルトとなった並行トラッキング（https://support.google.com/google-ads/answer/7544674?hl=ja）によって、トラッキングURLを挟まず、広告掲載がされたサイトからLPへのダイレクトリンクになったため、広告掲載がされたサイトのドメインがITPにトラッカー認定されていない限りこちらも大丈夫かとは思いますが、ITP2.1で実装されたクライアントサイドで設定した1st Party Cookieの制限だけはどうしようもないので、CVを追ったりアトリビューション分析をするのは基本7日以内になってしまいますね。

この辺、私も実地検証ができていないので、評価版のSafariを入れて試してみたいと思います。

***Google AnalyticsなどのGMP製品の活用やチューニングを承ります***
まずはambit.akiyama@gmail.comまでお気軽にメールをください

秋山 大志 2019/05/04 12:13:54 Comment(0)