서버사이드 GTM이 필요한 회사와 필요 없는 회사를 가르는 기준

📖 약 3분 읽기

서버사이드 GTM을 도입하면 전환 데이터가 늘어난다는 말을 여러 곳에서 듣게 된다. 동시에 구축 비용과 운영 부담이 커진다는 경고도 함께 따라온다. 두 말은 상황에 따라 모두 맞을 수 있다. 서버사이드 태깅이 효과를 내는 조건과 그렇지 않은 조건이 따로 있기 때문이다. 이 글은 도입을 권하는 글이 아니라 판단 기준을 정리하는 글이다.

서버사이드 태깅이 되돌리는 유실과 되돌리지 못하는 유실

서버사이드 태깅이 해결하는 문제는 분명하다. 브라우저가 추적 방지 기능으로 자바스크립트 기반 태그를 차단하거나 쿠키 저장 기간을 짧게 제한하면, 광고 매체는 전환을 인식하지 못하고 광고주는 실제보다 적은 전환수를 보게 된다. 서버 쪽에서 같은 이벤트를 다시 전송하면 브라우저 제약을 우회해 이 신호를 상당 부분 회복할 수 있다. 이것이 서버사이드 태깅이 존재하는 이유다.

그런데 서버로 옮긴다고 해서 모든 문제가 사라지지는 않는다. 사용자 동의를 받지 않고 수집한 데이터는 서버를 거쳐도 여전히 동의 없이 수집한 데이터다. 이벤트 트리거가 잘못 설계되어 중복으로 발화되거나, 전환 조건 자체가 실제 구매와 다르게 정의되어 있다면 같은 오류가 서버 로그에도 그대로 쌓인다. 서버사이드 GTM은 전송 경로를 바꾸는 장치이지 측정 설계를 대신 고쳐주는 장치가 아니다.

투자 대비 효과를 가르는 네 가지 조건

서버사이드 전환으로 옮겨서 실제로 득을 보는 회사에는 공통된 특징이 있다. 다음 네 가지 가운데 해당하는 항목이 많을수록 도입 검토의 우선순위가 올라간다.

• 월 전환 건수가 일정 규모 이상으로 꾸준히 발생해 표본이 작지 않은 경우
• 광고 예산 가운데 재방문 고객을 대상으로 한 리타게팅 비중이 큰 경우
• 사파리 브라우저와 인앱 브라우저를 통한 유입 비중이 높은 경우
• 카카오, 네이버, 메타 등 여러 매체에 동일한 전환 이벤트를 동시에 전달해야 하는 경우

반대로 이 중 해당하는 항목이 하나도 없거나 전환 자체가 드문 사업이라면, 서버 컨테이너를 세우는 데 드는 시간과 운영 부담에 비해 돌아오는 전환 신호 개선폭이 크지 않다.

도입에 앞서 점검할 순서

서버 컨테이너를 세우기 전에 비용이 들지 않거나 적게 드는 조치부터 순서대로 확인할 필요가 있다.

1. 이벤트 설계를 다시 점검한다. 전환으로 잡는 이벤트가 실제 구매 완료 시점과 정확히 일치하는지 확인한다.
2. 중복 발화 여부를 확인한다. 같은 전환이 새로고침이나 뒤로가기로 인해 두 번 이상 집계되는 구간이 있는지 점검한다.
3. 참조 제외 설정을 점검한다. 결제 대행사 도메인이나 사내 도메인이 유입 경로로 잘못 잡혀 데이터를 왜곡하지 않는지 확인한다.
4. 매체별 전환 API를 개별 적용한다. 서버 컨테이너를 세우지 않고도 메타, 카카오 등 각 매체가 제공하는 전환 API를 매체 단위로 먼저 연결하면 적은 작업으로 일부 유실을 회복할 수 있다.

이 네 단계를 거치고도 매체 보고 전환수와 분석 도구의 전환수 차이가 크게 남는다면, 그 때 서버 컨테이너 도입을 구체적으로 검토할 차례다.

필요한 회사와 필요 없는 회사를 가르는 조건표

서버사이드 GTM 운영에 드는 비용은 정액으로 정해져 있지 않다. 트래픽 규모와 호스팅 방식에 따라 달라지므로, 네 가지 조건에 해당하지 않는 상태에서 비용을 먼저 치르는 선택은 신중할 필요가 있다.

태그맨은 이벤트 설계 점검부터 매체별 전환 API 적용, 서버 컨테이너 도입 여부 판단까지를 진단 항목으로 제공한다.