UTM 파라미터 완전 기초: 링크에 꼬리표 다는 법과 흔한 실수 5가지

대상: UTM을 처음 듣는 마케터·운영자  ·  형식: 설명 가이드  ·  2026-07-11

리포트를 열었더니, 페이스북이 세 줄로 쪼개져 있었다

어느 팀에서 실제 있었던 일이다. 지난달 트래픽 리포트를 열었는데, 소셜 채널 한 줄이어야 할 자리에 Facebook과 facebook과 FB, 세 줄이 나란히 앉아 있었다.

이미지: 원래 한 줄이어야 할 채널이 표기가 제각각이라 세 줄로 쪼개진 리포트.

합쳐서 봐야 할 성과가 셋으로 흩어지니 어느 게 진짜 1등 채널인지 한눈에 안 잡혔다. 원인을 추적해보니, 광고 링크를 만들 때마다 담당자가 소스 이름을 자기 방식대로 적어 넣어 대문자·소문자·줄임말이 그렇게 뒤섞여 있었던 거였네.

그 팀은 결국 표기 규칙 문서를 만들었지만, 몇 주 지나면 또 흐트러지곤 했지. 문서는 지키라고 있는 거지, 강제하는 게 아니었으니까. 나중에는 아예 자유 입력을 막고 정해둔 값만 드롭다운으로 고르게 하는 도구까지 만들게 됐다. 그 이야기는 뒤에서 풀겠다.

이 글은 그 사건의 원인이었던 UTM 파라미터가 정확히 무엇이고 어떻게 링크에 붙이고 뭘 조심해야 하는지를 순서대로 다루는데, 처음 듣는 사람도 끝까지 읽으면 오늘 바로 링크에 꼬리표를 달 수 있게 짰다.

링크에 붙이는 택배 송장, UTM

택배 상자를 하나 떠올려보자. 상자 겉면에는 늘 송장이 붙어 있는데, 거기엔 어디서 보냈는지·어떤 방법으로 보냈는지·무슨 이벤트로 발송된 물건인지가 다 적혀 있다.

UTM 파라미터는 정확히 이 송장 역할을 링크에서 한다. 웹페이지 주소(URL) 끝에 물음표(?)와 함께 몇 개의 짧은 값을 덧붙이면, 그 링크를 타고 들어온 방문자가 "어디서, 어떤 경로로, 무슨 캠페인을 통해" 왔는지가 분석 도구에 그대로 찍히는데, 서버를 새로 설정할 필요는 없다. 링크 문자열 자체에 정보를 실어 보내는 방식이라 그렇다.

이 이름의 유래를 따라가면 뜻밖에 옛날 이야기가 나온다. UTM은 Urchin Tracking Module의 줄임말인데, Urchin은 1998년 처음 나온 웹 분석 소프트웨어 회사(Urchin Software Corporation)의 이름이다. 이 회사가 방문자 행동을 추적하려고 URL에 파라미터를 붙이는 방식을 고안했고, 그 체계가 지금 쓰는 UTM으로 이어졌다.

구글이 2005년 4월 Urchin을 인수했고, 같은 해 11월 구글 애널리틱스(Google Analytics)가 출범했다. 인수 금액은 알려진 바로는 3천만 달러 안팎이라는 말이 있는데, 이건 2차 자료에서만 반복되는 숫자라 공식 확인까지는 안 된다. 확실한 건, Urchin이라는 이름의 제품 자체는 그 뒤로도 몇 년 더 따로 팔리다가 2012년 3월 28일에 판매가 종료되고 기능이 구글 애널리틱스로 완전히 흡수됐다는 사실이다.

그러니까 UTM은 특정 회사 제품의 고유 기능이 아니라, 그 회사가 만든 추적 방식이 업계 표준처럼 굳어 살아남은 경우인 셈. 구글 애널리틱스는 물론이고 다른 분석 도구들도 지금까지 같은 규칙의 파라미터를 그대로 읽는다.

이미지: Urchin이라는 분석 소프트웨어의 파라미터 방식이 구글 애널리틱스로 이어졌다.

다섯 칸짜리 송장: 파라미터 해부

택배 송장에도 칸이 나뉘어 있듯, UTM도 정해진 다섯 개의 칸으로 이뤄진다. 구글 공식 문서가 정의한 각 칸의 역할은 다음과 같다.

구글 공식 문서는 "URL에 파라미터를 추가할 때는 항상 utm_source, utm_medium, utm_campaign을 사용해야 한다"고 못박는다. 나머지 두 칸(term·content)은 필요할 때만 채우면 된다.

GA4로 넘어오면서 utm_id(캠페인 식별용, 리포트에 값 자체는 안 보이고 업로드용으로 쓰인다), utm_source_platform(Search Ads 360 같은 구매 플랫폼 표시), utm_creative_format, utm_marketing_tactic이 추가됐다. 다만 뒤의 세 가지는 아직 GA 리포트 화면에 값이 그대로 노출되지는 않는다. 지금 당장은 "이런 확장 칸도 있다" 정도로만 알아두면 된다.

