예전엔 픽셀만 깔면 고객이 어디서 왔는지 다 보였어요. 요즘은 데이터가 자꾸 새요. 브라우저가 쿠키를 막기 시작했거든요. 이 변화가 왜 생겼고, 사장님이 지금 뭘 준비해야 하는지 하나씩 짚어볼게요.
몇 년 전만 해도 광고 관리자 하나만 들여다보면 고객이 어느 광고를 보고 들어왔는지 거의 그대로 보였어요. 요즘은 다르죠. 광고 관리자 숫자와 실제 주문 건수가 조금씩 어긋나고, 리타겟팅 광고가 예전만큼 안 붙는다고 느끼시는 사장님도 많으실 거예요. 이건 착각이 아니라 실제로 브라우저 환경이 바뀌고 있기 때문이에요. 사파리와 파이어폭스는 이미 오래전부터 제삼자 쿠키를 차단해왔고, 크롬도 단계적으로 같은 방향으로 움직이고 있어요. 이 글에서는 왜 쿠키 기반 추적이 흔들리고 있는지, 그리고 그 대안으로 퍼스트파티 데이터와 서버사이드 추적이 왜 필요한지 하나씩 풀어드릴게요.
쿠키에는 크게 두 종류가 있어요. 사장님 쇼핑몰 도메인이 직접 심는 퍼스트파티 쿠키와, 광고 플랫폼이나 다른 사이트가 심는 서드파티 쿠키예요. 지금까지 광고 리타겟팅이나 여러 사이트를 넘나드는 추적은 대부분 이 서드파티 쿠키에 의존해왔어요. 고객이 오늘 쇼핑몰을 구경만 하고 나가도, 다음날 다른 뉴스 사이트에서 같은 상품 광고가 따라붙던 게 바로 이 방식이에요. 그런데 사생활 보호 요구가 커지면서 브라우저들이 하나둘 이 방식을 막기 시작했고, 사파리는 이미 몇 년 전부터 사실상 서드파티 쿠키를 차단하고 있어요. 시장 점유율이 가장 큰 크롬도 프라이버시 샌드박스 같은 대체 기술로 옮겨가는 중이라, 사장님이 체감하는 흐름은 앞으로 더 강해질 가능성이 커요.
여기서 헷갈리시면 안 되는 게, 퍼스트파티 쿠키까지 다 사라지는 건 아니라는 점이에요. 사장님 도메인이 직접 발급한 쿠키, 그러니까 로그인 상태를 유지하거나 장바구니를 기억하는 용도는 여전히 살아있어요. 문제가 되는 건 광고 플랫폼이 여러 사이트를 넘나들며 같은 사람을 추적하던 서드파티 방식이에요. 이 차이를 이해하셔야 왜 서버사이드 추적이 해법이 되는지도 자연스럽게 이해가 돼요.
가장 먼저 체감하시는 건 리타겟팅 광고의 정확도예요. 예전엔 상품 상세페이지만 봐도 다음날 그 상품 광고가 따라붙었는데, 이제는 그 연결이 뚝뚝 끊겨요. 광고 플랫폼이 방문자를 다시 찾아내는 능력 자체가 떨어졌기 때문이에요. 두 번째는 기여 분석의 정확도예요. 고객이 광고를 클릭하고 며칠 뒤 다른 기기나 브라우저로 결제하면, 쿠키 기반 추적은 이 둘을 같은 사람으로 인식하지 못하고 각각 다른 신규 유입처럼 잡아버려요.
세 번째는 캠페인 최적화 속도예요. 광고 플랫폼은 전환 데이터를 학습해서 비슷한 고객을 찾아주는데, 추적되는 전환 건수 자체가 줄어들면 학습 속도도 느려지고 결과적으로 광고 효율이 떨어진 것처럼 보여요. 실제로는 광고가 나빠진 게 아니라 데이터가 안 보이는 것뿐인데, 사장님 입장에서는 성과가 나빠졌다고 오해하기 딱 좋은 상황이에요. 이 셋을 합치면 결국 광고비를 쓰고도 정확히 어디서 성과가 나는지 점점 더 불투명해지는 방향으로 가고 있는 거예요. 게다가 이 흐름은 특정 브라우저 한두 개만의 문제가 아니라 전체 시장이 한 방향으로 움직이는 구조적인 변화라서, 시간이 지날수록 체감하는 손실 폭은 오히려 더 커질 가능성이 높아요. 그래서 지금 당장 큰 타격이 없더라도 미리 대비해두시는 게 나중에 훨씬 유리해요.
퍼스트파티 데이터는 쇼핑몰이 고객과 직접 주고받아서 얻은 정보예요. 회원가입 이메일, 주문 이력, 장바구니 데이터, 뉴스레터 구독 정보 같은 것들이 여기 해당돼요. 이 데이터는 서드파티 쿠키처럼 브라우저 정책에 좌우되지 않아요. 고객이 사파리를 쓰든 크롬을 쓰든, 회원가입을 하고 주문을 하면 그 정보는 사장님 서버에 그대로 남거든요. 그래서 앞으로의 광고 추적은 이 퍼스트파티 데이터를 어떻게 활용하느냐가 관건이 될 수밖에 없어요.
실제로 메타나 구글 같은 광고 플랫폼도 이미 이 흐름에 맞춰 퍼스트파티 데이터를 직접 업로드하거나 서버로 연동하는 기능을 강화하고 있어요. 고객 이메일 목록을 해시 처리해서 업로드하는 커스텀 오디언스, 서버에서 직접 전환을 보내는 CAPI 같은 기능이 다 이 흐름의 연장선이에요. 소규모 쇼핑몰이라도 회원 데이터베이스와 주문 이력이 있다면 이미 퍼스트파티 데이터 자산을 갖고 계신 거예요. 문제는 이걸 광고 플랫폼과 제대로 연결하는 인프라가 아직 안 갖춰진 경우가 많다는 점이에요.
서버사이드 추적은 말 그대로 브라우저가 아니라 쇼핑몰 서버가 직접 이벤트를 광고 플랫폼으로 보내는 방식이에요. 고객이 결제를 완료하면 서버가 즉시 그 정보를 정리해서 메타나 구글 서버로 전송하는 구조예요. 브라우저 쿠키가 막히든 안 막히든 이 경로는 영향을 받지 않아요. 왜냐하면 애초에 브라우저를 거치지 않고 서버끼리 통신하기 때문이에요. 이 방식이 지금 각광받는 이유는 단순히 기술 유행이 아니라, 브라우저 정책 변화라는 구조적인 흐름에 대한 근본적인 대응이기 때문이에요.
다만 서버사이드 추적이 모든 문제를 자동으로 해결해주는 건 아니에요. 서버가 보낼 데이터, 즉 퍼스트파티 데이터가 애초에 잘 정리되어 있어야 효과가 나요. 회원 이메일이 뒤죽박죽이거나 주문 데이터와 고객 정보가 따로 놀면, 서버사이드 추적을 켜도 매칭률이 낮게 나와요. 그래서 이 흐름을 준비하는 순서는 기술 도입보다 먼저 내부 데이터를 정리하는 것부터 시작해야 해요.
많은 사장님이 이미 갖고 계신데 활용을 못 하고 있는 자산이 있어요. 회원 이메일 목록, 뉴스레터 구독자, 최근 6개월 구매 고객 리스트 같은 것들이에요. 이런 리스트를 메타 광고 관리자의 커스텀 오디언스로 업로드하면, 서드파티 쿠키 없이도 기존 고객을 다시 찾아 리타겟팅하거나 비슷한 고객을 찾는 유사 타겟팅에 활용할 수 있어요. 실제로 쿠키 기반 리타겟팅보다 이메일 기반 커스텀 오디언스의 매칭 정확도가 더 안정적인 경우도 많아요.
여기에 더해 아임웹이나 카페24의 회원 데이터, 주문 데이터를 광고 플랫폼과 정기적으로 동기화하는 구조를 만들어두면 훨씬 유리해요. 예를 들어 최근 30일 이내 구매 고객은 광고에서 제외하고, 90일 이상 재구매가 없는 휴면 고객에게는 별도 캠페인을 돌리는 식으로 퍼스트파티 데이터를 세분화해서 쓸 수 있어요. 이런 세분화는 서드파티 쿠키가 있던 시절보다 오히려 더 정교한 타겟팅을 가능하게 해주는 경우도 많아요.
거창하게 시작할 필요는 없어요. 가장 먼저 할 일은 지금 쇼핑몰이 갖고 있는 회원 데이터와 주문 데이터가 얼마나 깨끗한지 점검하는 거예요. 이메일 형식이 제각각이거나 중복 회원이 많다면 이 정리부터가 우선이에요. 그다음 아임웹이나 카페24 관리자에서 메타 픽셀과 전환 API를 함께 켜는 설정을 확인하고, 마지막으로 회원 이메일 리스트를 커스텀 오디언스로 업로드해보는 순서로 진행하시면 무리 없이 시작할 수 있어요. 이 순서를 지키면 한 단계씩 진행할 때마다 눈에 보이는 변화를 확인할 수 있어서, 다음 단계로 넘어갈 때 훨씬 자신감이 붙어요.
이 모든 걸 한 번에 다 하려고 하면 지치기 쉬워요. 저도 처음엔 서버사이드 추적이라는 말 자체가 너무 낯설어서 손을 못 대고 있었는데, 회원 이메일 업로드 하나만 먼저 해보고 나서야 감을 잡을 수 있었어요. 작은 것부터 시작해서 하나씩 늘려가는 게 오히려 실수도 적고 결과도 빨리 확인할 수 있는 방법이에요. 특히 처음 몇 주는 완벽하게 세팅하려고 애쓰기보다, 일단 커스텀 오디언스 업로드까지만 끝내놓고 그 이후 반응을 지켜보면서 하나씩 보완해가는 방식이 마음도 편하고 결과도 꾸준히 좋아지는 걸 느끼실 수 있을 거예요.
| 준비 단계 | 구체적으로 할 일 | 난이도 |
|---|---|---|
| 1단계 데이터 점검 | 회원 이메일 형식, 중복 여부 정리 | 쉬움 |
| 2단계 픽셀 설정 확인 | 메타 픽셀 정상 작동 여부 재점검 | 쉬움 |
| 3단계 전환 API 연동 | 아임웹, 카페24 관리자에서 CAPI 활성화 | 중간 |
| 4단계 커스텀 오디언스 업로드 | 회원 이메일 리스트 광고 관리자 업로드 | 쉬움 |
| 5단계 세분화 리스트 구성 | 최근 구매, 휴면 고객 등으로 나누기 | 중간 |
| 6단계 정기 동기화 체계 마련 | 주 1회 이상 데이터 갱신 루틴화 | 중간 |
| 7단계 성과 재점검 | 4주 뒤 매칭률과 리타겟팅 성과 비교 | 쉬움 |