추적 링크에 이름과 이메일이 섞이지 않게: URL 분류값 설계

캠페인을 구분하는 주소에 수신자를 넣지 않습니다

뉴스레터에서 누가 들어왔는지 알고 싶어 링크 끝에 이메일을 붙이는 경우가 있습니다. 담당자는 편리하게 구분할 수 있지만, 그 값은 방문자가 보는 주소창과 복사한 링크에 함께 남습니다. 이후 분석 태그가 주소를 수집하면 캠페인 보고서에 필요하지 않은 식별 정보까지 전달할 수 있습니다. 캠페인을 구분하는 일과 특정 사람의 문의를 처리하는 일은 처음부터 별도 흐름으로 설계하는 편이 낫습니다.

Google Analytics의 개인 식별 정보 전송 방지 안내는 페이지 URL과 제목, 사용자 입력, 맞춤 캠페인 매개변수에 PII가 들어가지 않도록 요구합니다. 여기서는 이 제품의 데이터 수집 정책에 맞춰 링크를 만드는 방법을 다룹니다. 특정 값의 법적 분류나 서비스 전체의 법규 준수 여부를 판정하는 글은 아닙니다.

같은 캠페인에는 같은 분류값을 씁니다

가상의 사용 안내 뉴스레터를 생각해 보겠습니다. 발송 채널은 이메일, 캠페인은 가을 가이드, 본문 첫 버튼은 요약 읽기입니다. 이 정도면 어떤 발송물의 어느 위치가 유입을 만들었는지 구분할 수 있습니다. 수신자의 이름, 이메일, 전화번호, 자유 입력 메시지는 이 분류에 필요하지 않습니다. 아래 이메일 주소는 설명용 예시입니다.

분류값은 보고서를 읽을 수 있을 만큼만 구체적으로 정합니다. 담당자가 매번 별명을 입력하게 하면 고객명이나 계약명이 섞일 수 있습니다. 미리 정한 선택 목록으로 발송물과 위치를 고르게 하면 이름 규칙도 일관되게 유지됩니다. 채널·매체·캠페인의 역할은 UTM 링크 기록표와 연결해 관리할 수 있습니다.

기존 주소에서 지우기보다 필요한 값으로 새 링크를 만듭니다

이메일처럼 보이는 문자열만 정규식으로 지우는 방식은 이름이나 자유 입력을 놓치기 쉽습니다. 또한 모든 쿼리를 없애면 페이지 번호, 언어, 상품 선택처럼 화면에 필요한 정보까지 사라질 수 있습니다. 새 캠페인 링크를 만드는 도구라면 목적지와 허용값을 제한한 뒤 필요한 매개변수만 추가하는 방식이 명확합니다.

다음은 목적지 한 개와 발송물 두 개만 지원하는 설명용 코드입니다. 사용자 입력 주소를 세척하는 범용 보안 함수가 아니며, 현재 브라우저의 주소나 개인 정보를 읽지 않습니다. URL API로 주소를 구성하고 선택 목록 밖의 값은 거절합니다.

const campaigns = new Set(["autumn_guide", "winter_guide"]);
const positions = new Set(["body_summary", "footer_guide"]);

function makeGuideLink(campaign, position) {
  if (!campaigns.has(campaign) || !positions.has(position)) {
    throw new Error("목록에 없는 캠페인 또는 위치입니다.");
  }
  const url = new URL("https://example.com/guides/");
  url.searchParams.set("utm_source", "newsletter");
  url.searchParams.set("utm_medium", "email");
  url.searchParams.set("utm_campaign", campaign);
  url.searchParams.set("utm_content", position);
  return url.href;
}

목적지를 늘린다면 승인한 페이지 주소 목록을 따로 둡니다. 코드가 문자열을 올바르게 인코딩한다는 사실은 그 문자열에 개인정보가 없다는 뜻이 아닙니다. URL API는 주소 형식을 다루고, 어떤 값을 허용할지는 서비스가 정해야 합니다.

물음표 뒤를 고쳐도 경로와 제목에 남을 수 있습니다

