プライバシーと同意の実装ガイド

Amplitudeはプライバシーに配慮した方法で設定できます。 適切な設定は、お客様のポリシー、お客様の地域、および同意前に収集したいデータの量によって異なります。 方法を選択する前に、法務チームとプライバシーチームと協力して、お客様のケースで何が許容されるかについて確認してください。

考え方としては、まず同意モデルを選択し、次にそれに合わせてAmplitudeのストレージとアクセスを設定するのが良いでしょう。

本ガイドの使い方

このガイドは、Amplitudeでプライバシーを意識したアナリティクス設定を実装するのに役立ちます。これは法的助言に代わるものではありません。 どの同意モデル、開示方法、および地域の要件をビジネスに適用するかは、チームが決定します。 このガイドでは、これらの選択肢をAmplitudeで実装するための実践的な方法について説明します。

すべての企業に適した単一のセットアップはありません。 一部の組織では、アナリティクスを開始する前に厳格なオプトインが必要となります。一部の地域では、より限定された測定のみのアプローチを使用している企業もあります。 適切な選択は、お使いのプロダクト、データ、および事業を行う場所に適用される規則によって異なります。

このガイドを意思決定と実装の枠組みとして使用してください。

1. ポリシーに合った同意方法を選択してください。
2. Amplitudeをその方法に合わせて設定します。
3. 必要なガバナンス、リテンション、削除のコントロールを追加できます。
4. 起動前に設定を検証してください。

このガイドでは、一般的な実装パターンと、ほとんどのチームが最初に必要とするコントロールについて説明しています。複雑なユースケースの場合、これを出発点として使用し、法務、プライバシー、セキュリティの各チームと協力して下すべき決定事項を特定してください。

始める前に

設定を行う前に、次の3つの質問に答えてください。

1. アナリティクスを開始する前に同意が必要ですか？
2. 同意を得る前に、データを収集しないか、または限定的な匿名測定を行うようにしますか？
3. どのフィールドがAmplitudeに到達すべきですか？

必要な同意を得ること、適切な開示を行うこと、およびポリシーにおけるAmplitudeのクッキーの分類方法を決定することは、お客様の責任です。

実践的な出発点は、次のことを書き留めることです。

• どのイベントを収集したいか。
• どの識別子を保存したいか。
• どのプロパティが機密性の高いものか。
• ユーザーが同意を拒否した場合に何が起こるべきか。
• ユーザーが最初の拒否後に同意を与えた場合に何が起こるべきか。

その1ページの決定文書により、実装のレビューとテストがはるかに簡単になります。

お客様のポリシーに合った設定を選択してください

方法1：同意を求め、同意したユーザーからのみデータを収集する

ポリシーがアナリティクスを開始する前に同意を必要とする場合、これは最も明確なオプションです。また、ユーザーが同意を与えるまで何も始まらないため、ユーザーや監査人に対して説明するのが最も簡単なモデルです。

仕組み

ブラウザ SDK 2 では、SDK は初期化直後に Amplitude Cookie を作成することがあります。同意を得る前に Cookie を回避する必要がある場合は、ユーザーが同意するまで SDK を初期化しないでください。

Amplitudeで設定する方法

同意が取得されたamplitude.init()後にのみコールを実行してください。サイトを正常に読み込ませ、同意ツールによってアナリティクスが許可されたことが確認されるまで、初期化を保留してください。

import * as amplitude from '@amplitude/analytics-browser';
// User hasn't consented yet.
// Don't initialize the SDK here.
function onConsentGranted() {
  amplitude.init('API_KEY');
}

ログアウト後にユーザーを匿名化する必要がある場合は、amplitude.reset() を呼び出してください。これにより、userId がクリアされ、新しいdeviceId が作成されます。 次のアクティビティは、ユーザーが再度サインインするまで、新しい匿名ユーザーとして表示されます。

Amplitude以外でできること

CMPを使用して、初期化を実行するかどうかを制御してください。AmplitudeはデフォルトのCMP連携を提供していないため、CMPは同意の結果をAmplitudeの実装に渡す必要があります。

SDK 初期化の一元化

amplitude.init(...) を1か所からのみ実行してください。複数のチームがサイトの異なる部分でSDKを初期化する場合、トラッキングが同意によって制限されていることを証明することは非常に困難になります。

