ttclid를 퍼스트파티 쿠키로 보존하고, 실제 예약 확정 이벤트를 서버 사이드 CAPI(전환 API)로 전송하는 하이브리드 구조가 필요하다.event_id를 공유해 중복 없이 단 1회만 기여도를 기록하는 것이다.틱톡 고 광고를 처음 집행한 담당자들이 공통적으로 겪는 장면이 있다. 광고 대시보드에는 클릭이 찍히고 있고, 플랫폼 내부 예약 DB에는 실제 결제가 들어오고 있는데, 틱톡 광고 관리자 화면의 전환 컬럼은 텅 비어 있다.
이 현상의 원인은 하나다. 틱톡 고는 인앱 브라우저에서 외부 예약 페이지로 넘어가는 딥링크 전환 구간을 거치는데, 이 과정에서 iOS의 앱 추적 투명성(ATT) 정책과 사파리의 지능형 추적 방지(ITP)가 브라우저 쿠키와 클릭 ID 파라미터를 차단하거나 소멸시킨다. 프론트엔드 픽셀은 이 구간을 통과한 이후의 신호를 잡지 못한다.
픽셀은 브라우저가 '허락한' 신호만 본다. 실제 예약 DB는 그보다 훨씬 많은 것을 알고 있다.
문제를 해결하려면 어디서 신호가 끊기는지 먼저 짚어야 한다.
틱톡 고 광고를 클릭한 사용자는 틱톡 인앱 브라우저에서 플랫폼 예약 페이지로 이동한다. 이때 URL에 붙어 있던 ttclid 파라미터가 딥링크 리다이렉트 과정에서 탈락하는 경우가 잦다. 픽셀이 ttclid를 읽지 못하면 이 유입은 '출처 불명'으로 처리된다.
사용자가 앱 추적을 거부하면 IDFA(광고 식별자)가 차단된다. 픽셀은 이 기기의 이벤트를 틱톡 광고 클릭과 연결할 방법을 잃는다. 국내 iOS 사용자 비중이 높은 여행·레저 버티컬에서는 이 손실이 특히 크다.
사파리는 서드파티 쿠키를 즉시 차단하고, 자바스크립트로 생성된 퍼스트파티 쿠키도 최대 7일로 수명을 제한한다. 예약 탐색 후 며칠 뒤 결제를 완료하는 사용자(여행 예약의 전형적인 패턴)는 이 구간에서 기여도가 끊긴다.
해결책은 프론트엔드 SDK(픽셀)와 백엔드 전환 API(CAPI)를 동시에 운영하되, 두 채널이 동일한 예약 이벤트를 '하나'로 인식하게 만드는 것이다. 구조는 세 단계로 나뉜다.
ttclid를 퍼스트파티 쿠키로 즉시 저장사용자가 틱톡 고 광고를 클릭해 예약 페이지에 도달하는 순간, 서버 사이드 혹은 자바스크립트가 URL에서 ttclid 값을 파싱해 퍼스트파티 쿠키에 저장해야 한다. 서드파티가 아닌 자사 도메인 쿠키이므로 ITP의 7일 제한을 우회할 수 있다.
이때 중요한 실무 포인트가 있다. 쿠키 저장을 클라이언트 자바스크립트에만 맡기면 사파리에서 여전히 단축된다. HTTP 응답 헤더의 Set-Cookie로 서버 사이드에서 직접 심으면 수명 제한을 피할 수 있다.
Set-Cookie: ttclid=YOUR_TTCLID_VALUE; Path=/; Max-Age=2592000; SameSite=Lax; Secure결제가 완료되는 순간, 플랫폼 서버는 예약 레코드에 다음 데이터를 함께 기록해야 한다.
ttclidevent_id (예: order_20260707_12345)event_id는 픽셀과 CAPI 양쪽에서 동일하게 사용할 난수 값이다. 틱톡 시스템은 이 값이 일치하는 두 신호를 자동으로 병합(Deduplication)해 1회 전환으로만 집계한다.
서버는 예약 확정 직후 비동기 큐를 통해 아래 구조의 JSON을 틱톡 비즈니스 API 엔드포인트로 전송한다.
{
"pixel_code": "C1234567890PIXEL",
"event": "CompletePurchase",
"event_id": "order_20260707_12345",
"timestamp": "2026-07-07T00:01:00Z",
"context": {
"ad": { "callback": "YOUR_TTCLID_VALUE" },
"user": {
"emails": ["f660ab912ec121d1b1e928a0bb4bc61b15f5ad44d5efdc4e1c92a25e99b8e44a"],
"phones": ["4813494d137e1c258d929aa9bdf11f26f241a63c8de8170d473b642a66e4407b"],
"ip": "192.168.0.1",
"user_agent": "Mozilla/5.0..."
}
},
"properties": {
"value": 150000,
"currency": "KRW",
"contents": [{ "id": "room_deluxe_01", "quantity": 1, "price": 150000 }]
}
}emails와 phones 필드에는 반드시 SHA-256 해시값을 넣어야 한다. 평문 개인정보를 그대로 전송하면 틱톡 보안 정책 위반으로 광고 계정이 정지될 수 있다.
2026년 틱톡 고 출시 당시 익스피디아, 부킹닷컴, 비아터는 최초 파트너로 참여해 인앱 예약 CAPI 연동 테스트를 완료했다. 이들이 공통적으로 적용한 구조는 위에서 설명한 하이브리드 방식과 동일하다.
글로벌 애드테크 데이터에 따르면, 순수 픽셀 단독 운영 시 모바일(iOS 14.5+) 환경에서 예약 유입 데이터의 30~40%가 유실된다. 반면 CAPI 하이브리드 구조를 완성하면 이벤트 매치 품질(EMQ) 점수가 올라가 95% 이상의 전환을 추적·매칭할 수 있다는 것이 업계 기준이다.
중소 플랫폼 입장에서 이 수치는 단순한 측정 정확도 문제가 아니다. 틱톡 알고리즘이 '실제 예약을 완료한 사람'의 데이터를 충분히 학습해야 유사 오디언스 확장과 입찰 최적화가 제대로 작동한다. 신호가 40% 빠진 상태로는 알고리즘 자체가 엉뚱한 사람에게 예산을 쓴다.
비동기 큐 설계는 선택이 아닌 필수다. 여름 성수기에 예약이 몰리면 실시간 S2S API 요청이 서버 부하를 유발한다. 예약 확정 이벤트를 메시지 큐(예: Redis, SQS)에 넣고 백그라운드 워커가 처리하도록 분리해야 한다.
재시도(Retry) 로직을 반드시 넣어라. 틱톡 API 서버가 일시적으로 응답하지 않을 때 이벤트가 소실되면 그 예약의 기여도는 영구적으로 사라진다. 지수 백오프(Exponential Backoff) 방식으로 최소 3회 재시도를 설계해야 한다.
EMQ 점수를 주기적으로 모니터링하라. 틱톡 이벤트 관리자에서 확인할 수 있는 이 점수가 낮다면 전송 중인 식별자 파라미터 중 누락된 항목이 있다는 신호다. ttclid, 이메일, 전화번호, IP, User-Agent 중 하나라도 빠지면 점수가 떨어진다.
페이로드 컨버터 활용을 검토하라. 2026년 틱톡은 메타나 타 플랫폼 규격의 이벤트 데이터를 틱톡 포맷으로 자동 변환하는 페이로드 컨버터 도구를 지원하기 시작했다. 이미 메타 CAPI를 운영 중인 팀이라면 이 도구를 통해 연동 공수를 크게 줄일 수 있다.
Q. 픽셀만 설치하면 안 되나요? CAPI 연동이 꼭 필요한가요?
A. 픽셀은 브라우저가 허용하는 신호만 수집합니다. iOS 기기에서 ATT를 거부한 사용자, 사파리 ITP 환경, 인앱 브라우저 딥링크 전환 구간에서 발생한 예약은 픽셀로 잡히지 않습니다. 여행·레저 예약 플랫폼의 주요 고객층이 iOS 사용자라면 픽셀 단독 운영은 전환 데이터의 30~40%를 포기하는 것과 같습니다.
Q. event_id를 양쪽에 심지 않으면 어떻게 되나요?
A. 픽셀이 ViewContent나 InitiateCheckout을 쏘고, CAPI가 CompletePurchase를 쏘는 구조에서 event_id가 없으면 틱톡 시스템이 두 신호를 같은 예약 건으로 인식하지 못합니다. 중복 집계가 발생하거나 기여도 계산이 틀어질 수 있습니다. 예약 생성 시점에 UUID 형태의 고유 값을 만들어 양쪽에 동일하게 심는 것이 기본입니다.
Q. SHA-256 해싱을 클라이언트(브라우저)에서 해도 되나요?
A. 권장하지 않습니다. 브라우저에서 해싱하면 해싱 전 평문이 네트워크 요청 로그에 남을 수 있습니다. 이메일·전화번호는 서버에서 수집한 즉시 해싱해 DB에 저장하고, 그 해시값만 CAPI 페이로드에 실어 보내는 것이 안전합니다.
Q. 틱톡 고 연동 없이 오가닉 콘텐츠 링크로 유입되는 경우도 이 구조가 적용되나요?
A. 네. 오가닉 예약 태그나 바이오 링크를 통한 유입도 URL에 ttclid가 붙어 있다면 동일한 방식으로 추적할 수 있습니다. 유료 광고와 오가닉 유입 모두 같은 파이프라인으로 처리하면 전체 틱톡 채널 기여도를 통합 관리할 수 있습니다.
Q. 소규모 팀에서 이 연동을 직접 구현하기 어려운데, 어디서부터 시작해야 할까요?
A. 우선순위는 ttclid 서버 사이드 쿠키 저장 → 예약 확정 이벤트 CAPI 전송 → 중복 제거 event_id 삽입 순입니다. 픽셀 최적화는 그 다음입니다. 세 가지 중 첫 번째만 완성해도 유실되던 신호의 상당 부분을 복구할 수 있습니다.
틱톡 고는 '발견에서 예약까지'를 한 화면에서 완성하려는 구조다. 그 가능성을 실제 성과로 연결하려면, 광고 클릭부터 결제 완료까지 신호가 끊기지 않는 측정 인프라가 먼저 갖춰져야 한다.
서드파티 쿠키 없이 광고 기여도를 100% 매칭하는 SDK-서버 통합 구조는 대형 OTA만의 전유물이 아니다. 설계 순서와 우선순위를 알면 중소 플랫폼도 같은 인프라를 구축할 수 있다.
에이달(ADALL)은 여가·숙박 플랫폼의 틱톡 CAPI 연동 설계부터 EMQ 점수 최적화까지 실무 단위로 지원합니다. 현재 측정 구조에서 신호가 어디서 새고 있는지 진단이 필요하다면 아래로 문의해 주세요.
프로젝트 문의는 언제든 환영합니다.
무료 컨설팅 받아보고 싶다면?
무료 컨설팅 신청하기