개인정보 보호 및 동의 구현 가이드

Amplitude는 개인정보 보호 친화적인 방식으로 설정할 수 있습니다. 올바른 설정은 귀하의 정책, 귀하의 지역 및 동의 전에 수집하고자 하는 데이터의 양에 따라 달라집니다. 방법을 선택하기 전에 법률 및 개인정보 보호팀과 협력하여 귀하의 사건에서 허용되는 사항에 대해 확인하십시오.

이에 대해 생각해 볼 수 있는 좋은 방법은 먼저 동의 모델을 선택한 다음, 여기에 맞게 Amplitude에서 스토리지와 액세스를 구성하는 것입니다.

이 가이드 사용

이 가이드는 Amplitude에서 개인정보 보호를 중시하는 분석 설정을 구현하는 데 도움을 줍니다. 이는 법률 자문을 대체하지 않습니다. 귀사의 팀은 귀사의 비즈니스에 적용되는 동의 모델, 공개 및 지역 요건을 결정합니다. 이 가이드는 Amplitude에서 이러한 선택을 구현하는 실용적인 방법을 보여줍니다.

모든 기업에 적합한 단일 설정은 없습니다. 일부 조직에서는 분석을 시작하기 전에 엄격한 옵트인을 요구합니다. 다른 기업들은 일부 지역에서 보다 제한적인 측정 전용 접근법을 사용할 수 있습니다. 올바른 선택은 귀사의 제품, 귀사의 데이터 및 귀사가 운영하는 지역에 적용되는 규칙에 따라 달라집니다.

이 가이드를 의사 결정 및 구현 프레임워크로 사용하십시오.

1. 귀하의 정책에 맞는 동의 방법을 선택하십시오.
2. Amplitude를 해당 방법과 일치하도록 구성합니다.
3. 필요한 거버넌스, 리텐션 및 삭제 제어를 추가하십시오.
4. 시작하기 전에 설정을 확인하십시오.

이 가이드는 대부분의 팀이 먼저 필요로 하는 일반적인 구현 패턴과 제어 기능을 다룹니다. 복잡한 사용 사례의 경우 이를 출발점으로 삼고 법무, 개인정보 보호 및 보안 팀과 함께 내려야 할 결정을 식별하십시오.

시작하기 전에

어떤 작업을 구성하기 전에 다음 세 가지 질문에 답하십시오.

1. 분석을 시작하기 전에 동의가 필요한가요?
2. 동의 전에 데이터를 수집하지 않거나 익명의 측정을 제한적으로 수행하기를 원하십니까?
3. 어떤 필드가 Amplitude에 도달해야 합니까?

전체 필요한 동의를 얻고, 올바른 정보를 공개하며, 귀하의 정책에서 Amplitude 쿠키를 분류하는 방법을 결정하는 것은 귀하의 책임입니다.

실질적인 출발점은 다음과 같이 기록하는 것입니다.

• 수집하고자 하는 이벤트.
• 어떤 식별자를 저장할 것인지를 결정합니다.
• 어떤 속성이 민감한지.
• 사용자가 동의를 거부할 때 어떻게 해야 하는지
• 사용자가 초기 거절 후 동의를 허용할 경우 어떻게 해야 합니까?

이 1페이지 분량의 결정 문서는 구현을 훨씬 쉽게 검토하고 테스트할 수 있게 해줍니다.

정책에 맞는 설정을 선택하십시오.

방법 1: 동의를 요청하고 동의한 사용자에게서만 데이터를 수집하십시오.

정책에 따라 분석을 시작하기 전에 동의가 필요한 경우 이 옵션이 가장 명확합니다. 또한 사용자가 동의를 할 때까지 아무것도 시작되지 않기 때문에 사용자와 감사자에게 설명하기 가장 쉬운 모델입니다.

작동 방식

브라우저 SDK 2에서 SDK는 초기화되는 즉시 Amplitude 쿠키를 생성할 수 있습니다. 동의하기 전에 쿠키를 사용하지 않아야 하는 경우, 사용자가 동의할 때까지 SDK를 초기화하지 마십시오.

Amplitude에서 설정하는 방법

동의가 기록된 후에만 amplitude.init()호출하십시오. 사이트가 정상적으로 로드되도록 두고 동의 도구가 분석이 허용된다는 것을 확인할 때까지 초기화를 미루십시오.

import * as amplitude from '@amplitude/analytics-browser';
// User hasn't consented yet.
// Don't initialize the SDK here.
function onConsentGranted() {
  amplitude.init('API_KEY');
}

