결측은 어떤 기준으로 잡아야 하나

결측 검사는 "행이 있는가"가 아니라 "있어야 할 날짜가 다 있는가"로 설계합니다. 매체 API 연동에서 흔한 실패는 어느 하루의 적재가 통째로 빠지는 것인데, 총합만 보면 조금 줄어든 것처럼 보여 며칠씩 지나갑니다. 그래서 첫 번째 점검은 매체별·계정별로 최근 N일 동안 날짜가 몇 개 존재하는지 세는 쿼리입니다. 기대 일수보다 적으면 그 자체가 경보입니다.

두 번째는 값 수준의 결측입니다. 행은 있는데 비용이 0이거나 캠페인명이 비어 있는 경우입니다. 이 검사는 컬럼별로 널 비율을 계산해 기준선과 비교하는 방식이 무난합니다. 여기서 기준선은 외부 표준이 아니라 자사 데이터로 만들어야 합니다. 최소 4주치 기준선을 확보하고 같은 요일끼리 비교하는 방식이 요일 편차에 속지 않는 방법입니다.

세 번째는 조인 결측입니다. 매체 테이블의 캠페인 식별자가 표준화 테이블에서 매칭되지 않는 비율을 봅니다. 이 비율이 갑자기 오르면 대개 매체 쪽에서 새 캠페인이 생겼는데 명명 규칙이 적용되지 않은 것입니다.

중복은 왜 생기고 어떻게 잡나

중복의 원인은 대체로 재적재입니다. BigQuery Data Transfer Service는 장애나 공백 구간을 메우는 백필 기능을 제공하는데, 백필을 돌린 구간이 기존 데이터와 겹치면 같은 날짜의 같은 캠페인이 두 번 들어옵니다. 자체 API 적재 코드를 쓰는 국내 매체는 재시도 로직이 있는 경우 같은 이유로 중복이 생깁니다.

검사는 유일성 키를 정하는 것에서 시작합니다. 매체 성과 데이터라면 대개 날짜와 계정, 캠페인 식별자, 광고그룹 식별자 조합이 하나의 행이어야 합니다. 이 조합으로 그룹핑해 개수가 1을 넘는 건이 있는지 세는 쿼리가 기본 검사입니다. 여기서 중요한 것은 검사보다 처리 방침입니다. 중복이 나왔을 때 최신 적재분을 남길지, 두 값을 비교해 큰 쪽을 남길지, 아예 해당 날짜를 지우고 다시 받을지를 미리 정해두지 않으면 매번 담당자 판단에 맡겨져 결과가 달라집니다.

전환 쪽 중복도 별도로 봐야 합니다. 웹뷰 결제처럼 자동 기록과 수동 기록이 겹칠 수 있는 구간은 주문번호 단위로 유일성을 확인해야 합니다. Firebase 웹뷰 문서는 iOS에서 수동으로 기록한 인앱 구매 이벤트를 중복 제거하지 않는다고 명시하므로, 이 구간은 구조적으로 중복 가능성이 있습니다.

값이 나중에 바뀌는 데이터는 어떻게 다루나

매체 데이터는 확정 데이터가 아닙니다. 무효 클릭 차감, 전환 지연 반영, 통화 환산 정정 같은 이유로 며칠 뒤에 값이 바뀝니다. GA4 쪽에서도 지연은 존재합니다. GA4 키 이벤트를 Google Ads로 가져올 때 데이터 동기화에 최대 24시간의 지연이 발생할 수 있습니다.

그래서 검증 루틴에는 재적재 정책이 포함되어야 합니다. 최근 며칠을 항상 다시 받아 덮어쓰는 창(rolling window)을 정하고, 그 창 밖의 날짜는 확정으로 취급하는 방식입니다. 창의 길이는 매체별로 다르므로, 같은 날짜의 값이 며칠 뒤까지 바뀌는지 실제로 관측해 정합니다. 이 정책이 없으면 어제 뽑은 리포트와 오늘 뽑은 리포트가 달라지는 이유를 설명할 수 없고, 그 순간 신뢰가 무너집니다.

또 하나 구분해야 할 것이 매체 보고 전환과 자사 측정 전환의 차이입니다. 메타처럼 자체적으로 클릭·전환을 판정해 보고하는 자기귀속 네트워크는 어트리뷰션 로직과 집계 시점이 달라 수치가 구조적으로 어긋납니다. 이 차이는 품질 오류가 아니므로 검사에서 경보로 처리하면 안 되고, 차이율의 급변만 경보 대상으로 두는 것이 맞습니다.

점검 쿼리는 어떻게 짜야 부담이 없나

점검 루틴 자체가 비용을 만들면 오래 못 갑니다. BigQuery 표준 SQL에서 WHERE 절은 그룹화·집계 전에 행 단위로 걸러내므로, 점검 대상 기간을 먼저 좁히는 것이 스캔량 절감의 기본입니다. GA4 Export처럼 날짜별로 테이블이 나뉜 소스는 대상 날짜 테이블만 지정하면 스캔 대상 자체가 줄어듭니다.

구글의 비용 통제 권장사항도 그대로 적용됩니다. 실행 전 쿼리 검사기나 드라이런으로 예상 바이트를 확인하고, 청구 바이트 최대값으로 상한을 걸며, 결과를 단계적으로 구체화합니다. 점검 결과는 매번 조회하지 말고 검사 결과 테이블에 날짜·검사항목·판정·수치로 적재해두는 편이 낫습니다. 그러면 대시보드는 결과 테이블만 읽으면 되고, 원본 테이블을 반복 스캔하지 않습니다. 탐색 목적이라면 쿼리 대신 테이블 미리보기를 쓰라는 권장도 유효합니다. LIMIT는 클러스터링되지 않은 테이블의 비용을 줄여주지 않기 때문입니다.

경보는 어디까지 울려야 하나

검사 항목을 다 만들고 나면 모든 항목에 경보를 거는 유혹이 생기는데, 경보가 많으면 아무도 안 봅니다. 실무에서 유지되는 구성은 두 단계입니다. 즉시 알림은 데이터가 통째로 안 들어온 경우와 유일성 위반이 발생한 경우로 한정하고, 나머지는 일간 요약 리포트에 수치로만 남깁니다.

경보 문구에는 판단에 필요한 정보를 함께 넣습니다. 어느 매체·계정의 어느 날짜에 무슨 검사가 실패했는지, 직전 4주 같은 요일 값은 얼마였는지까지 포함하면 받는 사람이 대시보드를 열지 않고도 심각도를 판단할 수 있습니다. 그리고 경보가 울렸을 때 누가 1차로 확인하고 몇 시간 안에 회신하는지를 문서에 적어두어야 합니다. 검사 쿼리를 만드는 것보다 이 회신 규칙을 정하는 쪽이 실제 품질을 결정합니다.