Safari で Cookie が無効になるITPをWebディレクター視点での押さえておくべきまとめ

2019年11月13日 Webディレクション #ツール #iOS

ITP2.3って何?Safariとcookieの取り扱いがどのように変わるのか?

EUでのGDPR(EU一般データ保護規則:General Data Protection Regulation)が施行されましたが、日本では比較的グレーな扱いでした。それが最近(2019年)になって少しずつ大手ベンダーが「cookieの使い方」についてのアラートをサイトの初回訪問時に出すようになってきました。

その流れで問題になってきているのが、

iOS13以降のSafariブラウザのセキュリティ機能強化
それに伴うcookie情報の取り扱いの変更
サイトに埋め込む媒体効果測定タグ(Criteoやアドエビス)による3rdpartycookieの利用不可化

です。

Webディレクターとして、企業サイトの媒体効果測定についての知見は必須とも思いますので、まとめておきたいと思います。

問題となる ITP とはなにか?

ITP (インテリジェンス・トラッキング・プリベンション・Intelligent Tracking Prevention)はユーザのプライバシー保護のためにブラウザの「Safari」に組み込まれたトラッキング防止機能です。 cookie周りの処理不備はクロスサイトスクリプティング(XSS)に繋がることもあり、また近年ECサイトや広告からのサイト行動へのトラッキングを嫌がるユーザも増え、ITP でユーザ保護の施策としてクロスサイトトラッキングを制御しています。

具体的には、

各ドメインへのアクセス状況をブラウザが分析
クロスドメイントラッキングを行なっているサービスを抽出
NG判定のドメインにはDouble Keyingの判定
cookieの寿命短縮化
4ドメイン以上で相互利用されていると判断されると「トラッカー判定」

となるようです。

iOS11から組み込まれるようになり、これまでも仕様アップデートによってリターゲティング広告配信や、コンバージョン計測ツールの媒体効果測定に影響が出てきましたが、今年になってからのアップデートでいよいよ看過できなくなってきました。

ITP のアップデート変遷

日付	バージョン	内容	対象ブラウザ
2017年9月	ITP 1.0	3rd Party Cookieの保存期間が24時間	iOS 11.0以降のSafariブラウザ
2018年9月	ITP 2.0	3rd Party Cookieが即時破棄 1st Party Cookieの保存期間が30日間	iOS 12.0、macOS(Mojave、High Sierra)以降のSafariブラウザ
2019年3月	ITP 2.1	JavaScript発行の1st Party Cookieの保存期間が7日間	iOS 12.2、macOS(Mojave、High Sierra)以降のSafariブラウザ
2019年4月	ITP 2.2	JavaScript発行の1st Party Cookieの保存期間が24時間	iOS 12.3、macOS(Mojave、High Sierra)以降のSafariブラウザ
2019年9月	ITP 2.3	利用条件によってLocalStorageの保存期間が7日間	iOS13、iPadOS(β)、macOS(Catalina、Mojave、High Sierra)以降のSafariブラウザ

直近9月の ITP 2.3 発表で大きな問題になったのは「LocalStorage(ローカルストレージ)」にも影響が出てきたことです。 LocalStorage(ローカルストレージ)自体は、cookieの次世代的な利用も想定されていて、ITP 2.1が発表された時は「LocalStorage(ローカルストレージ)の利用」が回避策として上がっていました。

ツールベンダーの「アドエビス」さんではこのサイトで、ITP 2.1への対応策として、

ITP2.1の影響回避として、ITP端末の計測では、[1st party cookie]に加え[localStorage]にもユーザー情報を保存するよう機能追加をいたしました。

[localStorage]では、ITP2.1の影響を受けずユーザー情報を保管し続けることが可能です。

という記載のあるページが「【重要】Safari ITP2.1/Firefoxトラッキング防止機能がアドエビスへ与える影響に関して」で公開されています。

しかしその対応についても影響が出てきたことは今回の大きな変更です。

LocalStorage(ローカルストレージ)が対象になったことの詳細

LocalStorage(ローカルストレージ)が対象になりましたが、ITP 2.3ではあくまで「トラッカー判断」されたドメイン(cookieが4ドメイン以上で相互利用されていると判断されたドメイン)からのパラメータ付きのURLが対象です。

ITP 2.1でJavaScript経由での1st Party Cookieの有効期限が1週間にされた時に比べれば影響は少ないかもしれません。とはいえ、ITPのそもそもが「ASP(アフィリエイトサービスプロバイダー・Affiliate Service Provider)」のユーザトラッキングを抑制する施策であり、LocalStorage(ローカルストレージ)にも対象になったことで、今後も抑制対象が増えていく、強化されていくことは想像に固くありません。

リターゲティング広告などはもろに狙われた状態で「楽天で商品を買ったら、初めてのブログの広告枠で自分が買った商品が出ていて、類似商品をオススメされる」といったことはどんどん難しくなっていくと思います。

何が問題なの?

ITP の実装によってSafariユーザの安全・安心は向上するのですが、cookieを利用したリターゲティング・リマーケティング広告の配信や、コンバージョン計測ツールの媒体効果測定の計測ができなくなります。

