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 のアップデート変遷

直近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等のコマンドを使って確認・・・といったことも求められます。

CNAMEの権限移譲の権利問題

またサブドメインの割り振りでは、企業によっては「サブドメインの割り振りに関しての企業間で利用条件の契約をしてもらわないと無理」ということもありえます。

サブドメインを媒体効果測定ベンダーのサーバに割り振ることになるので、極論サブドメイン側で何か問題(それこそ個人情報流出や、サイト乗っ取りのよる改ざん)等があった場合には、「ドメイン所有会社」の責任になりかねません。

少なくとも一般人からみたら、

• www.hogehoge.comはサービスサイト
• asp.hogehoge.comは媒体効果測定ベンダー側に割り振っているドメインでそのドメインでの挙動は管理出来ない

というのは分かりません。

その意味で「契約を」となるのですが、ベンダーによっては「そういった契約書面はない」といった回答もあるようで、そこで設定依頼を受理をすることに二の足を踏む企業も出てきています。

まとめ

今回のITPは、Safariだけに実装されているもの(Firefoxでは別の形の実装がありますが)であり、見た目に影響が少ないので、Google ChromeのフルHTTPS化対応よりも、Webディレクター視点では気が付きにくいものかもしれません。

そうでなくても内容にアルファベット、カタカナ多くて、サーバ周りの案件で、苦手意識が動きやすいですしね・・・。 でも、媒体効果測定やコンバージョン計測に影響が出るものなので、情報としては押さえておくべきなものだと思います。

ITP2.3だけではく、過去のバージョンアップ時の仕様変更を含めて結構なブログが出ていますので、それらも押さえてみてください!