著者:
Ira Holubovska
一般データ保護規則(GDPR)により、ユーザーのプライバシー保護が必要不可欠となりました。GDPR によると、ユーザーデータを米国企業が所有するツールに転送する前に、個人を特定できる情報を削除する必要があります。この対応は、Privacy Shield(プライバシーシールド)が無効とされたことを受けて必要になりました。
この記事では、Stape の Anonymizer power-up を使用してユーザーデータを自動的に削除する方法と、ウェブおよびサーバー側の GTM を使用して手動で削除する方法について説明します。この記事は、Google アナリティクスを GDPR に準拠して使用するためにプロキシサーバーが必要な理由を解説した以前の記事の続編です。
EU 諸国(イタリア、フランス、オーストリア、デンマーク)では、ウェブサイトでの Google アナリティクスの使用が GDPR に準拠しているかどうかを確認するために、利用者が各国のデータ保護当局に問い合わせた事例がいくつかありました。いずれのケースでも、Google アナリティクスの使用は GDPR に準拠していないという回答でした。
主な理由は、Google を含む米国企業が、EU ユーザーの個人データを保護するための十分なセキュリティ対策を提供していないことです。そのため、個人を特定できる情報(PII)を米国企業と共有することは GDPR に違反します。詳しくは以前のブログ記事をご覧ください。
幸いなことに、Google アナリティクスを使用しながら、サーバー側トラッキングを GDPR に準拠させる方法があります。フランスのデータ保護当局である CNIL によると、Google アナリティクスを GDPR に準拠して使用するには、主に 2 つの対策が必要です。EU 内のプロキシサーバーを使用することと、ユーザーデータを転送する前に仮名化することです。
プロキシサーバーは、ウェブサイトと米国の分析ツールが直接通信することを防ぎます。このようなプロキシサーバーを導入する最も簡単な方法は、サーバー側 Google Tag Manager(sGTM)コンテナを使用することです。プロキシサーバーには、いくつかの要件があります。主な要件は、プロキシサーバーを提供する企業が EU 域内で登録されていること、そして sGTM コンテナをホストするサーバーが物理的に EU 域内に設置されていることです。この 2 つの理由から、sGTM に Google Cloud(GCP)を使用することはできません。Google アナリティクスと同様に、Google Cloud も米国企業である Google が所有しているためです。
もう一つの朗報は、Stape がこの問題に対応するソリューションを提供していることです。Stape には、EU のプロキシサーバーに関するすべての要件を満たす専用製品、Stape Europe があります。Stape Europe は EU(エストニア)で登録されており、Scaleway が提供する EU 内のクラウドサーバーを使用して sGTM コンテナを実行します。
この記事では、法的要件の 2 つ目であるユーザーデータの仮名化に重点を置きます。Stape では、ユーザーデータを自動的に削除できるさまざまな機能を開発しています。そのため、記事を次の 2 つの部分に分けて説明します。
仮名化が必要なユーザーデータの範囲は、明確に定義されていません。
IP アドレスは、分析プラットフォームにデータを送信する際に、プライバシー上の懸念が生じやすい情報の一つです。GA4 は IP アドレスを自動的に匿名化しますが、企業によっては、自社のインフラストラクチャから IP アドレスが送信される前に置き換える必要がある場合があります。サーバー側 GTM を使用して GA4 の IP アドレスを追加で匿名化する方法をご確認ください。
現在、Stape の Anonymizer power-up は GA4 専用として開発しています。ただし、今後のアップデートでは UA の匿名化機能にも対応する予定です。
GA4 が送信するパラメータは変更される可能性があることを理解しておくことが重要です。この記事は継続的に更新しますが、本番環境に公開する前に、ユーザーデータが正しく匿名化されているか必ずテストしてください。
GA4 のパラメータを追跡・特定するために、私が見つけた最も便利なツールはこちらです。
ユーザーデータの仮名化は、ウェブおよびサーバー側 GTM コンテナ内の GA4 タグで行います。GA4 のサーバー側トラッキングをまだ設定していない場合は、GA4 のサーバー側トラッキング設定ガイドをご覧ください。
削除すべきデータについて、厳密なガイドラインはありません。企業のデータ保護対策をどのように実施するかは、それぞれの判断に委ねられています。例えば、ユーザーの IP アドレスを完全に削除する方法もあれば、末尾の数桁だけを削除する方法もあります。また、国、言語、ブラウザなどのパラメータをどう扱うかも重要な問題です。各パラメータだけでは個人を特定するのに十分な情報が得られなくても、複数を組み合わせるとユーザーを識別できる可能性があります。
一方、クライアント ID や URL クエリパラメータなどを削除すべきかどうかについては、疑問の余地がありません。それぞれのパラメータに含まれる Google の一意の識別子によって、単独でもユーザーの特定につながる可能性があるためです。
例えば、モバイルとデスクトップのトラフィックを比較したり、ブラウザ別のコンバージョンを分析したりすることが重要な場合があります。その場合、フィンガープリンティングやユーザー識別に利用できるすべてのデータを削除すべきでしょうか。それとも一部だけで十分でしょうか。他のパラメータをすべて削除すれば、ブラウザやデバイスの情報を残しても問題ないのでしょうか。
規制当局による調査が行われた場合に企業を適切に保護できるよう、これらの問題について法務担当者やデータ保護責任者(DPO)と相談してください。個人的には、フィンガープリンティングや再識別に利用できるすべてのユーザー識別子を削除することが、企業の安全性を確保するうえで望ましいと考えています。
この記事は、必ず従うべき手順を示すものではありません。データの削除や仮名化に関する経験と、Stape がこれらの処理を自動的に実行する方法を共有するものです。Anonymizer power-up を使用せず、各パラメータを手動で匿名化することもできます。
最近、Anonymizer power-up をリリースしました。この機能は、すべての Stape ユーザーが利用できます。Anonymizer の主な目的は、Google アナリティクス 4 のユーザーデータを削除または匿名化することです。
Anonymizer を有効にするには、Stape で sGTM コンテナを開き、Power-ups をクリックして Anonymizer を選択します。

