Campaign でのプライバシーリクエストの管理 privacy
ビジネスの性質と管轄区域に応じて、データ操作は法的プライバシー規制の対象となる場合があります。 多くの場合、これらの規制により、顧客は収集されたデータへのアクセスをリクエストする権利と、保存されたデータの削除をリクエストする権利を得ることができます。 個人データに対するこれらの顧客リクエストは、ドキュメント全体で「プライバシーリクエスト」と呼ばれます。
アドビは、Campaign に保存されているデータに対するプライバシーリクエストの作成と処理を行うためのデータコントローラー用ツールを用意しています。しかし、要求者であるデータ主体の ID、および要求者に返されるデータがデータ主体に関するものであることの確認は、データコントローラーの責任です。個人データおよびデータを管理する様々なエンティティについて詳しくは、Adobe Campaign Classic v7 ドキュメントを参照してください。
Campaign でプライバシーリクエストを管理するには、まず名前空間を定義する必要があります。その後、プライバシーリクエストを作成および管理できます。 プライバシーリクエストを実行するには、Adobe Privacy Service 統合を使用します。Privacy Service からすべての Adobe Experience Cloud ソリューションにプッシュされたプライバシーリクエストは、専用のワークフローで Campaign によって自動的に処理されます。詳細情報
詳しくは、 アクセスする権利 そして 忘れられる権利 （削除リクエスト） Adobe Campaign Classic v7 ドキュメント.
名前空間を定義 namespaces
プライバシーリクエストを作成する前に、使用する 名前空間を定義する 必要があります。名前空間は、 データベースでデータ主体を識別するために使用されるキーです。
現在、Adobe Campaign は、Experience Platform ID 名前空間サービスからの名前空間のインポートをサポートしていません。したがって、ID 名前空間サービスで名前空間を作成したら、対応する名前空間を Adobe Campaign インターフェイスで手動で作成する必要があります。それには、次の手順に従います。
-
ID 名前空間サービスで名前空間を作成します。
-
ID 名前空間のリストが組織で使用可能な場合、例えば、次の名前空間が得られます。
code language-none { "updateTime": 1632903236731, "code": "lumanamespace", "status": "ACTIVE", "description": "new namespace for Luma privacy requests", "id": 10998717, "createTime": 1632903236731, "idType": "Email", "namespaceType": "Custom", "name": "Luma Namespace", "custom": true } -
Adobe Campaign で、管理／Platform／名前空間 を参照し、新規 を選択します。
-
ラベル を入力します。
-
ID 名前空間サービスで作成した名前空間に一致するように、新しい名前空間の詳細を入力します。
- AEC 名前空間 ID は、「id」属性に一致する必要があります。
- 内部名 は、「code」属性に一致する必要があります。
- 紐付けキー は、「idType」属性に一致する必要があります。
紐付けキー フィールドは、Adobe Campaign データベースでデータ主体を識別するために使用します。
-
ターゲットマッピング を選択し、Adobe Campaign での名前空間の紐付け方法を指定します。
note note NOTE 複数のターゲットマッピングを使用する必要がある場合は、ターゲットマッピングごとに 1 つの名前空間を作成します。 -
変更内容を保存します。
これで、新しい名前空間に基づいてプライバシーリクエストを作成できます。複数の名前空間を使用する場合、同じ紐付け値に対して、名前空間ごとに 1 つのプライバシーリクエストを作成します。
プライバシーリクエストの作成 create-privacy-request
Adobe Experience Platform Privacy Service 統合を使用すると、単一の JSON API の呼び出しで、複数のソリューションのコンテキストでプライバシーリクエストを自動化できます。Adobe Campaign は、専用のワークフローを通じて Privacy Service からプッシュされたリクエストを自動的に処理します。
Privacy Core Service からプライバシーリクエストを作成する方法については、Experience Platform Privacy Service のドキュメントを参照してください。
各 Privacy Service ジョブは、使用されている名前空間の数に基づいて、Adobe Campaign で複数のプライバシーリクエストに分割されます。1 つのリクエストが 1 つの名前空間に対応します。
また、1 つのジョブを複数のインスタンスで実行できます。したがって、1 つのジョブに対して複数のファイルが作成されます。例えば、リクエストに 2 つの名前空間があり、3 つのインスタンスで実行されている場合、合計 6 つのファイルが送信されます。名前空間およびインスタンスごとに 1 つのファイル。
ファイル名のパターンは次のとおりです。<InstanceName>-<NamespaceId>-<ReconciliationKey>.xml
- InstanceName：Campaign インスタンス名
- NamespaceId：使用する名前空間の ID サービス名前空間 ID
- 紐付けキー：エンコードされた紐付けキー
リクエストの処理時に検索されるテーブル list-of-tables
プライバシーに関連する削除またはアクセスリクエストの実行時に、Adobe Campaign では、受信者テーブル（独自タイプ）にリンクされたすべてのテーブルの 紐付け値 に基づいて、データ主体のすべてのデータを検索します。
プライバシーリクエストの実行時に考慮される組み込みテーブルのリストは、次のとおりです。
- 受信者（recipient）
- 受信者配信ログ（broadLogRcp）
- 受信者トラッキングログ（trackingLogRcp）
- アーカイブしたイベント配信ログ（broadLogEventHisto）
- 受信者リストのコンテンツ（rcpGrpRel）
- 訪問者オファー提案（propositionVisitor）
- 訪問者（visitor）
- 購読履歴（subHisto）
- 購読（subscription）
- 受信者のオファーの提案（propositionRcp）
受信者テーブル（独自タイプ）にリンクされるカスタムテーブルを作成した場合は、そのテーブルも考慮されます。例えば、受信者テーブルにリンクしているトランザクションテーブルと、そのトランザクションテーブルにリンクしているトランザクション詳細テーブルがある場合、両方のテーブルが考慮されます。
プライバシーリクエストのステータス privacy-request-statuses
Adobe Campaign のプライバシーリクエストの様々なステータスと、その解釈方法を次に示します。
- 新規／再試行保留：ワークフローは進行中で、リクエストの処理は完了していません。
- 処理中／再試行中：ワークフローはリクエストを処理しています。
- 削除保留：ワークフローにおいて、削除対象のすべての受信者データが特定済みです。
- 削除中：ワークフローは削除を処理しています。
- 完了：リクエストの処理が終了しました。エラーは発生していません。
- エラー：ワークフローにおいて、エラーが発生しました。理由は、プライバシーリクエストのリストの「リクエストのステータス」列に表示されます。例えば、「エラー : データが見つかりません」は、データ主体の 紐付け値 と一致する受信者データがデータベースに見つからなかったことを示します。
Campaign Classic v7 ドキュメントの関連トピック：
-
プライバシー管理に関する規制（GDPR、CCPA、PDPA、LGPD）
-
個人情報の販売に対するオプトアウト（CCPA に固有）