왜 오프라인 데이터를 CAPI로 다시 넣어야 하는가

온라인 구매만 CAPI로 잡고 있다면, 메타의 머신러닝은 그 사용자가 매장에서 실제로 구매했는지, 콜센터 상담 후 오프라인으로 계약했는지를 전혀 알지 못합니다. 온라인 광고를 보고 매장으로 유입돼 구매한 고객, 온라인 문의를 남긴 뒤 콜센터 상담으로 실제 계약이 성사된 고객은 광고 성과 리포트상으로는 '전환 없음'으로 잡힙니다. 이 데이터를 CAPI로 다시 넣어주지 않으면, 실제로는 성과를 낸 캠페인이 저성과로 오판돼 예산이 줄어드는 역설이 생깁니다.

CAPI는 온라인 이벤트뿐만 아니라 오프라인 전환(오프라인 구매, CRM 고객 데이터)도 공식적으로 지원합니다. 이를 통해 온오프라인 전환을 통합 추적할 수 있다는 것이 CAPI가 단순 픽셀 보완 도구를 넘어서는 지점입니다. 다만 이 오프라인 전환 지원은 원클릭 설정으로 자동화되지 않으므로, CRM 통합이나 직접 구현 형태의 고급 CAPI 구현이 별도로 필요합니다.

매장 결제·콜센터 데이터를 CAPI 페이로드로 바꾸는 구조

오프라인 데이터를 CAPI로 이식하는 핵심은 "그 고객이 온라인에서 남긴 식별자와 오프라인 거래 기록을 어떻게 연결하느냐"입니다. 매장 결제라면 멤버십 앱이나 포인트 적립 시 수집한 이메일·전화번호를 결제 시스템(POS)이 함께 기록하도록 만들어야 하고, 콜센터 상담이라면 CRM 시스템에 남은 고객 연락처를 상담 완료·계약 성사 상태와 함께 저장해야 합니다. 이 식별자가 있어야 3강에서 다룬 em·ph 파라미터로 CAPI 페이로드를 구성할 수 있습니다.

실무 구조는 보통 야간 배치(batch job) 형태로 짜입니다. 낮 동안 발생한 매장 결제·상담 완료 기록을 CRM DB나 POS 시스템에서 집계해, 매일 밤 특정 시간에 배치 스크립트가 이 기록들을 CAPI 페이로드 형식(event_name을 Purchase나 커스텀 이벤트로, event_time을 실제 거래 발생 시각으로)으로 변환한 뒤 메타 서버로 일괄 전송하는 방식입니다. CAPI는 배치 요청(batch requests)을 지원하므로, 대량의 이벤트를 한 번에 전송해 API 호출 효율성을 높이고 서버 부하를 줄일 수 있습니다.

배치 전송에서도 중복제거 규칙은 그대로 적용된다

오프라인 배치라고 해서 4강에서 다룬 event_id 중복제거 규칙이 면제되는 것은 아닙니다. 배치 요청도 event_id 중복제거 규칙을 따르므로, 배치 내 이벤트 각각도 고유한 event_id를 포함해야 합니다. 매장 거래라면 POS 영수증 번호, 콜센터 상담이라면 CRM 상담 티켓 번호처럼 시스템 내에서 유일한 값을 event_id로 쓰는 것이 안전합니다. 만약 같은 고객이 온라인에서도 별도로 CAPI 이벤트를 발생시킨 적이 있다면(예: 온라인 문의 후 매장 구매), 이 둘은 실제로는 서로 다른 사건이므로 각각 다른 event_id를 갖는 것이 맞습니다 — 중복제거는 "같은 사건의 중복 보고"를 걸러내는 장치이지, "같은 고객의 여러 행동"을 하나로 합치는 장치가 아니라는 점을 구분해야 합니다.

프로토콜 변경 이력도 함께 확인해야 한다

과거에는 오프라인 전환 데이터를 별도의 오프라인 전환 API(Offline Conversions API)로 전송하는 구조가 따로 있었지만, 메타는 이 구(舊) API를 2025년 5월 14일부로 완전히 종료했고 오프라인 전환 기능은 CAPI로 통합됐습니다. 2025년 5월 이전 문서를 참고해 만들어진 레거시 오프라인 연동이 남아있다면, CAPI의 오프라인 이벤트 포맷으로 마이그레이션이 필요한 시점입니다.

데이터 지연을 어디까지 허용할지 미리 정해둔다

야간 배치 구조는 실시간 CAPI 연동과 달리 최대 24시간의 데이터 지연을 전제로 합니다. 이 지연은 오프라인 데이터 특성상 불가피한 경우가 많지만, 매장 프로모션처럼 즉각적인 최적화 반영이 필요한 캠페인에서는 이 지연이 성과 반영 속도를 늦추는 제약이 될 수 있습니다. 배치 주기를 하루 한 번으로 할지, 몇 시간 간격으로 나눌지는 오프라인 매출 규모와 캠페인 성격에 맞춰 사전에 정해두는 것이 좋습니다.