ITP管理

AppleのIntelligent Tracking Prevention(ITP)は、Webサイトおよびそこにインストールされたさまざまなスクリプトによる不要な追跡を防止することで、ユーザーのプライバシーを向上させることを目的とした技術です。これは、デスクトップコンピュータ(Macintosh)およびすべてのiOSデバイス(iPhoneおよびiPad)を含むすべてのSafariブラウザで使用されています。ITPは、JavaScriptベースのソフトウェアが実行できる操作に大きな制限をもたらします。ITPは主にオンライン広告システムをターゲットにしていますが、最新バージョンははるかに積極的で、Google Analyticsなどのウェブ解析ソフトウェアに大きな影響を与えます。ITPはA/Bテストツールにも大きな影響を与えます。 Kameleoonは、ITPが有効なAppleデバイスでも完全に機能します。 ただし、バックエンドサーバーに小さな同期コードセクションを挿入する必要があります。 この記事では、実験と解析に対するITPの技術的制限と影響について説明します。

• ITPによって課される技術的制限。
• ウェブ解析とコンバージョン最適化操作への影響。
• ITPの問題を回避するためのKameleoonの推奨ソリューション。

​

ITPの技術的制限​

Intelligent Tracking Preventionは、Cookieやその他のクライアントサイドストレージ(ローカルストレージなど)の使用に関してかなりの制限を実装しています。Cookieのいくつかの重要な特性を理解することが重要です。 Cookieは、Webサイトが訪問者のブラウザに保存する(非常に)小さなデータです。多くの場合、ランダムに生成されたユニークな識別子を表します。すべてのCookieはドメイン(www.example.comなど)に関連付けられており、有効期限があります。コンピュータに保存されている1つ以上のCookieにリンクされたドメインへのサーバー呼び出しが行われるたびに、これらのCookieに含まれるデータがそのドメインのWebサーバーに自動的かつ透過的に送信されます。その結果、Cookieはほとんどのウェブリクエストに常に追加されており、2つの直接的な影響があります。

• Webリクエストのサイズが増加し、ブラウジング速度が遅くなります。
• 明示的な同意なしにブラウザがデータをリモートサーバーに転送し、ユーザーが識別および追跡される可能性があります。

Cookieは通常非常に小さいため、最初の問題は一般的にそれほど重大ではありません。ただし、2つ目の問題ははるかに広範囲に及び、ユーザープライバシー支持者にとって主要な懸念事項です。Cookieはウェブ上でさまざまな目的に使用されるため、Cookieの使用は複雑なトピックです。HTTPプロトコルのステートレスな性質により、それらの多くは基本的なWebサイトの操作に必要です。たとえば、eコマース取引は通常それらに依存しています。ITPでは、Appleは「有用な」Cookie(指定のウェブサイトの通常の操作に必須のもの)と「悪い」Cookie(広告、追跡、プライバシー侵害に関連するもの)を分離することを目指しています。 Webサイトは2つの異なるメカニズムを使用してCookieを設定できます。

• Webサーバーへの呼び出しが行われると、サーバーはHTTP応答にHTTPヘッダーを追加することでCookieを設定します。
• クライアントのJavaScriptコードを使用する。

Cookieの関連ドメインは、使用される方法に依存します。サーバーCookieの場合、サーバー呼び出しが送信されたドメインです。クライアントサイドJavaScript Cookieの場合、ドメインはJavaScriptコードが実行されるページの1つです(必ずしもJavaScriptファイルのホストドメインとは限りません)。サードパーティCookieとは、現在表示しているWebページ以外のドメインに送信されるCookieを指します。たとえば、www.randomshop.comを閲覧している場合、そのWebサイトがtracking.ad-system.comを呼び出すと、www.ad-system.comに関連するCookieがHTTPクエリと一緒に送信される可能性があります。これらは、www.randomshop.comでの現在のブラウジングセッションのコンテキスト内でサードパーティCookieとみなされます。 Cookieが期限切れになると、ブラウザはそれを完全に削除します。ただし、Cookieを作成するエンティティが有効期限を選択するため、はるか先(たとえば10年以上)に設定できます。この期間により、元のWebサイトの通常の操作に必要な期間をはるかに超えて存続します。この慣行はITPによって変わっています。 ITP 2.3によって課される2つの主な制限は次のとおりです。

• すべてのITPバージョンで、サードパーティCookieは厳しく制限されています。サードパーティCookieは、ブラウザに設定されてから24時間後にSafariによってブロックされます。 技術的には削除されませんが、HTTPリクエスト経由で自動的にサードパーティサーバーに送信されなくなります。前の例で、www.randomshop.comに来る訪問者は、最初の訪問中にそのサーバーへのHTTP呼び出し経由でwww.ad-system.comからCookieを取得します。訪問者が24時間以上後に戻ってきた場合、www.ad-system.comへの次のHTTPリクエストは元のCookieデータを受信しません。
• バージョン2.3以降、すべてのクライアントサイドストレージ(JavaScriptベースのCookieとLocalStorage)は7日後に期限切れになります!

ウェブ解析およびA/Bテストソフトウェアは通常サードパーティCookieに依存していないため、最初の制限は主に広告システムに関係します。この記事の残りの部分では、2番目の制限に焦点を当てます。

​

クライアントサイドストレージ制限の影響​