로그아웃 후 사용자를 익명화해야 하는 경우, amplitude.reset()호출하십시오. 이렇게 하면 userId가 지워지고 새 deviceId가 생성됩니다. 다음 활동은 사용자가 다시 로그인할 때까지 새로운 익명 사용자로 표시됩니다.

Amplitude 외부에서 할 일

CMP를 사용하여 초기화가 수행되는지 여부를 제어하십시오. Amplitude는 기본 CMP 연동을 제공하지 않으므로 귀하의 CMP는 동의 결과를 귀하의 Amplitude 구현에 전달해야 합니다.

SDK 초기화 중앙 집중화

amplitude.init(...)한 곳에서만 실행되도록 하십시오. 여러 팀이 사이트의 다른 부분에서 SDK를 초기화할 경우 추적이 동의에 의해 제어되었음을 증명하는 것이 훨씬 더 어려워집니다.

이 설정을 테스트할 때는 브라우저 개발자 도구를 열고 동의하기 전에 Amplitude 쿠키가 존재하지 않는지 확인하십시오.

방법 2: 동의를 요청하지만 동의하지 않는 사용자로부터 제한된 익명의 측정 값을 수집하십시오.

일부 조직은 동의하는 사용자를 위한 완전한 분석과 동의하지 않는 사용자를 위한 매우 제한적인 측정 등 중간 지점을 원합니다. 이는 귀하의 법률팀이 이러한 종류의 제한된 고객 측정이 귀하의 관할권에서 허용된다는 것을 확인한 경우에만 적절할 수 있습니다.

작동 방식

이 방법을 총 트래픽 또는 페이지 뷰와 같이 익명이거나 매우 최소화된 잠재고객 측정에만 사용하십시오. 사용자 수준의 행동 분석으로 전환되지 않도록 하십시오.

유럽 전역에서 규칙이 다를 수 있으므로 현지 규제 지침을 구현 결정의 일부로 간주하십시오. 프랑스가 잘 알려진 사례 중 하나입니다. 쿠키 및 동의 관리 가이드에서는 CNIL 면제를 동의 없이 익명의 통계적 잠재고객 측정을 위한 좁은 사례로 설명하고 있으며, 완전한 분석은 아닙니다. 유용한 기준점이지만, 이를 모든 유럽 시장의 기본 규칙으로 취급해서는 안 됩니다.

Amplitude에서 설정하는 방법

제한된 익명 흐름의 경우 영구 ID를 줄이거나 제거하십시오.

• 브라우저 ID를 지속적으로 사용하지 않으려면 identityStorage으로 설정하십시오none.
• 단일 세션 내에서는 사용자를 추적하지만 세션 간에는 추적하지 않으려면 session이identityStorage 옵션을 설정하십시오. 이는 일부 구현에 유용한 중간 지점입니다.
• 안정적인 userId을(를) 보내지 마십시오.
• 이벤트 세트를 작게 유지하고 총 트래픽 측정에 중점을 둡니다.

amplitude.init('API_KEY', {
  identityStorage: 'none',
});

정책에서 쿠키를 허용하지만 보다 보수적인 설정을 원할 경우 쿠키 지속 시간을 줄일 수도 있습니다.

Amplitude 외부에서 할 일

익명 흐름에 속하는 이벤트를 정확하게 결정하십시오. 그 목록을 짧게 유지하십시오. 대부분의 팀에서 이는 페이지 뷰, 트래픽 합계 및 기타 고수준 측정만을 의미합니다.

보다 강력한 제어가 필요하다면 데이터를 Amplitude에 도달하기 전에 자체 프록시를 통해 전송하세요. 도메인 프록시는 전송하기 전에 데이터를 필터링, 차단 또는 익명화하는 데 도움이 될 수 있습니다.

익명 흐름을 좁히십시오

이 방법을 선택한다면 절제력을 갖춰야 합니다. 시간별로 "제한된 익명 측정" 흐름을 조용히 완전한 행동 분석으로 전환하지 마십시오. 익명 흐름이 사용자 분석과 비슷해질수록 개인정보 보호 지위는 더욱 약해집니다.

동의된 데이터와 동의되지 않은 데이터를 별도의 프로젝트에 보관

동의된 분석 데이터와 제한된 비동의된 측정 스트림을 모두 수집하는 경우, 항상 별도의 Amplitude 프로젝트에 보관하십시오. 이 두 가지를 하나의 프로젝트에 혼합하면 나중에 해결하기 어려운 문제가 발생합니다. 처음부터 이 문제를 엄격하게 다루어야 하는 세 가지 이유가 있습니다.

