플랫폼 리포트 숫자와 내부 집계가 안 맞을 때, 원인을 좁혀가는 6단계 순서

숫자가 안 맞는 날은 꼭 월요일 아침에 옵니다

저는 광고 대행사에서 여러 브랜드의 인스타그램, 유튜브 계정과 광고 계정을 함께 운영하고 있습니다. 이 일을 오래 하면서 가장 자주 받는 질문이 뭐냐고 하면, 의외로 "왜 성과가 떨어졌냐"보다 "왜 숫자가 안 맞냐"입니다.

광고 관리자에는 구매 120건이 찍혀 있는데 쇼핑몰 주문 관리 화면에는 87건뿐인 상황이요. 반대로 내부 매출은 늘었는데 플랫폼 리포트에서는 전환이 줄어든 경우도 있습니다. 클라이언트는 둘 중 하나는 틀렸다고 생각하고, 실무자는 일단 픽셀이 깨졌다고 의심하면서 태그부터 뜯어봅니다.

그런데 제 경험상 숫자가 어긋나는 원인의 절반 이상은 기술 문제가 아니라 기준 문제였습니다. 그래서 저는 순서를 정해 두고, 위에서부터 하나씩 지워 나갑니다. 오늘은 그 순서를 공유하겠습니다.

0단계: 먼저 '얼마나' 안 맞는지부터 적어 두기

원인을 찾기 전에 차이의 모양부터 기록합니다. 이걸 건너뛰면 나중에 "고쳤더니 좀 나아진 것 같다"는 느낌만 남고, 실제로 무엇이 효과가 있었는지 알 수 없습니다.

• 차이 비율: 플랫폼 기준인지 내부 기준인지 정하고, 몇 % 차이인지
• 방향: 플랫폼이 더 많은지, 내부가 더 많은지
• 시작 시점: 원래 맞았는데 어느 날부터 벌어졌는지, 처음부터 달랐는지
• 범위: 특정 캠페인이나 계정만 그런지, 전체가 그런지

이 네 가지만 적어 둬도 방향이 꽤 잡힙니다. 예를 들어 처음부터 일정 비율로 달랐다면 기준 정의 문제일 가능성이 높고, 어느 날 갑자기 벌어졌다면 설정 변경이나 추적 오류 쪽을 봐야 합니다.

1단계: '같은 것'을 세고 있는지 확인하기

가장 먼저 의심해야 할 건 두 숫자가 정말 같은 대상을 세고 있느냐입니다. 의외로 여기서 대부분 풀립니다.

특히 취소·반품 반영 여부와 금액 기준 차이가 큽니다. 플랫폼은 결제 순간에 이벤트를 받고 끝이지만, 내부 시스템은 취소와 부분 환불을 계속 반영합니다. 그러니 주간 리포트는 비슷하다가 월말로 갈수록 차이가 벌어지는 패턴이 나옵니다.

저는 이 단계에서 클라이언트와 "우리 보고서의 구매는 무엇인가"를 한 줄로 정의하고 리포트 상단에 고정합니다. 이것만 해도 매달 반복되던 해명이 확 줄었습니다.

2단계: 시간대와 날짜 경계 맞추기

두 번째는 시간입니다. 광고 계정의 시간대와 쇼핑몰 관리자의 시간대가 다르면 날짜 경계가 어긋납니다. 하루 단위로 보면 차이가 크고, 한 달로 묶으면 오히려 비슷해지는 경우가 이 유형입니다.

확인할 것은 세 가지입니다.

1. 광고 계정의 리포트 시간대

2. 내부 시스템(쇼핑몰, CRM, 정산 시트)의 시간대

3. 날짜 기준이 '주문일'인지 '결제일'인지 '입금 확인일'인지

무통장 입금이나 후불 결제가 섞인 브랜드는 3번 때문에 하루에서 사흘까지 밀리기도 합니다. 이럴 땐 일 단위 비교를 멈추고 주 단위로 묶어서 비교하는 게 현실적입니다.

3단계: 기여 기간과 기여 방식 이해하기

세 번째가 실무자들이 가장 헷갈려하는 부분입니다. 플랫폼 리포트는 '광고를 본 사람, 클릭한 사람이 일정 기간 안에 전환했다'는 기준으로 숫자를 잡습니다. 반면 내부 집계는 보통 마지막 유입 경로 기준이거나 아예 경로 구분이 없습니다.

• 조회 후 전환이 포함되어 있으면 플랫폼 숫자가 내부보다 크게 나옵니다.
• 여러 플랫폼에 동시에 광고하면 각 플랫폼이 같은 구매를 자기 성과로 가져갑니다. 플랫폼별 전환을 다 더하면 실제 주문 수보다 많아지는 이유입니다.
• 기여 기간 설정을 바꾸면 과거 데이터도 다르게 보일 수 있으니 변경 시점을 꼭 기록해야 합니다.

