Show Menu
화제×

레이블 지정 우수 사례

새 보고서 세트를 작성할 때마다 또는 기존 보고서 세트 내에서 새 변수를 활성화하는 경우 레이블 지정을 검토해야 합니다. 또한, 새로운 솔루션 통합이 활성화된 경우 레이블 지정이 필요할 수 있는 새로운 변수를 노출할 수 있으므로 레이블 지정을 검토해야 할 수 있습니다. 모바일 앱 또는 웹 사이트를 재구현하면 기존 변수가 사용되는 방식이 변경될 수 있으며, 이로 인해 레이블 업데이트가 필요할 수도 있습니다.

직접 또는 간접적으로 식별 가능한 ID

어떤 변수/필드에 어떤 레이블을 적용해야 하는지 파악하려면 먼저 Analytics 데이터에서 캡처 중인 ID를 파악하고 데이터 개인 정보 보호 요청에 사용할 ID를 결정해야 합니다. 데이터 개인 정보 보호에 따르면 ID로 간주할 수 있는 항목의 범위가 확장됩니다. ID는 직접 식별 가능한 ID(ID 레이블: I1)와 간접 식별 가능한 ID(ID 레이블: I2)의 광범위한 두 클래스로 구분됩니다.
  • 직접 식별 가능한 ID(I1) : 사용자 이름을 지정하거나 사용자에게 연락하는 직접적인 방법을 제공합니다. 예를 들어 누군가의 이름(수백 명의 사용자가 사용할 수 있는 John Smith와 같은 일반적인 이름 포함), 이메일 주소 또는 전화 번호 등이 있습니다. 이름이 없는 우편 주소는 가정 또는 회사 내의 특정 개인이 아니라 해당 가정 또는 회사만 식별할 수 있다 하더라도 직접 식별 가능한 것으로 간주될 수 있습니다.
  • 간접 식별 가능한 ID(I2) : 개인을 자체적으로 식별할 수는 없지만, 다른 정보(소유하고 있거나 소유하고 있지 않은 정보)와 결합하여 누군가를 식별할 수 있습니다. 예를 들어 고객 충성도 번호 또는 회사의 CRM 시스템에서 사용되며 각 고객에 대해 고유한 ID가 있습니다. 데이터 개인 정보 보호에 따르면, Analytics에서 사용하는 추적 쿠키에 저장된 익명 ID는 개인이 아닌 장치만 식별할 수 있고 공유된 장치에서 시스템의 서로 다른 사용자를 구별할 수 없지만 간접적으로 식별할 수 있는 것으로 간주됩니다. 예를 들어 쿠키를 사용하여 쿠키를 포함하는 컴퓨터를 찾을 수 없는 경우 다른 사용자가 컴퓨터에 액세스하여 쿠키를 찾으면 Analytics 쿠키 데이터를 다시 컴퓨터에 연결할 수 있습니다.
    또한, IP 주소는 특정 시점에 제공된 인스턴스에서 단일 장치에만 지정될 수 있으므로 간접적으로 식별 가능한 것으로 간주됩니다. 하지만 ISP에서 정기적으로 대부분의 사용자에 대해 IP 주소를 변경할 수 있으며 자주 변경하므로, 시간이 지남에 따라 사용자 중 누군가가 해당 IP 주소를 사용했을 수 있습니다. 또한 한 회사 내에서 동일한 인트라넷에 있는 여러 직원 또는 한 ISP의 여러 고객이 동일한 외부 IP 주소를 공유하는 일도 일반적입니다. 이러한 이유로 Adobe는 데이터 개인 정보 보호 요청에 대한 ID로 IP 주소를 사용하는 것을 지원하지 않습니다. 그러나 Adobe에서 허용하는 ID가 삭제 요청의 일부로 사용된 경우 해당 ID와 함께 발생한 IP 주소도 지웁니다. 사용자는 수집하는 ID 중에서 I1 또는 I2 카테고리에 해당할 수 있지만 데이터 개인 정보 보호 요청에 대한 구별 ID로 사용하기에는 적합하지 않은 다른 ID가 있는지 파악해야 합니다.
