GA4 빅쿼리 연동: 켜기 전에 정할 4가지 기준과 점검 순서
GA4 빅쿼리 연동은 단순히 데이터를 백업하는 기능이 아닙니다.
GA4 화면이 요약해서 보여주는 숫자 뒤의 이벤트 원본을, 광고 성과 판단에 직접 쓸 수 있게 만드는 작업입니다.
GA4 빅쿼리 연동에서 가장 중요한 건 버튼을 누르는 순서가 아니라 연동 전에 정하는 네 가지 설정입니다.
데이터 위치, 내보내기 방식, 내보낼 범위, 비용 관리 방식은 나중에 바꾸기 어렵거나, 잘못 정하면 그 기간 데이터를 다시 받을 수 없습니다.
그리고 연동은 과거 데이터를 채워주지 않습니다. 하루라도 빨리 켜두는 쪽이 유리합니다.
아래에서 연동 전에 정할 기준, 실제 연결 순서, 연동 후 숫자가 GA4 화면과 다를 때 판독하는 방법을 순서대로 설명합니다.
1. GA4 빅쿼리 연동 전에 정해야 할 4가지 기준
연동 화면 자체는 5분이면 끝납니다.
문제는 그 5분 안에 고르는 선택지 중 일부가 되돌릴 수 없다는 점입니다.
먼저 꼭 알아야 할 전제가 하나 있습니다.
GA4 빅쿼리 연동은 연결한 날부터 쌓입니다.
연결 전에 수집된 GA4 데이터는 BigQuery로 넘어가지 않습니다(백필 없음).
그래서 "분석할 일이 생기면 그때 연동하자"는 판단이 가장 비싼 실수입니다.
대형 프로모션이 끝난 뒤 채널별 구매 경로를 뜯어보려고 연동했는데, 정작 프로모션 기간 데이터는 하나도 없는 경우가 실무에서 꽤 자주 나옵니다.
-> 쓸 계획이 조금이라도 있다면, 분석 설계보다 연동을 먼저 켜두는 것이 맞습니다.
① 데이터 위치(리전): 한 번 정하면 못 바꿉니다
연동할 때 BigQuery 데이터 세트가 생성될 위치를 고릅니다.
이 위치는 연동 후 변경할 수 없습니다.
판단 기준은 단순합니다.
이미 회사에서 쓰는 BigQuery 데이터(CRM, 주문 DB 등)가 있다면 → 그 데이터와 같은 리전
처음 쓰는 경우 → 서울 리전(asia-northeast3) 또는 다중 리전(US) 중 하나로 통일
리전이 다르면 두 데이터를 한 쿼리로 바로 조인할 수 없습니다.
GA4 이벤트와 주문 DB를 붙여서 "광고 유입 고객의 실제 결제·환불"을 보려는 순간 이 문제가 터집니다.
② 내보내기 방식: 일별 vs 스트리밍
GA4 빅쿼리 연동의 내보내기 방식은 두 가지입니다.
구분 | 일별(Daily) | 스트리밍(Streaming) |
|---|---|---|
생성 테이블 | events_YYYYMMDD | events_intraday_YYYYMMDD |
반영 속도 | 하루 1회 전날 데이터 | 수 분 내 거의 실시간 |
표준 속성 한도 | 하루 이벤트 100만 건 | 별도 한도 없음 |
비용 | 내보내기 자체는 무료 | BigQuery 스트리밍 수집 비용 발생 |
샌드박스 사용 | 가능 | 불가(결제 계정 필요) |
광고 실무에서 대부분의 판단은 어제까지의 데이터로 충분합니다.
예산 증액, 소재 교체, 캠페인 종료 판단은 일 단위로 이뤄지기 때문입니다.
스트리밍이 필요한 경우는 좁습니다.
라이브커머스·한정 수량 오픈처럼 당일 몇 시간 안에 판단해야 하는 이벤트
실시간 대시보드를 내부에 띄워 운영하는 경우
-> 특별한 이유가 없다면 일별만 켜고 시작하는 편이 비용·관리 모두 안전합니다.
③ 내보낼 범위: 이벤트 100만 건 한도를 먼저 계산하세요
표준(무료) GA4 속성은 일별 내보내기가 하루 100만 이벤트로 제한됩니다.
이 한도를 꾸준히 넘기면 일별 내보내기가 일시 중지될 수 있습니다.
여기서 많이 놓치는 부분이 있습니다.
100만 건은 "방문자 수"가 아니라 이벤트 수라는 점입니다.
page_view, scroll, user_engagement, 그리고 직접 심어둔 커스텀 이벤트까지 전부 합산됩니다.
하루 방문자가 수만 명 수준이어도, 스크롤·클릭 이벤트를 촘촘히 심어둔 사이트라면 한도에 금방 닿습니다.
확인 방법은 GA4 보고서 > 참여도 > 이벤트에서 하루 전체 이벤트 수를 보는 것입니다.
한도에 가깝다면 연동 설정에서 두 가지로 줄일 수 있습니다.
데이터 스트림 선택: 웹·앱 중 분석에 필요한 스트림만 내보내기
이벤트 제외 목록: 분석에 쓰지 않는 이벤트(예: 과도하게 발생하는 스크롤·노출 이벤트) 제외
단, 제외한 이벤트는 그 기간 데이터가 BigQuery에 남지 않습니다.
purchase, add_to_cart, begin_checkout, generate_lead처럼 광고 최적화와 직결된 이벤트는 절대 제외하지 않는 것이 기준입니다.
④ 비용 관리: 샌드박스로 시작해도 되는지
BigQuery는 결제 계정 없이 쓸 수 있는 샌드박스 모드가 있습니다.
저장 10GB, 쿼리 처리 월 1TB까지 무료라 테스트하기 좋습니다.
하지만 샌드박스에는 결정적인 제약이 있습니다.
테이블이 60일 후 자동 만료됩니다.
샌드박스로 연동해두고 잊고 있다가, 석 달 뒤 분석하려고 열어보니 최근 60일치만 남아 있는 경우가 대표적인 실패 사례입니다.
연동의 가장 큰 가치가 "GA4 화면의 보존 기간(최대 14개월)을 넘어 원본을 계속 보관하는 것"인데, 샌드박스는 그 가치를 스스로 지웁니다.
-> 테스트 목적이면 샌드박스, 실제 운영이면 결제 계정을 연결한 프로젝트로 시작하세요.
일별 내보내기만 쓰는 중소 규모 사이트라면 저장 비용은 대체로 크지 않고, 비용의 대부분은 저장이 아니라 쿼리를 어떻게 짜느냐에서 갈립니다(3장에서 다룹니다).
2. GA4 빅쿼리 연동 순서: 권한부터 첫 테이블 확인까지
기준이 정해졌다면 실제 연결은 다음 순서로 진행합니다.
1단계. 권한 확인
연동이 막히는 원인의 절반은 권한입니다.
작업하는 계정이 아래 두 가지를 동시에 갖고 있어야 합니다.
GA4 속성: 편집자 이상
Google Cloud 프로젝트: 소유자 권한(서비스 계정에 BigQuery 권한을 부여해야 하기 때문)
광고 대행사나 외주 분석가가 GA4 권한만 받고 Cloud 프로젝트는 광고주 쪽에 있는 경우, 여기서 멈춥니다.
이때는 광고주 쪽 Cloud 소유자가 직접 연결하거나, 작업 기간만 권한을 열어주는 방식이 깔끔합니다.
프로젝트의 소유권은 반드시 광고주 계정에 두는 것이 원칙입니다.
대행사 계정 소유 프로젝트에 데이터를 쌓으면, 계약이 끝날 때 원본 데이터까지 함께 넘겨받아야 하는 상황이 생깁니다.
2단계. Cloud 프로젝트 준비
Google Cloud 콘솔에서 프로젝트 생성(또는 기존 프로젝트 선택)
BigQuery API 사용 설정 확인
운영 목적이면 결제 계정 연결
3단계. GA4에서 연결
GA4 관리 > 제품 링크 > BigQuery 링크 > 연결
프로젝트 선택 → 데이터 위치 선택(1장 ① 기준)
데이터 스트림·이벤트 범위 설정(1장 ③ 기준)
내보내기 방식 선택: 일별 / 스트리밍(1장 ② 기준)
필요하면 사용자 데이터 내보내기도 함께 선택
연결이 완료되면 BigQuery에 analytics_속성ID 이름의 데이터 세트가 생깁니다.
4단계. 첫 테이블 확인 (연동 후 24~48시간)
일별 테이블은 연결 직후 바로 생기지 않습니다.
보통 다음 날 이후 events_YYYYMMDD 테이블이 처음 나타납니다.
48시간이 지나도 테이블이 없다면 이 순서로 점검합니다.
BigQuery API가 꺼져 있지 않은지
결제 계정이 정지되거나 연결 해제되지 않았는지
프로젝트에서 서비스 계정(firebase-measurement@system.gserviceaccount.com)의 권한이 지워지지 않았는지
GA4 링크 화면에 오류 메시지가 표시되는지
3번은 보안 정리를 하던 IT 담당자가 "모르는 서비스 계정"이라고 권한을 삭제하면서 생기는 경우가 있습니다.
연동 후 사내에 이 계정을 지우면 안 된다고 공유해두는 것도 점검 항목입니다.
-> 핵심: 연동은 "연결 완료" 화면이 아니라 첫 일별 테이블이 생긴 것을 확인한 시점에 끝난 것입니다.
구글 태그 설치 순서: 광고 성과 측정 전 확인할 4단계 기준
3. 연동 후 GA4 화면과 빅쿼리 숫자가 다를 때 판독 기준
연동 후 가장 먼저 받는 질문은 거의 같습니다.
"GA4에서는 사용자 1만 명인데, 빅쿼리에서 세보니 숫자가 달라요."
결론부터 말하면 약간의 차이는 정상입니다.
중요한 건 차이가 나는 이유를 구분해서, 어느 숫자를 어떤 판단에 쓸지 정하는 것입니다.
차이가 생기는 4가지 이유
① GA4 화면은 추정치를 씁니다
GA4 표준 보고서의 사용자 수·세션 수는 HyperLogLog++ 방식으로 근사 계산된 값입니다.
BigQuery에서 COUNT(DISTINCT user_pseudo_id)로 정확히 세면 소폭 차이가 납니다.
② 모델링 데이터는 BigQuery에 없습니다
동의 모드로 쿠키 동의를 거부한 사용자의 행동을 GA4가 모델링해 채운 값은 화면에만 반영됩니다.
BigQuery에는 실제로 수집된 이벤트만 들어갑니다.
③ 보고 ID 설정이 다릅니다
GA4 화면은 User-ID, Google 신호 등 보고 ID 설정에 따라 사용자를 합칩니다.
BigQuery 원본은 이 처리가 되지 않은 상태라 user_pseudo_id 기준으로 세면 사용자 수가 더 많게 나오기도 합니다.
④ 유입 경로 필드를 잘못 고른 경우
광고 실무에서 가장 치명적인 차이는 여기서 나옵니다.
필드 | 의미 | 쓰임 |
|---|---|---|
traffic_source | 사용자를 처음 데려온 경로 | 신규 획득 채널 분석 |
collected_traffic_source | 해당 이벤트 시점에 수집된 UTM·gclid | 이벤트 단위 원천 확인 |
session_traffic_source_last_click | 세션의 마지막 클릭 기준 경로 | GA4 화면의 세션 소스와 비교 |
traffic_source로 캠페인별 구매를 집계하면, 3개월 전 첫 방문 채널에 이번 달 구매가 전부 귀속됩니다.
이번 달 집행한 리타겟팅 캠페인 성과가 0에 가깝게 나오고, 몇 달 전 브랜드 검색이 구매를 다 가져간 것처럼 보입니다.
-> 캠페인 성과를 볼 때는 traffic_source를 쓰지 않는다가 기준입니다.
어느 숫자를 믿어야 할까
판단 기준은 용도로 나눕니다.
추이·보고용(주간 리포트, 전주 대비) → GA4 화면 숫자
원인 분석용(경로, 코호트, 주문 DB 조인) → BigQuery 원본
광고 매체 최적화 판단 → 매체 숫자와 BigQuery 숫자를 같은 기준(기간·귀속)으로 맞춘 뒤 비교
한 쪽 숫자로 보고하고 다른 쪽 숫자로 해석하면, 회의 때마다 숫자 해명에 시간을 쓰게 됩니다.
보고서 첫 장에 "이 지표는 어느 소스 기준인지"를 적어두는 것만으로 이 문제가 상당히 줄어듭니다.
메타 ga4 데이터 차이, 왜 생기고 어디를 믿어야 할까
쿼리 비용을 줄이는 3가지 습관
BigQuery 주문형 요금은 스캔한 데이터 양으로 과금됩니다.
같은 질문이라도 쿼리를 어떻게 쓰느냐에 따라 비용이 수십 배 차이 날 수 있습니다.
날짜 범위를 항상 지정합니다.
events_*를 쓸 때_TABLE_SUFFIX BETWEEN '20260901' AND '20260930'조건을 넣지 않으면, 연동 이후 전 기간을 스캔합니다.SELECT * 를 쓰지 않습니다.
BigQuery는 열 단위로 과금되기 때문에, 필요한 열만 고르는 것이 가장 확실한 절약입니다.자주 쓰는 집계는 중간 테이블로 만듭니다.
매일 원본에서 캠페인별 구매를 다시 계산하지 말고, 일 단위 요약 테이블을 만들어 대시보드는 그 테이블만 읽게 합니다.
쿼리 실행 전 편집기 오른쪽 위에 예상 처리량이 표시됩니다.
처리량이 예상보다 크면 실행하지 말고 조건부터 다시 보는 습관이 비용 사고를 막습니다.
Cloud 콘솔에서 예산 알림을 걸어두는 것도 함께 권장합니다.
4. GA4 빅쿼리 연동을 광고 판단에 쓰는 실무 활용 3가지
연동해두고 아무도 열어보지 않는 경우가 생각보다 많습니다.
광고 운영에서 바로 쓸 수 있는 활용처는 다음 세 가지입니다.
① 이벤트 누락·중복 검증
purchase 이벤트를 transaction_id 기준으로 집계하면, 같은 주문번호가 두 번 이상 들어온 건수를 바로 셀 수 있습니다.
주문 완료 페이지 새로고침, 결제 모듈 리디렉션 때문에 구매가 중복 수집되는 사이트는 생각보다 흔합니다.
GA4 화면만 볼 때는 "전환이 좀 많네" 정도로 넘어가던 문제가, 원본에서는 주문번호 단위로 드러납니다.
매체에 보내는 전환이 부풀려져 있으면 입찰 알고리즘이 잘못 학습하기 때문에, 이 검증은 연동 직후 가장 먼저 해볼 만한 작업입니다.
② 광고 클릭 이후 구간 분석
gclid, UTM이 붙은 세션만 골라 session_start → view_item → add_to_cart → begin_checkout → purchase 단계별 이탈을 캠페인 단위로 볼 수 있습니다.
같은 ROAS가 낮은 캠페인이라도
- 장바구니까지는 잘 가는데 결제에서 끊기는 캠페인 → 랜딩·결제 문제
- 상품 조회부터 끊기는 캠페인 → 타겟·소재와 랜딩의 불일치
로 원인이 갈립니다.
GA4 탐색 보고서로도 일부 가능하지만, 기간이 길어지거나 조건이 복잡해지면 임계값·샘플링 없이 볼 수 있는 원본 쪽이 훨씬 안정적입니다.
③ 주문 DB와 붙여 실제 매출 기준으로 보기
GA4의 purchase 금액은 결제 시점 금액입니다.
취소·환불·부분 반품은 반영되지 않습니다.
transaction_id로 주문 DB의 최종 결제 상태를 붙이면, 캠페인별 환불 반영 후 실매출을 계산할 수 있습니다.
특히 반품률이 높은 패션·가전 카테고리에서는 GA4상 ROAS가 좋았던 캠페인이 환불 반영 후 손익분기 아래로 내려가는 경우가 있습니다.
1장에서 리전을 기존 데이터와 맞추라고 한 이유가 바로 이 작업 때문입니다.
-> 정리하면, 연동의 가치는 "데이터를 더 많이 보는 것"이 아니라 광고 판단에 쓰는 숫자를 한 번 검증할 수 있게 되는 것입니다.
자주 묻는 질문
GA4 빅쿼리 연동하면 과거 데이터도 들어오나요?
들어오지 않습니다. 연동은 연결한 날 이후 수집된 데이터만 내보내며, 이전 기간 백필 기능은 제공되지 않습니다. 그래서 당장 분석 계획이 없더라도 미리 연동해두는 편이 유리합니다.
GA4 빅쿼리 연동 비용은 얼마나 드나요?
일별 내보내기 자체는 무료이고, BigQuery 저장 비용과 쿼리 비용이 발생합니다. 스트리밍 내보내기를 켜면 수집 비용이 추가됩니다. 중소 규모 사이트는 저장보다 쿼리 습관(날짜 범위 지정, 필요한 열만 선택)이 비용을 좌우합니다.
GA4 빅쿼리 내보내기 100만 건 한도를 넘으면 어떻게 되나요?
표준 속성에서 일별 이벤트가 100만 건을 꾸준히 넘기면 일별 내보내기가 중지될 수 있습니다. 데이터 스트림 선택이나 이벤트 제외로 범위를 줄이거나, 스트리밍 내보내기 또는 GA4 360을 검토해야 합니다.
GA4와 빅쿼리 사용자 수가 다른 이유는?
GA4 화면은 사용자 수를 근사 계산하고 동의 모드 모델링·보고 ID를 반영하지만, 빅쿼리는 실제 수집된 원본 그대로이기 때문입니다. 소폭 차이는 정상이며, 크게 차이 난다면 집계 기준 필드나 기간 설정을 먼저 확인합니다.
빅쿼리 샌드박스로 GA4 연동해도 되나요?
테스트 용도로는 가능하지만, 샌드박스 테이블은 60일 후 자동 만료되고 스트리밍 내보내기도 쓸 수 없습니다. 장기 보관이 목적이라면 결제 계정을 연결한 프로젝트로 연동해야 합니다.
마무리
GA4 빅쿼리 연동은 연결 자체보다 연결 전 결정이 성패를 가릅니다.
데이터 위치는 기존 데이터와 같은 리전으로, 한 번 정하면 못 바꿉니다
내보내기는 일별로 시작하고, 당일 판단이 필요할 때만 스트리밍을 켭니다
하루 이벤트 수를 먼저 계산하고, 광고 최적화 이벤트는 절대 제외하지 않습니다
운영 목적이면 샌드박스가 아닌 결제 계정 프로젝트로, 소유권은 광고주 쪽에 둡니다
그리고 연동 후에는 GA4 화면 숫자와 원본 숫자를 용도별로 나눠 쓰는 기준을 먼저 정하세요.
원본 데이터는 쌓아두는 것만으로는 가치가 없고, 광고 판단에 쓰는 숫자를 한 번 검증하는 데 쓰일 때 비로소 의미가 생깁니다.
오늘 연동을 켜두면, 다음 분기 분석에 쓸 데이터가 그날부터 쌓이기 시작합니다.