서버사이드 트래킹: 정의 및 작동 방식

서버사이드 트래킹은 사용자가 제어하는 서버에서 마케팅 및 분석 이벤트를 수집 및 전송하는 방식으로, 고객 브라우저에서 실행되는 스크립트에 전적으로 의존하여 태그와 픽셀을 발송하는 대신 사용됩니다. 브라우저가 12개의 타사 트래킹 스크립트를 직접 로드하는 대신, 이벤트는 자체 백엔드 또는 서버사이드 컨테이너에서 한 번 캡처된 후 필요한 모든 광고 플랫폼 및 분석 도구로 전달됩니다.

브라우저 전용 트래킹을 대체한 이유#

브라우저 기반 트래킹 픽셀 및 태그는 브라우저가 실제로 타사 JavaScript를 실행하는 데 의존합니다. 이는 광고 차단기, 브라우저 트래킹 방지 기능, 느린 페이지 로드로 인해 중단될 수 있습니다. 서버사이드 설정은 데이터 수집 지점을 브라우저에서 완전히 이동시킵니다. 예를 들어 체크아웃 시스템에서 실제 이벤트가 발생할 때 자체 서버가 이벤트를 기록하고 그곳에서 전달하므로 훨씬 덜 취약합니다.

일반적인 구현 방식#

퍼스트파티 트래킹 도메인은 타사 대신 자체 서브도메인을 통해 태그 요청을 라우팅하므로, 브라우저 수준의 광고 차단기가 트래픽을 차단할 가능성이 낮아집니다. 서버사이드 태그 관리자 컨테이너(Google Tag Manager의 서버사이드 옵션이 가장 일반적인 예)는 이벤트를 수신하여 여러 대상으로 분산시키는 단일 서버 엔드포인트를 제공합니다. 플랫폼별 이벤트 API는 이벤트를 하나의 광고 네트워크 서버로 직접 전송합니다. 제휴 또는 CPA 설정에서 postback URL은 유사한 기능을 수행하여, 전환이 완료될 때 네트워크 서버가 사용자 서버에 직접 알리거나 그 반대의 경우도 가능하게 합니다.

개선되는 점과 개선되지 않는 점#

서버사이드 트래킹은 일반적으로 전환 트래킹의 완전성을 향상시킵니다. 이벤트가 더 이상 온전한 브라우저 세션에 의존하지 않기 때문입니다. 또한 클라이언트사이드에서 실행해야 하는 타사 스크립트가 줄어들기 때문에 페이지 로드 무게를 줄일 수 있습니다. 그러나 그 자체로 여러 채널 간의 어트리뷰션 문제를 해결하지는 않습니다. 잘 기록된 이벤트에도 각 터치포인트가 얼마나 기여했는지 결정하는 모델이 여전히 필요합니다. 서버사이드 트래킹은 이벤트가 존재하도록 보장할 뿐, 누가 기여를 인정받을지 결정하지 않습니다.

설정 시 고려사항#

트래킹을 서버사이드로 이동하는 것은 페이지에 픽셀 스니펫을 삽입하는 것보다 훨씬 더 많은 엔지니어링 작업이 필요합니다. 안정적인 이벤트 파이프라인, 동일한 전환에 대해 클라이언트사이드와 서버사이드에서 기록된 이벤트를 중복 제거하는 방법, 그리고 각 광고 플랫폼이 API를 업데이트함에 따른 지속적인 유지보수가 필요합니다. 대부분의 팀은 가장 가치가 높은 전환 이벤트(완료된 구매)부터 시작하여 모든 태그를 한 번에 마이그레이션하기보다는 점차 확장합니다. 모든 네트워크에서 일관된 클릭 트래킹 식별자를 사용하면 중복 제거 단계가 훨씬 덜 고통스러워집니다.

정확한 트래킹이 가장 중요한 경우#

더 깨끗한 전환 데이터는 트래킹 신뢰도가 다른 여러 광고 네트워크의 성과를 비교할 때 가장 큰 효과를 발휘합니다. 네이티브 픽셀 지원이 약한 네트워크는 실제 트래픽 품질이 낮은 것이 아니라 단순히 트래킹 손실 때문에 대시보드에서 인위적으로 더 나쁘게 보일 수 있습니다. 트래킹에 영향을 받은 비교를 기반으로 예산을 재할당하기 전에 각 네트워크에서 실제로 실행 중인 내용과 기간을 확인하십시오. OpenAdLibrary의 광고 인텔리전스 플랫폼은 경쟁사의 광고 수명 및 네트워크별 크리에이티브 볼륨에 대한 가시성을 제공하여 자체 트래킹 수치와 함께 독립적인 신호를 제공합니다.