회사에서 Analytics 데이터 내에 있는 서로 다른 여러 ID를 수집하는 경우에도 데이터 개인 정보 보호 요청에 대해서는 이러한 ID의 하위 집합만 사용하도록 선택할 수 있습니다. 이에 대해서는 다음과 같은 여러 이유가 있을 수 있습니다.
  • 시스템 내에서 ID 중 하나(예: 이메일 주소)를 다른 ID(예: CRM ID)에 매핑할 수 있습니다. 그런 다음 일관성을 위해 개인 정보 보호 처리 시에는 데이터 개인 정보 보호 요청에 CRM ID만 사용하도록 결정합니다.
  • 사용자가 해당 ID와 실제로 연관된 사람인지 확인할 방법이 없습니다. 예를 들어, IP 주소를 이전에 한 사람만 사용했는지 그리고 그 사람이 요청을 제출한 사람과 실제로 동일한 사람인지 확인하기 어려울 수 있습니다.
  • 일부 ID의 경우 여러 사용자에게 해당할 수 있으므로 한 사람에 대한 정보를 동일한 ID를 가진 다른 사람에게 반환할 위험을 감수하고 싶지는 않을 것입니다. 예를 들어, 사용자 이름이 John Smith임을 확인할 수 있다 하더라도 시스템에 있는 모든 John Smith에 대한 모든 데이터를 반환하고 싶지는 않을 것입니다.
  • 또 다른 예는 Analytics 쿠키 ID와 같은 장치 ID입니다. ID가 휴대전화 앱에서 발생하는 경우 휴대전화 소유자가 해당 ID를 사용하는 모든 상호 작용을 사용할 수 있도록 결정할 수 있습니다. 그러나 홈 컴퓨터나 도서실 또는 인터넷 카페의 컴퓨터와 같은 공유된 장치에서 ID가 발생하는 경우, 해당 장치의 사용자를 구분할 수 없으며 다른 사용자의 데이터를 반환할 위험이 너무 크므로 이 유형의 ID를 사용하도록 허용하지 않을 수 있습니다.

Analytics에서 지원하는 ID에 대한 우수 사례

