태그 매니저

광고 채널을 하나 늘리려면 그 채널이 주는 짧은 자바스크립트 조각을 사이트 모든 페이지에 붙여야 했습니다. 붙이는 일 자체는 한 줄이지만 사이트 코드를 고치는 일이라, 마케터는 개발팀에 요청하고 그 요청이 다음 작업 목록에 들어가고 배포가 나가기를 기다렸습니다. 조각 하나 넣는 데 2주가 걸렸습니다.

실제로는 이렇게 굴러갔습니다. 현우가 새 광고 채널의 전환 코드를 붙여 달라고 요청을 올리고, 태오는 이번 주기에 이미 잡힌 일이 있어 다음 주기로 넘깁니다. 광고 채널이 다섯 개면 이 왕복이 다섯 번 일어나고, 그 사이 캠페인은 성과를 재지 못한 채로 돕니다.

태그 매니저는 이 왕복을 한 번으로 줄입니다. 조각을 대신 실어 주는 상자 하나를 사이트에 심어 두고, 그 뒤로는 상자 안에 무엇을 넣을지를 도구 화면에서 정합니다. 사이트 코드를 고치는 일은 처음 한 번으로 끝나고, 그다음부터 조각을 넣고 빼는 일은 배포와 무관해집니다.

추적 코드를 넣고 빼는 일을 개발 배포 주기에서 떼어 냅니다. 사이트에는 컨테이너라고 부르는 상자 하나만 심습니다. 이 상자는 어떤 조각을 언제 실행할지를 도구 서버에서 받아와 대신 실행해 주는 중개자입니다.

상자 안의 설정은 셋으로 이루어집니다.

1. 태그 — 실제로 실행할 코드 조각입니다. 광고 플랫폼의 전환 코드, 분석 도구의 수집 코드가 각각 태그 하나가 됩니다.
2. 트리거 — 그 태그를 언제 실행할지 정한 조건입니다. 모든 페이지가 열릴 때, 가입 완료 화면이 열릴 때, 특정 버튼이 눌릴 때 같은 식으로 고릅니다.
3. 변수 — 태그에 함께 실어 보낼 값입니다. 결제 금액, 요금제 이름, 페이지 주소처럼 도구 쪽에서 나눠 보고 싶은 정보가 여기 들어갑니다.

이 셋을 조립하면 "가입 완료 화면이 열릴 때 광고 플랫폼의 전환 태그를 요금제 이름과 함께 보낸다" 같은 설정 하나가 됩니다. 전환 추적을 붙이는 일, 곧 목표 행동이 일어났는지 광고 플랫폼에 알려 주는 설정이 대개 이런 모양입니다.

배포에서 떼어 낸 대신 안전장치는 도구가 따로 답니다. 발행 전에 미리보기 모드로 내 브라우저에서만 새 설정을 켜서 태그가 실제로 실행되는지 확인하고, 발행할 때마다 버전이 하나 쌓여서 문제가 생기면 이전 버전으로 되돌립니다. 광고 태그가 두 번 실행돼 전환이 두 배로 잡히는 사고가 가장 흔한데, 이때 되돌릴 자리가 있다는 것이 도구를 쓰는 실질적인 이유입니다.

옮겨진 것은 심는 사람일 뿐이고 심는 일 자체는 남습니다. 실제로 시간이 드는 쪽은 도구를 설치하는 30분이 아니라, 무엇을 기록할지 목록으로 정리하고 그 이름을 팀 전체가 같은 뜻으로 쓰게 맞추는 며칠입니다.

같은 일을 하는 길이 셋 더 있고, 셋 다 태그 매니저와 함께 쓰이기도 합니다.