URL 한 줄을 실제로 해부하면

말로만 들으면 감이 안 잡히니, 실제 URL 하나를 칸별로 잘라보자. 필수 3종(진한 남색)과 선택 2종(옅은 테두리)이 어떻게 나란히 붙는지 아래 도해로 보면 된다.

필수 3종의 순서를 헷갈리는 사람이 많은데, 이렇게 외우면 편하다. source는 "어디서"(장소), medium은 "어떻게"(수단), campaign은 "무슨 일로"(사유)다. 택배 송장의 발송지, 배송 방법, 발송 사유 세 칸과 정확히 대응한다.

붙인 꼬리표는 어디서 보나: 세션이냐 첫 사용자냐

1편에서 다룬 세션(방문 한 덩어리)과 사용자(사람 한 명) 개념이 여기서 그대로 쓰인다. UTM 값도 이 두 단위 중 어느 쪽 기준으로 볼지에 따라 리포트가 갈린다.

GA4는 UTM 값을 두 개의 서로 다른 창으로 보여준다. 하나는 세션 소스/매체(Session source/medium)로, 그 세션이 시작될 때 붙어 있던 UTM 값이다. 다른 하나는 첫 사용자 소스/매체(First user source/medium)로, 그 사람이 사이트에 맨 처음 들어왔을 때의 UTM 값인데, 이후 몇 번을 다시 방문해도 이 값은 안 바뀐다.

GA4의 "트래픽 획득(Traffic acquisition)" 리포트는 세션 기준으로 짜여 있고, "사용자 획득(User acquisition)" 리포트는 첫 사용자 기준으로 짜여 있다. 같은 UTM 값인데 두 리포트 숫자가 다르게 보인다면, 이 스코프 차이 때문일 확률이 높지 않을까.

예를 들어 한 사람이 지난달엔 검색으로 처음 들어와 회원가입만 하고, 이번 달엔 이메일 링크를 타고 다시 들어와 결제까지 했다고 하자. 사용자 획득 리포트에는 이 사람의 모든 활동이 "지난달 검색"으로 잡히고, 트래픽 획득 리포트에는 이번 달 결제가 "이메일"로 따로 잡힌다. 어느 쪽이 맞고 틀리고의 문제가 아니라, 질문 자체가 다른 거다. "누가 처음 데려왔나"를 물으면 첫 사용자, "이번 성과가 어디서 났나"를 물으면 세션 기준을 본다.

이미지: 같은 UTM 값도 세션 렌즈로 보느냐, 첫 사용자 렌즈로 보느냐에 따라 숫자가 달라진다.

다섯 가지, 매번 반복되는 실수

UTM 자체는 어렵지 않다. 문제는 항상 붙이는 방식에서 난다. 실무에서 가장 자주 반복되는 다섯 가지를 순서대로 짚는다.

첫째, 대소문자를 섞어 쓴다. 구글 공식 문서가 "utm_source=naver와 utm_source=Naver는 서로 다른 값"이라고 명시한다. 이 한 줄 때문에 facebook, Facebook, FACEBOOK이 리포트에서 각각 다른 행으로 잡히고, 한 채널의 성과가 셋으로 쪼개진다. 앞서 언급한 사건이 정확히 이 실수였다.

둘째, 사이트 내부 링크에 UTM을 단다. UTM은 사이트 바깥에서 안으로 들어오는 링크용이지, 사이트 안의 메뉴나 배너에 쓰라고 만든 게 아니다. 검색으로 들어온 방문자가 사이트 안에서 utm_source=newsletter가 달린 배너를 누르면 원래 세션의 출처가 그 값으로 덮어써지는데, 옛날 방식(Universal Analytics)에서는 아예 세션이 새로 끊기기도 했다. 이 문제를 실측으로 파고든 심화 편에서 더 자세히 다룬다.

셋째, source와 medium의 역할을 혼동한다. source는 "어디서"고 medium은 "어떻게"다. 이 둘을 뒤섞어(예: source에 email, medium에 채널명을 넣는 식) 쓰면 채널 그룹핑 자체가 깨진다.

넷째, 규칙 없이 각자 알아서 짓는다. 팀원마다 표기가 다르면 같은 채널이 여러 줄로 쪼개진다는 건 공식 문서엔 안 나오지만, 실무에서 가장 흔히 겪는 문제다. 앞의 사건도 결국 여기서 시작됐다.

다섯째, 리다이렉트를 거치는 링크를 확인 없이 쓴다. 단축 URL 서비스나 특정 리다이렉트 설정을 거치면 파라미터가 중간에 유실될 수 있다. 모든 리다이렉트가 그런 건 아니지만, 설정에 따라 달라지는 상황 의존적인 문제라 일반화해 단정하긴 어렵다. 안전한 습관은 하나다. 리다이렉트를 거치는 링크는 게시한 뒤 반드시 직접 클릭해서 최종 URL에 파라미터가 그대로 살아있는지 확인하는 것.

