광고 CAC가 안 내려가는 팀을 보면 대부분 ‘타게팅/소재’부터 뜯습니다. 그런데 실제로는 그 이전 단계에서 비용이 새요. (1) 유입이 제대로 잡히지 않아 채널 효율을 오판하고, (2) 클릭이 도착하는 랜딩이 준비가 안 돼 전환을 태워 먹습니다. 이 둘은 그로스의 기본 공정인데, 동시에 망가지면 A/B 테스트는 의미를 잃고 CAC는 구조적으로 높아집니다.
dev.to의 실험 사례가 꽤 충격적입니다. 한 달 동안 Google Analytics와 Umami를 같은 사이트에 붙여 비교했더니 GA가 방문자의 약 40%를 놓쳤다고 합니다(‘I ran GA and Umami side by side…’, dev.to). 특히 Hacker News나 개발자 커뮤니티에서 뜬 글일수록 누락이 커졌는데, 이유는 단순합니다. 그 세그먼트는 광고 차단기(uBlock Origin 등)를 기본값처럼 쓰고, GA는 가장 먼저 차단되는 트래커이기 때문이죠.
이게 왜 CAC 이슈냐면, 측정 누락은 “분모가 줄어드는” 문제라서입니다. 유입·전환이 덜 잡히면 채널별 CPA/CAC가 실제보다 비싸 보이고, 유의미한 코호트(예: 개발자 커뮤니티 유입)의 LTV 신호를 과소평가합니다. 결과적으로 예산은 잘못 재배분되고, 성과 좋은 채널을 ‘비효율’로 잘라먹는 의사결정이 나옵니다. 프라이버시 논쟁이 아니라 ‘정확도’가 성장의 전제라는 원문 메시지가 여기서 바로 연결됩니다.
해결 방향은 “측정 스택을 광고/오가닉의 현실에 맞게” 바꾸는 겁니다. Umami처럼 셀프호스팅을 하면 스크립트 요청이 내 도메인에서 나가 차단 확률이 내려가고, 쿠키 없는 경량 스크립트로 속도 부담도 줄일 수 있습니다(원문은 Docker로 반나절 세팅, 월 6달러 수준 서버로 운영 가능하다고 설명). 물론 GA를 완전히 버리라는 얘기가 아니라, 최소한 ‘2개 계측을 병렬로’ 돌려 누락 바이어스를 계량화하라는 제안이 더 실전적입니다. 채널 실험을 하기 전, 측정 오차부터 수치로 고정해야 합니다.
두 번째는 랜딩 품질입니다. 또 다른 dev.to 글에서는 인스타 광고로 500달러를 태웠는데, 문제는 광고가 아니라 랜딩이었다고 합니다(‘Check Your Landing Page Before Running Ads…’, dev.to). OG 이미지 없음(소셜 프리뷰 박살), CTA 불명확(다음 행동 부재), 모바일 4초 로딩(대량 이탈) 같은 기본 결함이 그대로였죠. 그래서 60줄짜리 Node.js 스크립트로 OG 메타, Twitter Card, CTA 개수, 카피 분량, 로딩 타임 등을 자동 점검해 “광고 집행 전” 걸러내는 방식을 제시합니다.
시사점은 명확합니다. CAC를 낮추는 가장 빠른 길은 ‘새 채널 찾기’가 아니라 실험 루프의 손실을 제거하는 겁니다. ① 측정 누락을 줄이면 채널별 효율 판단이 정확해지고(예산 재배분 최적화), ② 랜딩 자동 점검을 붙이면 광고비가 랜딩 결함에 의해 소각되는 확률이 급락합니다. 저는 이를 “채널→랜딩→전환” 파이프라인의 QA라고 봅니다. QA가 없으면 성과는 운이고, QA가 있으면 성과는 시스템이 됩니다.
바로 실행 가능한 다음 단계는 간단합니다. (1) 주요 랜딩 3~5개에 대해 GA + 대체 계측(Umami/Plausible 등) 병렬 운영을 2주만 돌려 ‘누락률’을 채널/디바이스/커뮤니티별로 쪼개세요. (2) 랜딩 점검 스크립트를 CI에 넣고, 로드타임>3초 또는 CTA 0개 같은 조건이면 배포를 실패 처리하세요. (3) 이후에야 광고 실험을 하되, KPI는 CTR보다 LP→Signup(또는 Lead) 전환율을 1차로 두고 CAC를 재계산합니다.
전망적으로는 이 흐름이 더 강해집니다. 광고 차단·프라이버시 규제로 ‘외부 트래커 기반’ 측정은 계속 불안정해질 가능성이 큽니다. 반대로 셀프호스팅/퍼스트파티 측정과 랜딩 자동 QA는 비용 대비 효과가 커서, 작은 팀일수록 레버가 됩니다. CAC는 결국 “더 잘 속이는 크리에이티브”가 아니라, 더 정확하게 측정하고 더 덜 새게 랜딩하는 팀이 깎습니다.