名村がWeb制作・ホームページ制作会社である株式会社サービシンクでお手伝いしているあるクライアントは、サイト訪問者のiOSのユーザの割合がかなり高く、そこでの広告効果測定ができないと、マーケティング施策についての成否が判断ができず、正しい費用対効果が分からない、という事態になっています。

またITP 2.2によって実装された「JavaScript発行の1st Party Cookieが24時間で消えてしまう」ことで考えられるのは、JavaScriptで生成するcookieの利用を機能です。

想定されるのは「物件検索サイト」や「ECサイト」での「お気に入り保存」機能。これが24時間で消えてしまうので、事実上意味をなさなくなります。

それ以外では媒体効果測定のためのビーコン型の解析ツールは当然ですが、MA(マーケティングオートメーション)ツールや、それこそGoogleアナリティクスにも影響が出ることが懸念されます。

対象はSafari利用者だけなのですが、これまでcookieの利用は「どんなブラウザでも可能」であることが前提だったことを考えると、特にiOSのSafariでの挙動が取れないのはキツイかもしれません。

それこそ、全体の数字を把握する際、Safariの数字を把握するために、

cookieベースでコンバージョン等が取れている総数
Google Analyticsによる各ブラウザの利用率
そのうちのSafariの利用割合

などのデータから「Safariでのデータ欠損率」を算出して、「(あくまで想定される)総数」を出す・・・というコトになるかもしれません。

純粋な制作や開発だけをしているならば、マーケティングや広告周りの影響は不問かもしれませんが、Webディレクターとしては「知っておかなければならない」事情であると思います。

回避策はあるの?

3rd Party Cookieについては現状では事実上使えなくなります。

1st Party Cookieについては、「JavaScript発行」ですので、サーバサイド側で発行し、その際にSecure属性とHttpOnly属性を付与することで現状は対応ができます。これは、JavaScript発行のcookieではSecure属性とHttpOnly属性を付与出来ないことによるものです。逆にいえば、Secure属性とHttpOnly属性を付与していなければサーバサイド側で発行していても24時間で消えてしまいます。

ですので、自社で開発をしていて、開発しているプログラムでcookieを元にして何か機能制御をしている場合、cookieの発行方法、付与している属性情報、発行したcookieの利用方法と処理の仕方は洗い出しておくほうがいいでしょう。気がついたらSafariユーザだけ、

「全く効果測定が取れていない」
「マイページログイン機能が使えない状態だった」
「お気に入りが毎回登録しても(1日経ったら)消える」

といった状態になりかねません。

如何せん、時限式で発火する挙動であり、ブラウザでレンダリングされている結果だけを見ていても分かりづらく、しかもブラウザ依存です。「顕在化しづらく、気がつきにくい不具合」になるのが一番怖いです。

この仕様変更への対応不備が後になって発覚し、クライアントから「いつから発生していたのですか?」と報告書を求められた時「実は・・・3年前の2019年3月から・・・です・・・」みたい報告なってしまいます。(絶対に「プロとしてなんで気が付かなかったんですか?」と言われる事案なので)

一方で、トラッキングツールを利用してる場合には、ツールベンダー側の対応に期待をするということでいいと思います。ただし、そのために「ページに埋め込んでいる既存のツールベンダーからの『タグ』を全部張り直し」といったことになる可能性があります。

YTM(Yahoo!タグマネージャー)、GTM(Googleタグマネージャ)などのタグマネージャーを利用していればある程度容易に差し替えができるかもしれません。しかし顧客情報をパラメーターとして付与するタグや、HTMLに直接埋め込んでいる形のものは修正作業もそうですが、張替え後の動作確認テストの工数が大変なことになると思われます。(受託案件の場合、クライアントへの費用請求に繋がりますし・・・)

Cookieベース利用不可に伴うCNAME対応

幾つかの広告効果測定ツールで、発行済の「タグ」そのものは変更しないが、cookieを食わせるための方法として「ツールベンダーのサーバにサブドメインを割り振ってもらう」という流れが出てきています。

ツールベンダー側から「貴社のドメインのサブドメインを割り振ってください」と言われ、

ツールベンダー指定のサブドメイン(これが既存サブドメインと被ることはほぼなさそうな仕様)
そのドメインに対してCNAMEのリソースレコードを指定(Aレコード設定ではない)

を行うことになります。

「CNAMEリソーレコード」は別名のホストに対して名前解決を行えるようにする設定です。詳しくはjprsの用語辞典の「CNAMEリソースレコード(シーネームリソースレコード)」をご覧ください。

ここで大変なのはこのCNAMEの設定です。このCNAMEの設定が「できるかできないか」という話です。

最近のレンタルサーバでは、ドメイン取得から設定までは比較的容易です。それこそサブドメインの発行も容易だったりしますが、

サブドメインに対してCNAME設定をする

ことができるか?というと、レンタルサーバによっては出来ないところがあります。また、お名前.comやさくらインターネット等のドメイン設定では可能ですが、そもそもネームサーバの設定になってくるので、それが可能なエンジニア(Webディレクターでも知ってれば普通にできるレベルですが)がいるか?という話にもなります。

CNMAEのリソースレコードを設定し、TTLの設定タイミング以降に、ターミナル等でnslookupやdig等のコマンドを使って確認・・・といったことも求められます。