• 보고의 무결성: 동의되지 않은 데이터는 최소화되거나 순환되는 식별자를 사용하므로 고유 사용자, 퍼널, 코호트와 같은 사용자 수준의 메트릭은 동의된 데이터와 매우 다르게 작동합니다. 이를 별도로 유지하면 어떤 숫자가 무엇을 의미하는지 명확해집니다.
• 의도하지 않은 사용자 연결 위험: Amplitude는 프로젝트 수준이 아닌 조직 수준에서 ID를 확인합니다. 동일한 사용자 ID 또는 장치 ID가 두 프로젝트 모두에 나타나면 Amplitude는 이들을 동일한 사용자로 취급합니다. 동의되지 않은 프로젝트가 이를 염두에 두지 않고 설계되었다면 실수로 프로젝트 전체에서 식별된 사용자에게 익명의 데이터를 연결할 수 있습니다.
• 접근 제어: 동의되지 않은 프로젝트는 더 엄격한 통제를 받아야 합니다. 분석이 집계 수준에 머무르도록 개별 사용자 수준의 이벤트 조회를 비활성화합니다. 데이터가 이미 자체 프로젝트에 있을 때 이를 적용하기가 훨씬 쉽습니다.

동의되지 않은 프로젝트를 보다 엄격하게 구성하십시오.

별도의 프로젝트를 사용하면 동의되지 않은 스트림을 처음부터 다르게 구성할 수 있습니다. 실제로 이는 일반적으로 동의되지 않은 프로젝트에서 더 엄격한 설정을 사용하는 것을 의미합니다: 쿠키가 없고, 영구 저장소가 없으며, 안정적인 사용자 ID가 없으며, 최소한의 이벤트 세트가 있습니다.

설정 방법

일반적인 설정은 다음과 같습니다.

• 동의한 사용자를 위한 하나의 프로젝트로, 동의 후 전체 분석이 시작됩니다.
• 동의하지 않은 사용자를 위한 하나의 프로젝트로, 정책이 허용하는 제한된 익명 측정 이벤트만 전송합니다.

방문자가 동의하지 않은 경우 허용된 이벤트를 동의하지 않은 프로젝트로 라우팅합니다. 방문자가 나중에 동의를 표명할 경우, 동의한 프로젝트로 Amplitude를 초기화하고 거기에서 정상적인 추적을 시작하십시오.

이 접근 방식을 사용하는 경우 두 프로젝트 모두에서 ID 전략이 의도적이어야 합니다. 동일한 조직의 여러 프로젝트 간에 Amplitude는 동일한 사용자 ID 또는 장치 ID가 동일한 사용자를 가리킨다고 가정합니다. 이는 합법적인 프로젝트 간 분석에 유용하지만, 또한 법률 및 구현 모델과 일치하지 않는 한 동의 상태 간에 식별자를 재사용하지 않도록 주의해야 한다는 것을 의미합니다.

적절한 경우 사용자 수준의 액세스를 제한하십시오.

일부 팀의 경우, 프로젝트를 분리하는 것만으로는 충분하지 않습니다. 또한 동의되지 않은 데이터가 포함된 프로젝트가 사용자 수준의 뷰에 보다 엄격하게 액세스할 수 있기를 원합니다.

이러한 경우에는 사용자 조회, 사용자 프로필, 사용자 스트림 또는 유사한 사용자 수준 표면과 같은 기능을 해당 프로젝트에서 계속 사용할 수 있어야 하는지 검토하십시오. 이는 프로젝트에 익명이거나 동의되지 않은 데이터가 포함되어 있고 개인정보 보호 정책이 개인 수준의 탐색을 피하기 위한 목적인 경우 특히 중요합니다.

실질적인 규칙으로, 많은 팀은 동의하지 않은 프로젝트에는 더 엄격한 설정을 원하고 동의한 프로젝트에는 더 표준적인 설정을 원합니다. 이러한 종류의 프로젝트별 제한이 필요한 경우, 구현 설계의 일환으로 Amplitude 팀과 논의하여 조직에 적합한 통제를 적용하도록 하세요.

프로젝트 레벨에서 사용자 조회 비활성화

DAC와 RBAC 외에도 Amplitude는 프로젝트 수준에서 사용자 조회 기능을 비활성화하는 것을 지원합니다. Amplitude 팀에서 이 설정을 활성화하면 팀 구성원은 차트와 대시보드의 상황별 메뉴(예: 사용자의 이벤트 스트림을 여는 현미경 아이콘)에서 개별 사용자 이벤트 스트림에 액세스할 수 없습니다.