JavaScriptベースのCookieを7日間の有効期限に制限することは非常に積極的です。ほぼすべてのウェブ解析プラットフォーム(Google Analyticsを含む)はJavaScriptまたはフロントエンドベースで、訪問者のユニーク識別子を保存するためにCookieを使用しています。この識別子は、訪問者の最初の訪問の最初のページビューでランダムに生成されます。その後のページビューおよび訪問では、Cookieから識別子を再利用して訪問者を識別します。これにより、解析ソフトウェアは新しい訪問者(新しいCookieが生成される)か、戻ってきた訪問者(以前に設定されたCookieが見つかった)かを区別できます。Safariがcookieの存続期間を7日に短縮するため、月曜日に最初の訪問を行い、翌週の火曜日に戻ってきた訪問者は完全に新しい訪問者とみなされます。言い換えれば、新しい訪問のデータは前回の訪問にリンクされません。その結果、解析ソフトウェアの 新規訪問者 メトリクスは、Safariトラフィックに対して信頼できなくなります。他にも多くのメトリクスが歪む可能性があります(ユニーク訪問者数、購買までの時間など)。Cookieベースの解析ソリューションが生成する数値を信頼することはもはや困難です。 デスクトップWebサイトの場合、AppleのSafariデスクトップ市場シェアは比較的低い(一般に5%から10%)ため、これは軽微な迷惑とみなされる可能性があります。ただし、モバイル重視のWebサイトでは、iOSデバイスの市場シェアが40%~50%の範囲に近いことがよくあります。この市場シェアは、トラフィックのほぼ半分が影響を受ける可能性があることを意味します! テストおよびコンバージョン最適化プラットフォームの大部分は、ウェブ解析機能をバンドルしています。これらは同様の問題に悩まされており、それ自体が問題です。しかし、A/B実験ではさらに深刻な障害が現れます。訪問者が実験にバケットされるたびに、テストソフトウェアは訪問者用のバリエーションを選択します。このバリエーションは正確に記憶される必要があります。訪問者が戻ってきた場合、訪問者は以前に見たのと同じバリエーションを見る必要があるからです。すべてのフロントエンドテストソリューションは、この情報(実験とバリエーションの関連付け)をCookieに保存します。ITPでは、最初に実験をトリガーしてから7日以上後に戻ってくる訪問者は、別のバリエーションを見るリスクがあります。これらの条件下では、A/Bテストは信頼性のある結果を生成しません。 技術的詳細については、ITPおよびそのウェブ解析への影響に関するこのブログ記事を参照してください。この記事では、次のセクションで取り上げるITPチャレンジに対する回避策のリストも提供されています。

​

Kameleoonのソリューション​

Kameleoonが最初に実装した回避策は、バリエーション割り当てなどの重要な情報をCookieではなくLocalStorageに保存することでした。実際、KameleoonでCookieの代わりにLocalStorageを使用することはITPに先立っており、LocalStorageにはCookieに対していくつかの利点があります。1つの利点は、JavaScriptによって設定されたCookieは、ユーザーが手動で消去できるため、ITP以前にも完全に信頼できなかったことです。代わりにLocalStorageを使用することは当初機能しましたが、ITPの最新バージョンはLocalStorageをCookieのように扱い、エントリは7日後に期限切れになります。その結果、この方法はもはやSafariでの信頼できるA/Bテストとパーソナライゼーションを保証しません。 Kameleoonの推奨ソリューションは、重要な visitorCode 識別子を含む kameleoonVisitorCode Cookieを、JavaScriptを使用したブラウザだけでなく、HTTPヘッダーを使用してサーバーで設定することです。ITPはサーバーによって設定されたCookieに制限を課さないため、このCookieは十分に長い有効期限を持つことができます。この方法を使用すると、システムはこのCookieをフロントエンドとバックエンド間で同期し、Cookieの寿命はITPによって制限されなくなります。 Safariでは、Kameleoonはサーバーが設定した kameleoonVisitorCode Cookieを読み取って visitorCode を取得すると、現在のLocalStorageが空かどうかを確認します。空の場合、訪問者の最後の訪問は7日以上前である可能性があります。KameleoonはServer Synchronization Call(SSC)を実行して、LocalStorageに存在していたすべてのデータをバックエンドサーバーから取得します。この呼び出しが完了すると、データは以前の状態に復元されます。通常の操作が再開できます。 解析コアはITPの影響を受けず、報告されたトラフィックデータは信頼できますが、Kameleoonはサードパーティのウェブ解析プラットフォームについて同じことを保証することはできません。パートナーツールとの統合ブリッジは同じように動作し続けます。選択した解析ソリューションのベンダーと状況について話し合ってください。

​

結論​

この記事で詳述されているソリューションを使用することで、Safariユーザーベースで信頼できるA/B実験を引き続き実行できます。Kameleoonは推奨される回避策を提供し、Safariをテストベースから除外するのではなく実装を推奨します。 Appleがユーザープライバシーを保護するために取り組む中、ITPへのさらなる変更が予想されます。KameleoonはAppleのITP技術および他のブラウザベンダーの同様の取り組みの進化を継続的に監視しています。たとえば、FirefoxはITPに似たソリューションを持っていますが、まだそれほど厳しくありません。重大な変更があれば分析され、ソリューションが伝達されます。