Looker Studio 매출 보고서에서 숫자가 맞지 않을 때: 원본·집계·기간을 대조하는 순서

Looker Studio 매출 보고서의 숫자가 원본과 다를 때는 차트부터 수정하지 않는 편이 안전합니다. 먼저 같은 원본·같은 기간·같은 필터·같은 집계·같은 갱신 시점을 한 줄씩 맞춰 보세요. 이 다섯 조건 중 하나라도 다르면, 두 화면은 같은 질문에 답하고 있지 않을 수 있습니다.

이 글은 “왜 매출이 틀렸는지”를 단정하는 방법이 아닙니다. 보고 직전에 숫자 차이를 발견했을 때, 원인을 재현 가능하게 좁히는 기술적 점검 순서입니다. 실제 회계 처리나 세무 판단은 사용 중인 원장과 담당 전문가의 기준으로 별도 확인해야 합니다.

먼저 결론: 숫자 하나를 고르되, 두 화면의 질문을 같게 만든다

“이번 달 매출”처럼 보이는 숫자도 세부 정의가 다르면 일치하지 않습니다. 한쪽은 결제 완료 금액, 다른 쪽은 주문 생성 금액일 수 있고, 한쪽은 취소를 제외했는데 다른 쪽은 포함했을 수 있습니다. 따라서 첫 단계는 숫자를 맞추려는 시도가 아니라 비교 대상의 이름을 정확하게 붙이는 일입니다.

예를 들어 보고서 카드와 원본 시트에 각각 다음 다섯 항목을 적습니다.

이 표는 단순하지만 효과가 큽니다. “숫자가 안 맞는다”는 막연한 문제를 다섯 개의 확인 가능한 조건으로 나누기 때문입니다.

1. 원본을 먼저 고정한다: 어느 데이터가 기준인지 정한다

원본은 대개 스프레드시트, 주문 시스템의 내보내기 파일, GA4, 광고 플랫폼, CRM 중 하나입니다. 그러나 여러 시스템을 모두 원본으로 놓으면 비교가 끝나지 않습니다. 이번 보고에서 답하려는 질문에 가장 가까운 시스템을 한 개 정하고, 그 시스템의 조회 화면 또는 추출 파일을 기준본으로 보관하세요.

기준본에는 조회한 날짜, 시간대, 적용한 필터, 파일 생성 시각을 함께 남깁니다. CSV를 내려받았다면 파일명만 적지 말고 “어느 화면에서 어떤 조건으로 내려받았는지”를 기록합니다. 나중에 원본이 새로 갱신돼도 당시 보고서와 무엇을 비교했는지 추적할 수 있습니다.

원본에 계산 열이 있다면 그 식도 확인합니다. 예컨대 환불을 뺀 순액인지, 배송비를 포함한 금액인지, 여러 통화를 하나로 환산한 값인지에 따라 Looker Studio의 단순 합계와 다른 결과가 나올 수 있습니다. 여기서 차이가 발견되면 시각화 문제로 넘어가기보다 정의를 문서에 남기는 것이 먼저입니다.

2. 날짜 범위는 화면의 달력만 보지 말고 날짜 필드까지 맞춘다

Looker Studio에서는 보고서 전체, 페이지, 개별 차트가 서로 다른 날짜 범위를 가질 수 있습니다. 차트가 어떤 날짜 필드를 기준으로 삼는지도 결과에 영향을 줍니다. Google Cloud의 날짜 범위 설정 안내는 보고서와 차트의 날짜 범위 설정 및 날짜 차원의 관계를 설명합니다.

점검할 때는 다음을 함께 적으세요.

• 시작일과 종료일이 둘 다 포함되는지
• 날짜가 주문일, 결제일, 이벤트 발생일 중 무엇인지
• 보고서와 원본의 시간대가 같은지
• 비교 기간에 오늘처럼 아직 끝나지 않은 날짜가 섞였는지
• 차트의 날짜 범위가 보고서 기본값을 덮어쓰고 있는지