この設定をテストする際は、ブラウザの開発者ツールを開き、同意の前にAmplitudeのクッキーが存在しないことを確認してください。

方法2: 同意を求めるが、同意しないユーザーから限定的な匿名測定値を収集する

一部の組織は、同意したユーザーには完全なアナリティクスを行い、同意しないユーザーには非常に限定的な測定を行うという中間的な立場を求めています。これは、この種の限定的なオーディエンス測定がお客様の管轄区域で許可されていることを法務チームが確認した場合にのみ適切です。

仕組み

この方法は、総トラフィックやページビューなど、匿名または極めて最小限に抑えられたオーディエンス測定に限定してください。 これをユーザーレベルの行動分析に変えてはいけません。

ヨーロッパ各地でルールは異なる場合があるため、現地の規制ガイダンスを導入に関する決定の一部として扱う必要があります。 フランスはよく知られた例の1つです。クッキーと同意管理ガイドでは、CNILの免除は同意なしの匿名の統計的オーディエンス測定のための狭いケースであり、完全なアナリティクスではありません。これは有用な参照ポイントですが、これをすべてのヨーロッパ市場のデフォルトルールとして扱うべきではありません。

Amplitudeで設定する方法

限定された匿名フローの場合、永続的なアイデンティティを減らすか削除します。

• ブラウザー ID を永続的に保持したくない場合は、identityStorage をnone に設定します。
• 単一のセッション内でユーザーを追跡したい場合（複数のセッション間ではなく）、identityStorage をsession に設定します。これは一部の実装にとって有用な中間的な手法です。
• 安定したものを送信することは避けてくださいuserId。
• イベントセットは小さく抑え、集約されたトラフィックの測定に重点を置いてください。

amplitude.init('API_KEY', {
  identityStorage: 'none',
});

ポリシーで Cookie を許可しているが、より保守的な設定が必要な場合は、Cookie の有効期間を短縮することもできます。

Amplitude以外でできること

どのイベントが匿名フローに属するかを正確に決定します。 そのリストを短くしてください。 ほとんどのチームにとって、これはページビュー数、トラフィック総数、その他のハイレベルな測定値のみを意味します。

より強力な制御が必要な場合は、データがAmplitudeに到達する前に独自のプロキシを通じてデータを送信してください。ドメインプロキシを使用すると、データを転送する前にフィルタリング、ブロック、または匿名化できます。

匿名フローを狭く抑える

この方法を選ぶなら、規律を守ってください。「限定的な匿名測定」フローを静かに時間をかけて完全な行動分析に変えてはいけません。 匿名フローがユーザー分析のように見えるようになればなるほど、プライバシーに対する立場は弱くなります。

同意済みデータと同意されていないデータを別々のプロジェクトに保持する

同意済みのアナリティクスデータと、同意されていない限られた測定ストリームの両方を収集する場合、必ずそれらを別々のAmplitudeプロジェクトに保管してください。この2つを単一のプロジェクトに混ぜると、後で解決することが困難な問題が発生します。最初からこのことを厳格に扱うべき理由は3つあります：

• レポートの整合性: 同意されていないデータは最小化された識別子または回転する識別子を使用するため、ユニーク、ファネル、コホートなどのユーザーレベルの指標は、同意済みデータとは大きく異なります。 これらを分離しておくことで、どの数字が何を意味しているのかが明確になります。
• 意図しないユーザーのスティッチングリスク：Amplitudeはプロジェクトレベルではなく組織レベルでアイデンティティを解決します。 両方のプロジェクトに同じユーザーIDまたはデバイスIDが表示される場合、Amplitudeはそれらを同じユーザーとして扱います。 同意のないプロジェクトがこれを念頭に置いて設計されていない場合、プロジェクト全体で匿名データを特定されたユーザーとリンクさせることがあります。
• アクセス制御：同意を得ていないプロジェクトはより厳格な管理をすべきです。 個々のユーザーレベルのイベント検索を無効にすることで、分析が集約レベルにとどまります。 データがすでに独自のプロジェクトに存在する場合、この方法を適用するのがはるかに簡単です。

同意されていないプロジェクトをより厳格に設定する

プロジェクトを別々に設定することで、同意されていないストリームを最初から異なる方法で設定できます。 実際には、これは通常、同意のないプロジェクトでより厳格な設定を使用することを意味します：クッキーを使用しない、永続的なストレージを使用しない、安定したユーザーIDを使用しない、最小限のイベントセットを使用します。