이 테이블을 사용하여 데이터 개인 정보 보호 요청을 Analytics에 제출할 때 사용할 ID 유형을 확인합니다. 이 정보를 알고 있으면 변수에 사용해야 하는 다른 레이블을 쉽게 확인할 수 있습니다.
ID 유형 Recommendations
쿠키 ID
이러한 쿠키는 장치, 그중에서도 장치 사용자의 브라우저를 식별합니다. 공통 로그인이 사용되는 공유된 장치의 경우 이 ID는 장치의 모든 사용자에게 적용될 수 있습니다. Adobe는 사용자가 이러한 쿠키를 데이터 개인 정보 보호 요청에 사용할 수 있도록 하려는 경우 해당 쿠키를 수집하기 위해 웹 사이트에 배치할 수 있는 일부 통합 JavaScript 를 만들었습니다.
Adobe Analytics Mobile SDK 사용자도 ECID(Experience Cloud ID)가 있습니다. SDK 내에 이 ID를 읽는 API 호출이 있으므로, 데이터 개인 정보 보호 요청에 대해 해당 ID를 수집하도록 앱을 향상시킬 수 있습니다.
많은 회사에서 브라우저 쿠키 ID를 공유된 장치의 ID로 간주합니다. 따라서 이러한 회사에서는 해당 법률팀과 상의하여 데이터 개인 정보 보호 요청에 허용 가능한 ID로 이러한 ID를 사용하는 것을 지원하지 않도록 하거나, 이러한 ID가 사용될 때 매우 제한된 양의 데이터만 반환하도록 하거나, 삭제 요청에 대해서만 수락하도록 할 수 있습니다.
이러한 쿠키에는 I2 및 DEL-DEVICE 레이블뿐만 아니라 변경할 수 없는 ID-DEVICE 레이블이 있습니다. 기본 Adobe Analytics 구성은 장치 유형, OS, 브라우저 등과 같은 장치에 대한 일반 정보와 이러한 ID를 사용할 때 웹 사이트를 방문한 시간/날짜만 반환합니다. 그러나 데이터 개인 정보 보호 요청에 대해 이러한 ID를 지원하도록 선택하는 경우, 아래 설명된 대로 ACC-ALL 레이블을 추가하거나 제거하여 데이터 개인 정보 보호 액세스 요청에 대해 반환하려는 정확한 필드 집합을 구성할 수 있습니다.
특히 보고서 세트가 모바일 앱에 해당되고 모바일 앱에 로그인이 필요한 경우에는 장치에 대한 Experience Cloud ID가 특정 사용자에 해당한다고 판단할 수 있으므로 방문한 페이지 이름, 확인한 제품 등을 비롯하여 더 많은 필드에 ACC-ALL 레이블을 지정할 수 있습니다.
참고: 데이터 개인 정보 보호 요청에 "expandIds" 옵션을 지정하는 경우 요청에 사용자가 지정한 다른 ID 외에도 항상 쿠키 ID가 포함됩니다. 자세한 내용은 ID 확장 을 참조하십시오. 이러한 경우 쿠키 ID만 있고 다른 ID는 없는 히트는 액세스 요청의 일부로 데이터 레이블이 지정된 ACC-ALL만 반환합니다.
사용자 지정 변수의 ID
일부 고객은 ID를 사용자 지정 트래픽 변수(props) 또는 사용자 지정 전환 변수(eVars) 에 배치합니다. 가장 일반적인 것은 CRM ID이지만 이메일 주소, 사용자 로그인 이름, 고객 충성도 번호 또는 이러한 값의 해시를 포함합니다.
  • 데이터 개인 정보 보호 요청에 이러한 ID 중 하나를 사용하려면 해당 ID가 포함된 필드에 ID-PERSON 레이블을 지정해야 합니다.
  • 덜 일반적이긴 하지만, 이러한 사용자 지정 변수 중 하나에 있는 ID만 여러 사용자가 공유할 수 있는 장치를 식별하는 경우에는 ID-DEVICE 레이블을 대신 사용할 수 있습니다.
  • 이러한 필드에는 I1 또는 I2 레이블도 필요하므로 DEL-PERSON 또는 DEL-DEVICE 레이블을 포함해야 합니다. 일반적으로 DEL 레이블의 PERSON/DEVICE 옵션은 ID 레이블의 PERSON/DEVICE 옵션과 일치합니다.
보고서 세트에 데이터 개인 정보 보호 요청에 대한 데이터 주체를 식별하는 데 사용할 ID가 포함된 1개~2개 이상의 사용자 지정 변수가 있는 경우는 거의 없습니다. I1 또는 I2 레이블이 지정된 변수가 여러 개 있을 수 있지만, 일반적으로 이 중 한두 개에만 ID-PERSON 또는 ID-DEVICE 레이블이 있습니다.
사용자 지정 방문자 ID
이 방법은 널리 사용되지 않지만, Analytics에서는 사용자 지정 방문자 ID를 제공할 수 있는 구현을 지원하며, 이 ID가 있으면 기존 Analytics 추적 쿠키 대신 사용됩니다. 이 필드는 I2, ID-PERSON 및 DEL-PERSON 레이블을 가집니다.
많은 구현에서 이 ID는 CRM ID로부터 파생되므로 사용자가 이 사이트에 로그인하는 동안에만 존재합니다. 따라서 여러 장치에서 동일한 사용자 지정 방문자 ID를 사용할 수 있습니다. 한 가지 기술적인 문제는 사용자가 로그인하기 전에 발생하는 추적을 사용자가 로그인한 후에 수집된 추적과 연결할 수 없다는 점입니다. 대신 사용자 지정 방문자 ID를 사용하여 장치를 식별하는 경우 ID-PERSON 및 DEL- PERSON 레이블을 각각 ID-DEVICE 및 DEL- DEVICE로 각각 변경해야 합니다.

삭제 레이블 설정에 대한 우수 사례