1. 개발팀이 코드에 직접 심기 — 조각을 사이트 코드 안에 그대로 넣습니다. 언제 무엇이 실행되는지가 코드에 남아 추적하기 쉽고 페이지가 가장 가볍습니다. 대신 조각을 하나 바꿀 때마다 배포를 기다립니다.
2. 서버 수집 — 사용자 브라우저가 아니라 우리 서버에서 기록을 만들어 도구로 보냅니다. 광고 차단기나 브라우저의 추적 차단에 걸리지 않아 기록이 덜 빠지고, 결제 금액처럼 틀리면 안 되는 값에 강합니다. 대신 서버 쪽 작업이라 개발 없이는 못 붙이고, 화면에서 벌어지는 일 가운데 서버에 전달되지 않는 것은 잡지 못합니다.
3. 고객 데이터 플랫폼으로 모아 보내기 — 기록을 한 곳에 모아 두고 거기서 여러 도구로 나눠 보냅니다. 도구가 여덟 개쯤 되면 각 도구에 태그를 따로 붙이는 일보다 이쪽이 관리하기 낫습니다. 도구값은 훨씬 비쌉니다.

고르는 기준은 간단합니다. 마케터가 자주 갈아 끼우는 광고 조각은 태그 매니저에, 틀리면 돈이 어긋나는 결제 기록은 서버 수집에 둡니다.

"그 픽셀은 태그 매니저로 붙일게요. 배포 기다릴 필요 없습니다."

개발 작업 없이 오늘 안에 붙일 수 있다는 뜻입니다.

"전환이 두 배로 잡혀요. 태그가 중복 발사되는지 먼저 보세요."

같은 태그가 두 트리거에 걸려 한 번의 행동을 두 번 보내고 있을 가능성을 의심하라는 말입니다.

"태그 매니저에 들어간 게 서른 개인데 누가 왜 넣었는지 아는 사람이 없어요."

이름 규칙과 기록 없이 쌓아 온 설정을 정리해야 한다는 신호입니다.

페이지덱에서는 현우가 태그 매니저를 들고 있고 태오가 처음 컨테이너만 심어 줬습니다. 새 광고 채널을 붙일 때 현우가 태그와 트리거를 만들고 미리보기로 확인한 뒤 발행합니다. 전환 수가 갑자기 두 배로 뛴 날에는 발행 기록을 열어 그날 무엇이 바뀌었는지부터 봅니다.

한 번은 가입 완료 버튼 클릭에 전환 태그를 걸었는데, 민서가 그 버튼을 다른 화면으로 옮기면서 태그가 조용히 멈췄습니다. 오류는 뜨지 않고 전환 수만 줄어서 사흘 뒤에 발견했습니다. 그 뒤로 화면 구조가 바뀌는 작업에는 태그 확인을 같이 넣기로 했습니다.

태그 매니저가 데이터를 모아 준다고 아는 경우가 가장 많습니다. 이름에 관리가 들어가고 화면에서 이벤트 설정을 하니 여기에 숫자가 쌓이는 것처럼 보입니다. 하지만 이 도구는 조각을 대신 실행해 주는 중개자일 뿐이고 숫자는 각 도구로 바로 갑니다. 그래서 여기서는 어제 전환이 몇 건이었는지 볼 수 없습니다. 이 오해를 그대로 두면 분석 화면의 숫자가 틀렸을 때 엉뚱한 자리를 뒤지게 됩니다.

개발팀이 더는 필요하지 않다고 읽는 것도 흔한 오해입니다. 배포를 기다리지 않게 된 경험이 워낙 커서 그렇게 읽힙니다. 그런데 트리거는 화면의 버튼 이름이나 구조에 매달려 있어서 화면이 바뀌면 조용히 끊어지고, 결제 금액이나 요금제처럼 화면에 없는 값은 개발팀이 데이터 레이어라는 자리에 따로 실어 줘야 읽을 수 있습니다. 여기에 쿠키 동의까지 걸립니다. 동의를 받기 전에는 추적 태그를 실행하지 않도록 조건을 걸어야 하는데, 이 판단은 마케터 혼자 정할 일이 아닙니다.