실무 컨벤션 만들기: 규칙은 문서가 아니라 도구로 강제된다

앞서 언급한 팀 이야기로 돌아가자. 표기 규칙 문서를 만들고 나서도 몇 주 지나면 다시 흐트러졌는데, 문서는 읽으라고 있는 거지 입력을 막아주진 않기 때문. 사람은 바쁘면 규칙을 잊고 손에 익은 대로 입력하기 마련이다.

그 팀이 찾은 답은 문서를 더 정교하게 다듬는 게 아니라, 아예 자유 입력 자체를 막는 것이었다. source·medium·campaign 각 칸에 "이 값만 쓴다"는 허용값 목록을 미리 정해두고, 새 링크를 만들 때 텍스트를 직접 타이핑하는 대신 정해진 값 중에서 드롭다운으로 고르게 하는 생성 도구를 만든 거다.

이렇게 하면 오타가 날 수 없고 대소문자가 섞일 수도 없는데, 금지 문자(공백, 특수문자, 한글 등)가 애초에 선택지에 없으니 규칙 위반 자체가 물리적으로 불가능해진다. 여기에 생성 이력을 로그로 남겨두면 나중에 "이 링크 누가 언제 만들었나"도 바로 찾을 수 있지.

단, 모든 칸을 드롭다운으로 막으면 오히려 불편해지는 지점이 하나 있다. utm_term(검색 키워드)은 실제 검색어를 그대로 넣어야 의미가 있는 칸이라, 여기만은 자유 입력을 허용하고 나머지 칸(source·medium·campaign)만 표준화하는 예외를 두는 편이 실용적이다. "키워드류 필드는 자유, 나머지는 표준화"라는 원칙으로 기억해두면 된다.

이미지: 문서로 부탁하는 대신, 드롭다운으로 규칙 위반 자체를 막는다.

공짜 도구: 구글 공식 캠페인 URL 빌더

사내 생성 도구까지 만들 여유가 없다면, 구글이 공식으로 제공하는 무료 도구부터 써보는 게 순서. Campaign URL Builder라는 이름으로 웹에 공개돼 있고, GA4용 버전도 따로 있다.

쓰는 순서는 단순하다. 첫째, 랜딩페이지의 전체 URL을 넣는다. 둘째, Campaign Source·Medium·Name(=campaign) 칸을 채우고 필요하면 Term·Content도 채운다. 셋째, 도구가 자동으로 조합해준 최종 URL을 복사해 쓰면 끝.

실무 가이드 여러 곳에서 이 도구가 입력값을 자동으로 소문자로 바꿔준다고 설명하는데, 이 동작을 구글 공식 문서 원문에서 직접 확인하지는 못했다. 도구가 대소문자를 알아서 정리해줄 거라 믿고 아무렇게나 입력하기보다는, 처음 몇 번은 결과 URL을 직접 눈으로 확인하고 쓰는 편이 안전하다.

이미지: 사내 도구가 없어도, 구글 공식 빌더부터 쓰면 된다.

오늘 링크에 꼬리표를 달고, 다음 편에서 새는 곳을 잡는다

여기까지가 UTM의 기본기다. 이제 실제로 쓰는 링크에 하나씩 대보면 된다.

그래도 하나만 챙긴다면, 이것이다.

규칙은 문서로 부탁하지 말고, 도구로 강제해라.

시리즈 안내. 이 글은 "디지털 마케팅 분석 입문" 시리즈 2편이다. 세션·쿠키·이벤트 같은 기초 개념은 1편: 쿠키·세션·이벤트 기초에서, 픽셀 없이 광고 성과를 잡는 응용 기법은 다크 퍼널 추적법에서, UTM이 실제로 어디서 얼마나 새는지 실측한 결과는 심화 편: UTM 추적 실측에서 이어서 다룬다.

근거·출처

• UTM의 유래·Urchin 인수·서비스 종료 시점: Wikipedia, "Urchin (software)"
• UTM 파라미터 5종 공식 정의·대소문자 구분 경고: Google Analytics 고객센터, "[GA4] URL builders"
• 구글 공식 무료 URL 생성 도구: Google, "Campaign URL Builder"
• 세션/사용자 스코프 트래픽 소스 차원: Google Analytics 고객센터, "Traffic-source dimensions"
• 내부 링크 UTM이 세션 출처를 덮어쓰는 메커니즘(구버전 공식 설명): Google Analytics 고객센터, "[UA] Self-Referrals [Legacy]"

Urchin 인수 금액은 2차 자료에서만 반복되는 추정치라 "알려진 바로는" 수준으로 표기했다. ga-dev-tools 빌더의 소문자 자동변환 동작은 실무 가이드의 서술일 뿐 공식 문서로 직접 확인하지 못해 단정하지 않았다. 리다이렉트로 인한 파라미터 유실은 설정에 따라 갈리는 상황 의존적 문제로 다뤘다. 컨벤션·생성 도구 사례는 실무에서 겪은 일반화된 사례이며, 회사명·도구명은 특정하지 않았다.