この製品には、MaxMind が作成した GeoLite2 データが含まれています。詳細は https://www.maxmind.com をご覧ください。
どのパラメータをそのまま保持するか、削除するか、匿名化するかを選択する必要があります。パラメータを設定したら、Google アナリティクス 4 のタグ設定サーバー URL を更新してください。以前 https://sgtm.example.com を使用していた場合、Anonymizer を有効にすると、更新後の URL は https://sgtm.example.com/anonymize になります。リクエストは /anonymize パスを経由して sGTM にプロキシされ、指定されたデータが削除されます。
GA のリクエストが /anonymize を含むタグ設定サーバー URL を経由すると、選択したパラメータが自動的に削除または匿名化されます。
Anonymizer を有効にして設定したら、Web GTM の設定タグにある GA4/UA の転送 URL を、末尾が /anonymize の URL に変更したことを確認してください。
以下は、Anonymizer で削除または匿名化できるすべてのパラメータの一覧です。Anonymizer の開発では、個人データとみなされる可能性のあるすべてのパラメータを削除できるようにすることを目指しました。削除するパラメータは自由に選択できます。どのパラメータを削除する必要があるかについては、DPO または法務担当者に相談してください。
ほとんどのパラメータには、「そのまま保持」と「削除」の 2 つのオプションがあります。IP と Client ID の 2 つのパラメータには、さらに Anonymize と Anonymize Strictly のオプションがあります。
IP
Anonymize – 最後のオクテットを削除します。
Anonymize Strictly – 最後の 2 つのオクテットを削除します。
Client ID – JavaScript Managed によるクライアント識別を使用している場合にのみ機能します。
Anonymize – IP + UserAgent のハッシュを使用し、年と月を追加します。
Anonymize Strictly – IP + UserAgent のハッシュを使用し、タイムスタンプを追加します:crc32_hash(IP+UA).timestamp。
| パラメータ名 | 説明 | GA4 パラメータ | 匿名化 |
|---|---|---|---|
| IP | ユーザーの IP アドレス | IP Address | Anonymize – 最後のオクテットを削除。Anonymize Strictly – 最後の 2 つのオクテットを削除 |
| Client ID | Google アナリティクスのクライアント ID、_ga、_ga_*、FPLC、FPID Cookie | cid, _ga, _ga_*, FPLC, FPID | Anonymize – IP + UserAgent のハッシュに年と月を追加。Anonymize Strictly – IP + UserAgent のハッシュにタイムスタンプを追加:crc32_hash(IP+UA).timestamp |
| User ID | ユーザー ID、Google Developer ID、Firebase ID | uid, gdid, _fid | – |
| Session ID | セッション ID、新しいセッション ID | sid, _nsi | – |
| Query parameters | Document Location からクエリパラメータを削除 | dl | – |
| Referer | Document Referrer ヘッダー、Document Referrer パラメータ | referer header, dr | – |
| パラメータ名 | 説明 | GA4 パラメータ |
|---|---|---|
| User Agent | Document User-Agent ヘッダー、Sec-Ch-Ua ヘッダー、Sec-Ch-Ua-Platform ヘッダー、Sec-Ch-Ua-Mobile ヘッダー、User-Agent パラメータ | user-agent header, sec-ch-ua header, sec-ch-ua-platform header, sec-ch-ua-mobile header, ua |
| User Country | 地理的識別子、ユーザーの現在の国 | geoid, _uc |
| Browser plugins | Java の有効状態、Flash のバージョン | je, fl |
| Screen Info | ブラウザの画面解像度、ビューポートサイズ | sr, vp |
| Screen Colors | 画面の色深度を示す | sd |
| User Language | ブラウザの有効な言語設定 | ul |
| パラメータ名 | GA4 パラメータ |
|---|---|
| User Agent Architecture | uaa |
| User Agent Bitness | uab |
| User Agent Full Version List | uafvl |
| User Agent Mobile | uamb |
| User Agent Model | uam |
| User Agent Platform | uap |
| User Agent Platform Version | uapv |
| User Agent WOW64 | uaw |
| パラメータ名 | GA4 パラメータ |
|---|---|
| Campaign Medium | cm |
| Campaign Source | cs |
| Campaign Name | cn |
| Campaign Content | cc |
| Campaign ID | ci |
| Campaign Term | ck |
| Campaign Creative Format | ccf |
| Campaign Marketing Tactic | cmt |
| Google Ads ID | gclid |
| Google Display Ads ID | dclid |
Google アナリティクス 4 が収集するパラメータは、随時変更される可能性があります。そのため、GA4 のリクエストを確認し、すべてのユーザーデータが削除されていることを確認してください。
Anonymizer でパラメータを設定し、GA4 の転送 URL を末尾が /anonymize の URL に変更すると、指定されたパラメータが削除または匿名化されます。
Anonymizer を有効にして GA4 の転送 URL を更新した後は、ウェブおよび sGTM のデバッガー、コンソール、GA4 デバッガーを使用して、必要なすべてのパラメータが削除されているかテストしてください。
この処理は比較的簡単に実装できますが、いくつか議論のある点があります。Google には、IP アドレスの最後の 1 バイトを削除する組み込み機能があります。最後の 1 バイトを削除すると、Google がユーザーを識別できる確率は 256 分の 1 になります。ただし、IP アドレスは他のパラメータと組み合わせることで、特定の個人を容易に識別できる場合があります。
最後のオクテットを削除するだけで十分だと考える人もいれば、ユーザーの IP アドレスを完全に削除する必要があると考える人もいます。私の意見では、ユーザーの IP アドレスを完全に別の値で上書きする方が望ましいです。Google が IP アドレスを再利用しているかどうか、またどのように再利用しているかはわからないためです。
「IP アドレスや Cookie に保存された情報などのオンライン識別子は、特に同様の情報と組み合わせることで、ユーザーを識別するために一般的に使用できる点に注意する必要があります。これは GDPR の前文第 30 項でも示されています。同項によると、IP アドレスや Cookie 識別子などのオンライン識別子を自然人やそのデバイスに割り当てることで、特に一意の識別子やサーバーが受信したその他の情報と組み合わせた場合、自然人のプロファイルを作成し、個人を識別するために使用できる痕跡が残る可能性があります。」
IPについて、CNIL(フランスの規制当局)は次のように述べています。
ユーザーの IP アドレスを削除するために、サーバー側 GA4 タグを使用し、ip_override をランダムな IP アドレスに設定しました。

