レコード削除リクエスト（UI ワークフロー） record-delete
Data Lifecycle ワークスペースを使用して プライマリ ID に基づいてAdobe Experience Platform内のレコードを削除します。 これらのレコードは、個々のコンシューマーまたは ID グラフに含まれるその他のエンティティに関連付けることができます。
前提条件 prerequisites
レコードを削除するには、Experience Platformの ID フィールドがどのように機能するかについての実践的な理解が必要です。 特に、削除元の（1 つまたは複数の）データセットに応じて、レコードを削除するエンティティの ID 名前空間値を把握する必要があります。
Experience Platformの ID について詳しくは、次のドキュメントを参照してください。
- Adobe Experience Platform ID サービス：デバイスやシステム間で ID をブリッジし、準拠する XDM スキーマで定義された ID フィールドに基づいてデータセットをリンクします。
- ID 名前空間：ID 名前空間は、1 人の人物に関連している可能性のある様々なタイプの ID 情報を定義する、各 ID フィールドに必須のコンポーネントです。
- リアルタイム顧客プロファイル :ID グラフを使用して、ほぼリアルタイムで更新される、複数のソースからの集計データに基づいて統合された消費者プロファイルを提供します。
- エクスペリエンスデータモデル（XDM） ：スキーマの使用により、Experience Platform データの標準的な定義および構造を提供します。 すべてのExperience Platform データセットは特定の XDM スキーマに準拠しており、スキーマはどのフィールドが ID であるかを定義しています。
- ID フィールド：XDM スキーマで ID フィールドが定義される方法を説明します。
リクエストの作成 create-request
プロセスを開始するには、Experience Platform UI の左側のナビゲーションで「Data Lifecycle」を選択します。 Data lifecycle requests ワークスペースが表示されます。 次に、ワークスペースのメインページから Create request を選択します。
リクエスト作成ワークフローが表示されます。 デフォルトでは、「Delete record」セクションで「Requested Action」オプションが選択されています。 このオプションを選択されたままにします。
データセットの選択 select-dataset
次の手順では、単一のデータセットとすべてのデータセットのどちらからレコードを削除するかを決定します。 組織の設定によっては、データセット選択オプションを使用できない場合があります。 このオプションが表示されない場合は、ガイドの ID の提供 の節に進みます。
「Record Details」セクションで、ラジオボタンを選択して、特定のデータセットまたはすべてのデータセットを選択します。
特定のデータセットから削除するには、「Select dataset」を選択してから、データベースアイコン（
すべてのデータセットから削除するには、「All datasets」を選択します。 このオプションを使用すると、操作の範囲が広がり、関連するすべての ID タイプを指定する必要があります。
Experience Platformの各データセットでサポートできるプライマリ ID タイプは 1 つだけです。
- 単一データセット から削除する場合、リクエスト内のすべての ID が 同じタイプ を使用する必要があります。
- すべてのデータセット から削除する場合、データセットが異なるとプライマリ ID が異なる可能性があるので、複数の ID タイプ を含めることができます。
ID を提供 provide-identities
レコードを削除する場合、システムがどのレコードを削除するかを決定できるように、ID 情報を指定する必要があります。 Experience Platformのデータセットの場合、レコードは、データセットのスキーマによって定義された id 名前空間 フィールドに基づいて削除されます。
Experience Platformのすべての ID フィールドと同様に、ID 名前空間は、タイプ （ID 名前空間とも呼ばれる）と 値 の 2 つで構成されます。 ID タイプは、フィールドがどのようにレコードを識別するかについてのコンテキストを提供します（メールアドレスなど）。 値は、そのタイプに対するレコードの特定の ID を表します（例えば、jdoe@example.com ID タイプの email）。 ID として使用される共通のフィールドには、アカウント情報、デバイス ID および Cookie ID が含まれます。
レコードを削除する場合、ID を提供するには 2 つのオプションがあります。
JSON ファイルのアップロード upload-json
JSON ファイルをアップロードするには、ファイルを指定された領域にドラッグ&ドロップするか、「Choose files」を選択して、ローカルディレクトリから参照して選択できます。
JSON ファイルは、各オブジェクトが ID を表す、オブジェクトの配列としてフォーマットされている必要があります。
[
{
"namespaceCode": "email",
"value": "jdoe@example.com"
},
{
"namespaceCode": "email",
"value": "san.gray@example.com"
}
]
namespaceCodevalueファイルがアップロードされると、引き続きリクエストを送信できます。
ID を手動で入力 manual-identity
ID を手動で入力するには、「Add identity」を選択します。
ID を 1 つずつ入力できるコントロールが表示されます。 「identity namespace」の下で、ドロップダウンメニューを使用して ID タイプを選択します。 「Primary Identity Value」で、レコードの ID 名前空間の値を指定します。
さらに ID を追加するには、プラスアイコン（
割り当て量と処理タイムライン quotas
レコードの削除リクエストは、組織のライセンス使用権限によって決まる、1 日ごとおよび 1 か月ごとの識別子送信制限の対象です。 これらの制限は、UI ベースの削除リクエストと API ベースの削除リクエストの両方に適用されます。
製品別の月間送信使用権限 quota-limits
次の表に、製品および使用権限レベル別の識別子の送信制限の概要を示します。 各製品の月額上限は、固定の識別子上限またはライセンス取得済みデータボリュームに関連付けられた割合ベースのしきい値の、2 つの値のいずれか小さい方です。
クォータは、毎月 1 日にリセットされます。 未使用の割り当ては引き継がれ い。
識別子の送信のタイムラインの処理 sla-processing-timelines
送信後、レコードの削除リクエストはキューに入り、使用権限レベルに基づいて処理されます。
組織でさらに上限が必要な場合は、Adobe担当者に連絡して使用権限のレビューを依頼してください。
リクエストの送信 submit
リクエストへの ID の追加が完了したら、Request settings を選択する前に Submit でリクエストの名前とオプションの説明を入力します。
ID が削除されると復元できないことを示す Confirm request のダイアログが表示されます。 「Submit」を選択し、データを削除する ID のリストを確認します。
リクエストが送信されると、作業指示が作成され、Record Workspace の「Data Lifecycle」タブに表示されます。 ここから、リクエストを処理する作業指示のステータスを監視できます。
リレーショナルスキーマに基づくデータセットからのレコードの削除 relational-record-delete
削除するデータセットがリレーショナルスキーマに基づいている場合は、次の考慮事項を確認して、レコードが正しく削除され、Experience Platformとソースシステムの間の不一致が原因で再び取り込まれないようにします。
レコードの削除動作
次の表に、取り込み方法と change data capture configuration に応じて、Experience Platformとソースシステム間でレコード削除がどのように動作するかを示します。
_change_request_type = 'd' でフラグ付けされたレコードは、取り込み中に削除されます。 フラグが設定されていないレコードは再度取り込まれる場合があります。再取り込みを防ぐには、ソースシステムとExperience Platformの両方で同じ削除方法を適用します。つまり、両方のシステムからレコードを削除するか、削除するレコードの _change_request_type = 'd' を含めます。
データ取得および制御列の変更
チェンジ・データ・キャプチャでソースを使用するリレーショナル・スキーマでは、削除とアップサートを区別する際に _change_request_type コントロール列を使用できます。 取り込み中に、d のフラグが設定されたレコードはデータセットから削除され、u のフラグが設定されたレコードや列がないレコードはアップサートとして扱われます。 _change_request_type 列は取り込み時にのみ読み取られ、ターゲットスキーマに保存されたり、XDM フィールドにマッピングされたりすることはありません。
リレーショナルスキーマの追加の削除方法
リレーショナルスキーマでは、標準のレコード削除ワークフローに加えて、特定の使用例に対して追加の方法をサポートしています。
- データセットセーフコピーアプローチ：実稼動データセットを複製し、実稼動データに変更を適用する前に、制御されたテストまたは紐付けのための削除をコピーに適用します。
- 削除のみのバッチアップロード：他のデータに影響を与えずに特定のレコードを削除する必要がある場合は、ターゲットハイジーンに対する削除操作のみを含むファイルをアップロードします。
ハイジーン操作に対する記述子のサポート descriptor-support
リレーショナルスキーマ記述子は、正確なハイジーン操作に不可欠なメタデータを提供します。
- プライマリキー記述子: ターゲットの更新または削除でレコードを一意に識別し、正しいレコードが影響を受けることを確認します。
- バージョン記述子：削除と更新が正しい時系列順に適用され、順序が正しくない操作が防がれます。
- タイムスタンプ記述子（時系列スキーマ）：削除操作を、取り込み時間ではなく、イベントの発生時間に合わせます。
リレーショナルスキーマのスケジュールされた保持
特定の ID ではなくデータ年齢に基づく自動ハイジーンについては、データレイクのスケジュールされた行レベルの保持に対する エクスペリエンスイベントデータセット保持（TTL）の管理 を参照してください。
リレーショナルレコード削除のベストプラクティス
意図しない再取り込みを避け、システム間でデータの一貫性を維持するには、次のベストプラクティスに従います。
- 削除の調整：レコードの削除を、変更データ取得設定とソースデータ管理戦略に合わせます。
- 変更データキャプチャフローの監視:Platform でレコードを削除した後、データフローを監視し、ソースシステムが同じレコードを削除するか、
_change_request_type = 'd'ータと共に含めることを確認します。 - ソースのクリーンアップ：完全な更新の取り込みを使用しているソースや、変更データ取得による削除をサポートしていないソースの場合、再取り込みを避けるためにソースシステムから直接レコードを削除します。
スキーマ要件について詳しくは、 リレーショナルスキーマ記述子の要件 を参照してください。
Change Data Capture がソースと連携する方法については、 ソースでの Change Data Capture の有効化 を参照してください。
次の手順
このドキュメントでは、Experience Platform UI でレコードを削除する方法について説明しました。 UI で他のデータライフサイクル管理タスクを実行する方法について詳しくは、 データライフサイクル UI の概要 を参照してください。
Data Hygiene API を使用したレコードの削除方法については、 作業指示エンドポイントガイド を参照してください。