その設定方法

一般的な設定は次のようになります。

• 同意を得たユーザーのための1つのプロジェクト。このプロジェクトでは、同意後に完全なアナリティクスが開始されます。
• 同意を得ていないユーザー向けの1つのプロジェクトでは、ポリシーで許可されている限られた数の匿名測定イベントのみを送信できます。

訪問者が同意していない場合は、許可されたイベントを同意されていないプロジェクトにルーティングしてください。 訪問者が後で同意した場合、同意されたプロジェクトでAmplitudeを初期化し、そこで通常のトラッキングを開始します。

このアプローチを使用する場合は、両方のプロジェクトでアイデンティティ戦略が意図的であることを確認してください。 同じ組織内のプロジェクト全体において、Amplitudeは同じユーザーIDまたはデバイスIDが同じユーザーを参照していると仮定します。 これは正当なプロジェクト横断分析に役立ちますが、お客様の法的および実装モデルと一致しない限り、同意状態間で識別子を再利用しないように注意する必要があることも意味します。

必要に応じてユーザーレベルのアクセスを制限する

一部のチームにとって、プロジェクトを分離するだけでは不十分です。 また、同意されていないデータを含むプロジェクトについては、ユーザーレベルのビューへのアクセスをより厳密に制限することも望んでいます。

このような場合、ユーザールックアップ、ユーザープロファイル、ユーザーストリーム、または同様のユーザーレベルのサーフェスといった機能が、そのプロジェクトで引き続き利用可能であるべきかどうかを確認してください。これは、プロジェクトに匿名データや同意を得ていないデータが含まれており、プライバシーに関する方針が個人レベルの調査を避けることを意図している場合に特に重要です。

実際のルールとして、多くのチームは同意のないプロジェクトに対してはより厳格な設定を、同意を得たプロジェクトに対してはより標準的な設定を望んでいます。 このようなプロジェクト固有の制限が必要な場合は、実装設計の一環としてAmplitudeチームと相談し、組織に適切なコントロールを適用できるようにしてください。

プロジェクトレベルでのユーザールックアップの無効化

DACとRBACに加えて、Amplitudeはプロジェクトレベルでユーザールックアップ機能を無効にすることもサポートしています。Amplitudeチームがこの設定を有効にすると、チームメンバーはチャートやダッシュボードのコンテキストメニューから個々のユーザーイベントストリームにアクセスすることはできません（ユーザーのイベントストリームを開く顕微鏡アイコンなど）。

このコントロールは、プライバシーに関する状況が集計レベルでのみ分析を行うことを要求する場合や、個人レベルの未加工ユーザーイベントへのアクセスを防止したい場合に特に重要です。 たとえば、フランスのCNIL要件を遵守するため、同意のないアナリティクスに対する免除は集計的な統計的測定にのみ適用されます。

お客様のAmplitudeチームはプロジェクトレベルでこの設定を管理します。これを適用するには、Amplitudeチームに連絡して、プロジェクト構成の一部として有効にしてもらうようにしてください。 RBACを使用してより広範なユーザレベルのアクセスを制御することもできますが、ユーザールックアップコントロールは別個のもので、よりターゲットを絞り込み、個々のイベントストリームへのアクセスを無効にすることに特化しています。

ポートフォリオを使用してトップラインレポートを統合

同意済みプロジェクトと同意されていないプロジェクトを一緒に分析したい場合は、ポートフォリオビューを使用してください。

ポートフォリオを使用すると、複数のプロジェクトを1つのプロジェクト横断ビューにまとめることができるため、プロジェクト全体にグラフを作成できます。 これは、基礎となる実装を1つのプロジェクトにまとめることなく、同意状態全体にわたるトラフィックやアクティビティの全体像を把握したい場合に役立ちます。

推奨されるパターンは以下の通りです:

• データ収集は別々にしておきましょう。
• ポートフォリオを使用して、両方のプロジェクトにわたってそれが意味のある場合にレポートを作成してください。
• 何が組み合わせられるか、何が組み合わせられないかについて、明確な認識を共有してください。

たとえば、トップラインイベント数は両方のプロジェクトで役に立つ可能性がありますが、ユーザーレベルのメトリックについてはより注意が必要です。 同意されていないプロジェクトが最小化されたIDを使用している場合、ポートフォリオレポートが同意済みプロジェクトと同じ種類のユーザー継続性を再現することを期待することはできません。

