AI 마케팅 링크 UTM 검사: 중복·누락을 배포 전에 찾는 법

AI가 만든 캠페인 링크는 배포 전에 UTM 값의 누락과 중복을 검사해야 합니다. 로컬 검사기로 오류를 찾고 수정된 링크가 같은 규칙을 통과하는지 직접 비교했습니다.

Table of Contents

왜 링크 문장보다 캠페인 규칙을 먼저 정해야 하나

뉴스레터와 소셜 게시물을 AI로 작성할 때 본문을 읽는 검수는 익숙하지만, 링크 뒤의 매개변수는 지나치기 쉽습니다. 같은 캠페인을 news, newsletter, Newsletter로 따로 기록하면 보고서를 해석하는 작업이 늘어납니다. 예쁜 문장보다 먼저 유입 출처·매체·캠페인 이름을 정한 표가 필요합니다. 담당자가 링크를 여러 번 수정했다면 기존 쿼리에 새 값을 덧붙여 동일한 키가 두 번 생겼는지도 확인해야 합니다.

이번 실습의 목표는 유입 숫자를 늘리는 것이 아니라 배포할 문자열의 오류를 줄이는 것입니다. 특정 광고 계정이나 GA4 계정에 연결하지 않고, 예제 주소를 브라우저의 URL 객체로 해석했습니다. AI에게는 “링크를 만들어 줘” 대신 “아래 세 이름을 변경하지 말고 한 번씩만 넣어 줘”라고 요청하고, 생성된 결과는 별도의 검사에 넘기는 방식이 적합합니다. 생성과 검증에 같은 답변을 다시 믿는 과정이 들어가지 않게 하는 것이 핵심입니다.

공식 문서와 자체 편집 기준의 차이

Google Analytics의 캠페인 URL 안내는 source·medium·campaign 같은 태그로 유입을 식별하는 방법을 설명합니다. MDN의 URLSearchParams 문서는 같은 이름의 값이 여러 개 있을 수 있고 getAll로 그 목록을 읽을 수 있음을 보여 줍니다. 이 두 근거를 조합해 자체 검사에서는 세 키의 존재, 비어 있지 않은 값, 키당 한 개의 값이라는 조건을 사용했습니다.

세 값이 모두 있어야 한다는 것은 이 글의 팀 운영 기준입니다. 모든 분석 시스템이 모든 상황에서 동일한 세 항목을 강제한다는 뜻은 아닙니다. 자동 태깅을 쓰는 광고 링크라면 이미 쓰는 식별자를 임의로 삭제하거나 UTM으로 덮어쓰지 마세요. 기존 계정의 태깅 정책과 URL 리디렉션 동작을 확인한 뒤 규칙을 정해야 합니다. 원문에 있는 매개변수의 의미와 팀이 선택한 검수 조건을 구분하면 검사 결과를 과장하지 않을 수 있습니다.

직접 실행 결과: 잘못된 링크 1개를 수정했다

검증일은 2026-10-01입니다. 환경은 Windows의 독립 Chromium 브라우저, 화면 크기 1200×675이며 자체 작성한 로컬 검사기를 사용했습니다. 입력값에는 utm_source가 news와 other로 두 번 들어 있고 utm_campaign은 없습니다. 직접 검사 버튼을 누르면 중복 source와 campaign 누락이라는 두 오류가 표시됩니다.

수정 예제에서는 source=news, medium=email, campaign=october를 한 번씩 넣었습니다. 수정 예제 적용 뒤 다시 검사하자 오류 0건과 세 값 확인 메시지가 나왔습니다. 아래 캡처는 실제 입력 화면과 그 결과이고 영상은 수정 버튼과 재검사 과정을 같은 세션에서 기록한 것입니다. 실제 캠페인을 제출하거나 방문자 데이터를 전송하지 않았습니다. 이 관찰로 확인한 범위는 문자열 검사이며 광고 성과나 Analytics 수집 성공은 포함하지 않습니다.

AI 마케팅 링크 UTM 검사: 중복·누락을 배포 전에 찾는 법의 실제 입력 화면 — 2026-10-01, 자체 로컬 실습의 입력값과 검사 시작 화면. 계정과 실제 개인정보를 사용하지 않았다.

UTM 3개 값 각각 1개 확인가 표시된 실제 결과 화면 — 같은 세션에서 수정 예제를 적용하고 직접 검사한 결과: UTM 3개 값 각각 1개 확인.

실제 브라우저 버튼 조작과 결과 변화. 자체 실습이며 외부 제품 사용이나 서버 호출 영상이 아니다.