?email=...을 지운 뒤 /members/이름/처럼 경로에 이름을 넣으면 문제를 옮긴 것에 가깝습니다. 접수 완료 화면의 제목이 ‘홍길동님의 문의가 접수되었습니다’라면 URL에는 이름이 없어도 수집 대상 제목에 포함될 수 있습니다. 화면에 개인화된 문장을 보여주는 결정과 그 값을 분석 이벤트로 보내는 결정은 구분해야 합니다.

문의 완료 이벤트에는 문의 본문 대신 ‘접수 성공’처럼 필요한 상태만 남기는 설계를 검토합니다. 주문 번호나 내부 회원 번호도 이름이 아니라는 이유만으로 자동 허용하지 않습니다. 분석 목적에 필요한지, 다른 데이터와 어떻게 연결되는지, 해당 제품의 규칙에 맞는지 따로 판단해야 합니다. 숫자·난수·해시로 바꾸는 것만으로 모든 사용이 허용되는 것도 아닙니다.

실제 접수 내용을 처리하는 과정은 문의 전송·수신·답변 단계에 남기고, 캠페인 분석에는 꼭 필요한 집계 관계만 전달합니다. 이렇게 하면 링크 규칙을 수정할 때 고객 응대에 필요한 원본까지 무작정 없애는 일을 피할 수 있습니다.

GA4 데이터 가림은 추가 방어이며 링크 제작을 대신하지 않습니다

GA4 데이터 가림 안내에 따르면 웹 데이터 스트림에서 이메일 패턴과 지정한 URL 쿼리 매개변수를 수집 전에 가릴 수 있습니다. 그러나 Measurement Protocol이나 데이터 가져오기로 들어오는 PII를 막는 기능은 아니며 HTTP 헤더도 검사하지 않습니다. ‘설정을 켰다’와 ‘모든 전송 경로가 정리됐다’는 다른 말입니다.

가림 목록에는 실제 사용되는 키를 넣어야 합니다. 예를 들어 링크 제작 도구는 email_address를 사용하지만 설정에는 email만 등록했다면 같은 항목으로 생각해서는 안 됩니다. 먼저 사용하는 주소 형식을 확인하고, GA4의 미리보기에는 가상 값만 넣어 어떤 항목이 처리되는지 살펴봅니다. 실제 고객 주소를 시험 자료로 복사할 필요는 없습니다.

이미 잘못된 링크가 배포됐다면 전송 경로부터 끊습니다

수정 순서는 원본 발송 템플릿, 도착 페이지, 분석 전송을 함께 보는 것입니다. 템플릿만 고치면 이미 보낸 링크에는 이전 값이 남습니다. 주소창에서 값을 지우는 스크립트만 넣어도 그 전에 실행된 태그나 다른 시스템이 이미 받은 값까지 되돌아가지는 않습니다. 어느 시점에 URL이 바뀌고 어느 시점에 수집이 실행되는지 시간 순서로 확인해야 합니다.

설명용 확인은 새 링크 열기, 이전 형식 링크 열기, 완료 화면 이동의 세 경로로 나눌 수 있습니다. 각 경로에서 페이지 주소·제목·이벤트 매개변수에 허용하지 않은 값이 있는지 보고, 발견한 값 자체를 다른 공유 문서에 복사하지 말고 ‘이메일 키가 남음’처럼 종류와 위치를 기록합니다. 이미 수집된 데이터의 처리는 현재 사용 중인 제품의 삭제 절차에서 별도로 다뤄야 합니다.

링크 규칙의 완성도는 정보를 얼마나 많이 붙였는지로 판단하지 않습니다. 발송 담당자가 새 링크를 만들 때 개인 정보를 넣을 필요가 없고, 분석 담당자는 공통 분류값으로 질문에 답할 수 있으며, 문의 담당자는 별도 접수 경로에서 업무를 이어갈 수 있어야 합니다. 세 역할의 자료를 한 URL에 몰아넣지 않는 것이 이 설계의 핵심입니다.