Prop은 항상 대/소문자를 구분하지 않습니다. eVars는 기본적으로 대/소문자를 구분하지 않지만, Adobe 고객 지원 센터를 통해 대소문자를 구분하도록 구성할 수 있습니다. ID를 포함하는 대/소문자 구분 eVar가 있는 경우, 사용자는 요청에 사용된 대/소문자가 이러한 ID를 포함하는 히트에 사용된 대/소문자와 일치하도록 데이터 개인 정보 보호 요청을 제출할 때 적절한 대소문자를 사용해야 합니다.
삭제 레이블 DEL-DEVICE 및 DEL-PERSON은 드물게 사용해야 합니다. 데이터 개인 정보 보호 요청의 일부로 사용된 ID가 포함되지 않은 변수에 적용할 경우 기록 Analytics 보고서의 카운트(지표)가 거의 항상 변경됩니다.
  • 이러한 레이블 중 하나를 I1, I2 또는 S1 레이블이 지정된 변수에 적용하는 것이 좋습니다. I1, I2 또는 S1 레이블이 지정되지 않은 변수에는 적용할 수 없습니다.
  • DEL- 레이블을 사용하면 이러한 변수가 익명 처리됩니다 (ID가 "데이터 개인 정보 보호-" 접두사가 있는 임의의 문자열로 대체됨). 익명 처리된 동일한 값이 요청에 사용된 ID로 식별된 모든 히트의 원래 값에 대한 모든 인스턴스를 대체합니다. 이 필드의 원래 값이 그러한 ID 중 하나이면 보고서 지표가 변경되지 않습니다.
  • 일반적으로 필드에 ID-DEVICE 레이블이 있는 경우 DEL-DEVICE 레이블도 지정해야 합니다.
  • 마찬가지로, 필드에 ID-PERSON 레이블이 있는 경우 DEL-PERSON 레이블도 지정해야 합니다.
  • 필드에 ID- 레이블이 없지만 익명 처리할 식별 정보가 포함된 경우, 구현에 따라 적합한 레이블(DEVICE 또는 PERSON)이 달라집니다. 데이터 개인 정보 보호 요청에 쿠키 ID만 사용하는 경우 DEL-DEVICE를 사용해야 합니다.
  • ID-PERSON 레이블이 있는 다른 필드에서 사용자 지정 ID를 사용하고 해당 ID가 발생하는 행에서만 지워지도록 하려면 DEL-PERSON을 사용합니다.
  • ID 확장을 사용 중이며 식별된 모든 장치에서 모든 히트에 대한 값을 모두 지우려면 DEL-DEVICE를 사용합니다. 이 경우 원한다면 DEL-DEVICE 레이블과 DEL-PERSON 레이블을 모두 적용할 수 있지만, ID 확장은 사용자 ID와 일치하는 모든 행이 장치 ID와도 일치함을 의미하므로 DEL-PERSON 레이블이 필요하지 않습니다.
  • ID 확장을 사용하도록 지정하지는 않지만 서로 다른 요청에 대해 장치와 개인 ID를 혼합하여 사용할 경우에는 이 중 한 유형의 ID가 사용되면 삭제되어야 하는 변수에 대해 DEL-DEVICE와 DEL-PERSON 레이블을 둘 다 지정할 수 있습니다.
  • 해당 요청(확장된 ID 포함)에 대한 ID로도 사용되지 않는 변수에 DEL-DEVICE 또는 DEL-PERSON 레이블이 지정된 경우 해당 변수의 고유 값은 지정된(또는 확장된) ID가 발생하는 히트에 대해서만 익명으로 지정됩니다. 다른 히트에 동일한 값이 있는 경우 해당 값은 그러한 다른 위치에서 업데이트되지 않습니다. 이로 인해 카운트(지표)가 변경될 수 있습니다.
    예를 들어, eVar7에 "foo" 값을 포함하는 히트가 세 개 있지만, 이들 중 하나만 삭제에 대해 일치하는 다른 변수의 ID를 포함하는 경우 해당 히트의 "foo"는 "데이터 개인 정보 보호-123456789"와 같은 값으로 수정되고 다른 두 히트에서는 변경되지 않습니다. eVar7에 대한 고유 값 수를 표시하는 보고서에는 이전에 수행한 것보다 한 개 더 많은 고유한 값이 표시됩니다. eVars의 최상위 값을 표시하는 보고서에는 두 개(이전의 세 개가 아님)의 인스턴스만 있는 "foo"가 포함될 수 있고, 단일 인스턴스가 있는 새 값도 표시됩니다.