ルーティングルールを文書化する

個別のプロジェクトパターンを採用する場合は、実装者とアナリストの両方のためにそのパターンを明確に文書化してください。チームが知っておくべきこと：

• どのイベントがどのプロジェクトに送られるのか。
• トラフィックが同意されていないプロジェクトから同意済みプロジェクトに移動する場合。
• どの識別子が各プロジェクトで許可されているか。
• 同意を得ていないプロジェクトでどのユーザーレベルの機能を制限すべきか。
• どのグラフでポートフォリオビューを使用し、どのグラフで単一のソースプロジェクトを使用すべきか。

これは、プライバシーに配慮した測定をサポートしながら、アナリティクス設定を理解しやすく保守しやすいものにするための最も実践的な方法の1つです。

方法3：同意を求めるのではなく、ポリシーが許可している場合には識別子とデータ収集を減らす。

一部の地域やユースケースでは、法務チームがアナリティクス設定に同意は必要ないと判断する場合があります。 その場合でも、識別子を制限したり、ストレージを短縮したり、送信する内容を最小限に抑えることで、この設定をよりプライバシーに配慮したものにすることができます。

Amplitudeで設定する方法

ポリシーに合致するストレージモードを選択します。

• cookie 標準的なブラウザの永続性のために使用します。
• localStorage クッキーを使用しないブラウザストレージを希望する場合。
• none 永続的なIDを望まない場合。

localStorageを使用する場合は、サブドメインによって制限されていることに注意してください。 あるサブドメインのユーザーが同じ保存済みアイデンティティを別のサブドメインに自動的に持ち込むことはありません。

identityStorage: "none"を使用する場合、Amplitudeはdevice_idページの読み込み（またはアプリの起動）ごとに新しいものを生成します。これは、読み込み間で再利用できる保存済みIDがないためです。

Amplitude以外でできること

プライバシーに関する通知が、実際に行っていることと一致していることを確認してください。 同意を求めていない場合でも、ポリシーには、収集対象とその理由、およびユーザーがそのモデルに該当する場合にオプトアウトする方法について説明する必要があります。

デフォルトでデータを最小化

同意が不要な場合でも、データの最小化は依然として良いデフォルトです。 偶然利用可能なものではなく、必要なものを収集してください。

より厳密な制御が必要な場合はプロキシを使用してください

ドメインプロキシは、Amplitudeに届くものをより詳細に制御したい場合に便利です。 これにより、独自のドメインを通じてトラッキングリクエストを送信することができ、データをAmplitudeに転送する前にフィルタリング、ブロック、デバッグ、監査ログ作成、匿名化を行うことができます。

これは、データが環境から出る前に、IP アドレスやuserIdロケーションなどのフィールドを削除する場合に特に役立ちます。これを行うにはプロキシだけが唯一の方法ではありません。 初期化時にSDKで直接特定のフィールドを除外または抑制することもできます。これは、クライアント側で少数のフィールドのみを削除する必要がある場合に便利です。

プロキシを構築する場合は、開発運用チームと情報セキュリティチームを早い段階から関与させてください。

ノイズの多いトラフィックをデータから排除

プライバシー設定は、データもクリーンである場合に有効です。

ボットトラフィックをブロック

パブリックなWebトラフィックを追跡する場合、ボットトラフィックがメトリクスを歪める可能性があります。Amplitudeを使用すると、ブロックフィルタを作成できるため、このデータはそもそも取り込まれません。

設定方法：

1. プロジェクトのメインブランチに移動します。
2. フィルターを開きます。
3. [ブロックフィルタ] タブを開きます。
4. ［Create Block Filter］ をクリックします。
5. **[Bot Traffic] **を選択します。
6. フィルタを保存します。

Amplitudeは、IAB/ABCインターナショナル・スパイダーとボット・リストを使用して、ユーザーエージェントに基づいてボットをブロックします。

内部トラフィックをブロックする

チームが本番環境でテストを行う場合は、従業員のトラフィックがメトリックを膨張させないように、内部IPアドレスをブロックしてください。Amplitude Dataで、IP アドレスがブロックしたいアドレスと等しい場合のイベント用のブロックフィルタを作成します。