저는 여러 채널을 동시에 운영하는 브랜드의 경우 "플랫폼 숫자는 채널 안에서의 상대 비교용, 실제 매출 판단은 내부 숫자"로 역할을 나눠서 보고합니다. 둘을 같은 표에 넣고 합계를 내는 순간 혼란이 시작됩니다.

4단계: 중복과 누락 패턴 보기

기준을 다 맞췄는데도 차이가 남으면 그때 추적 자체를 봅니다. 여기서도 무작정 태그부터 열지 말고 패턴부터 봅니다.

플랫폼이 더 많을 때 (중복 의심)

• 결제 완료 페이지를 새로고침하거나 뒤로 가기로 재방문하면 이벤트가 두 번 찍히는지
• 같은 이벤트가 페이지 코드와 태그 관리 도구 양쪽에서 동시에 발송되는지
• 서버 측 전송과 브라우저 측 전송을 같이 쓰면서 중복 제거 키가 빠져 있는지

내부가 더 많을 때 (누락 의심)

• 간편결제나 외부 결제창을 거친 뒤 완료 페이지로 돌아오지 않는 결제 수단이 있는지
• 모바일 인앱 브라우저에서 결제가 끝나는 비율이 높은지
• 쿠키 동의 배너나 브라우저 추적 차단으로 이벤트가 안 나가는 비율이 늘었는지

실무 팁 하나만 드리면, 결제 수단별로 내부 주문 수와 플랫폼 전환을 나눠 보세요. 특정 간편결제에서만 차이가 크다면 원인이 거의 확정됩니다. 저는 이 방법으로 한 브랜드의 30% 가까운 누락이 특정 결제 수단 하나에서 나오던 걸 찾은 적이 있습니다.

5단계: 계정과 운영 환경 쪽 변수 확인하기

여러 브랜드 계정을 동시에 운영하는 대행사라면 이 단계를 꼭 넣어야 합니다. 의외로 운영 환경이 숫자를 흐리는 경우가 있거든요.

• 테스트 주문이 섞였는지: 담당자가 결제 흐름을 점검하느라 넣은 테스트 주문이 플랫폼 전환으로 잡혔는데 내부에서는 취소 처리된 경우
• 다른 브랜드 픽셀이 섞였는지: 한 담당자가 여러 브랜드 사이트를 같은 브라우저 환경에서 오가다 보면, 랜딩 페이지 점검 중 다른 계정의 태그 설정을 잘못 복사하는 실수가 생깁니다
• 팀원이 설정을 바꿨는지: 전환 이벤트 우선순위, 기여 기간, 맞춤 전환 규칙을 누군가 바꾸고 기록을 안 남긴 경우
• 내부 트래픽이 집계되는지: 사무실 직원들의 사이트 방문과 장바구니 행동이 그대로 리포트에 들어가는 경우

저희 팀은 브랜드별로 브라우저 프로필을 분리해서 운영하고, 각 프로필에 어떤 계정과 어떤 사이트가 묶여 있는지 시트로 관리합니다. 다계정을 운영할 때 안티디텍트 브라우저 같은 도구로 환경을 나누는 이유가 계정 보호 때문만은 아닙니다. "이 숫자가 어느 환경에서 나왔는가"를 추적할 수 있게 해 준다는 점이 리포트 관리에서 생각보다 큰 도움이 됩니다.

6단계: 허용 오차를 정하고 문서로 남기기

마지막으로, 모든 차이를 0으로 만들 수는 없다는 걸 인정해야 합니다. 추적 차단, 기여 방식 차이, 결제 지연은 구조적으로 남습니다. 그래서 저는 브랜드마다 허용 오차 범위를 정해 둡니다.

이 범위는 업종과 결제 구조마다 다르니 그대로 쓰기보다는 3개월 정도 데이터를 보고 브랜드별로 정하시길 권합니다. 중요한 건 범위를 미리 합의해 두는 것입니다. 그래야 차이가 생겼을 때 감정적인 해명이 아니라 정해진 절차로 대응할 수 있습니다.

정리: 기술보다 기준이 먼저입니다

숫자가 안 맞을 때 저는 늘 이 순서를 지킵니다.

1. 차이의 모양 기록 (비율, 방향, 시점, 범위)

2. 같은 것을 세고 있는지

3. 시간대와 날짜 경계

4. 기여 기간과 기여 방식

5. 중복과 누락 패턴

6. 계정과 운영 환경 변수

7. 허용 오차 합의와 기록

픽셀을 뜯어보는 건 4단계 이후의 일입니다. 위 단계를 건너뛰고 태그부터 고치면, 원래 정상이던 추적을 건드려서 진짜 문제를 하나 더 만드는 경우를 여러 번 봤습니다. 숫자가 안 맞는 날일수록 천천히, 위에서부터 지워 나가 보세요.