구매자의 반복 메시지가 항상 새 문의인 것은 아닙니다. 보고서를 위해 안정적인 문의 번호를 부여하고, 원래 기록을 보존한 채 그 번호에 확인 사항을 연결하세요. 이름이나 주제가 일치한다는 것만으로 두 사람을 합칠 근거가 되지는 않습니다.
집계 단위 정의하기
귀하의 프로세스에서 문의가 무엇을 의미하는지 선택하세요. 예를 들어 팀이 작업에 착수한 특정 과제에 대한 문의입니다. 메시지, 사람, 과제, 주문은 서로 다른 개체입니다. 한 구매자가 동시에 두 개의 독립적인 주문을 논의할 수 있고, 고객 팀의 두 구성원이 하나의 과제에 대해 글을 쓸 수 있습니다.
연결에는 확인된 문의 번호나 다른 업무용 식별자를 사용하세요. 연락처 정보는 필요한 접근 권한이 있는 보호된 시스템에 두고, 분석 예시에는 익명화된 표기를 사용하세요.
다섯 개의 기록: 두 개의 문의와 한 개의 질문
학습용 레지스트리: 기록 A — 새 문의 L1; B — 확인된 보충 사항 L1; C — 새 문의 L2; D — 확인된 보충 사항 L2; E — 이름이 비슷한 메시지, 연결이 확인되지 않음. 결과적으로 두 개의 확인된 문의와 하나의 미분류 메시지가 되며, 자동으로 다섯 개나 세 개의 문의가 되는 것이 아닙니다.
A–E에 대해 원래 행과 별도의 연결 필드를 보존하세요. B와 D에는 통합 근거를 명시하세요. E에는 일반 업무 프로세스에서 확인 질문을 하고, 답변 전에는 추측으로 기록을 합치지 마세요. 확인 후에는 변경 흔적을 남긴 채 결과를 갱신하세요.
구매 규칙을 모든 신호에 적용하지 않기
예를 들어 Google Analytics는 웹 스트림에서 transaction_id를 기준으로 반복 purchase를 제거하는 방법을 한 사용자에 관한 단서와 함께 설명합니다. 이는 구매에 관한 특정 메커니즘이지, 모든 CRM에서 대화를 자동으로 통합하는 것이 아닙니다. 문의에 대해서는 귀하의 규칙을 별도로 정의하고 검증해야 합니다.
보고서 작성 전에 원래 메시지 수, 확인된 문의 수, 미분류 사례 수를 보여주세요. 그러면 중복 감소가 설명되지 않는 수요 감소로 보이지 않고, 팀이 집계를 재현할 수 있습니다.
도식: 1 — 원래 메시지 보존; 2 — 확인된 일치만 연결; 3 — 문의와 불확실한 사례를 별도로 집계.
다른 실용 안내는 Boosted 블로그에서 확인하세요.
출처
Google Analytics: 거래 식별자. 확인일 21월 2026. 실용 예시와 도식은 편집 방법론이며, 예시 숫자는 고객 데이터가 아닙니다.
별도의 완성된 공개 게시물의 경우 조회 조건을 확인할 수 있습니다. 이 서비스는 설명된 작업을 수행하지 않으며 유기적 관심, 신청 또는 판매를 보장하지 않습니다.