실제로 쓰는 이름을 수집합니다
이상적인 명명 규칙만 만들지 말고 현재 수집되는 이벤트와 코드의 문자열을 확인합니다. 대소문자, 밑줄, 접두사뿐 아니라 같은 이름이 서로 다른 행동에 쓰이는지도 봅니다. 관리 화면의 오래된 이벤트와 현재도 발생하는 이벤트를 구분해 수정 대상을 정합니다.
업무 의미를 기준으로 묶습니다
가정한 예로 contact_submit과 consultation_complete가 모두 서버 저장 완료를 뜻한다면 통합 후보입니다. 그러나 하나는 버튼 클릭이고 다른 하나는 성공 응답이라면 이름이 비슷해도 단순 통합하면 안 됩니다. 먼저 발생 조건을 바르게 고친 뒤 대표 이름을 정해야 비교 가능한 지표가 됩니다.
승인된 사전을 만듭니다
이벤트명, 정의, 발생 위치, 필수 필드와 책임자를 적습니다. 화면 이름이 바뀌어도 업무 행동의 정의가 같으면 이름을 유지할 수 있는지 판단합니다. 제품에서 실제 사용하지 않는 분류를 미리 수십 개 만들기보다 현재 필요한 행동을 안정적으로 설명하는 사전이 관리하기 쉽습니다.
적용과 확인 순서
- 기존 이름과 새 이름의 대응표를 작성합니다.
- 공통 함수와 화면별 직접 호출을 함께 검색합니다.
- 정상·실패 시나리오에서 예상 이름만 발생하는지 확인합니다.
- 새 이름의 보고서와 이전 기간 비교 규칙을 점검합니다.
명세만 수정하고 태그 관리자의 별도 트리거를 남겨두면 두 이름이 계속 발생할 수 있습니다. 코드를 바꿀 권한과 분석 설정 권한이 다르면 담당별 완료 증거를 분리해 받고 한쪽 작업만으로 통합 완료라고 표시하지 않습니다.
운영 중의 기준
새 이벤트를 추가할 때 기존 사전에서 같은 의미가 있는지 확인하는 절차를 둡니다. 이벤트명에 고객명·캠페인 문구·날짜를 붙여 이름이 끝없이 늘어나지 않게 필요한 분류는 별도 허용값으로 다룹니다. 변경 전후 수치가 갈라지는 기간에는 통합 집계의 계산식을 공개해 감소나 증가를 사업 성과로 오해하지 않게 합니다.
자주 묻는 질문
- 이름을 통일하면 과거 이벤트도 바뀌나요?
- 앞으로 발생하는 코드의 이름을 바꾸는 작업과 과거 보고 데이터를 정리하는 작업은 다릅니다. 기존 데이터를 자동 변경한다고 가정하지 않고 보고서의 매핑과 적용 기간을 별도로 관리합니다.
- 모든 버튼 클릭을 한 이름으로 합쳐도 되나요?
- 분석하려는 행동과 완료 조건이 같을 때 공통 이름과 위치 매개변수를 사용할 수 있습니다. 클릭·접수·계약처럼 다른 단계까지 하나로 합치면 이벤트의 의미가 흐려집니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.