특히 “이번 달”은 안전한 비교 조건이 아닙니다. 한 화면은 현재 시각까지, 다른 화면은 전날 마감 데이터까지만 보여 줄 수 있습니다. 오늘 데이터를 포함해야 한다면, 두 시스템이 어느 시각까지 반영되는지 먼저 확인하고 차이를 잠정 상태로 표시하세요.

3. 데이터 소스와 새로고침 상태를 확인한다

동일한 원본을 연결했더라도 Looker Studio가 언제 데이터를 다시 읽었는지에 따라 화면이 달라질 수 있습니다. Google Cloud의 데이터 최신성 관리 문서는 데이터 소스의 캐시 및 새로고침 관련 동작을 설명합니다. 보고서에서 보이는 마지막 갱신 정보와 원본의 최신 입력 시각을 같은 메모에 적어 두세요.

새로고침은 숫자를 “정답으로 바꾸는 버튼”이 아닙니다. 그것은 같은 조건의 최신 데이터를 다시 비교하기 위한 준비 단계입니다. 새로고침 뒤에도 차이가 남으면, 다음 단계인 필터와 집계 정의를 살펴야 합니다. 반대로 새로고침 전후 값이 바뀌었다면, 보고서 작성 시점과 원본 조회 시점이 달랐다는 사실을 보고에 함께 밝혀야 합니다.

4. 필터와 세그먼트는 보이는 것뿐 아니라 숨은 조건까지 비교한다

필터는 보통 차트 옆의 드롭다운에서만 생기지 않습니다. 데이터 소스 수준의 필터, 차트 수준의 필터, 보고서 컨트롤, 계산 필드 안의 조건이 함께 적용될 수 있습니다. 원본 화면의 필터와 Looker Studio의 조건을 한 줄씩 비교해 보세요.

다음 순서가 실무에서 비교하기 쉽습니다.

1. 채널, 매체, 캠페인 같은 유입 조건을 모두 해제한 값부터 비교합니다.
2. 주문 상태, 취소 여부, 테스트 주문 제외 같은 운영 조건을 하나씩 다시 적용합니다.
3. 국가, 기기, 상품군처럼 범주를 나눈 조건을 적용합니다.
4. 차이가 처음 생긴 조건을 기록하고, 그 조건의 정의를 원본과 대조합니다.

한 번에 모든 필터를 켜 둔 채 원인을 찾으면, 무엇이 차이를 만들었는지 알기 어렵습니다. 조건을 하나씩 넣는 방식은 느려 보여도 재현 가능한 설명을 남깁니다. 분석 도구에서 차원과 측정항목 조합의 호환성이 결과에 영향을 줄 수 있다는 점은 Google Analytics의 데이터 호환성 안내도 참고할 수 있습니다.

5. 집계 방식은 “합계”라는 말만으로 충분하지 않다

Looker Studio의 측정항목은 합계, 평균, 개수, 고유 개수 등 서로 다른 방식으로 집계될 수 있습니다. Google Cloud의 집계 안내는 필드의 기본 집계와 차트 수준의 집계가 결과에 영향을 줄 수 있음을 설명합니다.

숫자가 클수록 먼저 확인할 질문은 이것입니다. “이 행은 거래 한 건인가, 상품 한 줄인가, 사용자 한 명인가?” 주문 한 건이 상품 수만큼 여러 행으로 저장됐다면 거래 금액을 단순 합계하는 방식은 중복될 수 있습니다. 반대로 고유 주문 수를 세야 하는데 전체 행 수를 세면 값이 커질 수 있습니다.

집계 대조에는 아래처럼 간단한 기록을 남깁니다.

빈칸을 채우지 못한 항목이 있으면 그 상태로 차트를 수정하지 않는 편이 낫습니다. 보기 좋은 대시보드는 집계 정의를 대신해 주지 않습니다.

6. 블렌드와 계산 필드는 마지막에 본다

여러 데이터 소스를 결합한 블렌드, 조인, 계산 필드는 유용하지만 첫 점검 대상은 아닙니다. 원본 하나와 단순 차트 하나의 값이 일치하는지 먼저 확인한 뒤에 결합된 차트로 넘어가세요. 그래야 문제의 위치를 원본, 연결, 결합, 표시 중 어디로 좁혀야 하는지 알 수 있습니다.

