Data Lake의 개인 정보 요청 처리

Adobe Experience Platform Privacy Service은 법적 및 조직의 개인 정보 보호 규정에 따라 고객의 개인 데이터 액세스, 판매 거부 또는 삭제를 요청합니다.

이 문서에서는 Data Lake에 저장된 고객 데이터의 개인 정보 요청 처리와 관련된 중요한 개념을 다룹니다.

시작하기

이 안내서를 읽기 전에 다음 Experience Platform 서비스에 대한 작업 이해를 구하는 것이 좋습니다.

• Privacy Service:Adobe Experience Cloud 애플리케이션에서 개인 데이터를 액세스, 판매 거부 또는 삭제하기 위한 고객 요청을 관리합니다.
• Catalog Service:데이터 위치 및 내부 계열에 대한 기록 Experience Platform시스템. 데이터 집합 메타데이터를 업데이트하는 데 사용할 수 있는 API를 제공합니다.
• Experience Data Model (XDM) System:고객 경험 데이터를 Experience Platform 구성하는 표준화된 프레임워크
• Identity Service:디바이스 및 시스템 간의 ID를 결합함으로써 고객 경험 데이터의 세분화로 인해 발생하는 기본적인 문제를 해결합니다.

ID 네임스페이스 이해

Adobe Experience Platform Identity Service은(는) 시스템 및 장치 간에 고객 ID 데이터를 연결해줍니다. Identity Service id 네임스페이스를 사용하여 자신의 원본 시스템에 대한 관계를 만들어 id 값에 컨텍스트를 제공합니다. 네임스페이스는 이메일 주소("이메일")와 같은 일반적인 개념을 나타내거나 ID를 Adobe Advertising Cloud ID("AdCloud") 또는 Adobe Target ID("TNTID")와 같은 특정 응용 프로그램과 연결할 수 있습니다.

Identity Service 전역적으로 정의된(표준) 및 사용자 정의(사용자 정의) ID 네임스페이스의 저장소를 유지 관리합니다. 표준 네임스페이스는 모든 조직(예: "이메일" 및 "ECID")에서 사용할 수 있지만 조직에서 특정 요구에 맞는 사용자 정의 네임스페이스를 만들 수도 있습니다.

Experience Platform의 ID 네임스페이스에 대한 자세한 내용은 ID 네임스페이스 개요를 참조하십시오.

데이터 세트에 ID 데이터 추가

Data Lake에 대한 개인 정보 요청을 만들 때 데이터를 찾아 적절하게 처리하기 위해 각 개별 고객에 대해 유효한 ID 값 및 관련 네임스페이스가 제공되어야 합니다. 따라서 개인 정보 요청의 대상이 되는 모든 데이터 집합은 관련 XDM 스키마에 ID 설명자를 포함해야 합니다.

이 섹션에서는 기존 데이터 세트의 XDM 스키마에 ID 설명자를 추가하는 단계를 안내합니다. ID 설명자가 있는 데이터 세트가 이미 있는 경우 다음 섹션으로 건너뛸 수 있습니다.

데이터 세트 스키마에 ID 설명자를 추가하는 방법에는 두 가지가 있습니다.

• UI 사용
• API 사용

UI 사용

