서버사이드 트래킹

주문 서버가 확인한 결과를 보낼 수 있지만, 서버로 보낸 이벤트도 누락되거나 중복될 수 있습니다. 이벤트 발생 시점, 동의 상태, 식별자 보존, 중복 제거를 설계해야 의미 있는 보고가 됩니다.

서버에서 측정해도 설계가 필요합니다

서버사이드 측정은 주문 서버가 확인한 상태를 보낼 수 있어 버튼 클릭 같은 불완전한 신호를 줄이는 데 도움이 됩니다. 그러나 결제 승인과 최종 주문 확정이 다른 경우에는 어떤 시점을 전환으로 삼는지 정해야 합니다. 취소와 환불을 반영하는 방법도 필요합니다.

브라우저에서 서버까지의 식별자 전달이 끊기면 광고와 연결할 정보가 사라질 수 있습니다. 재시도 요청이 여러 번 발생하면 같은 주문이 중복될 수도 있습니다. 서버 로그와 광고 플랫폼 수신 결과, 실제 주문 데이터의 건수를 비교하며 누락과 중복을 찾아야 합니다.

장애 상황을 포함해 설계합니다

주문 서버가 광고 플랫폼에 이벤트를 보내는 순간 네트워크가 끊길 수 있습니다. 재전송을 지원하되 주문 ID 기준으로 같은 구매가 한 번만 집계되도록 만드세요. 전송 실패 건을 다시 처리한 날짜와 실제 구매 날짜가 다를 수 있으므로 로그에 두 시각을 모두 남기면 보고서 차이를 추적할 수 있습니다.

주문 ORD-1001이 오후 2시에 확정됐지만 전송 응답을 받기 전에 연결이 끊겼다고 해봅시다. 서버는 오후 2시 5분에 같은 주문 이벤트를 다시 보냅니다. 첫 전송이 플랫폼에 도착했는지 모르는 상태이므로, 동일한 주문·이벤트를 식별할 값을 재시도에도 유지하고 실제 주문 한 건과 수신 이벤트를 대조해야 합니다. 어떤 중복 제거 키와 처리 기간을 지원하는지는 연결한 플랫폼의 사양에 맞춰 확인합니다.

장애·변경 상황	기록·처리할 것
전송 도중 네트워크 실패	실패 상태를 남기고 재전송 경로를 마련
같은 주문의 재시도	주문/이벤트 ID로 중복 집계 여부 확인
늦은 재전송	실제 구매 시각과 전송 시각을 각각 기록
구매 취소·환불	원주문과 연결해 성과 반영 기준을 정함

서버 전송에도 개인정보 처리 요건이 적용됩니다. 브라우저 이벤트와 합칠 때는 같은 주문이 두 번 잡히지 않는지 시험합니다.