쿠키리스

쿠키리스란?

쿠키리스가 실제로 바꾸는 것은 광고 소재나 매체 구성이 아니라 광고 계정에 찍히는 숫자의 신뢰도입니다. 사파리와 파이어폭스는 이미 서드파티 쿠키를 기본 차단했고, 크롬도 제한 일정을 미루는 대신 사용자 선택권을 넓히는 쪽으로 방향을 틀었습니다. 그래서 한 사람이 회사 PC에서 자료를 보고 퇴근길 휴대폰으로 다시 들어오면 같은 리드가 서로 다른 두 명으로 집계되고, 광고를 본 뒤 2주 지나 문의한 건은 매체 리포트에서 아예 사라집니다. 검토 기간이 긴 B2B일수록 이 누락 폭이 커집니다.

여기서 뭉뚱그리기 쉬운 두 가지를 갈라야 합니다. 사라지는 것은 광고 네트워크 도메인이 심는 서드파티 쿠키이고, 우리 도메인이 직접 심는 퍼스트파티 쿠키는 그대로 살아 있습니다. 데이터도 셋으로 나뉩니다. 방문·다운로드 기록 같은 퍼스트파티, 고객이 상담 신청서에 직접 적어 준 제로파티, 외부에서 사 온 서드파티입니다. 다만 사파리 환경에서는 스크립트로 심은 퍼스트파티 쿠키도 길어야 7일이면 만료되기 때문에, 서버사이드 태깅·전환 API와 함께 유입경로를 CRM 쪽에서 이어 붙이는 방식이 필요해집니다.

쿠키리스 대응을 태깅 세팅 같은 기술 과제로만 보면 툴 도입에서 끝납니다. 성과를 가르는 것은 동의를 받은 연락처를 얻는 접점이 몇 개인가입니다. 백서·가격표·자가진단처럼 실무자가 이름과 회사명을 적을 이유를 만들고, 수신 동의를 서비스 안내와 마케팅 활용으로 나눠 받아 두어야 합니다. 동의 항목별로 발송 가능한 명단이 갈린다는 점을 CRM 설계 때 반영하지 않으면, 명단은 쌓였는데 보낼 수 없는 상황이 생깁니다.

현장에서 어긋나는 지점은 크게 둘입니다. 하나는 측정 누락을 성과 하락으로 착각해 광고를 줄이는 것입니다. 문의는 그대로인데 리포트만 비어 있는 경우가 많아, 성급히 예산을 깎았다가 두세 달 뒤 파이프라인이 진짜로 마르는 일이 벌어집니다. 다른 하나는 '자사 데이터니까 마음대로 써도 된다'는 오해입니다. 회원가입 때 받은 동의는 서비스 운영용이라 광고성 정보 발송에는 별도 사전 동의가 필요하고, 이를 건너뛰면 수신거부 민원과 과태료로 돌아옵니다.