이 제어는 개인정보 보호 정책이 집계 수준에서만 분석을 수행해야 하고 개인 수준의 원시 사용자 이벤트에 대한 액세스를 방지하려는 경우에 특히 중요합니다. 예를 들어 프랑스의 CNIL 요건을 준수하기 위해 동의 없는 분석에 대한 면제는 집계적 통계 측정에만 적용됩니다.

귀하의 Amplitude 팀은 프로젝트 수준에서 이 설정을 관리합니다. 적용하려면 귀하의 Amplitude 팀에 문의하여 프로젝트 구성의 일부로 이를 활성화할 수 있도록 하십시오. RBAC를 사용하여 더 광범위한 사용자 수준 액세스를 제어할 수도 있지만, 사용자 조회 컨트롤은 별개이며 더 구체적으로 개별 이벤트 스트림 액세스를 비활성화합니다.

포트폴리오를 사용하여 주요 보고서를 통합

동의된 프로젝트와 동의되지 않은 프로젝트를 함께 분석하려면 포트폴리오 보기를 사용하십시오.

포트폴리오는 여러 프로젝트를 하나의 교차 프로젝트 뷰로 결합하여 프로젝트 전체에 차트를 작성할 수 있도록 해줍니다. 이 기능은 기본 구현을 하나의 프로젝트로 축소하지 않고 동의 상태 전반에 걸쳐 트래픽이나 활동에 대한 더 넓은 그림을 원할 때 유용합니다.

좋은 패턴은 다음과 같습니다.

• 데이터 수집을 분리하여 유지하십시오.
• 적절한 경우 포트폴리오를 사용하여 두 프로젝트 모두에 걸쳐 리포트하십시오.
• 결합할 수 있는 것과 결합할 수 없는 것에 대한 기대치를 명확하게 설정하십시오.

예를 들어 최상위 이벤트 수는 두 프로젝트 모두에서 유용할 수 있지만 사용자 수준의 메트릭은 더욱 신중해야 합니다. 동의하지 않은 프로젝트가 최소화된 ID를 사용하는 경우, 포트폴리오 보고가 동의한 프로젝트에서 누렸던 것과 동일한 종류의 사용자 연속성을 재현할 것이라고 기대하지 마십시오.

경로 지정 규칙 문서화

개별 프로젝트 패턴을 채택할 경우, 구현자와 분석가 모두에게 명확하게 문서화하십시오. 팀원들이 알아야 할 사항:

• 어떤 이벤트가 어떤 프로젝트로 가는지.
• 트래픽이 비동의 프로젝트에서 동의 프로젝트로 이동할 때.
• 각 프로젝트에서 허용되는 식별자.
• 동의되지 않은 프로젝트에서 어떤 사용자 수준 기능을 제한해야 하는지.
• 단일 소스 프로젝트와 비교하여 어떤 차트가 포트폴리오 뷰를 사용해야 하는지.

이는 개인정보보호에 민감한 측정을 지원하는 동시에 분석 설정을 이해하고 유지 관리할 수 있도록 유지하는 가장 실용적인 방법 중 하나입니다.

방법 3: 동의를 요청하지 말고, 정책이 허용하는 경우 식별자와 데이터 수집을 줄이십시오.

일부 지역 또는 사용 사례에서는 법무팀이 분석 설정에 동의가 필요하지 않다고 결정할 수 있습니다. 그렇다면, 식별자를 제한하고, 저장공간을 줄이고, 전송 내용을 최소화함으로써 이 설정을 더욱 개인정보 보호 친화적으로 만들 수 있습니다.

Amplitude에서 설정하는 방법

정책과 일치하는 스토리지 모드를 선택합니다.

• cookie 표준 브라우저 지속성을 위해.
• localStorage 쿠키 없는 브라우저 저장을 선호하는 경우.
• none 지속적인 ID를 원하지 않는 경우

localStorage를 사용하는 경우, 이 기능은 하위 도메인에 의해 제한된다는 점을 기억하십시오. 한 하위 도메인의 사용자는 동일한 저장된 ID를 다른 하위 도메인으로 자동으로 전달하지 않습니다.

identityStorage: "none"를 사용하는 경우, Amplitude는 페이지 로드(또는 앱 시작)마다 새 device_id를 생성합니다. 이는 로드 간에 재사용할 저장된 ID가 없기 때문입니다.

Amplitude 외부에서 할 일

귀하의 개인정보 보호정책이 귀하가 실제로 하고 있는 일과 일치하는지 확인하십시오. 동의를 요청하지 않는 경우에도 정책은 귀하가 무엇을 수집하는지, 그 이유를 설명하며, 귀하의 모델에 적용되는 경우 사용자가 옵트아웃할 수 있는 방법을 설명해야 합니다.

기본적으로 데이터 최소화

