오차 허용 범위부터 정해두기

제휴사 네트워크가 집계한 전환 수와 사업자 내부 주문 수가 5%에서 10% 이상 차이 나는 것이 추적 시스템에 문제가 있다는 뚜렷한 신호로 꼽힙니다. 반대로 이 범위 안의 차이는 여러 시스템이 독립적으로 데이터를 처리하는 이상 자연스럽게 발생할 수 있는 오차로 볼 수 있습니다. 이 기준을 미리 정해두지 않으면, 아주 작은 차이에도 매번 전면적인 조사에 들어가야 하는 비효율이 생기거나, 반대로 실제로 문제가 되는 큰 차이를 대수롭지 않게 넘기는 실수를 할 수 있습니다.

이 허용 범위는 계약서나 운영 가이드에 명시해두는 것이 바람직합니다. "5% 이내의 차이는 정상 오차로 간주하고, 이를 초과하면 공동 조사에 들어간다"는 식의 조항을 미리 합의해두면, 실제 차이가 발견됐을 때 조사에 들어갈지 말지를 두고 다시 다투는 시간을 아낄 수 있습니다.

1단계: 정의부터 대조한다

숫자가 다를 때 가장 먼저 확인해야 할 것은 시스템 자체의 오류가 아니라, 두 시스템이 같은 용어를 같은 의미로 쓰고 있는지입니다. '전환'이라는 단어 하나도 한쪽에서는 신청서 제출을, 다른 쪽에서는 결제 완료를 의미할 수 있습니다. 이런 정의 차이는 실제로는 시스템 오류가 아니라 애초에 다른 것을 세고 있었다는 뜻이므로, 여기서 원인이 발견되면 데이터를 다시 대조할 필요 없이 정의를 통일하는 것만으로 문제가 해결됩니다.

앞선 레슨에서 다룬 데이터 사전이 있다면 이 단계는 빠르게 지나갈 수 있습니다. 데이터 사전이 없는 상태라면, 이번 분쟁을 계기로 만드는 것이 다음 분쟁을 예방하는 첫걸음이 됩니다.

2단계: 시점을 대조한다

정의가 같다면, 다음으로 확인할 것은 두 시스템이 같은 시점을 기준으로 집계하고 있는지입니다. 한쪽은 클릭 시점, 다른 쪽은 전환 시점을 기준으로 삼고 있다면 당연히 숫자가 다르게 나타납니다. 또한 집계 기간의 경계(예: 자정을 기준으로 하루를 나누는 시간대가 서로 다른 경우)도 이 단계에서 확인해야 할 대상입니다.

특히 GA4의 데이터 기반 어트리뷰션처럼 전환 발생 후에도 며칠간 재기여가 이뤄지는 시스템을 쓰고 있다면, 리포트를 조회한 시점에 따라 같은 기간의 숫자도 달라질 수 있다는 점을 함께 고려해야 합니다.

3단계: 필터링 조건을 대조한다

시점까지 같다면, 다음은 각 시스템이 어떤 데이터를 걸러내고 있는지를 봐야 합니다. 부정 클릭으로 판단된 데이터를 제외하는 기준, 중복 클릭을 하나로 묶어 세는 기준, 특정 봇 트래픽을 걸러내는 기준이 시스템마다 다르면 최종 숫자도 자연스럽게 달라집니다. 이런 필터링 기준은 시스템 내부 로직이라 겉으로 드러나지 않는 경우가 많아, 이 단계에서는 각 시스템 제공자에게 필터링 기준을 직접 문의해야 하는 경우가 많습니다.

이 단계에서 특히 주의할 것은, 어느 한쪽의 필터링이 "틀렸다"고 단정하기보다 각자의 필터링 기준이 무엇을 목적으로 하는지부터 차분히 이해하는 것입니다. 사업자 내부 시스템은 실제 매출과 직결된 데이터만 남기려 하고, 매체 시스템은 광고 성과를 폭넓게 잡으려는 경향이 있어 필터링 방향 자체가 다를 수 있습니다.

4단계: 원시 로그를 대조한다

앞의 세 단계로도 차이의 원인이 밝혀지지 않는다면, 마지막으로 개별 이벤트 단위의 원시 로그를 직접 대조해야 합니다. 특정 유저 ID나 클릭 ID를 기준으로 양쪽 시스템에 각각 존재하는지, 존재한다면 기록된 시각과 값이 일치하는지를 하나하나 확인하는 작업입니다. 이 작업은 시간이 많이 들지만, 앞의 세 단계에서 원인을 찾지 못했을 때는 이 정밀 대조가 유일한 방법인 경우가 많습니다.

이 단계까지 왔다면, 표본을 몇 건만 뽑아 대조하기보다 일정 기간의 전체 데이터를 대조하는 것이 더 확실한 결론을 줍니다. 소수 표본만으로는 우연히 일치하거나 불일치하는 결과가 나와 전체 경향을 오판할 위험이 있습니다. 특히 표본을 매체가 직접 골라서 제공하는 경우라면, 그 표본 자체가 매체에 유리한 사례로 편향돼 있을 가능성도 함께 염두에 둬야 합니다.

원시 로그 대조 작업은 광고주 혼자 진행하기보다, 매체·제휴사와 공동으로 진행하는 것이 결과에 대한 신뢰도를 높이는 방법입니다. 한쪽만 데이터를 들여다보고 결론을 내리면, 다른 쪽은 그 결론을 그대로 받아들이기보다 재검증을 요구할 가능성이 높기 때문입니다.

이 순서를 왜 반드시 지켜야 하나

많은 담당자가 숫자 차이를 발견하면 곧바로 원시 로그부터 파고들려는 경향이 있습니다. 하지만 정의나 시점 차이처럼 훨씬 간단한 원인이 먼저 확인되지 않은 상태에서 로그 대조부터 시작하면, 애초에 다른 것을 세고 있었다는 사실을 모른 채 방대한 로그 데이터 속에서 존재하지 않는 '기술적 오류'를 찾아 헤매는 시간 낭비로 이어질 수 있습니다. 쉬운 원인부터 순서대로 배제해나가는 것이 전체 조사 시간을 크게 줄여줍니다.

이 순서는 한 번 경험하고 나면 이후의 모든 분쟁에서 반복해 쓸 수 있는 절차가 됩니다. 처음 이 과정을 거칠 때는 시간이 걸리더라도, 그 결과를 매뉴얼로 남겨두면 다음번에는 같은 순서를 훨씬 빠르게 밟아갈 수 있습니다.