ITP2.1の「Cookie7日問題」の回避策
ここからの参考/引用文献：
【一問一答】Appleの「 ITP 2.3 」アップデートとは？：ユーザー体験への影響が大きくなる可能性
https://digiday.jp/platforms/wtf-apples-itp-2-3-update/
2019年9月23日に発表され、Mac、iPhone、iMacの最新OSに搭載されるITP 2.3は、2019年に行われた2つのアップデートで導入された制限を進めるものです。しかし、訪問者の設定を保持するためにCookieベースでないウェブストレージツールを使用しているウェブサイトに広範な影響が及ぶ可能性があります。
https://support.karte.io/post/1N6RpkqOCDt9QenDg7HAd6
ここからの参考/引用文献：
【最新】3分で分かるITP2.3｜広告マーケ担当者が知っておきたいことまとめ
https://infinity-agent.co.jp/lab/itp2-3/
CNAME対応で計測
これだけ厳しい扱いとなった広告トラッキングですが、まだ抜け道があったのです。
1st party cookieが制限される条件は、先述のとおり「Javascriptによって生成された」Cookieです。
自社サーバーから直接発行される1st party cookieであればITPの影響を受けません。
これを受けて、アトリビューション計測ツール「ADEBiS」や、DSP「Criteo」で実装されているのが「CNAME対応」です。
自社サーバーのDNS設定を行うことで、完全に現ITP環境を克服することができています。
画像参考：CNAMEを利用したトラッキング方式のご提供
https://support.ebis.ne.jp/s/article/29550#CNAME1
2. CNAME方式の仕組み
CNAMEとは、DNSサーバー（≒コンピュータ上の住所録）にあだ名を付ける仕組みです。
アドエビスのドメインにお客様サイトのドメインを使ったあだ名を付けることで、お客様サイト同様httpヘッダーによるCookie付与が可能となり、ITPのCookie保管期間制限による影響を回避することが可能です。
例）
本名 ：ac.ebis.ne.jp（アドエビスサーバー）
あだ名：cname.example.com（お客様ドメイン）
別名に対する正式名を指定するためのリソースレコードです。
ホスト名には、「canonical name（正式名）」以外に、「aliases（別名）」を付けることができます。DNSの名前解決では、CNAMEリソースレコードが見つかった場合、ドメイン名を正式名に置き換えて名前解決を継続します。ある別名に対する正式名は常に一つであるため、一つの別名に対し、正式名を二つ以上指定することはできません。
CNAMEリソースレコードは、以前はホスト名に別名を付ける手段として使われていました。現在では主にCDN （Contents Delivery Network）や、/24未満のIPv4アドレスの逆引きを設定する際に使われています。
別名は、例えば1台のサーバーで複数のサービスを提供している場合に、サービスごとにサーバーの名前を変えるときに使用します。サーバーの正式なドメイン名はservice.example.jpであるが、将来のことを考えて情報提供ではinfo.example.jpを、ショッピングではshop.example.jpというドメイン名で運用したいといったケースが該当します。この例のような場合、DNSではCNAMEリソースレコードを用いて以下のように定義できます。
コンバージョン数を正確に計測したい場合は、このCNAME対応を行える計測ツールを利用するのが良いでしょう。
しかし、ツール上で計測できたとしても、各広告媒体はITP環境下であるため、コンバージョンによる自動最適化はやはり部分的なデータしか取得できないことになります。
そのうえ、いつAppleがまたITPをアップデートして、CNAME対応の対策をしてくるか分かりません。
“その場しのぎ”とまでは言いませんが、長期に渡って安心して計測できる方法とも断言できません。
ここからの参考/引用文献：
Safari ITP2.3に関するアドエビスの対応と影響についてhttps://support.ebis.ne.jp/s/article/33499
これまでのITP
ITP1.0
《影響》
・アドエビスのcookie[ebis.ne.jp]を含む3rd party cookieが24時間で削除される
《アドエビスの対応》
・2017年11月にリリースした新タグへ移行していただくことで計測への影響を回避
ITP2.0
《影響》
・3rd party cookieは『即時』で削除される
・アドエビスの旧タグを利用している場合、リファラがドメインまでしか取得できなくなる
・トラッカー判定されたドメインにリダイレクトする“リダイレクト元ドメイン“も
トラッカー判定の対象となるため、アドエビスの「リダイレクトプログラム」が使えなくなる
《アドエビスの対応》
・ITP1.0での新タグ移行に加え、リダイレクトプログラムの使用をお控えいただくことにより、計測への影響を回避。
ITP2.1
《影響》
・1st party cookieも『8日以上』アクセスがないと削除される
※JavaScriptで設定された1st party cookieが対象です。
《アドエビスの対応》
・ITP端末の計測では、[1st party cookie]に加え、ITP2.1の影響を受けずユーザー情報を保管可能な[localStorage]にもユーザー情報を保存する機能追加を行い、計測への影響を最小限に留める
※7日を超えてドメインやサブドメイン、http/httpsを跨いだ計測をする場合のみ影響がございます。
ITP2.2
《影響》
・1st party cookieの保存期間が1日以内になる(ITP2.1では7日以内)
※「トラッカー判定されているドメインからパラメータ付きで流入したページでCookie付与」およびJavaScriptで設定された1st party cookieという条件が対象です。 また、サイト流入後にPV計測をしている別ページに遷移した場合は保存期間が延長されます。
2．ITP2.3での変更点
概要
変更点1
以下条件すべてを満たす場合に、[localstorage]が即時削除される
・媒体ドメイン等トラッカー判定されているサイトから流入
・ランディングページURLにパラメータやフラグメントが付与されている
・サイト流入後でページで操作（クリック・タップ・テキスト入力）がない
※サイト流入後でページで上記操作が行われた場合、 [localstorage]の有効期限は7日に延長されます。
1st party cookieの延長条件は「PV計測をしている別ページへの遷移」となり、条件が異なります。
※計測サイトのドメインがトラッカー判定されていない前提でのご案内です。
変更点2
以下条件すべてを満たす場合に、Javascriptで取得できるリファラがドメインのみになる
・媒体ドメイン等トラッカー判定されているサイトから流入
・流入元ページURLにパラメータやフラグメントが付与されている
3．アドエビスでの対策
ITP機能によるCookie削除の影響を受けない種類の[1st Party Cookie]で計測可能な、CNAMEを利用した新たなトラッキング方式を提供させていただきます。
トラッキング方式のご変更をご希望の場合は、以下ページに沿ってお手続きください。
CNAMEを利用した新トラッキング方式のご提供
※「変更点2」のリファラ取得制限については対策ができかねます。ご了承ください。
4．アドエビスへの影響
変更点1による影響
CNAMEを利用した新たなトラッキング方式にご変更いただける場合、一部機能を除き影響はございません。
ただし、CNAME方式をご利用いただけないケースがございます。
ご利用いただけないケースについては、CNAME方式ご利用にあたっての注意事項をご確認ください。
◇CNAME方式へご変更いただけない場合の影響（ITP端末からアクセスされた場合） 下記のように各アクセスをそれぞれ別ユーザーと判別してしまう影響がございます。
・広告クリックや自然検索からの流入情報とCVの情報が紐正しく付かなくなる
・CVの直接効果/間接効果が正しく紐付かなくなる
・UU数が増加する 等
変更点2による影響
リファラがドメインまでしか取得できなくなることにより下記のような影響が発生します。
①LOGエビスのリンク元URLがドメインのみとなる(サブドメインも表示されない)
②一部条件において、外部リンク流入と判別していたアクセスが自然検索流入と判別される
③SEOエビス/LOGエビスにおいて、僅かにとれている"検索ワード"がより取得できなくなる
④trflg(※)フラグを外している場合、一部条件で広告クリックと自然検索流入が重複計測される
※[仕様]AD×SEOをご利用のお客様へ_「trflg=1」がURLに表示される仕様について
それぞれの対象機能と、"一部条件"に該当する条件をご案内いたします。
①LOGエビスのリンク元URLがドメインのみとなる(サブドメインも表示されない)
【影響を受ける条件】 ※すべてに該当するケースが対象
・媒体等トラッカー判定されているドメインから流入
・流入元ページのURLにパラメータかフラグメントがついている
・safari13以降の端末からのアクセス
【対象機能】
・LOGエビス（[リンク元]画面/各画面[個別追跡][遷移元]）
②一部条件において、外部リンク流入と判別していたアクセスが自然検索流入と判別される
【影響を受ける条件】 ※すべてに該当するケースが対象
・Google/Yahoo!等の検索エンジンもしくは検索エンジンと同じドメインの同社提供サービスからの流入
・流入元ページのURLにパラメータかフラグメントがついている
・safari13以降の端末からのアクセス
・AD広告での計測をしていない
※ただし検索エンジン側で「パラメータやフラグメントを使用しない仕組み」があるケースがあり、
すべてのケースで影響を受けるとは限りません。
【対象機能】
・SEOエビス
・LOGエビス（[検索サイトシェア]画面）
・すべてのチャネル（[概況]/[期間別]/[コンバージョン属性]/[コンバージョンフロー]画面）
・ユーザー分析
③SEOエビス/LOGエビスにおいて、僅かにとれている"検索ワード"がより取得できなくなる
【影響を受ける条件】 ※すべてに該当するケースが対象
・媒体等トラッカー判定されているドメインから流入
・流入元ページのURLにパラメータかフラグメントがついている
・safari13以降の端末からのアクセス
【対象機能】
・SEOエビス（[直接効果測定]画面
・LOGエビス（[概況]/[検索ワード]画面）
※検索ワードについては、検索エンジンをSSL化により、ITP機能に関わらず大半が取得できません。
検索ワードが取得できない場合、(検索ワードなし)で集計されます。
④trflg(※)フラグを外している場合、一部条件で広告クリックと自然検索流入が重複計測される
※[仕様]AD×SEOをご利用のお客様へ_「trflg=1」がURLに表示される仕様について
【影響を受ける条件】 ※すべてに該当するケースが対象
・検索エンジンと同一ドメインから流入
（リスティング広告やGoogleやYahoo!のサービスに配信されている広告等）
・流入元ページのURLにパラメータかフラグメントがついている
・safari13以降の端末からのアクセス
・trflg(※)フラグを外している
・「計測方式：リダイレクト」で広告を計測している
・ITP Safari/Firefox トラッキング設定を無効にしている
※リダイレクト計測の場合、広告クリック→ページ流入（自然検索計測）と計測されるため、
すべてのチャネル評価では直接効果が自然検索となります。
【対象機能】
・SEOエビス
・LOGエビス（[検索サイトシェア]画面）
・すべてのチャネル（[概況]/[期間別]/[コンバージョン属性]/[コンバージョンフロー]画面）
・ユーザー分析
ここからの参考文献/引用文献：
ITP2.1対策 Safari 12.1 でCookieの有効期限を8日以上に延長する方法
https://qiita.com/yossaito/items/6ffb1b8bb3f9d91107b8
ITP2.1の「Cookie7日問題」の回避策
ここからは、Javascript（document.cookie）で作成されるファーストパーティCookieの有効期限が最大７日に制限される問題を回避するための対策をいくつか挙げます。
以下に挙げる対策は、WebサイトやWebアプリケーションで独自にCookieを作成しているケースへの対策であり、アクセス解析ツールやWebマーケティング系ツールに向けた対策ではありません。
なお、LocalStorageなどのCookie以外の技術に乗り換えが可能ならば、この機会にCookieをやめることをオススメします。やむを得ずCookieの継続が必要である場合に限り、回避策の検討をするべきでしょう。
１．Webサーバー側でSet-Cookieする
ITP2.1で有効期限が制限されるCookieは、Javascript（document.cookie）で作成されるCookieです。
Webサーバーからのレスポンスヘッダー Set-Cookie で作成されたファーストパーティCookieは、有効期限の制限を受けません。これが最善の対策になります。
しかし、Webサーバー側でSet-Cookieが出来るならば、始めからそうしているでしょう。なんらかの理由により、CookieをJavascriptで作成する必要があるならば、次の方法がオススメです。
２．AjaxでSet-Cookieヘッダーをオウム返しする
Cookieに保存する値をJavascript側で生成し、それをWebサーバー側からSet-Cookieする方法です。
これにはAjax（XMLHttpRequest）とサーバーサイドプログラム（PHPなど）を利用します。
Javascriptで生成したCookieの値をAjaxでWebサーバーに送り、
サーバーサイドプログラムでSet-Cookieをオウム返しする。
これで有効期限の制限を受けることなくCookieを作成できます。
ただし、サーバーサイドプログラムは、同じドメインかサブドメインの範囲内に設置することが前提です。
他ドメインからSet-Cookieを受ける場合はサードパーティ扱いになるので利用できません。
なお、AjaxでサブドメインのCORS制約を超える場合は、以下の２つのヘッダーを併用することでSet-Cookieが可能になります。
Access-Control-Allow-Origin
Access-Control-Allow-Credentials
このあたりについては、以下の記事が参考になります。
CORSリクエストでクレデンシャル(≒クッキー)を必要とする場合の注意点
※この場合はCookieのドメイン名に親ドメインを指定して、サブドメイン間でCookieを共有する。
しかし、サーバーサイドプログラムの設置ができない場合、この方法は使えません。
次はクライアントサイド（Javascript）のみで対策する方法です。
３．LocalStorageに保存したデータでCookieを作成する
データをCookieに保存するのではなく、WebStorage APIでLocalStorageに保存しておきます。
LocalStorageならば、期限の制限なく永続的にデータを保存できます。
ただし、LocalStorageは、Cookieのようにリクエスト時にWebサーバーへデータが送信されませんので、必要に応じて、必要なタイミングで、JavascriptによりCookieを作成する必要があります。
もちろんこのCookieの有効期限は最大7日に制限されますが、元のデータはLocalStorageに残っていますので、何度でもCookieを再作成できます。
この方法なら、クライアントサイド（Javascript）だけで処理を完結できます。
デメリットは、Cookieを再作成するよりも前のリクエストでは、Cookieを送信できないという点です。
再来訪の初回リクエスト時にCookieが必要になる場合、この方法は適していません。
LocalStorageの注意点
１．LocalStorageは同一オリジン単位で保存されので、Cookieのようにサブドメイン間で共有できない。
HTTPとHTTPSの違いでも別々になります。
ちなみに、少々面倒ですが、クロスドメインメッセージングと併用すると、複数のドメイン間でLocalStorageの共有が可能になります。
クロスドメインで同じlocalStorageを使うテクニック
https://news.mynavi.jp/article/20100909-localstrage-on-many-domains/
２．LocalStorageは必ず使用できるわけではない。
問題を起こしやすいのがIE11。
LocalStorageの保存フォルダにユーザーのアクセス権がない場合、LocalStorageが使えません。
法人が使用しているPCで、たまにあります。
ここからの参考文献/引用文献：
クッキーはもう古い!?HTML5 LocalStorageの使い方
https://wp.tech-style.info/archives/742
LocalStorageとは
LocalStorageとはWebStorageと呼ばれるものの一つで、javascriptを用いてクライアント側にデータを保存する仕組みです。ユーザのローカル(ブラウザ)にデータを保存することができるので、半永久的にデータを保持することができます。データの読み込み・更新も比較的簡単に行うことができます。
クッキーとの違い
今までどおりクッキーでいいじゃん！という方もいるかと思いますが、LocalStorageはクッキーにはない大きな強みがあります。ここでそれぞれの特徴を比較してみましょう。
クッキー
クッキーの特徴
保存容量が最大4KB
リクエストの度にサーバへ値を送信
任意に有効期限を決められる
クッキーはフロントでもバックエンドでも利用でき、使い勝手が良いのですがサーバとの通信の度にデータが送信されるため、僅かに通信のリソースを使用することになります。例えば、初回アクセスの判定でクッキーを使ったりすると、関係ない画面でもサーバとの間でクッキーのやり取りが発生してしまうのです。
LocalStorage の特徴
保存容量はブラウザにより異なる(5MB～10MB)
サーバへ値を送信しない
無期限
LocalStorage はフロントエンドでのみ利用でき、データ自体はブラウザに保存されます。クッキーとは違い、サーバへデータを送信しないので通信への影響はありません。有効期限も無期限なので、半永久的にデータを保持することができます。また、データの容量もクッキーとは段違いなので、様々なデータを保持することができます。Amazonの「最近見た商品」などでこの機能が利用されているのは有名な話ですね。
LocalStorageの注意点
前述した通り、LocalStorage は半永久的にデータを保持します。つまり、データ構造を考慮せず何でもかんでもデータを保持してしまうと無駄なデータをクライアント側に保持させることになってしまいます。また、誤ったデータが LocalStorage へ保存された場合、クライアント側で保存されるため修正もかなり難しくなります。そのため中長期的に運用する場合は注意が必要です。一時的なデータなど短期間で保持したい場合はSessionStorageの利用も検討してみてください。
この記事が気に入ったらサポートをしてみませんか？