동의가 필요하지 않은 경우에도 데이터 최소화는 여전히 좋은 기본값입니다. 사용 가능한 정보가 아닌 필요한 정보를 수집하십시오.

더 엄격한 제어를 원할 때 프록시를 사용하십시오.

도메인 프록시는 Amplitude에 도달하는 내용을 더 잘 제어하려는 경우 유용합니다. 이를 통해 자체 도메인을 통해 추적 요청을 전송할 수 있으며 데이터를 Amplitude로 전달하기 전에 필터링, 차단, 디버깅, 감사 로깅 및 익명화에 도움이 될 수 있습니다.

이는 IP 주소, 위치 또는 기타 필드와 같은 데이터를 환경 밖으로 내보내기 전에 제거하려는 경우 userId특히 유용합니다. 프록시만이 이 작업을 수행하는 유일한 방법은 아닙니다. 초기화 시에 SDK에서 직접 특정 필드를 제외하거나 억제할 수도 있습니다. 이는 클라이언트측에서 소수의 필드만 제거해야 할 때 더 쉽습니다.

프록시를 구축할 경우, 개발자 운영 팀과 정보 보안 팀을 일찍 참여시켜야 합니다.

데이터에서 불필요한 트래픽을 차단하십시오

데이터도 깨끗할 때 개인 정보 보호 설정이 더 효과적입니다.

봇 트래픽 차단

공개 웹 트래픽을 추적하는 경우 봇 트래픽이 귀하의 지표를 왜곡시킬 수 있습니다. Amplitude를 사용하면 블록 필터를 생성할 수 있으므로 이 데이터가 애초부터 수집되지 않습니다.

설정하려면 다음과 같이 하십시오.

1. 프로젝트의 기본 분기로 이동합니다.
2. 필터를 엽니다.
3. 블록 필터 탭을 엽니다.
4. 블록 필터 작성을 클릭합니다.
5. Bot Traffic을 선택합니다.
6. 필터를 저장합니다.

Amplitude는 IAB/ABC International Spiders and Bots List를 사용하여 User-Agent를 기반으로 봇을 차단합니다.

내부 트래픽 차단

팀이 프로덕션 환경에서 테스트를 수행하는 경우, 직원 트래픽이 측정 기준을 부풀리지 않도록 내부 IP 주소를 차단하십시오. Amplitude Data에서 IP 주소가 차단하려는 주소와 동일한 이벤트에 대한 블록 필터를 생성합니다.

테스트를 위한 별도의 개발 프로젝트를 유지하고 최종 검증을 위해서만 프로덕션을 사용하는 것이 좋습니다.

민감한 데이터를 볼 수 있는 사용자 제한

데이터를 책임감 있게 수집하는 일은 업무의 절반에 불과합니다. 또한 이를 볼 수 있는 사람을 제어해야 합니다.

Amplitude의 데이터 액세스 제어(DAC)를 사용하면 속성을 PII, 수익 또는 중요 항목으로 분류한 다음 그룹별로 해당 분류에 대한 액세스를 허용하거나 거부할 수 있습니다.

DAC 사용 시:

• 제한된 사용자는 제한된 데이터가 포함된 차트, 코호트, 대시보드, 노트북 또는 사용자 세션을 볼 수 없습니다.
• Amplitude는 이벤트 스트림과 사용자 또는 계정 조회에서 분류된 속성을 숨깁니다.
• 제한된 값은 [DAC Restricted]로 표시됩니다.

설정하려면 다음과 같이 하십시오.

1. Amplitude 서포트에 문의하여 귀사의 조직에 DAC를 적용하십시오.
2. Amplitude 데이터에서 보호하려는 속성을 분류합니다.
3. 설정 > 조직 설정 > 그룹에서 그룹을 열고 데이터 액세스 탭에서 액세스를 구성합니다.

중요한 속성 이외의 더 폭넓은 역할 제어를 원할 경우 RBAC를 사용하여 사용자가 각 프로젝트에서 수행할 수 있는 작업을 정의하고 그룹을 통해 해당 역할을 할당하십시오.

리텐션 기간 설정

이벤트 데이터를 영구적으로 보관할 필요가 없다면 리텐션 기간을 설정하십시오.

Amplitude의 TTL(Time to Live)을 사용하면 조직 수준에서 이벤트 리텐션을 정의하고 프로젝트별로 이를 재정의할 수 있습니다.

이를 구성하려면 다음과 같이 하십시오.

