이벤트 이름을 채널별로 나누면 왜 곤란해지나

앱에서는 app_purchase, 웹에서는 web_purchase, 매장에서는 pos_sale로 이름을 지으면 그때는 편합니다. 문제는 세그먼트 조건입니다. "최근 30일 내 구매한 고객"이라는 조건 하나를 만들려면 세 이벤트를 모두 나열해야 하고, 채널이 하나 늘 때마다 기존 세그먼트를 전부 찾아 고쳐야 합니다.

권장 원칙은 행동 단위로 이름을 정하고 채널을 속성으로 넣는 것입니다. purchase라는 이벤트 하나에 channel 속성으로 app, web, offline을 구분해 담는 방식입니다. 이렇게 두면 전체 구매를 볼 때는 조건이 하나로 끝나고, 채널을 나눠 볼 때만 속성 필터를 겁니다. 통합 프로필을 만든다는 CDP의 목적 자체가 채널별로 나뉜 데이터를 사람 단위로 다시 붙이는 것이므로, 이벤트 이름 단계에서 채널을 붙여 놓으면 그 목적과 어긋납니다.

이벤트 이름에 넣으면 안 되는 값은 무엇인가

상품명, 주문번호, 캠페인 이름처럼 값이 계속 바뀌는 항목을 이벤트 이름에 끼워 넣으면 고유한 이벤트 이름이 무한정 늘어납니다. Braze는 고유한 커스텀 이벤트 이름이 2만 개를 넘거나 구매 데이터의 고유 상품명이 2만 개를 넘는 프로필을 차단한다고 문서에 명시합니다. 세션 500만 건 초과도 같은 차단 기준입니다.

이 한도는 정상적인 사용자보다 스키마 설계 실수나 병합 사고를 잡아내는 지표로 유용합니다. 한도에 가까워지는 프로필이 보이면 개별 고객의 문제가 아니라 이벤트 이름 규칙이 잘못됐다는 신호로 읽는 편이 맞습니다. 가변 값은 전부 속성으로 옮기고, 속성 이름 자체도 목록으로 관리해 임의 추가를 막아야 합니다.

이벤트 지연을 어떻게 다뤄야 하나

CDP 사고의 상당수는 값이 틀려서가 아니라 늦게 도착해서 생깁니다. 결제 완료 이벤트가 세그먼트 재평가보다 늦게 들어오면 이미 결제한 고객에게 장바구니 독촉이 나갑니다. 이 문제를 사후에 추적하려면 이벤트에 발생 시각과 함께 시스템에 도착한 시각을 별도로 남겨야 합니다.

두 시각을 함께 보면 채널별 지연 분포를 만들 수 있고, 그 분포를 근거로 시나리오의 대기 시간을 정할 수 있습니다. 지연이 긴 채널이 확인되면 그 채널의 이벤트를 조건으로 쓰는 시나리오에는 여유 시간을 더 두거나, 발송 직전 재조회로 다시 확인하는 단계를 넣습니다. 억제 조건을 배치 동기화에 맡기지 말라는 원칙이 여기서 나옵니다.

브라우저 쪽 수집에서 무엇이 깨지나

웹 이벤트를 브라우저에만 의존하면 식별이 끊깁니다. 사파리의 추적 방지 기능은 자바스크립트로 생성한 퍼스트파티 쿠키의 수명을 최대 7일로 제한하고, 광고 클릭 파라미터가 붙어 유입된 세션에서 생성된 쿠키는 24시간으로 더 짧게 제한합니다. 서버가 발급한 쿠키라도 그 서버가 서드파티를 가리키는 우회 구조로 판정되면 같은 7일 제한을 받습니다.

그래서 웹 이벤트는 두 가지를 함께 설계합니다. 하나는 로그인 시점에 자사 식별자를 확실히 연결하는 것이고, 다른 하나는 서버에서 이벤트를 보내는 경로를 두는 것입니다. 다만 자사 식별자를 GA4 같은 도구에 연결하는 기능은 로그인 시점부터만 연결되고 로그인 전 익명 행동이 자동으로 소급 연결되지는 않으므로, 로그인 트리거가 정확히 심겨 있어야 실제 매칭이 일어납니다.

재적재를 대비한 구조는 어떻게 만드나

파이프라인 장애나 스키마 변경으로 데이터를 다시 적재해야 하는 상황은 반드시 옵니다. 이때 같은 이벤트가 두 번 집계되면 누적 구매 횟수 같은 세그먼트 조건이 통째로 틀어지고, 그 세그먼트로 이미 나간 발송은 되돌릴 수 없습니다.

대비책은 모든 이벤트에 고유 ID를 부여하고 같은 ID가 다시 들어오면 한 번으로 처리하는 멱등 구조입니다. 메타 전환 API나 틱톡 이벤트 API처럼 클라이언트와 서버 신호를 병행 운영하는 구조에서도 이벤트 ID로 중복을 제거하는 것이 공식 권장 방식이며, 내부 파이프라인에도 같은 원리를 적용하면 됩니다. 백필을 실행하기 전에 발송 자동화를 일시 중지하는 절차도 함께 문서에 넣어 둡니다.