For AI agents: a documentation index is available at /docs/llms.txt. Append .md to any page URL for markdown, or send Accept: text/markdown.
データ可変性機能
Data mutabilityは、ウェアハウスからのINSERT、UPDATE、およびDELETE操作をすでにAmplitudeに存在するイベントデータに適用するため、信頼できる唯一の情報源（source of truth）での訂正、遅れて到着した行、削除がアナリティクスに反映されます。Mirror 同期は、Snowflake、Databricks、Google BigQuery、およびAmazon S3からこれらの操作を実現します。
ウェアハウスが真実のソースであり、GDPRやCCPAの削除、バックフィルによる訂正、遅延した更新など、最初の書き込み後にその行が変更された場合は、ミラー同期をオンにします。イベントが取り込まれた後に変更されることがない場合は、標準の追記型取り込みを維持してください。ウェアハウスを接続せずに誤ったラベル付けや重複したデータを修正する必要がある場合のみ、代わりに変換を使用してください。
サポートされているデータソース
データの可変性は、以下のウェアハウス統合を通じて利用できます。
スノーフレーク
- 変更データキャプチャ（CDC）を使用したミラー同期戦略。
INSERT、UPDATE、およびDELETE操作をサポートしています。- ソース テーブルで変更追跡を有効にする必要があります。
- Snowflake連携の詳細についてはこちらをご覧ください →。
Databricks
- 変更データフィード（CDF）を使用したミラー同期戦略。
INSERT、UPDATE、およびDELETE操作をサポートしています。- デルタテーブルで変更データフィードを有効にする必要があります。
- Databricks連携の詳細についてはこちらをご覧ください →。
Google BigQuery（ベータ）
- BigQueryの
CHANGES()変更履歴を使用したミラー同期戦略。 - イベントデータ型の
INSERT、UPDATE、およびDELETE操作をサポートしています。 - ソーステーブルで変更履歴を有効にする必要があります (
enable_change_history = TRUE)。 - BigQuery連携の詳細についてはこちらをご覧ください →。
Amazon S3
- ファイルベースの変更に対するミラー同期戦略。
INSERT、UPDATE、およびDELETE操作をサポートしています。- データファイルに構造化された変異メタデータが必要です。
- Amazon S3連携の詳細についてはこちらをご覧ください →。
ミラー同期の仕組み
データの変更性を備えたミラー同期を有効にするとき:
変更検出: この連携は、ネイティブの変更追跡機能 (Snowflake の場合は CDC、Databricks の場合は CDF、
CHANGES()BigQuery の場合は変更履歴、S3 の場合はファイルメタデータ) を使用して、お客様のウェアハウスにデータ変更がないかを監視します。操作処理：Amplitudeは3種類の操作を処理します：
INSERT: Amplitude に新しいイベントを追加します。UPDATE: Amplitude の既存イベントを変更します。DELETE: Amplitude からイベントを削除します。
Amplitudeは、
user_id、insert_idおよびevent_timeの組み合わせに基づいて一致するイベントを検出します。 Amplitudeが正しいイベントを識別して修正するには、3つのフィールドすべてが一致する必要があります。データ同期：変更は、データウェアハウスとAmplitudeの間で一貫性を保つために適用されます。
エンリッチメントサービス
エンリッチメントサービスは無効です
データ可変性を伴うミラー同期を使用する場合、Amplitudeは以下を含むエンリッチメントサービスを無効にします：
- ID解決とユーザー統合。
- プロパティとアトリビューションの同期。
- ロケーションの解決。
- タクソノミーの検証。
エンリッチメントを無効にすると、データが真実のソースに存在していたまま正確に維持されるようになります。
一般的な要件
- ユーザー ID が必要です：すべてのイベントにはユーザー ID が含まれている必要があります。Mirror 同期は匿名イベントをサポートしていません。
- ユニークな挿入 ID: 重複を防ぐため、各イベントにはユニークで不変の
insert_idが必要です。 - 時系列順: 可能な限り、イベントを時系列順に処理します。
イベントボリュームの考慮事項
イベントボリュームへの影響
データミューテーションはイベントボリュームにカウントされます。
- ウェアハウスソース（Snowflake、Databricks、BigQuery）：同期ウィンドウ内の同じイベントに対する複数の操作は、1つのイベントとしてカウントされます。
- ファイルソース（S3）：各操作は個別にイベントボリュームにカウントされます。
使用状況をモニターし、イベント数が必要な場合は営業担当者に連絡してください。
データリテンション
- Snowflake:
DATA_RETENTION_TIME_IN_DAYS≥ 1 である必要があります（推奨：≥ 7 日）。 - Databricks: 変更データフィードのリテンションは、同期頻度をカバーする必要があります。
- BigQuery: テーブルのタイムトラベルウィンドウは、同期頻度をカバーしている必要があります (デフォルトは7日間ですが、2～7日間設定できます)。
- S3: ファイルは処理中もアクセス可能な状態にしておく必要があります。
ベストプラクティス
データの変更性を有効にする際には、次のベストプラクティスに留意してください。
導入計画を立てる
テストプロジェクトから始める: 本番環境に実装する前に、ミューテーションロジックを検証するための専用のテスト環境を作成します。
冪等性を考慮した設計: データミューテーション操作を構築することで、データの不整合を引き起こすことなく安全に再試行できます。
データ品質のモニター: 検証チェックを実施して、ミューテーションが正しく適用されることを確認します。
データプライバシーコンプライアンス
プライバシーコンプライアンスのためにデータの変更性を利用する場合：
まずデータフローを停止する：ユーザーデータを削除する前に、そのユーザーに関する新しいデータをAmplitudeに送信しないことを確認してください。
ユーザープライバシー API を使用： ユーザーを完全に削除するには、ユーザープライバシー API をウェアハウス削除と併用して使用します。
削除の確認： 削除されたデータがアナリティクスに表示されなくなったことを確認します。
パフォーマンスの最適化
- バッチ操作： 可能な限り関連する変異をまとめてグループ化します。
- 同期頻度の最適化: データの鮮度のニーズと処理オーバーヘッドのバランスをとります。
- リソース使用状況のモニター: 変更追跡に関連するウェアハウスのコンピューティングコストを追跡します。
データの可変性への移行
標準的な取り込み戦略からミラー同期に移行する場合は、以下の手順に従ってください。
推奨される移行手順
カットオフ戦略の作成：
- 時間フィルターを使用して既存の接続を変更します（例：
WHERE time < {cutOffDate}）。 - カットオフ日を明日（エポックからのミリ秒単位）に設定します。
- 時間フィルターを使用して既存の接続を変更します（例：
カットオフを待つ: カットオフ日が過ぎるのを待ち、古い接続を介して新しいデータが流れていないことを確認します。
新しいミラー同期ソースを作成します。
- 補完フィルタを使用して新しいソースを構成します (例：
WHERE time >= {cutOffDate})。 - 必要なミューテーション設定を使用してミラー同期を有効にします。
- 補完フィルタを使用して新しいソースを構成します (例：
クリーンアップ：新しいソース接続が正しく動作することを確認した後、古いソース接続を削除してください。
一般的な問題
イベントが更新されない
- ソーステーブルで変更追跡が有効になっていることを確認します。
- イベントに必要なユーザーIDが含まれていることを確認してください。
- 同期頻度設定を確認します。
削除項目がない
- DELETE操作がソースで正しく設定されていることを確認してください。
- 削除されたイベントに有効なユーザーIDが割り当てられていたことを確認してください。
- 変更内容のリテンション期間が切れていないことを確認してください。
データの不整合
- ミューテーション操作の順序を確認します。
- Amplitudeが期待どおりにエンリッチメントサービスを無効にしたことを確認してください。
- ウェアハウスの変更と同期実行の間のタイミング上の問題を確認してください。
これは役に立ちましたか？