액세스 레이블 설정에 대한 우수 사례

다른 레이블이 들어 있는 필드는 거의 없지만, 일반적으로 많은 필드에 ACC 레이블이 있습니다. 적절한 액세스 레이블은 데이터 개인 정보 보호 요청에 사용하는 ID에 따라 다릅니다.
다음 항목을 사용하는 경우 다음 권장 사항 사용
장치 ID만
사용 중인 유일한 ID가 쿠키 ID이거나 ID-DEVICE 레이블이 있는 ID인 경우 ACC-ALL 레이블만 사용해야 합니다.
각 액세스 요청에 대한 한 쌍의 파일을 가져옵니다. 한 파일에는 지정된 모든 ACC-ALL 필드와 일치하는 각 히트에 대한 행이 포함되고, 한 파일에는 이 데이터에 대한 요약이 포함됩니다.
ID 확장이 없는 개인 ID
ID-PERSON 레이블이 있는 사용자 지정 ID만 사용하고 ID 확장을 수행하지 않는 경우에는 ACC-PERSON 레이블을 사용해야 합니다. 하지만 기본 ACC-ALL 레이블을 변경할 필요는 없습니다. 이러한 필드는 액세스 요청에 자동으로 포함됩니다.
각 액세스 요청에 대한 한 쌍의 파일을 가져옵니다. 한 파일에는 지정된 모든 ACC-DEVICE 및 ACC-PERSON 필드와 일치하는 각 히트에 대한 행이 포함되고, 한 파일에는 이 데이터에 대한 요약이 포함됩니다.
혼합 ID 및/또는 ID 확장
데이터 개인 정보 보호 요청에 장치와 개인 ID를 모두 포함하거나 사용자 지정 ID(사용자 지정 방문자 ID 또는 prop이나 eVar의 ID)를 사용하는 경우 사용하는 ACC 레이블에 주의를 기울여야 합니다. 각 액세스 요청은 두 쌍의 데이터 파일을 반환합니다. 한 쌍에는 일치한 개인 ID가 포함된 히트의 데이터가 포함되고, 한 쌍에는 개인 ID가 일치하지 않지만 장치 ID가 일치한 히트의 데이터가 포함됩니다.
"개인 ID" 파일에는 ACC-PERSON 또는 ACC-ALL 레이블이 있는 모든 필드와 개인 ID가 일치하는 모든 히트의 데이터가 포함됩니다(모든 일치하는 히트가 포함된 하나의 파일 및 요약으로서의 다른 파일).
"device ID" 파일 쌍에는 ACC-ALL 레이블이 있는 필드만 포함되며, 일치하는 개인 ID가 포함되지 않은 히트만 포함됩니다. 이러한 파일에는 공유된 장치의 다른 사용자가 생성한 데이터가 포함되어 있을 수 있으므로, ACC-ALL 레이블이 포함된 필드 세트를 주의해서 고려해야 합니다. Analytics 내의 기본 레이블 지정은 장치(장치 유형, OS, 브라우저 등) 및 각 히트의 날짜/시간과 관련된 일반 정보 필드에만 이 레이블을 적용합니다.
공유된 장치의 다른 사용자가 생성했을 수 있는 데이터를 공유하지 않도록 Adobe에서 장치 및 개인 파일 세트를 모두 수신한 다음 해당 사용자의 파일만 공유하도록 선택할 수 있습니다. 또는 데이터 주체에 대해 알고 있는 다른 정보와 한 세트 또는 두 세트 모두의 데이터를 결합하여 고유한 형식으로 반환할 수 있습니다.