1. 조직에 TTL 제어를 아직 활성화하지 않은 경우 Amplitude에 이를 활성화하도록 요청하세요.
2. 조직 설정으로 이동합니다.
3. TTL(Time to Live) 탭을 엽니다.
4. 리텐션 기간을 선택하고 확인하십시오.
5. 일부 프로젝트에 다른 리텐션 정책이 필요한 경우 프로젝트 수준의 재정의를 추가하십시오.

여기서 조심하세요. TTL은 되돌릴 수 없는 데이터 손실을 초래하며, 기존 차트는 리텐션 기간을 벗어난 기간 동안 제로아웃됩니다.

위험도가 높은 데이터 세트에는 TTL을 더 짧게 설정하고 비즈니스 요구가 명확한 경우에만 TTL을 더 길게 설정하는 것이 좋습니다.

삭제 요청 준비

사용자가 자신의 데이터를 삭제해 달라고 요청할 경우, Amplitude와 모든 업스트림 시스템을 모두 포괄하는 프로세스가 필요합니다.

Amplitude의 사용자 개인정보 보호 API를 사용하면 알려진 Amplitude ID 또는 사용자 ID에 대한 삭제 요청을 프로그래밍 방식으로 제출할 수 있습니다.

기본적으로 삭제는 프로젝트 기반으로 수행됩니다. 조직 전체에서 사용자를 삭제하려면 delete_from_org로 설정하십시오true.

실제로 중요한 것은 두 가지입니다.

• 사용자를 삭제해도 해당 사용자의 향후 추적을 차단하지는 않습니다.
• 동일한 사용자 데이터가 귀하의 웨어하우스 또는 다른 수집 소스에 여전히 존재하는 경우, Amplitude는 다음 동기화 시에 다시 수집할 수 있습니다.

따라서 삭제 워크플로우는 다음과 같아야 합니다.

1. 요청을 받습니다.
2. 올바른 사용자 ID를 식별합니다.
3. Amplitude에서 사용자를 삭제합니다.
4. 웨어하우스 또는 전체 동기화된 소스에서 동일한 사용자를 삭제합니다.
5. 감사를 위해 완료를 기록합니다.

시작하기 전에 설정을 확인하십시오.

설정이 라이브로 실행된 후에는 이를 실제 시나리오를 사용하여 테스트하십시오.

최소한 다음을 테스트하십시오.

• 동의하지 않은 방문객
• 동의를 허가하는 방문자.
• 로그인된 사용자입니다.
• 로그아웃한 사용자입니다.
• 데이터가 삭제된 사용자

Amplitude에서는 사용자 조회를 사용하여 특정 사용자에 대한 이벤트 스트림을 검사하고 실제로 어떤 데이터가 수집되었는지 확인합니다.

각 테스트 사례에 대해 다음을 확인하십시오.

• SDK가 초기화되었는지 여부입니다.
• Amplitude 쿠키 또는 스토리지가 생성되었는지 여부.
• 예상된 이벤트가 전송되었는지 여부
• 예상된 식별자가 존재했는지 여부.
• 제한된 데이터가 올바른 사용자에게만 표시되는지 여부

이 단계는 시간을 들일 가치가 있습니다. 대부분의 개인정보 보호 문제는 정책 자체가 아니라 작은 구현 차이에서 비롯됩니다.

권장 배포 순서

간단한 작업 순서를 원한다면 다음을 사용하십시오.

1. 동의 방법을 선택합니다.
2. 어떤 데이터가 허용되는지 결정하십시오.
3. SDK 초기화 및 저장을 구성합니다.
4. 필요한 경우 CMP를 연결합니다.
5. 봇 및 내부 트래픽에 대한 필터를 추가하십시오.
6. 민감한 속성을 분류하고 제한합니다.
7. 데이터 리텐션을 설정합니다.
8. 삭제 워크플로우를 문서화하십시오.
9. 엔드 투 엔드 테스트를 통해 모든 것을 검증하십시오.

이 순서를 사용하면 작업을 관리하기 쉽고 내부 이해 관계자와 외부 감사자에게 설정을 훨씬 쉽게 설명할 수 있습니다.

추가 고려 사항

구현에 따라 쿠키, 스토리지 및 액세스 제어 이상의 것을 구성해야 할 수도 있습니다. 아래 항목은 설치가 완료되었다고 판단하기 전에 검토할 가치가 있습니다.

세션 리플레이

세션 리플레이를 사용하는 경우 이를 핵심 분석 설정과 별도로 검토하십시오. 리플레이는 보다 풍부한 사용자 상호 작용을 캡처할 수 있으므로 자체적인 개인 정보 보호 검토, 마스킹 규칙 및 동의 처리가 필요할 때가 많습니다.

실제로 이것은 다음을 의미합니다.

