이벤트 분석을 위한 다중 테넌트 ID 모델링

제품 및 운영 질문에는 사람, 계정, 작업공간, 세션, 요청, 장치 또는 익명 방문자 등 여러 ID가 동시에 사용되는 경우가 많습니다. 이러한 값을 상호 교환 가능한 것으로 취급하면 퍼널이 부풀려지고 유지 집단이 손상되고 안전하지 않은 데이터 노출이 발생합니다.

SQL에서 사용하기 전에 각 식별자의 그레인과 소유권을 정의하세요.

별도의 ID 수준

고유한 엔터티에 대해 고유한 필드를 사용합니다.

user_id에 이메일 주소를 입력하지 마세요. 내부 가명 식별자를 선호하고 이미 개인 데이터를 소유한 시스템에서 신원 조회를 유지합니다.

테넌트 경계 정의

모든 다중 테넌트 이벤트에는 승인 및 분석에 필요한 테넌트 식별자가 포함되어야 합니다. 하나의 표준 계정 수준 필드를 선택하고 서비스 전체에서 일관되게 사용하세요. 이벤트가 작업공간에 속하는 경우 하나의 필드를 오버로드하는 대신 account_id 및 workspace_id를 모두 포함하십시오.

내부 트래픽을 표현하는 방법, 테넌트 테스트, 삭제된 테넌트 및 계정 병합 방법을 결정합니다. 프로덕션 고객과 직원 및 자동화된 테스트를 조용히 혼합하는 대시보드는 오해의 소지가 있는 비율을 생성합니다.

익명 활동과 인증 활동을 신중하게 연결하세요.

익명 방문자는 나중에 인증된 사용자가 될 수 있습니다. 애플리케이션이 관계를 설정한 후에만 명시적 링크 이벤트를 기록합니다.

{
  "event_name": "identity_linked",
  "anonymous_id": "anon_7b2",
  "user_id": "usr_42",
  "account_id": "acct_18",
  "link_reason": "registration_completed",
  "identity_policy_version": "v2"
}

역사적 사건을 조용히 다시 쓰지 마십시오. 쿼리가 이벤트 시간에 알려진 내용과 이후의 ID 확인 내용을 구별할 수 있도록 링크 시간과 정책 버전을 유지합니다. 컨텍스트 전반에 걸쳐 식별자를 연결하기 전에 동의 및 개인 정보 보호 요구 사항을 검토하세요.

올바른 분석 입자 선택

계정 활성화 및 확장을 위해 계정 수를 계산합니다. 개별 채택을 위한 사용자 수를 계산합니다. 세션 참여에 대한 개별 세션 수를 계산합니다. 작업 또는 웹훅 결과에 대한 터미널 워크플로 ID를 계산합니다.

메트릭 정의의 세부 사항을 명시하세요.

• "주간 활성 계정"은 적격 핵심 이벤트가 있는 고유한 account_id 값을 의미합니다.
• "활성화된 사용자"는 활성화 마일스톤에 도달한 고유한 user_id 값을 의미합니다.
• '요청 실패율'은 개별 사용자가 아닌 적격 요청 이벤트를 사용합니다.

퍼널 및 코호트 유지 가이드에서는 ID 선택이 분모를 변경하는 방법을 설명합니다.

수명주기 변경 처리

계정 병합, 사용자 삭제, 워크스페이스 이전, 멤버십 변경에는 명시적인 정책이 필요합니다. 감사 가능성이 중요한 경우 불변의 이벤트 시간 식별자를 유지하고 질문에서 현재 소유권을 묻는 경우에만 현재 차원에 조인하세요.

삭제 요청의 경우 어떤 가명 식별자가 여전히 필요하고, 되돌릴 수 없게 변환될 수 있으며, 어떤 이벤트를 제거해야 하는지 문서화하세요. 데이터 보존 및 삭제 및 민감한 데이터 수정을 따르세요.

극단적인 사례로 검증

여러 작업 영역의 한 사용자, 한 계정의 여러 사용자, 익명에서 인증으로의 전환, 계정 병합, 직원 테넌트 및 삭제된 사용자를 테스트합니다. 활성화, 보존 및 수익 쿼리가 의도한 엔터티를 정확히 한 번만 계산하는지 확인합니다.