Experience Platform사용자 인터페이스에서 Schemas 작업 공간을 사용하여 기존 XDM 스키마를 편집할 수 있습니다. 스키마에 ID 설명자를 추가하려면 목록에서 스키마를 선택하고 Schema Editor 자습서의 ID 필드](…/xdm/tutorials/create-schema-ui.md#identity-field)로 스키마 필드를 설정하는 단계를 따릅니다.[

스키마 내의 적절한 필드를 ID 필드로 설정한 경우 개인 정보 요청 제출의 다음 섹션으로 진행할 수 있습니다.

API 사용

Schema Registry API의 /descriptors 끝점에 POST 요청을 하여 데이터 집합의 XDM 스키마에 ID 설명자를 추가할 수 있습니다.

API 형식

POST /descriptors

요청

다음 요청은 샘플 스키마의 "이메일 주소" 필드에 ID 설명자를 정의합니다.

curl -X POST \
  https://platform.adobe.io/data/foundation/schemaregistry/tenant/descriptors \
  -H 'Authorization: Bearer {ACCESS_TOKEN}' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: {API_KEY}' \
  -H 'x-gw-ims-org-id: {IMS_ORG}' \
  -H 'x-sandbox-name: {SANDBOX_NAME}' \
  -d '
      {
        "@type": "xdm:descriptorIdentity",
        "xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
        "xdm:sourceVersion": 1,
        "xdm:sourceProperty": "/personalEmail/address",
        "xdm:namespace": "Email",
        "xdm:property": "xdm:code",
        "xdm:isPrimary": false
      }'

응답

성공적인 응답은 HTTP 상태 201(만들음)과 새로 만든 설명자의 세부 정보를 반환합니다.

{
  "@type": "xdm:descriptorIdentity",
  "xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
  "xdm:sourceVersion": 1,
  "xdm:sourceProperty": "/personalEmail/address",
  "xdm:namespace": "Email",
  "xdm:property": "xdm:code",
  "xdm:isPrimary": false,
  "meta:containerId": "tenant",
  "@id": "f3a1dfa38a4871cf4442a33074c1f9406a593407"
}

요청 제출 중

다음 섹션에서는 Privacy Service UI 또는 API를 사용하여 Data Lake에 대한 개인 정보 요청을 수행하는 방법에 대해 설명합니다.

UI 사용

UI에서 작업 요청을 만들 때는 Data Lake 또는 Real-time Customer Profile에 저장된 데이터의 작업을 각각 처리하려면 AEP Data Lake 및/또는 Profile 아래에서 Products​을 선택해야 합니다.

API 사용

API에서 작업 요청을 만들 때 제공된 모든 userIDs은 적용되는 데이터 저장소에 따라 특정 namespace 및 type를 사용해야 합니다. Data Lake에 대한 ID는 해당 type 값에 "등록되지 않음"을 사용하고 해당 데이터 세트에 추가된 개인 정보 레이블과 일치하는 namespace 값을 사용해야 합니다.

또한 요청 페이로드의 include 배열에는 요청이 수행되는 다른 데이터 저장소에 대한 제품 값이 포함되어야 합니다. Data Lake에 대한 요청을 할 때 배열에 aepDataLake 값이 포함되어야 합니다.

다음 요청은 등록되지 않은 "email_label" 네임스페이스를 사용하여 Data Lake에 대한 새 개인 정보 보호 작업을 만듭니다. 또한 include 배열에 있는 Data Lake의 제품 값도 포함합니다.

curl -X POST \
  https://platform.adobe.io/data/core/privacy/jobs \
  -H 'Authorization: Bearer {ACCESS_TOKEN}' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: {API_KEY}' \
  -H 'x-gw-ims-org-id: {IMS_ORG}' \
  -d '{
    "companyContexts": [
      {
        "namespace": "imsOrgID",
        "value": "{IMS_ORG}"
      }
    ],
    "users": [
      {
        "key": "user12345",
        "action": ["access","delete"],
        "userIDs": [
          {
            "namespace": "email_label",
            "value": "ajones@acme.com",
            "type": "unregistered"
          },
          {
            "namespace": "email_label",
            "value": "jdoe@example.com",
            "type": "unregistered"
          }
        ]
      }
    ],
    "include": ["aepDataLake"],
    "expandIds": false,
    "priority": "normal",
    "regulation": "ccpa"
}'

요청 처리 삭제

Experience Platform이(가) Privacy Service의 삭제 요청을 받으면 Platform은(는) 요청을 받았고 영향을 받는 데이터가 삭제하도록 표시되었다는 확인을 Privacy Service에 보냅니다. 그러면 7일 이내에 Data Lake에서 레코드가 제거됩니다. 이 7일 기간 동안 데이터는 소프트 삭제되므로 Platform 서비스에서 액세스할 수 없습니다.

데이터가 물리적으로 삭제된 후 Platform이(가) Privacy Service에 확인을 보냅니다.

다음 단계

이 문서를 읽음으로써 Data Lake에 대한 개인 정보 요청 처리와 관련된 중요한 개념을 도입했습니다. ID 데이터 관리 및 개인 정보 보호 작업 생성 방법에 대한 이해를 심도있게 하기 위해 이 안내서 전체에서 제공된 설명서를 계속 읽는 것이 좋습니다.

Profile 스토어에 대한 개인 정보 요청을 처리하는 단계는 실시간 고객 프로필에 대한 개인 정보 요청 처리에 관한 문서를 참조하십시오.

부록

다음 섹션에는 Data Lake의 개인 정보 요청을 처리하기 위한 추가 정보가 포함되어 있습니다.

중첩된 맵 유형 필드 레이블 지정

개인 정보 레이블을 지원하지 않는 두 가지 유형의 중첩된 맵 유형 필드가 있다는 점을 유의해야 합니다.

• 배열 유형 필드 내의 맵 유형 필드
• 다른 맵 유형 필드 내의 맵 유형 필드

위의 두 예 중 하나에 대한 개인 정보 작업 처리가 결국 실패하게 됩니다. 이러한 이유로 비공개 고객 데이터를 저장하기 위해 중첩된 맵 유형 필드를 사용하지 않는 것이 좋습니다. 관련 소비자 ID는 기록 기반 데이터 집합에 대해 identityMap 필드(자체를 지도 유형 필드) 내에 맵 데이터 유형이 아닌 데이터 유형으로 저장하거나, 시간 시리즈 기반 데이터 세트에 대해서는 endUserID 필드로 저장해야 합니다.