• Replay가 분석과 동일한 동의 선택 사항에 해당되는지 아니면 별도의 처리가 필요한지를 결정하십시오.
• 배포 전에 마스킹 및 제외 설정을 검토하십시오.
• 귀하의 개인정보 보호정책에 재생 기술의 사용이 정확하게 설명되어 있는지 확인하십시오.

세션 리플레이 문서를 참조하여 자세한 내용을 확인할 수 있습니다.

삭제 요청뿐만 아니라 액세스 요청도 포함됩니다.

많은 개인정보 보호 프로그램은 우선 삭제에 중점을 두지만, 고객은 개인 데이터에 대한 액세스 요청에 응답해야 할 수도 있습니다. 개인정보 보호 요청을 지원한다면 두 가지 모두를 계획하십시오.

삭제 워크플로우의 경우 사용자 개인 정보 보호 API를 사용하십시오. 데이터 액세스 요청도 지원해야 하는 경우 DSAR API 문서를 참조하십시오.

다음을 다루는 하나의 운영 워크플로우를 문서화하는 것이 좋습니다.

• 요청 접수.
• 신원 확인.
• Amplitude에서 액세스 또는 삭제.
• 업스트림 시스템의 정리.
• 감사 로깅.

개인정보 보호정책 및 공개

귀사의 구현 방침과 개인정보 보호 정책은 일치해야 합니다. 분석 데이터를 수집하거나, 세션 리플레이를 사용하거나, 제한된 익명의 측정 흐름에 의존하는 경우, 공개내용을 검토하여 귀하가 수집하는 내용, 수집하는 이유, 사용자가 선택권을 행사할 수 있는 방법을 여전히 설명하고 있는지 확인하십시오.

이는 팀이 시간별 구현 세부 사항을 변경할 때 특히 중요합니다. 개인정보 보호 문제는 종종 도구 자체가 아니라 제품의 기능과 공지사항에 대한 내용 간의 차이로 인해 발생합니다.

호스팅 지역 및 데이터 상주

일부 조직, 특히 유럽의 조직의 경우, 호스팅 지역은 개인정보 보호 결정의 일부입니다. Amplitude는 미국 및 EU 데이터 센터 옵션을 모두 제공하며, 이러한 선택은 내부 검토 프로세스에 영향을 줄 수 있습니다.

데이터 상주가 비즈니스에 중요한 요소라면 호스팅 설정을 조기에 확인하고 내부 요구 사항과 일치하는지 확인하십시오. 데이터 상주 옵션에 대한 자세한 내용을 확인할 수 있습니다.

출시 후 운영상의 주의사항

일부 개인정보 보호 제어는 예상대로 정확히 작동하지만 여전히 팀이 계획해야 할 실질적인 결과를 낳습니다.

몇 가지 중요한 예:

• 사용자를 삭제한다고 해서 Amplitude가 해당 사용자를 다시 추적하는 것을 방지하지는 않습니다.
• 삭제된 데이터가 웨어하우스 또는 동기화된 소스에 여전히 존재하는 경우 Amplitude는 이를 다시 수집할 수 있습니다.
• 리텐션 설정은 기록 데이터를 영구적으로 제거할 수 있으며 이전 차트에 영향을 줄 수 있습니다.
• 주요 계측 또는 태그 관리 변경 사항이 있을 때마다 개인 정보 보호 설정을 테스트하십시오.

좋은 배포가 출시와 함께 끝나는 것은 아닙니다. 특히 SDK 업데이트, 동의 배너 변경, 새로운 이벤트 시작 또는 업스트림 파이프라인 변경 이후에는 주기적으로 설정을 다시 테스트하십시오.

도움을 요청할 때

만약 여러분의 설정에 지역별 법률이 복잡하거나, 여러 동의 범주가 있거나, 민감한 개인 데이터가 있거나, 여러 다운스트림 활성화 도구가 포함되어 있다면, 법무팀, 개인정보 보호팀, 보안 팀을 조기에 참여시켜야 합니다. 처음부터 개인 정보를 보호하기 위해 설정을 설계하는 것이 나중에 개조하는 것보다 훨씬 쉽습니다.

일반적으로 가장 안전한 접근법은 구현을 단순화하고, 필요한 것만 수집하며, 이를 수행해야 할 명확한 비즈니스 및 법적 사례가 있는 경우에만 복잡성을 증가시키는 것입니다.

알려진 사용자를 위한 대안으로서의 서버측 추적

로그인되어 있거나 식별된 사용자의 경우, 서버측 추적은 일부 클라이언트측 동의 제약을 피하는 대안을 제공합니다. 사용자가 인증된 경우, 브라우저 SDK를 완전히 우회하면서 백엔드에서 Amplitude의 HTTP API로 사용자 ID를 직접 전달할 수 있습니다.

