뉴스레터, 세일즈 이메일, 파트너 채널에 하나의 캠페인 문서를 배포합니다. 한 사람은 newsletter, 다른 사람은 email, 또 다른 사람은 e-mail이라고 적습니다. 캠페인 이름도 summer_launch, 2026-summer, launch_aug로 갈립니다. 방문 기록이 남아도 같은 기준으로 묶기 어려운 이유는 데이터가 부족해서가 아니라 이름이 먼저 갈라졌기 때문입니다.
UTM은 URL 뒤에 값을 붙이는 개인 작업이 아닙니다. 같은 유입 맥락을 같은 이름으로 남기고, 예외와 오류를 누가 고칠지 정하는 팀 계약입니다. 채널을 비교하기 전에 네 필드의 역할과 허용 값을 먼저 승인해야 합니다.
네 필드는 서로 다른 질문에 답합니다
source, medium, campaign, content를 한 문장으로 정의하면 담당자마다 다르게 해석할 여지가 줄어듭니다.
| 필드 | 답할 질문 | 팀 convention 예시 |
|---|---|---|
| source | 어디에서 왔는가 | linkedin, newsletter, partner_a |
| medium | 어떤 전달 방식인가 | paid_social, email, partner |
| campaign | 어떤 계획에 속하는가 | 2026_q3_report_launch |
| content | 같은 계획 안에서 어떤 소재·위치인가 | hero_cta, followup_1, speaker_post |
이 값들은 제품이 정한 고정 schema가 아니라 팀이 승인할 convention의 예시입니다. source에 캠페인명을 넣거나 medium에 담당자 이름을 넣기 시작하면 필드가 답해야 할 질문이 바뀝니다. 새 값이 필요할 때는 기존 정의를 먼저 확인합니다.
허용 값은 짧게, 뜻은 문서로 남깁니다
표기 규칙은 단순할수록 검수하기 쉽습니다. 소문자 사용, 공백 대신 밑줄처럼 팀이 지킬 수 있는 규칙을 하나로 정합니다. 하지만 형식만 같다고 의미가 같아지는 것은 아닙니다. social, paid_social, linkedin을 어느 필드에 둘지 뜻까지 적어야 합니다.
Naming sheet에는 허용 값과 함께 설명, 사용 예, 금지할 별칭을 둡니다. newsletter를 source의 표준값으로 정했다면 email_news, news-letter 같은 표현을 금지 값에 기록합니다. 사람의 기억보다 표가 먼저 보이게 해야 같은 오류가 반복되지 않습니다.
Campaign과 content의 경계를 유지합니다
campaign은 일정 기간 함께 운영하고 비교할 계획의 이름입니다. content는 같은 캠페인 안에서 배포 소재나 위치를 구분할 때 씁니다. 제목 문구를 바꿀 때마다 campaign을 새로 만들면 하나의 계획을 묶기 어렵고, 여러 목적의 배포를 같은 campaign 아래 넣으면 구분이 사라집니다.
campaign을 새로 만들 기준을 먼저 적어 두세요. 목표나 운영 기간, 예산 단위처럼 팀이 실제로 계획을 나누는 기준이 바뀌었을 때 새 campaign을 만들고, 같은 계획 안의 소재·CTA·발송 차이는 content로 구분하는 식입니다. 이 기준은 조직의 운영 방식에 맞춰야 합니다.
한 명이 사전을 소유하고, 예외는 만료시킵니다
여러 사람이 값을 제안할 수 있어도 vocabulary를 승인하는 owner는 분명해야 합니다. owner는 모든 URL을 직접 만드는 사람이 아니라, 새 값을 등록하고 중복을 합치며 변경 이력을 남기는 책임자입니다.
파트너가 정해진 파라미터를 요구하거나 과거 시스템과 호환해야 하는 예외가 생길 수 있습니다. 예외에는 요청자, 이유, 적용 범위와 종료일을 남깁니다. 임시 예외를 표준값처럼 계속 쓰지 않으려면 다시 검토할 날짜가 필요합니다.
배포 전에 URL과 문서 목적을 함께 검수합니다
QA는 철자만 확인하는 단계가 아닙니다. 문서 링크가 맞는지, campaign과 content 값이 배포 위치를 정확히 설명하는지, 빈 값이나 금지 값이 없는지 확인합니다. 최종 URL이 실제 문서로 열리는지도 검수합니다.
검수 기록에는 예시 URL, 검수자와 승인 시각을 남깁니다. 생성자와 검수자를 분리할 수 있다면 한 사람이 익숙한 오타를 놓칠 가능성을 줄일 수 있습니다. 중요한 것은 사람이 몇 명인지보다, 오류가 발견됐을 때 어떤 규칙과 URL을 다시 봐야 하는지 추적할 수 있는가입니다.
이미 배포한 오류는 조용히 덮어쓰지 않습니다
오타를 발견해도 과거 기록의 의미가 자동으로 바뀌지는 않습니다. 새 배포부터 교정 값을 사용하고, 이전 값과 새 값의 대응 관계를 correction log에 남깁니다. 보고에서 두 값을 함께 해석했다면 어느 기간에 어떤 mapping을 적용했는지도 표시합니다.
오류를 수정한 사람, 발견 시각, 영향받은 URL과 이후 사용할 표준값을 기록하면 같은 실수가 반복되는지 확인할 수 있습니다. 잘못된 값을 삭제해 흔적을 없애기보다 비교 기준의 변경 이력을 남기는 것이 governance에 가깝습니다.
UTM은 유입 맥락이지 성과의 원인이 아닙니다
문서 방문을 source나 campaign별로 나누면 어떤 배포 경로에서 기록이 발생했는지 비교할 수 있습니다. 그러나 방문 수는 고유한 사람 수와 같지 않을 수 있고, UTM만으로 구매 의도나 매출 기여를 증명할 수도 없습니다. 채널 이름이 정돈되어도 전환의 원인이 자동으로 밝혀지는 것은 아닙니다.
먼저 같은 것을 같은 이름으로 남기는 기반을 만드세요. 필드 정의, 허용·금지 값, owner, 예외 만료일, QA와 correction log가 갖춰지면 팀은 숫자를 보기 전에 그 숫자가 같은 기준으로 만들어졌는지 설명할 수 있습니다.