テスト用に開発プロジェクトを別々に維持し、最終検証用にのみ実稼働環境を使用することが良いプラクティスです。

機密データを見ることができるユーザーを制限する

データを適切に収集することは仕事の半分にすぎません。 また、それを閲覧できる人を制御する必要があります。

Amplitudeのデータアクセス制御（DAC）を使用すると、プロパティをPII、収益、または機密に分類し、グループごとにこれらの分類へのアクセスを許可または拒否できます。

DACが有効になっている場合：

• 制限付きユーザーは、制限付きデータを含むチャート、コホート、ダッシュボード、ノートブック、またはユーザーセッションを表示することはできません。
• Amplitudeは、イベントストリームやユーザーまたはアカウント検索から分類されたプロパティを隠します。
• 制限値は [DAC Restricted] と表示されます。

設定方法：

1. 組織でDACを有効にするよう、Amplitude サポートにご依頼ください。
2. Amplitude データで、保護したいプロパティを分類します。
3. [設定] > [組織設定] > [グループ] で、グループを開き、[データアクセス] タブでアクセスを設定します。

機密性の高いプロパティを超えてより広範な役割制御が必要な場合は、RBACを使用して各プロジェクトでユーザーが実行できることを定義し、グループを通じてそれらの役割を割り当てます。

リテンション期間を設定する

イベントデータを永久に保持する必要がない場合は、リテンション期間を設定してください。

AmplitudeのTime to Live（TTL）を使用すると、イベントリテンションを組織レベルで定義し、プロジェクトごとにそれを上書きできます。

設定するには：

1. 組織のTTLコントロールがまだ有効になっていない場合は、Ask Amplitudeに依頼してください。
2. 組織設定に移動します。
3. **生存時間(TTL)**タブを開きます。
4. リテンション期間を選択して確認してください。
5. 一部のプロジェクトで異なるリテンションポリシーが必要な場合は、プロジェクトレベルのオーバーライドを追加してください。

ここは気をつけてください。 TTLは不可逆的なデータ損失を引き起こし、既存のグラフはリテンション期間外の期間にゼロアウトします。

リスクの高いデータセットにはより短いTTLを設定し、ビジネス上の明確なニーズがある場合にのみより長いTTLを設定することが良いルールです。

削除リクエストの準備

ユーザーが自分のデータを削除するよう求めた場合、Amplitudeと上流システムの両方をカバーするプロセスが必要です。

AmplitudeのユーザープライバシーAPIを使用すると、既知のAmplitude IDまたはユーザーIDの削除リクエストをプログラムで送信できます。

デフォルトでは、削除はプロジェクトごとに行われます。 組織全体でユーザーを削除したい場合は、設定をdelete_from_org に変更してくださいtrue。

実践において重要なことは 2 つです：

• ユーザーを削除しても、そのユーザーに対する今後の追跡がブロックされることはありません。
• 同じユーザーデータがお客様のウェアハウスや別の取り込みソースにまだ存在する場合、Amplitudeは次の同期時にそのデータを再度取り込む可能性があります。

したがって、削除ワークフローは次のようになります。

1. リクエストを受け取ります。
2. 正しいユーザーIDを識別します。
3. Amplitudeでユーザーを削除します。
4. 同じユーザーをウェアハウスまたは同期されたソースから削除します。
5. 監査目的で完了を記録します。

起動前に設定を検証する

セットアップが稼働したら、実際のシナリオでテストしてください。

少なくとも、次のことをテストしてください：

• 同意していない訪問者です。
• 同意を与えた訪問者です。
• サインイン済みのユーザーです。
• ログアウトしたユーザーです。
• データが削除されるユーザーです。

Amplitudeでは、ユーザールックアップを使用して特定のユーザーのイベントストリームを検査し、実際にどのようなデータが取り込まれたかを確認できます。

各テストケースについて、次のことを確認してください。

• SDKが初期化されているかどうか。
• Amplitudeのクッキーまたはストレージが作成されたかどうか。
• 予想されたイベントが送信されたかどうか。
• 期待される識別子が存在していたかどうか。
• 制限されたデータが適切なユーザーにのみ表示されるかどうか。

このステップは時間をかけて行う価値があります。 プライバシーに関する問題の多くは、ポリシーそのものではなく、実装上の小さなギャップから生じます。

推奨されるロールアウト順序

操作の順序をシンプルにしたい場合は、次のようにします：