많은 관할권에서 인증된 사용자의 서버 측 추적은 ePrivacy Directive 요건을 유발하지 않습니다. ePrivacy는 사용자의 기기에 있는 정보(쿠키, localStorage 등)에 액세스하거나 저장하는 데 적용되며, 서버 측 호출은 기기에 접촉하지 않습니다. 따라서 로그인한 사용자의 경우 서버 측 Amplitude 추적은 일부 지역의 ePrivacy 규칙에 따라 동의를 요구하지 않을 수 있습니다.

중요한 주의 사항:

• 이는 알려진 로그인된 사용자에게만 적용됩니다. 익명 방문자의 경우, 서버가 쿠키 없는 추적 접근법과 같이 해당 식별자를 생성하더라도 페이지 전체의 행동을 추적하기 위해 클라이언트측 식별자가 여전히 필요합니다. 사용자의 기기에 전체 영구 식별자를 저장하거나 액세스하는 즉시 ePrivacy 규칙이 적용됩니다.
• 귀사의 법률팀은 식별된 사용자의 서버측 추적이 귀사의 관할권과 활용 사례에 충분한지 여부를 확인해야 합니다.
• 인증된 사용자 데이터를 서버 측에서 처리하는 것이 귀사의 데이터 처리 계약 및 GDPR 법적 근거에 부합하는지 개인정보 보호팀과 확인하십시오.

Amplitude가 동의하지 않은 사용자를 위해 모델링된 데이터를 생성하지 않는 이유

일부 분석 플랫폼은 예상 행동을 모델링함으로써 동의하지 않은 사용자들이 남긴 격차를 메우고, 동의한 다음 이벤트의 사용자를 기반으로 해당 사용자가 어떤 행동을 했는지를 통계적으로 추론합니다. Amplitude는 이러한 접근법을 사용하지 않습니다. 그 이유는 다음과 같습니다.

• 모델링된 데이터는 일관성이 없으며 해석하기가 어렵습니다. 모델링을 제공하는 플랫폼은 일반적으로 이를 수행하기에 충분한 활동 양이 있을 때만 예측치를 생성합니다. 특정 임계값 이하의 경우 플랫폼은 모델을 전혀 생성하지 않으며 범위는 세그먼트, 기간 및 속성에 따라 균등하지 않습니다. 실제 데이터를 보고 있는 시점과 추정치를 보고 있는 시점을 쉽게 구분할 수 없으며, 데이터 세트 전체에 일관된 분석 규칙을 적용하는 것은 거의 불가능합니다.
• 모델링된 데이터는 쿼리 위치에 따라 다르게 동작합니다. 모델링된 이벤트 데이터를 웨어하우스로 내보내고 거기서 동일한 분석을 실행할 경우, 분석 UI 내부에서 수행한 것과는 다른 결과를 얻을 수 있는 경우가 많습니다. 플랫폼은 일반적으로 수집 시점이 아니라 UI의 쿼리 시점에 이 로직을 적용합니다. 이로 인해 진실의 소스가 분리되어 조정하기가 매우 어려워집니다. 특히 보고나 컴플라이언스를 위해 데이터 웨어하우스 내보내기에 의존하는 팀에게는 더욱 그렇습니다.

Amplitude의 접근 방식은 명확한 동의 범위와 정확한 자사 데이터에 중점을 둡니다. 검증하거나 감사자에게 설명하기 어려운 예측치로 격차를 메우는 것보다 무엇을 측정했는지, 누구를 위해 측정했는지를 정확하게 아는 것이 더 낫습니다. 조직에서 Amplitude와 함께 Google 서비스를 사용하는 경우 해당 도구에 대해 Google 동의 모드를 독립적으로 구성할 수 있습니다. 이는 Amplitude가 데이터를 처리하는 방식에 영향을 주지 않습니다.

개인정보 보호 및 Amplitude AI 기능

최종 추천

가장 안전하고 간단한 기본값을 원한다면 방법 1부터 시작하십시오. 동의 후에만 Amplitude를 초기화하고, 이벤트 스키마를 엄격하게 유지하며, 첫날부터 액세스 제어와 리텐션 규칙을 추가하십시오.

정책에 더 많은 유연성이 허용되는 경우에도 식별자를 줄이고, 필요할 때 프록시를 사용하며, 악성 트래픽을 필터링하고, Amplitude 내부의 민감한 데이터에 대한 액세스를 제한함으로써 설정을 개인정보 보호 친화적으로 유지할 수 있습니다.