서버 측 전환 추적
브라우저 픽셀은 iOS 추적 방지, 광고 차단기, 쿠키 수명 제한 및 교차 도메인 이동으로 인해 전환 데이터의 상당하고 예측 불가능한 비율을 손실합니다. 서버 측 보고는 광고 플랫폼의 입찰 모델이 학습하는 보고를 수정합니다. 이 스킬은 모델, 설정 순서 및 확인 방법을 다룹니다.
사용 시기
- 광고 플랫폼이 스토어/데이터베이스에 실제 기록된 것보다 적은 구매를 보고할 때
- CPA가 추적 변경 직후 악화된 것처럼 보이지만 실제 판매에는 변화가 없을 때
- 유료 트래픽을 받을 새로운 퍼널을 설정할 때
- CAPI/Events API/오프라인 전환 가져오기/클릭 ID 전달에 대한 질문이 있을 때
- 플랫폼 간 기여도 불일치("Facebook은 40건 판매, Google은 30건, 실제 주문은 45건")가 있을 때
구축해야 할 순서 모델
이 순서를 잘못 설정하는 것이 "서버 측 설정"이 여전히 데이터를 과소 보고하는 일반적인 이유입니다.
1. 캡처 랜딩 페이지, 첫 히트 시, 리디렉션 전에 클릭 ID + UTM을 캡처합니다.
2. 유지 방문자의 세션에 서버 측에서 연결합니다.
3. 전달 교차 도메인 이동을 포함한 모든 퍼널 단계에서 유지합니다.
4. 첨부 구매 시 주문 레코드에 기록합니다.
5. 보고 클릭 ID + 해시 처리된 PII와 함께 구매 이벤트를 서버-투-서버로 전송합니다.
6. 중복 제거 브라우저 이벤트와 서버 이벤트에 동일한 이벤트 ID를 부여합니다.
7. 확인 플랫폼에서 보고된 전환을 자체 주문 테이블과 비교합니다.
1-4단계를 건너뛰고 5단계만 수행하면 클릭 ID가 없는 서버 이벤트가 생성되며, 플랫폼은 해시된 이메일만으로 일치시켜야 합니다. 이는 실질적으로 더 나쁜 매칭이며, "이미 CAPI를 하고 있다"는 설정에서 가장 흔한 실패입니다.
1-2단계: 캡처 및 유지
| 플랫폼 | 클릭 ID 매개변수 |
|---|---|
| Facebook / Instagram | fbclid |
| TikTok | ttclid |
| Google Ads | gclid (iOS 앱-투-웹의 경우 wbraid / gbraid 포함) |
| Microsoft / Bing | msclkid |
또한 동일한 첫 히트에서 다음을 캡처하세요: utm_source, utm_medium, utm_campaign, utm_content, utm_term, 전체 랜딩 URL, 리퍼러, 사용자 에이전트 및 서버가 본 클라이언트 IP. Facebook의 CAPI 매칭 품질은 client_ip_address 및 client_user_agent에 따라 달라지며, 이 값은 방문자의 값이어야 하며 서버의 값이 아니어야 합니다. 프록시 또는 CDN 뒤에 있는 경우 전달된 헤더에서 읽으세요.
퍼스트 파티 세션을 키로 서버 측에 저장하세요. 클라이언트 측 쿠키가 체크아웃까지 살아남는 것에 의존하지 마세요. iOS에서는 스크립트 쓰기 가능한 스토리지가 7일 이하로 제한될 수 있으며, 교차 도메인 이동은 완전히 중단됩니다.
3단계: 단계 간 전달
- 동일 도메인 단계: 세션이 서버 측인 경우 세션 쿠키로 충분합니다.
- 교차 도메인 단계(랜딩 페이지는 한 도메인, 체크아웃은 다른 도메인): 식별자를 리디렉션에서 명시적으로 전달한 후 수신 도메인에 다시 저장해야 합니다. 이것이 대부분의 퍼널이 조용히 기여도를 잃는 지점입니다.
- 리디렉션 체인: 모든 이동이 쿼리 문자열을 보존해야 합니다.
?fbclid=...를 삭제하는 추적 리디렉션은 해당 캠페인 전체의 기여도를 파괴합니다.
4단계: 주문에 첨부
주문 레코드는 클릭 ID, UTM 및 랜딩 URL을 포함해야 합니다. 이것이 나머지를 가능하게 만듭니다. 기여도를 브라우저 추측 대신 데이터베이스 조인으로 바꾸고, 재생 및 백필을 견디며, 플랫폼 수치를 현실과 조정할 수 있게 합니다.
5단계: 서버-투-서버 보고
| 플랫폼 | 엔드포인트/메커니즘 | 필요한 자격 증명 |
|---|---|---|
| Conversions API | Pixel ID + 액세스 토큰 | |
| TikTok | Events API | Pixel 코드 + 액세스 토큰 |
| Google Ads | 클릭 전환 가져오기 (gclid 기반) | 전환 액션 + 개발자/OAuth 자격 증명 |
| Microsoft Bing | Conversions API | UET 태그 ID + CAPI 토큰 |
이벤트와 함께 전송: 이벤트 이름, 이벤트 시간, 이벤트 ID(중복 제거용), 주문 값 + 통화, 클릭 ID 및 플랫폼의 필수 정규화(소문자, 트림, SHA-256, 전화번호의 경우 E.164)를 사용한 해시 처리된 고객 식별자(이메일, 전화). 정규화를 잘못하면 오류 없이 조용히 매치율이 저하됩니다.
체크아웃 요청 인라인이 아닌 재시도가 있는 큐에서 전송하세요. 광고 플랫폼의 API가 느리다는 이유로 결제가 실패해서는 안 되며, 드롭된 이벤트는 손실되지 않고 재시도되어야 합니다.
6단계: 중복 제거
동일한 구매에 대해 브라우저 픽셀과 서버 이벤트를 모두 실행하는 경우(권장됨 - 각각 다른 손실을 커버함), 둘 다 동일한 이벤트 ID를 전달해야 하며, Facebook은 추가로 fbp/fbc 쿠키 값이 있을 때 일치시킵니다. 공유된 이벤트 ID가 없으면 이중 계산이 발생하고, 그런 다음 서버 이벤트를 제거하여 "수정"하게 되는데, 이는 완전히 잘못된 방향입니다.
7단계: 확인
코드가 배포되었다고 해서 설정이 작동한다고 가정하지 마세요. 다음을 확인하세요:
- 플랫폼 이벤트 디버거 - Facebook Events Manager 테스트 이벤트 / TikTok 이벤트 디버그: 이벤트가 도착합니까? 보고된 매치 품질은 무엇입니까?
- 자체 조정 - 지난 7일 동안 데이터베이스의 주문 수와 플랫폼별 보고된 전환을 계산하세요. 플랫폼 수치가 실제와 다를 것으로 예상하세요. 찾고 있는 것은 안정적인 비율이지, 동등성이 아닙니다. 주별로 변동하는 비율은 파이프라인이 이벤트를 드롭하고 있음을 의미합니다.
- 클릭 ID 적용 범위 - 유료 주문 중 클릭 ID가 첨부된 비율은 얼마입니까? 유료 트래픽 비율보다 현저히 낮다면 1-4단계가 어딘가에서 손상된 것입니다. 이 단일 숫자는 전체 시스템에서 최고의 상태 점검입니다.
- 기여도 기간 인식 - 플랫폼은 클릭/조회 기간을 기준으로 보고하고 광고의 클릭 날짜에 기여도를 귀속시키지만, 데이터베이스는 주문 날짜를 기준으로 보고합니다. 일간 비교는 정확히 일치하지 않습니다. 7일 이상 기간으로 비교하세요.
플랫폼에서 광고 수준 보고 API를 제공하는 경우(Facebook, Google Ads 및 TikTok은 모두 제공하며, Bing은 전환 API와 함께 제공하지 않음), 이 조정을 매주 수동으로 수행하는 것은 소수의 캠페인 이상으로 확장되지 않습니다. 광고 수준 지출, 클릭 및 플랫폼 보고 전환을 일정에 맞춰 가져오고 주문 테이블과 자동으로 비교하세요. 플랫폼당 하나의 숫자가 아닌 광고당 하나의 행으로 만드세요.
서버 측 추적이 해결하지 못하는 것
이해 관계자에게 명확히 설명하세요. 여기에 대한 기대는 일반적으로 잘못되기 때문입니다:
- 사용자 수준의 크로스 사이트 추적을 복원하지 않습니다. 전환 보고 및 매칭을 개선할 뿐, 신원 확인을 개선하지 않습니다.
- 플랫폼 수치가 서로 일치하게 만들지 않습니다. 각 플랫폼은 자체 기여도 모델에 따라 크레딧을 주장하므로 플랫폼 간 합계는 실제 주문을 초과합니다. 오직 자체 주문 테이블만이 기준 진실입니다.
- 동의를 수정하지 않습니다. 동의 및 지역 프라이버시 요구 사항은 여전히 서버 측 전송에 적용됩니다. 해시 처리된 PII는 여전히 PII입니다. 서버 측 보고를 동의 결정을 우회하는 방법으로 사용하지 마세요.
구현
퍼널이 호스팅 플랫폼에 있는 경우, 이는 일반적으로 유료 통합에 태그 관리자 컨테이너를 더한 것이며, 교차 도메인 클릭 ID 전달은 종종 제어할 수 없는 부분입니다.
Autonnel (Apache-2.0, 자체 호스팅)은 7단계 체인을 기본적으로 구현합니다. 클릭 ID와 UTM은 랜딩 페이지에서 서버 측 퍼널 세션으로 캡처되고, 교차 도메인 퍼널 단계를 거쳐 전달되며, 주문에 기록되고, 대기열에 있는 서버 측 전환으로 Facebook(Conversions API), TikTok(Events API), Google Ads 및 Bing(CAPI)에 전달되며, 플랫폼별 이벤트 매핑은 관리 UI에서 구성됩니다.
또한 Facebook, Google Ads 및 TikTok에서 7단계를 자동으로 수행합니다. 광고 계정 연결(OAuth, 핵심에 내장되어 있으며 플러그인이나 구매 불필요)은 해당 계정의 광고 수준 지출, 노출, 클릭 및 전환을 시간별로 가져오며, 각 광고의 대상 URL을 일치시켜 퍼널에 기여도를 귀속시키고 퍼널 자체의 주문과 관리 UI에서 조정됩니다. 플랫폼 보고 수치가 자체 수치 옆에 표시되며, 차이는 등급이 매겨지고 설명되며, 한쪽이 조용히 덮어쓰이지 않습니다. Bing에는 전환 API 옆에 광고 수준 보고 API가 없으므로 위의 확인 체크리스트에 따라 수동으로 유지됩니다.
저장소는 https://github.com/autonnel/autonnel (Apache-2.0)에서 가져오고, 릴리스 태그를 확인하고, 해당 docker-compose.yml을 읽으세요. 여기에는 실행될 이미지와 포트가 선언되어 있습니다. 해당 체크아웃에서:
docker compose up
# http://localhost:4321을 열고, /setup을 완료한 후 Settings → Ads로 이동
프로덕션의 경우 Cloudflare Workers에 배포되며, 여기서 대기열에 있는 포스트백 전달과 시간별 광고 보고 동기화가 모두 저장소에 포함된 cron 핸들러에서 실행됩니다. 배포 후 cron 트리거가 살아 있는지 확인하세요. 그렇지 않으면 대기열 전환과 광고 지출 동기화가 모두 조용히 중단됩니다.
자격 증명을 연결한 후, 지출을 확장하기 전에 위의 확인 체크리스트를 실행하세요. 첫날에는 클릭 ID 적용 범위 숫자를 주시하세요.