변경 내용을 정확히 적습니다
필드 추가인지, 이름 변경인지, 발생 시점 이동인지 구분합니다. 코드 변경이 작아도 지표의 의미는 크게 바뀔 수 있습니다. 한 줄 조건문으로 실패 접수를 제외하기 시작했다면 이후 감소를 마케팅 성과의 악화로 오해하지 않게 해야 합니다.
호환성 기준
같은 질문에 같은 단위로 답할 수 있는지 확인합니다. 가정한 예로 amount가 월 예상액에서 연간 확정액으로 바뀌면 숫자 자료형이 같아도 서로 다른 값입니다. 기존 이름을 유지해 합계를 섞지 말고 금액 기준과 기간을 명세에 반영합니다.
전환 계획을 세웁니다
기존·신규 구현이 동시에 배포되는 기간과 캐시된 브라우저가 남을 수 있는 상황을 고려합니다. 두 이벤트를 병행할 경우 합산하면 중복된다는 사실을 명시합니다. 새 정의의 수신을 확인하기 위해 실제 사업 행동을 반복 생성하기보다 시험 데이터로 검증합니다.
배포 절차
- 변경 이유와 이전·새 정의를 대응표로 적습니다.
- 소비하는 대시보드와 자동 보고를 찾습니다.
- 새 수집과 보고 계산을 함께 시험합니다.
- 적용일·호환 범위·담당자와 되돌리는 방법을 남깁니다.
분석 코드를 되돌려도 이미 수집한 새로운 정의의 데이터가 과거로 돌아가는 것은 아닙니다. 롤백 후 보고서가 두 정의를 어떻게 구분하는지 계획해야 합니다. 변경 기록은 소스 커밋뿐 아니라 업무 담당자가 찾을 수 있는 지표 사전에도 남깁니다.
완료 기준
전환 기간의 자동 알림과 목표 설정도 확인합니다. 이벤트 이름 변경으로 경보가 멈췄는데 웹 수신만 정상이라며 완료하지 않습니다.
새 이벤트가 보이는 것에서 끝내지 않고 과거 기간과 현재 기간의 비교 화면을 검수합니다. 비교 불가 구간은 그 이유를 표시하고 임의 보정한 숫자는 원본과 구분합니다. 다음 담당자가 언제부터 어떤 정의를 써야 하는지 이해할 수 있어야 버전 관리가 작동하는 상태입니다. 사용하지 않게 된 필드와 이름은 재사용 금지 여부까지 정리해 같은 문제가 반복되지 않게 합니다.
자주 묻는 질문
- 매개변수 하나를 추가해도 새 이름이 필요한가요?
- 기존 의미와 발생 조건이 유지되는 호환 가능한 추가인지 판단합니다. 모든 변경에 새 이름을 만들기보다 어떤 변화가 비교 가능성을 깨는지 규칙을 정하는 것이 중요합니다.
- 완료 조건을 클릭에서 접수 성공으로 바꾸면 같은 추이를 봐도 되나요?
- 지표의 의미가 달라졌으므로 단순한 증감 비교는 오해를 만들 수 있습니다. 적용일을 표시하고 이전 클릭 기준과 새 성공 기준을 구분해 설명합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.