블렌드 차트만 다르다면 조인 키, 조인 방식, 키 값의 공백이나 형식 차이, 연결되지 않은 행의 처리 여부를 확인합니다. 계산 필드만 다르다면 계산식에 들어간 조건과 반올림 위치를 원본 수식과 나란히 둡니다. 이 단계에서 복잡한 수식을 바로 고치지 말고, 단순 지표에서 같은 차이가 재현되는지 먼저 확인하세요.

7. 차이가 남으면 ‘오류’ 대신 ‘검토 중’으로 보고한다

원인을 아직 확정하지 못했다면 “대시보드 오류” 또는 “원본 오류”라고 단정하지 않는 것이 좋습니다. 보고 문구는 다음처럼 사실과 다음 행동을 분리할 수 있습니다.

현재 차이는 동일 지표의 날짜 필드와 취소 포함 조건을 대조 중인 상태입니다. 기준 원본, 조회 시각, 적용 필터를 기록한 뒤 다음 보고에서 확정 값을 공유합니다.

Google Analytics도 보고서와 탐색의 값이 데이터 모델, 날짜 범위, 처리 시간, 임계값 또는 모델링 같은 조건에 따라 다를 수 있음을 공식 안내에서 설명합니다. 이 사실은 모든 차이가 정상이라는 뜻이 아닙니다. 차이를 설명하기 전에 비교 조건을 보존해야 한다는 뜻입니다.

보고 전 10분 점검 기록

보고서를 공유하기 전, 숫자 하나에 아래 여섯 줄만 남겨 보세요.

1. 기준 원본: 시스템 이름과 조회 또는 추출 시각
2. 지표 정의: 무엇을 포함하고 무엇을 제외했는지
3. 날짜: 시작일·종료일·시간대·사용한 날짜 필드
4. 필터: 적용한 상태, 채널, 상품 또는 테스트 제외 조건
5. 집계: 합계·개수·고유 개수·계산식 여부
6. 결과: 일치, 차이, 또는 검토 중과 다음 확인 담당자

이 기록은 다음 주 보고를 더 빨리 만드는 자산이기도 합니다. 수치가 달라졌을 때 이전 보고의 조건을 다시 열어 볼 수 있기 때문입니다. 데이터에서 주장까지 근거를 잃지 않는 방법은 공식 출처로 블로그 자료를 검증하는 흐름과, 조사 결과를 작업 상태로 남기는 콘텐츠 캘린더 관리 방법에서도 이어서 확인할 수 있습니다.

자주 묻는 질문

새로고침하면 숫자가 반드시 같아지나요?

아닙니다. 새로고침은 비교 시점을 맞추는 준비일 뿐입니다. 날짜 필드, 필터, 지표 정의, 집계가 다르면 최신 데이터여도 값은 다를 수 있습니다.

원본은 스프레드시트인가요, 주문 시스템인가요?

보고의 질문에 따라 다릅니다. 결제 완료 기준을 설명하는 보고라면 그 기준을 가장 직접적으로 보존하는 시스템을 정하고, 다른 데이터는 대조 자료로 둡니다. 여러 화면을 모두 같은 원본처럼 취급하지 않는 것이 중요합니다.

숫자 차이를 발견했을 때 차트를 숨겨야 하나요?

영향 범위와 보고 목적에 따라 판단해야 합니다. 다만 원인이 확정되지 않았다면 확정 수치처럼 설명하지 말고, 비교 조건과 검토 상태를 표시하는 편이 안전합니다. 이 글은 기술적 대조 절차만 다루며 회계·세무 판단을 제공하지 않습니다.

마무리

Looker Studio 매출 보고서의 숫자 불일치는 디자인 문제가 아니라 비교 조건의 문제일 때가 많습니다. 다음 보고에서 숫자 하나만 골라 원본, 기간, 필터, 집계, 갱신 시점을 표로 남겨 보세요. 다섯 줄의 기록이 쌓이면, 값이 다른 이유를 추측이 아니라 확인 순서로 설명할 수 있습니다.