レコード削除要求（UI ワークフロー） record-delete
Data Lifecycle ワークスペース を使用して、Adobe Experience Platformのレコードをプライマリ IDに基づいて削除します。 これらのレコードは、個々の消費者や、ID グラフに含まれるその他のエンティティに関連付けることができます。
前提条件 prerequisites
レコードを削除するには、Experience PlatformでID フィールドがどのように機能するかを理解する必要があります。 具体的には、削除するデータセット（またはデータセット）に応じて、レコードを削除するエンティティのプライマリ ID名前空間と値を知る必要があります。
Experience PlatformのIDについて詳しくは、次のドキュメントを参照してください。
- Adobe Experience Platform ID サービス：デバイスやシステム間で ID をブリッジし、準拠する XDM スキーマで定義された ID フィールドに基づいてデータセットをリンクします。
- ID 名前空間：ID 名前空間は、1 人の人物に関連している可能性のある様々なタイプの ID 情報を定義する、各 ID フィールドに必須のコンポーネントです。
- リアルタイムの顧客プロファイル :ID グラフを使用して、複数のソースから集約されたデータに基づいて、ほぼリアルタイムで更新される統合された消費者プロファイルを提供します。
- Experience Data Model （XDM） : スキーマを使用して、Experience Platform データの標準的な定義と構造を提供します。 あらゆるExperience Platformデータセットは、特定のXDM スキーマに準拠しており、スキーマはどのようなフィールドがIDであるかを定義します。
- ID フィールド：XDM スキーマで ID フィールドが定義される方法を説明します。
- セカンダリIDはスキャンされません。 データセットに複数のID フィールドが含まれる場合、一致にはプライマリ IDのみが使用されます。 プライマリ以外のIDに基づいて、レコードをターゲティングまたは削除することはできません。
- 入力されたプライマリ IDのないレコードはスキップされます。 レコードにプライマリ ID メタデータが入力されていない場合、削除の対象にはなりません。
- ID設定の前に取り込まれたデータは対象外です。 データ取り込み後にプライマリ ID フィールドがスキーマに追加された場合、以前に取り込んだレコードはこのワークフローを通じて削除できません。
リクエストの作成 create-request
プロセスを開始するには、Experience Platform UIの左側のナビゲーションで「Data Lifecycle」を選択します。 Data lifecycle requests ワークスペースが表示されます。 次に、ワークスペースのメインページから「Create request」を選択します。
リクエスト作成ワークフローが表示されます。 デフォルトでは、Requested Action セクションでDelete record オプションが選択されています。 このオプションを選択されたままにします。
データセットの選択 select-dataset
次の手順では、単一のデータセットとすべてのデータセットのどちらからレコードを削除するかを決定します。 組織の設定によっては、データセット選択オプションが使用できない場合があります。 このオプションが表示されない場合は、ガイドの「IDを指定」セクションに進みます。
「Record Details」セクションで、ラジオボタンを選択して、特定のデータセットまたはすべてのデータセットのいずれかを選択します。
特定のデータセットから削除するには、Select datasetを選択し、データベースアイコン（
すべてのデータセットから削除するには、All datasetsを選択します。 このオプションを選択すると、操作の範囲が拡大し、ターゲットにする各データセットのプライマリ ID タイプを指定する必要があります。
Experience Platformの各データセットは、1つのプライマリ ID タイプのみをサポートします。
- 単一データセットから削除する場合、リクエスト内のすべてのIDは 同じタイプ を使用する必要があります。
- すべてのデータセットから削除する場合、異なるデータセットが異なるプライマリ IDに依存する可能性があるため、複数のID タイプを含めることができます。」
ID を提供 provide-identities
レコードを削除する場合は、どのレコードを削除するかをシステムが判断できるように、ID情報を提供する必要があります。 Experience Platform内の任意のデータセットについて、データセットのスキーマで定義されているプライマリ ID フィールドに基づいてレコードが削除されます。
Experience PlatformのすべてのID フィールドと同様に、プライマリ IDは、type （ID名前空間）と value の2つから構成されます。 ID タイプは、フィールドでレコード（電子メールアドレスなど）を識別する方法に関するコンテキストを提供します。 値は、そのタイプのレコードの特定のIDを表します（例：email ID タイプのjdoe@example.com）。 プライマリ 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
レコード削除リクエストは、組織のライセンス資格によって決定される、毎日および毎月のID送信制限の対象となります。 これらの制限は、UI ベースの削除要求とAPI ベースの削除要求の両方に適用されます。
製品別の月次提出資格 quota-limits
次の表に、製品および資格レベル別の識別子の送信制限の概要を示します。 各製品の月間上限は、2つの値のうち小さい方の値です。つまり、固定識別子の上限と、ライセンス済みデータ量に関連付けられたパーセントベースのしきい値です。
割り当ては、各暦月の初日にリセットされます。 未使用の割り当て量は、notが引き継ぎます。
識別子の送信に関する処理タイムライン sla-processing-timelines
送信後、レコード削除リクエストはキューに入れられ、使用権限レベルに基づいて処理されます。
お客様の組織がより高い制限を必要とする場合は、Adobe担当者に連絡して使用権限のレビューを行ってください。
リクエストの送信 submit
リクエストへのIDの追加が完了したら、Request settingsの下に、リクエストの名前とオプションの説明を入力してから Submit を選択します。
削除したIDは復元できないことを示すConfirm request ダイアログが表示されます。 データを削除するIDのリストを確認するには、Submitを選択します。
リクエストが送信されると、作業指示が作成され、Data Lifecycle ワークスペースのRecord タブに表示されます。 ここから、リクエストを処理する作業指示のステータスを監視できます。
関係スキーマに基づくデータセットからのレコードの削除 relational-record-delete
削除するデータセットがリレーショナルスキーマに基づいている場合は、次の考慮事項を確認して、レコードが正しく削除され、Experience Platformとソースシステムの間の不一致が原因で再取り込まれないことを確認します。
レコード削除動作
次の表は、取り込み方法とデータキャプチャ設定の変更に応じて、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'と共に含めることを確認します。 - ソースのクリーンアップ：完全更新の取り込みを使用しているソースまたは変更データキャプチャによる削除をサポートしていないソースの場合は、再取り込みを避けるために、ソースシステムから直接レコードを削除します。
スキーマ要件について詳しくは、 リレーショナルスキーマ記述子の要件を参照してください。
変更データキャプチャとソースの連携の仕組みについては、 ソースでの変更データキャプチャの有効化を参照してください。
次の手順
このドキュメントでは、Experience Platform UIでレコードを削除する方法について説明しました。 UIで他のデータライフサイクル管理タスクを実行する方法について詳しくは、 データライフサイクル UIの概要を参照してください。
Data Hygiene APIを使用してレコードを削除する方法については、作業指示エンドポイントガイド を参照してください。