1. 同意方法を選択します。
2. どのデータを許可するかを決定します。
3. SDKの初期化とストレージを設定します。
4. 必要に応じてCMPを接続します。
5. ボットや内部トラフィックに対するフィルタを追加します。
6. 機密性の高いプロパティを分類および制限します。
7. データリテンションを設定します。
8. 削除ワークフローを文書化してください。
9. エンドツーエンドのテストですべてを検証します。

この手順により、作業を管理しやすくなり、社内の関係者や外部監査人に対してセットアップを説明することも非常に簡単になります。

その他の考慮事項

実装によっては、クッキー、ストレージ、アクセス制御以外の設定が必要になる場合があります。 以下の項目は、セットアップが完了したと判断する前に確認しておく価値があります。

セッションリプレイ

セッションリプレイを使用している場合は、コアアナリティクスの設定とは別に確認してください。リプレイはより豊富なユーザーインタラクションをキャプチャできるため、独自のプライバシーレビュー、マスキングルール、同意処理が必要になることがよくあります。

実際には、これは次のことを意味します：

• Replayがアナリティクスと同じ同意選択肢の対象となるのか、それとも別途扱われる必要があるのかを判断します。
• ロールアウト前にマスキングと除外設定を確認してください。
• プライバシーに関する通知にリプレイ技術の使用方法が正確に記載されていることを確認してください。

詳細については、セッションリプレイのドキュメントを参照してください。

削除要求だけでなく、アクセス要求

多くのプライバシープログラムはまず削除に重点を置いていますが、お客様は個人データへのアクセス要求に応える必要がある場合もあります。 プライバシーリクエストをサポートする場合は、両方に対応することを計画してください。

削除ワークフローについては、ユーザープライバシーAPIを使用してください。データ アクセス要求もサポートする必要がある場合は、DSAR API のドキュメントを参照してください。

次の項目を網羅する 1 つの運用ワークフローを文書化することが良いプラクティスです。

• リクエストの受付。
• 身元確認。
• Amplitudeでのアクセスまたは削除。
• 上流システムでのクリーンアップ。
• 監査ログ作成。

プライバシーに関する通知と開示

実装方法とプライバシーに関する通知は常に一致している必要があります。 アナリティクスデータを収集したり、セッションリプレイを使用したり、限定的な匿名の測定フローに依存している場合は、開示内容を確認して、収集する内容、収集する理由、ユーザーが選択を行う方法などが引き続き説明されていることを確認してください。

これは、チームが時間の経過とともに実装の詳細を変更する場合に特に重要です。 プライバシーの問題は、多くの場合、ツール自体が原因ではなく、プロダクトの機能と通知の内容との間のギャップが原因です。

ホスト地域とデータのレジデンシー

一部の組織、特にヨーロッパの組織では、ホスト地域がプライバシーに関する決定の一部となっています。 Amplitudeは米国とEUの両方のデータセンターオプションを提供しており、その選択肢はお客様の内部レビュープロセスに影響を与える可能性があります。

データの保存場所がビジネスにとって重要な場合、ホスティング設定を早期に確認し、ホスティング設定が社内の要件に合致していることを確認してください。データレジデンシーオプションの詳細について学習できます。

ローンチ後の運用上の注意事項

一部のプライバシーコントロールは期待どおりに機能しますが、それでもチームが計画を立てるべき実際的な結果をもたらします。

いくつかの重要な例を挙げます：

• ユーザーを削除しても、Amplitudeがそのユーザーを再度追跡することは防げません。
• 削除されたデータがウェアハウスまたは同期されたソースにまだ存在する場合、Amplitudeはそれを再取り込む可能性があります。
• リテンション設定は履歴データを永久に削除し、古いグラフに影響を与える可能性があります。
• 計装やタグ管理の大きな変更が行われるたびにプライバシー設定をテストしてください。

優れたロールアウトは、リリース時点で終わりではありません。特にSDKのアップデート、同意バナーの変更、新しいイベントの開始、アップストリームパイプラインの変更の後など、定期的にセットアップを再テストしてください。

助けを求めるとき

地域の法的複雑さ、複数の同意カテゴリ、機密性の高い個人データ、または複数のダウンストリームアクティベーションツールを含むセットアップが実施されている場合は、法務、プライバシー、セキュリティチームを早期に巻き込みます。 プライバシーを重視した設定を最初から設計するほうが、後でそれを改良するよりもはるかに簡単です。

