서버 사이드 트래킹
서버 사이드 트래킹은 방문자 브라우저의 자바스크립트가 보내게 하는 대신, 내가 통제하는 서버 — 즉 우리 백엔드 — 에서 이벤트를 기록하고 거기서 분석 도구나 광고 플랫폼으로 보내는 방식입니다. 그 숫자가 존재하기 위해 누가 협조해야 하는지가 바뀝니다. 브라우저는 요청을 거절할 자유가 있지만, 우리 서버가 스스로를 거절할 수는 없습니다. 다만 그것만으로 데이터가 더 정확해지지도, 동의 문제가 해결되지도 않습니다. 바뀌는 것은 쓰기가 일어나는 위치이고, 그와 함께 무엇이 여전히 보이는지와 무엇을 이제 직접 짊어져야 하는지가 달라집니다.
무엇이 옮겨가고 무엇을 대가로 치르나
브라우저 사이드 트래킹에서는 방문자의 브라우저가 이벤트를 곧장 공급업체로 보냅니다. 서버 사이드 트래킹에서는 브라우저가 우리 백엔드에 알리거나, 아예 아무 말도 하지 않습니다. 백엔드는 이미 그 일이 일어났음을 알고 있기 때문입니다. 그리고 이벤트를 다음 단계로 보내는 쪽은 백엔드입니다. 같은 이벤트, 다른 발신자이고, 그 발신자가 차이의 전부입니다.
- 얻는 것: 방문자의 기기를 한 번도 떠나지 않는 요청은 확장 프로그램이 없앨 수 없고, 실패한 전송은 재시도할 수 있으며, 보내기 전에 내용을 검증할 수 있고, API 키는 우리 쪽 선 안에 남습니다.
- 잃는 것: 브라우저는 알았지만 우리 데이터베이스는 모르는 모든 것 — 리퍼러, 화면 크기, 어떤 요소가 눌렸는지, 페이지를 얼마나 내렸는지, 그리고 세션을 꿰매던 익명 식별자.
- 어려워지는 것: 시점과 신원. 브라우저는 그 일이 *특정 방문자에게, 특정 페이지에서, 바로 그 순간에* 일어났다는 걸 알았습니다. 우리 백엔드가 아는 건 한 행이 바뀌었다는 사실뿐입니다. 나머지를 복원하는 일이 진짜 작업입니다.
아무도 경고하지 않는 신원 문제
브라우저 이벤트는 맥락을 이미 지고 도착합니다. 어느 페이지인지, 리퍼러가 무엇인지, 익명 식별자가 무엇인지, URL에 어떤 캠페인 라벨이 붙어 있었는지. 서버 이벤트는 우리가 저장해 두기로 기억한 것만 지고 옵니다. 서버로 옮기는 진짜 작업은 여기에 있고, 그것은 전송이 아닙니다. 누군가 착지하는 바로 그 순간에, 오 분 뒤면 사라질 것이므로 우리 데이터베이스로 복사해 둬야 할 것이 무엇인지 정하는 일입니다.
UTM 파라미터와 광고 클릭 식별자가 가장 날카로운 사례입니다. 맨 처음, 정확히 하나의 URL 위에만 존재하기 때문입니다. 가입 시점에 클릭 식별자를 계정에 붙여 저장해 두지 않았다면, 삼 주 뒤에 올리는 전환은 붙을 자리가 없습니다. 애써 지켜낸 숫자가 정작 그것을 만든 목적의 질문에는 더 이상 답하지 못하게 되는 것이죠. 그 질문이 바로 마케팅 어트리뷰션이고, 승부는 전환이 아니라 착지에서 갈립니다.
우리 전환을 서버에서 보내며 배운 것
AgentCeres(agentceres.com의 AI Growth Officer)는 검증된 리드의 전환을 누군가의 브라우저가 아니라 자체 데이터베이스에서 광고 플랫폼으로 올립니다. 키는 그 사람이 처음 착지했을 때 잡아 둔 클릭 식별자입니다. 놀라운 지점은 전송이 아니었습니다. 성공한 HTTP 응답이 영수증은 아니라는 사실이었습니다. 우리 업로드는 200으로 돌아왔지만 그 안의 행들은 거절되고 있었고, 진짜 결과는 나중에 따로 조회한 상태 확인에서만 보였습니다. 처음 손을 뻗은 엔드포인트는 신규 연동에 닫혀 있기까지 했는데, 그것 역시 200은 알려 주지 않았습니다.
형태는 일반화됩니다. 브라우저 쪽에서 잃어버린 이벤트는 특정한 의미에서 시끄러운 실패입니다. 숫자가 그냥 비고, 구멍이 보입니다. 서버 쪽에서는 실패가 우리 로그에 성공으로 기록된 요청이라, 구멍이 사실의 얼굴을 합니다. 서버로 옮기는 모든 것에는 그때의 응답을 믿는 대신 공급업체에게 '실제로 무엇을 저장했느냐'고 묻는 검증 단계가 필요합니다. 이 이야기의 수신 쪽 절반 — 애초에 브라우저 데이터가 얼마나 사라지는지, 그리고 왜 그 결손이 돈을 들여 데려오던 집단에서 가장 컸는지 — 는 우리 PostHog 페이지에 있습니다.
동의를 우회하는 방법이 아니다
서버 사이드 트래킹은 광고 차단기를 이긴다는 점으로 팔리곤 하고, 기계적으로는 실제로 그렇습니다. 그것이 무슨 뜻인지는 솔직하게 말할 필요가 있습니다. 차단기는 선호를 표현한 사람이 직접 설치한 것이고, 쓰기를 우리 서버로 옮긴다고 없던 법적 근거가 생기지도, 데이터가 우리 도메인을 거쳐 다른 곳으로 갔다는 이유만으로 우리 것이 되지도 않습니다.
- 동의가 지배하는 것은 목적이지 전송 경로가 아닙니다. 브라우저가 보낼 때 동의가 필요한 이벤트는 서버가 보낼 때도 동의가 필요합니다.
- 우리 도메인 위의 프록시라도 목적지가 제3자라면 그건 제공입니다. 재분류하지 말고 개인정보 처리방침에 그렇게 적으세요.
- 정직한 범위로도 대개 충분합니다. 작은 스타트업이 서버 쪽에서 실제로 필요로 하는 것 대부분은 가입·요금제·결제 같은 자사 제품 데이터이고, 애초에 브라우저가 보낼 것이 아니었습니다.
FAQ
- 브라우저 사이드보다 정확한가요
- 더 완전해지는 것이지 자동으로 더 정확해지는 것은 아닙니다. 차단되거나 실패하거나 중단된 브라우저 요청이라는 한 부류의 손실은 사라지지만, 다른 손실이 들어옵니다. 서버 이벤트는 저장해 두기로 기억한 것만 알기 때문입니다. 계측이 부실한 서버 쪽 구성은 브라우저 쪽에는 없는 방식으로 자신 있게 틀릴 수 있습니다. 빠진 것처럼 보이지 않기 때문입니다.
- 태그 매니저나 전용 파이프라인이 필요한가요
- 초기 단계 제품 대부분은 필요 없습니다. 가입, 결제, 요금제 변경처럼 우리 백엔드가 이미 아는 이벤트라면, 가장 단순한 서버 사이드 트래킹은 그 처리를 담당하는 코드에서 보내는 호출 한 줄입니다. 서버 사이드 컨테이너와 이벤트 파이프라인은 여러 목적지가 같은 스트림을 필요로 하거나, 물량 자체가 배관을 하나의 업무로 만들 때부터 제값을 합니다.
- 서버로 옮기면 어트리뷰션이 깨지나요
- 식별자를 함께 옮기지 않고 쓰기만 옮기면 깨집니다. 예전에는 쿠키와 리퍼러와 캠페인 라벨을 달고 오던 이벤트가, 이제는 데이터베이스에 있는 것만 달고 옵니다. 그러니 클릭 식별자와 익명 식별자는 착지 시점에 잡아 계정에 붙여 저장해야 합니다. 그렇게 하면 어트리뷰션은 이사를 견디고, 건너뛰면 깨끗하지만 아무 데도 귀속되지 않는 전환만 남습니다.
- 작은 스타트업에도 값어치가 있나요
- 판단이 걸린 숫자라면 그렇고, 프로젝트가 아니라 필드 하나로 끝날 수도 있습니다. 이미 쓰기를 쥐고 있는 곳에 기록하면 됩니다. 나머지는 브라우저 쪽 분석으로 충분합니다. 행동의 윤곽을 잡는 데 강하고, 그 윤곽은 일정 비율의 이벤트 손실을 견디기 때문입니다. 우리가 도달한 규칙은 예산 결정이 얹히는 것은 우리 쪽에 기록하고 나머지는 있던 자리에 둔다는 것입니다.
An AI growth team that runs this for you
AgentCeres is a managed AI marketing team — you approve what ships. 14-day free trial, from $39/month.