Google は、ブラウザとデバイスの組み合わせごとに一意のクライアント ID を割り当て、同じユーザーが再びウェブサイトを訪問したかどうかを識別するために使用します。このパラメータは、GA4 に送信する前に削除または仮名化する必要があります。
「効果的な仮名化を実現するには、識別子を置き換えるアルゴリズムが十分な衝突確率(異なる 2 つの識別子がハッシュ化後に同じ結果を生成する確率)を確保し、時間とともに変化する要素を含む必要があります。これにより、同じ識別子に対して常に同じハッシュ値が生成されることを防ぎます。」
CNILはクライアントIDについて次のように述べています。
クライアント ID を匿名化する方法は数多くあります。どの方法を選ぶかは、アイデアや使用するツールによって異なります。ただし、クライアント ID が一意であり、時間とともに変化する要素が含まれていることを確認してください。
User Agent、IP アドレス、GTM の乱数変数などのハッシュを使用できます。ユーザーの IP アドレスとは異なり、クライアント ID をサーバー側で削除する方法は見つからなかったため、クライアント側で処理しました。


Google アナリティクスのクライアント ID を匿名化した後、GA4 がユーザー識別子を設定しないように、GA4 Cookie の値を新しい値で上書きすることもできます。そのために、サーバー側 GTM コンテナの Cookie Monster タグテンプレートを使用しました。必要なのは、Cookie の名前と値を追加することだけです。設定後は、コンソールを使用して GA が設定する Cookie を確認してください。

