今年の2月21日にAppleがITP2.1をアナウンスしました。
Intelligent Tracking Prevention 2.1

すでに多くのTwitterやBlogなどで話題になっているので、ご存知の方も多いと思いますが、改めて確認しておきます。ITP2.1では、次回のiOSとSafariの更新で、ウェブ行動を計測する上で重要なCookieの取り扱いについて、大きな変更が行われます。たとえ 1st Party Cookieでもクライアント側で document.cookie APIを使って生成された場合には、7日間で削除される、というルールが適用されます。
これは影響が大きく、特にGoogleアナリティクスがもろに影響を受けることになります。

このアナウンスを受けて、ネット上では対策というか、早い話「抜け道」が記事になっています。
その多くは、Cookieの代わりにローカルのストレージに、ユーザーを認識するIDを記録して対応する方法の紹介になっています。
また、同時に、このITP2.1への「公式な」対応策を、Googleアナリティクスもやがて発表するだろう、という憶測が書かれています。
しかし、私自身はこの小手先の対策と希望的観測の両方に疑いを持っています。

まずGoogleが回避策をアナウンスするだろう、という推測ですが、この行間には「アップルが勝手にプライバシー保護を強めたので、Googleなら適切に戻してくれるに違いない」というGoogle救世主の思いがあるようです。
これは残念ながら「NO（ノー）」だと思われます。

まず、この決定はアップルが単独で決めたものではありません。Webkitの委員会という場で話し合われて決めています。そして、この委員会には、Googleの人間も参加しています。ある意味、Googleの決定でもあるのです。
https://webkit.org/team/

さらに、もし、Google アナリティクスのチームが、小手先の回避策を発表すれば、「Googleはプライバシーを軽視している」という印象を市場に与えかねません。これは現在の基準ではありえないと思います。

そして、対応策ですが、これは小手先のものではだめで、かなりしっかりした対応策が出るまで待つほうがよいと思います。
委員会の文書を読むと、そもそもこの決定の背景には、Javascriptで発行するクライアント側のCookieに根本的な問題があるからだと書かれています。
それは 1) プライバシー保護の観点、2) セキュリティが低く盗まれる危険があること、3) 余計なトラフィックを生んでしまっている点です。便利な方法でしたが、便利なだけにリスクもあり、今となってはこの方法に頼るのは危なすぎる、ということです。
上記の点をきちんと解決する対応策でないと、導入してもまたブロックされることになるでしょう。

では私たちはどうすればよいでしょうか？
一つは、サーバー側のPHPプログラムなどを使って、HTTPのセキュアな状態でCookieを発行する方法です。
1st. Party Cookieは、クライアント側で発行する方法と、サーバー側で発行する方法があり、後者はよりセキュアな状態で導入できます。しかし、これはサーバー側のプログラム変更になるので、かなり敷居が高いでしょう。
もう一つは、Cookieに代わる、Javascriptレイヤー以外でのIDの発行方法です。これについては、GoogleでWebkitの委員の人などが参考ドキュメントをGithubに出すなどの動きがはじまってはいます。ただ、これらの動きは動向を見極める必要があります。

おそらく、上記を踏まえ、Cookieに代わる現実的でセキュアな対応策が出てくるのか待つのがよいと思います。
決して安易に小手先の対応策に飛びつくことにないようにしたいです。