一般的に、最も安全なアプローチは、実装をシンプルに保ち、必要なものだけを収集し、ビジネス上および法的に明確な根拠がある場合にのみ複雑さを増すことです。

既知のユーザーに対する代替手段としてのサーバー側の追跡

ログインしているユーザーや身元を特定したユーザーの場合、サーバー側のトラッキングはクライアント側の同意制約の一部を回避する代替手段を提供します。 ユーザーが認証されている場合、ブラウザSDKを完全にバイパスして、バックエンドからAmplitudeのHTTP APIにユーザーIDを直接渡すことができます。

多くの管轄区域では、認証済みユーザーのサーバー側での追跡は、ePrivacy Directive の要件の対象とはなりません。ePrivacy はユーザーのデバイス上の情報へのアクセスまたは保存（クッキー、localStorage など）に適用され、サーバー側の呼び出しはデバイスに触れることはありません。そのため、ログインしているユーザーの場合、サーバー側のAmplitudeトラッキングは、一部の地域ではePrivacy規則に基づく同意を必要としない場合があります。

重要な注意事項：

• これは既知のログインユーザーにのみ適用されます。 匿名訪問者の場合、クライアント側の識別子はページ全体での行動を追跡するために必要です。これはサーバーがその識別子を生成した場合でも同様です (Cookie を使用しない追跡アプローチの場合と同様です)。 永続的な識別子をユーザーのデバイスに保存またはアクセスするとすぐに、eプライバシー規則が適用されます。
• 法務チームは、特定されたユーザーのサーバー側での追跡が、お客様の管轄区域やユースケースにとって十分かどうかを確認する必要があります。
• 認証済みのユーザーデータをサーバー側で処理することが、お客様のデータ処理契約および GDPR の法的根拠に沿っていることを、お客様のプライバシーチームに確認してください。

Amplitudeが同意していないユーザー向けにモデル化データを生成しない理由

一部のアナリティクスプラットフォームは、同意していないユーザーによって残されたギャップを埋め、推定された行動をモデル化し、同意したユーザーに基づいてそのユーザーが何をしたかを統計的に推測します。Amplitudeはこのアプローチを採用していません。 その理由は次のとおりです。

• モデル化されたデータは一貫性がなく、解釈が困難です。モデリングを提供するプラットフォームは通常、十分なアクティビティ量がある場合にのみ見積もりを生成します。 特定のしきい値を下回ると、プラットフォームはモデルをまったく生成しません。また、対象範囲はセグメントや期間、プロパティによってばらつきがあります。 実際のデータを見ているのか、それとも推定データを見ているのかを容易に区別することはできず、データセット全体に一貫した分析ルールを適用することはほぼ不可能です。
• モデル化されたデータの動作は、データを照会する場所によって異なります。モデル化されたイベントデータをウェアハウスにエクスポートし、そこで同じ分析を実行した場合、多くの場合、アナリティクス UI 内で実行した場合とは異なる結果が得られます。プラットフォームは通常、このロジックをインジェスチョン時ではなく、UI のクエリ時に適用します。このため、真実のソースが分割され、特にレポート作成やコンプライアンスの目的でウェアハウスからのエクスポートに依存しているチームにとっては、整合性が非常に困難になります。

Amplitudeのアプローチは、明確な同意の境界線と正確なファーストパーティデータに重点を置いています。 検証や監査人への説明が困難な見積もりでギャップを埋めるよりも、何を測定したのか、誰に対して測定したかを正確に把握しておく方が良いでしょう。 組織でAmplitudeと併せてGoogleサービスを使用している場合、これらのツールに対してGoogleの同意モードを個別に設定できます。 これはAmplitudeがデータを処理する方法に影響しません。

プライバシーとAmplitude AIの機能

最終的なレコメンデーション

最も安全でシンプルなデフォルト設定が必要な場合は、方法1から始めましょう。同意を得た後にのみAmplitudeを初期化し、イベントスキーマを厳密に保ち、初日からアクセス制御とリテンションルールを追加してください。

ポリシーにより柔軟性が認められている場合でも、識別子を減らし、必要に応じてプロキシを使用し、悪質なトラフィックをフィルタリングし、Amplitude内の機密データへのアクセスを制限することで、プライバシーに配慮した設定を維持できます。