クライアント ID を匿名化すると、GA4 のレポートに大きな影響が生じます。クライアント ID が毎回一意になるため、GA は新規訪問者とリピーターを区別できなくなります。また、マルチチャネルアトリビューションや、セッション開始、初回訪問などのイベントにも影響します。
外部参照元は、ユーザーがどのような経路でウェブサイトにアクセスしたかを判断するために使用されます。例えば、オーガニック検索、有料広告、ソーシャルメディアからのトラフィックなどです。
この情報を削除するには、page_referrer を上書きする必要があります。

URL パラメータの主な目的は、広告キャンペーンの流入元を特定することです。URL パラメータには、utm_source、utm_medium、さまざまな種類のクリック ID などがあります。また、一部のプラットフォームではユーザーデータが URL に自動的に追加されます。
URL パラメータを削除するには、ページ URL を上書きする必要があります。Web GTM のテンプレートギャラリーには、この処理に役立つさまざまな変数があります。私は Trim Query を使用しました。削除対象のクエリパラメータのブロックリスト、または保持を許可するパラメータの許可リストを指定するだけで、残りの処理は自動的に実行されます。

これには、User Agent、デバイス、ブラウザ、画面解像度、言語、オペレーティングシステムなどの情報が含まれます。フィンガープリンティングに利用できるすべての情報を削除したことを確認してください。

ユーザー ID や CRM ID などのクロスサイト識別子を使用していないことを確認してください。
この部分は少しわかりにくいかもしれませんが、sGTM コンテナから GA に送信されるリクエストを確認し、ユーザーの再識別に使用できるパラメータが含まれていないことを確認することをおすすめします。
まず、サーバー側 GTM のデバッガーを開き、GA4 への送信リクエストを確認してください。 ユーザーパラメータがある場合とない場合、URL パラメータ、さまざまなイベント、参照元など、複数のシナリオをテストしてください。

2 つ目の方法は、Google アナリティクス 4 のデバッガーを使用して、GA4 が処理しているデータを確認することです。

EU ユーザーのデータを収集して米国に転送し、GDPR に違反しているのは Google だけではありません。多くの企業が長年にわたり欧州市民の個人データを収集してきました。しかし、Privacy Shield が無効化され、EU ユーザーのデータを米国へ転送することが GDPR に違反するという判断が下されたことを受けて、こうした慣行は広く制限されることになりそうです。
EU 域内でウェブサイトを運営している場合は、米国企業と共有するデータの内容を見直す時期です。対応しなければ、規制当局による罰金の対象となる可能性があります。
サーバー側トラッキングを始めませんか?
無料で試す
コメント