복사해서 재현할 수 있는 검사 코드

아래 코드를 개발자 도구의 콘솔 또는 별도 JavaScript 파일에서 함수로 정의하세요. 본문에 포함한 함수는 실습 화면에서 실제로 호출한 코드입니다. 페이지 코드를 실행하기 전에 읽고, 예제 주소를 먼저 사용하세요. 반환된 errors 배열이 비어 있는지 확인한 뒤에만 배포할 링크를 승인하는 조건에 연결할 수 있습니다.

핵심은 문자열을 ampersand로 직접 자르는 대신 URL 파서를 사용하는 것입니다. get으로 첫 값만 읽으면 뒤에 남은 중복 값을 놓치므로 getAll을 사용했습니다. 이 함수는 자동으로 값을 수정하지 않습니다. 잘못된 링크를 조용히 고쳐 버리면 어떤 이름이 원래 캠페인 규칙이었는지 알 수 없기 때문입니다. 수정은 담당자가 하고 검사기는 변경 후의 결과를 다시 판단하게 두었습니다.

const check = function(value) {
      const errors = [];
      let u; try { u = new URL(value); } catch { return { errors: ['URL 형식 오류'] }; }
      if (u.protocol !== 'https:') errors.push('HTTPS 링크 필요');
      for (const key of ['utm_source', 'utm_medium', 'utm_campaign']) {
        const values = u.searchParams.getAll(key);
        if (!values.length || !values[0].trim()) errors.push(`${key}: 값 누락`);
        if (values.length > 1) errors.push(`${key}: 중복 값`);
      }
      return { errors, url: u.href };
    };

console.log(check("https://example.com/?utm_source=news&utm_source=other&utm_medium=email"));
console.log(check("https://example.com/?utm_source=news&utm_medium=email&utm_campaign=october"));

한계와 실패 조건: 통과가 측정 성공은 아니다

HTTPS를 요구하므로 개발용 HTTP 주소는 이 규칙에서 실패합니다. 상대 주소도 기준 URL을 지정하지 않았으므로 허용하지 않습니다. 대소문자 통일, 허용 매체 목록, 캠페인 이름 길이는 검사하지 않습니다. 조직에 그런 규칙이 있으면 별도의 오류 항목으로 추가해야 하며 무조건 소문자로 바꾸는 처리로 기존 보고 이름을 훼손하지 않는 편이 좋습니다.

URL 형식이 통과해도 대상 페이지가 404이거나 리디렉션 중 UTM이 사라질 수 있습니다. 동의 설정과 태그 설치, 자동 태깅, 보고 처리 시간도 수집 결과에 영향을 줍니다. 최종 배포 전에는 공개 페이지를 실제로 열고 도착 주소를 확인하며, 권한 있는 담당자가 Analytics의 테스트 흐름을 별도로 확인하세요. 이 검사기의 오류 0건을 전환 추적 완료라고 보고하면 확인한 범위를 넘는 결론이 됩니다.

캠페인 검수 표와 자주 묻는 질문

UTM을 매번 AI가 새로 정해도 되나요? 보고를 묶어야 하는 캠페인이라면 승인된 이름표를 먼저 주는 편이 좋습니다. source와 medium을 바꾼 이유가 있다면 변경 기록을 남겨 이전 자료와 비교할 수 있게 하세요.

중복 키는 첫 값이 맞으면 괜찮나요? 서버와 분석 도구마다 해석이 다를 수 있으므로 중복 상태를 배포 기준으로 인정하지 않는 것이 이 실습의 정책입니다. 링크를 자동 수정하기 전에 담당자가 의도한 값 한 개를 선택해야 합니다.

검사 통과 후에는 무엇을 남기나요? 원본 링크, 수정 링크, 검사 결과와 검사 시점을 같은 검수 행에 저장합니다. 오류가 발견됐을 때 담당자를 추적하기 위한 표보다 다음 배포에서 같은 실수를 재현하고 방지하는 자료로 사용하는 편이 실용적입니다.

검수 사례 표

입력 조건	직접 검사할 기대 결과
source 중복 + campaign 없음	오류 2건
세 키 각 1개	오류 0건
URL이 아닌 문자열	형식 오류
HTTP 주소	HTTPS 규칙 오류

공식 출처와 함께 읽을 글

공식 기준 문서 — 2026-10-01 확인
기술 동작 참고 문서 — 2026-10-01 확인

AI 프롬프트 회귀 테스트 실전에서는 입력을 고정하고 수정 전후 차이를 확인하는 다른 검수 과정을 살펴볼 수 있습니다.