データライフサイクル処理タイムライン data-lifecycle-processing-timelines

このドキュメントでは、レコードの削除リクエストがいつ完了し、そのタイムラインに何が影響するかを把握します。 タイムラインは、標準（30日間のSLA）またはPrivacy and Security ShieldまたはHealthcare Shield （15日間のSLA）のエンタイトルメント層によって異なります。 組織に適用される階層がわからない場合は、割り当て量を確認するか、Adobe担当者にお問い合わせください。 データセットの有効期限については、​ データセットの有効期限ガイド ​を参照してください。

レコード削除要求の処理方法 how-record-delete-timelines-work

​ レコード削除リクエスト ​を送信すると、キューとバッチ、下流処理、完了の3つのフェーズに移動します。 すべてのエンタイトルメント層は同じフローに従います。SLAによって、各フェーズにかかる時間が決まります。 SLAの標準使用権限は30日間、Privacy and Security ShieldまたはHealthcare Shield アドオンを使用している場合は15日間です。

リクエストを既に送信しており、正常に進行していることを確認する場合は、「使用権限によるタイムラインの処理」セクションを使用して、リクエストの経過時間に基づいてリクエストの場所を決定します。

フェーズ 1: キューとバッチ処理 queuing-and-batching

送信後、作業指示が作成され、リクエストが処理キューに入ります。 リクエストはキューに保持され、処理が開始される前にバッチにグループ化されます。 システムエラーではなくバッチ処理は、送信後すぐに削除が発生しない主な理由です。

キューの期間は、エンタイトルメント層によって異なります。 標準リクエストは、最大14日間キューに残ることがあります。 Privacy and Security ShieldまたはHealthcare Shieldの使用権限に基づくリクエストは、通常、約24時間以内に一括処理されますが、大量のリクエストは、ボリュームのしきい値に基づいて早期にプロモートされる場合があります。

フェーズ 2：下流処理 downstream-processing

バッチがキューを離れると、ダウンストリームサービスは、Experience Platform データストア全体で削除を処理します。 このフェーズでは、作業指示ステータスは更新されません。処理が確認されると、全体的な結果が反映されます。 リクエストの現在の状態を確認するには、​ リクエスト状態の監視を参照してください。 処理時間は、システム負荷と使用権限の階層によって異なり、使用権限の階層の操作SLA ウィンドウ内で発生します。

フェーズ 3：完了 completion

すべてのシステムで削除が確認されると、作業指示のステータスがcompletedに更新されます。 完了ステータスは、​ データライフサイクルワークスペース ​で確認できます。

使用権限による処理タイムライン processing-timelines-by-entitlement

上記の3つのフェーズは、すべてのエンタイトルメント層に適用されます。 次の表に、使用権限に基づく各フェーズの概算タイミングを示します。 特定のタイムラインを利用する前に、層を特定する。 ステージのタイミングはシステム負荷とバッチのスケジュールに基づいて概算され、異なります。エンドツーエンドのSLAは、操作のコミットメントです。

標準の使用権限 standard-entitlement

次のタイムラインは、Privacy and Security ShieldまたはHealthcare Shield アドオンを​ 持たない組織 ​に適用されます。

Privacy and Security Shield / Healthcare Shield shield-entitlement

以下の加速時系列は、Privacy and Security ShieldまたはHealthcare Shield アドオンを購入した組織にのみ適用されます。 使用権限レベルを確認するには、Adobe担当者にお問い合わせいただくか、割り当ての使用状況をご確認ください。

割り当て量と送信の制限 quota-and-submission-limits

処理タイムラインは、リクエストが承認された後に適用されます。 レコードの削除要求は、処理SLAとは別の、および処理SLAとは独立した、月次および日次のID送信クォータの対象となります。 送信されたリクエストが処理中であるように見えない場合は、バッチ処理に遅延を割り当てる前に、受け入れられたことを確認してください。 割り当て超過によってブロックされた要求は、処理キューに入らないため、アクションが必要です。 割り当て量を超えると、SLA層に関係なく、新しいリクエストが受け入れられなくなります。

割り当て階層、月間上限、および使用権限ベースの制限については、次を参照してください。

リクエストステータスの監視 monitoring-request-status

送信されたレコード削除リクエストのステータスを確認するには、Experience Platform UIの​データライフサイクル ワークスペースに移動し、「レコード」タブを選択します。 送信されたレコード削除要求とその現在のステータスのリストが表示されます。 プログラムによるステータスチェックの場合は、作業指示APIを使用します。

詳細な手順については、​ データライフサイクル作業指示の参照または作業指示エンドポイントガイド ​を参照してください。

次の手順 next-steps

レコード削除要求の操作を続行するには、次のリソースを参照してください。