GA4 원시 데이터는 어떤 형태로 들어오나

GA4의 BigQuery Export는 일일과 스트리밍 두 가지를 선택적으로 또는 동시에 설정할 수 있습니다. 일일 내보내기는 하루 한 번 events_YYYYMMDD 테이블을 만들고, 표준(무료) 속성에는 일일 내보내기 이벤트 100만 건 한도가 있습니다. 스트리밍 내보내기는 하루 종일 events_intraday_YYYYMMDD 스테이징 테이블에 계속 적재하며 건수 제한이 없습니다. 이 값은 확인 시점 기준이므로 실제 적용 전 GA4 고객센터 원문을 다시 확인하는 편이 안전합니다.

데이터세트 이름은 analytics_속성ID 형식이고, intraday 테이블은 매일 삭제되는 스테이징 성격입니다. 여기서 파이프라인 설계 시 반드시 정해야 할 것이 조회 대상 분리입니다. events_* 와일드카드로 쿼리를 짜면 intraday 테이블까지 함께 스캔돼 중복 집계가 납니다. 확정 리포트는 일일 테이블만, 실시간 모니터링은 intraday만 보도록 대상 테이블을 처음부터 분리해두어야 합니다.

광고 매체 데이터는 어떤 경로로 들어오나

구글 계열 매체는 BigQuery Data Transfer Service가 담당합니다. 이 서비스는 예약된 일정에 따라 BigQuery로의 데이터 이동을 자동화하는 관리형 서비스로, Google Ads, Campaign Manager, Display & Video 360, Google Ad Manager, Search Ads 360, YouTube 채널 보고서, YouTube 콘텐츠 소유자 보고서, Google Analytics 4, Google Play를 지원합니다(Google Merchant Center와 Comparison Shopping Service Center는 프리뷰). 장애나 공백 구간을 메우는 백필 기능도 제공합니다.

문제는 이 목록에 네이버와 카카오가 없다는 점입니다. 국내 매체 데이터는 각 매체의 오픈 API를 직접 호출하는 자체 적재 코드나 별도 커넥터가 필요합니다. "전송 서비스를 켜면 전 매체가 들어온다"는 전제로 일정을 잡으면 국내 매체 구간에서 통째로 지연됩니다. 매체별로 적재 방식(관리형 전송 / 자체 API / 수기 업로드)을 표로 먼저 나눠두는 것이 계획의 출발점입니다.

적재와 변환을 왜 분리해야 하나

BigQuery Data Transfer Service는 데이터를 적재하는 도구이며 범용 ETL 변환 도구가 아닙니다. 데이터가 BigQuery로 들어오는 단방향 전송이고, 같은 서비스 계열에서 데이터세트 복사와 예약 쿼리를 함께 다룹니다.

이 말은 매체별로 컬럼명·통화·시간대가 제각각인 원시 테이블이 손대지 않은 상태로 쌓인다는 뜻입니다. 어떤 매체는 비용 컬럼이 cost, 어떤 매체는 spend이고, 통화 단위가 원화인 곳과 마이크로 단위인 곳이 섞입니다. 변환 단계를 계획에 넣지 않으면 데이터는 다 있는데 아무도 못 쓰는 상태가 됩니다. 그래서 최소 두 레이어로 나눕니다. 원시 레이어는 소스를 손대지 않고 그대로 보관하고, 표준화 레이어는 공통 컬럼 규격으로 다시 쓴 테이블을 둡니다. 그 사이를 예약 쿼리가 매일 잇습니다.

표준화 레이어에는 무엇을 넣어야 하나

표준화 레이어의 목표는 매체가 몇 개든 같은 모양의 한 장짜리 테이블이 나오는 것입니다. 최소 컬럼은 날짜, 매체, 캠페인 식별자, 캠페인명, 비용, 노출, 클릭, 전환, 통화 기준입니다. 여기에 UTM 캠페인 값을 함께 남겨두면 나중에 GA4 이벤트 쪽과 이어붙일 조인 키가 생깁니다.

주의할 점은 매체가 보고하는 전환과 자사 분석 도구가 보고하는 전환을 같은 컬럼에 섞지 않는 것입니다. 메타처럼 자체적으로 클릭·전환을 판정해 보고하는 자기귀속 네트워크는 어트리뷰션 로직과 집계 시점이 달라 수치가 구조적으로 어긋납니다. 표준화 테이블에서는 매체 보고 전환과 자사 측정 전환을 별도 컬럼으로 나란히 두고, 차이를 은폐하지 말고 드러내는 편이 나중에 논쟁을 줄입니다.

조회 비용은 어떻게 설계에 반영하나

파이프라인 설계는 조회 설계까지 포함해야 합니다. GA4 Export는 날짜별로 테이블이 분리되는 구조이므로, 대상 날짜 테이블만 지정하거나 날짜 범위 조건으로 좁히면 스캔 대상 자체가 줄어듭니다. 이는 구글이 비용 통제 모범사례에서 권장하는 스캔 바이트 절감 원리와 같습니다.

같은 문서는 실행 전 쿼리 검사기나 드라이런으로 처리 예상 바이트를 미리 확인하고, 청구 바이트 최대값 설정으로 한도를 넘는 쿼리를 실패시켜 예상치 못한 과금을 막으라고 권합니다. 다만 상한을 너무 낮게 걸면 정상 배치 쿼리까지 실패하므로, 정기 쿼리는 며칠간 실제 스캔량을 관측한 뒤 상한을 정하는 순서가 안전합니다. 예상 바이트는 추정치라 실제 청구 바이트와 완전히 같지는 않다는 점도 함께 알아두어야 합니다.