📑 목차
선정 이유: 2026년 GA4-BigQuery 연동의 필요성
데이터가 쌓인다고 자산이 되지 않는다. 2024년 GA4로의 일괄 전환 이후 2년간 수집된 petabyte급 행동 데이터가 지금도 구글 클라우드 스토리지에 방치되고 있는 기업들이 적지 않다. 문제는 단순 연동이 아니라, 이 Raw 데이터를 마케팅 의사결정에 활용 가능한 구조로 정제하고, 이벤트 택소노미를 표준화하여 데이터 거버넌스를 확립하는 것이 2026년의 진짜 과제라는 사실이다.
특히 개인정보 보호법 강화와 서드파티 쿠키 종식으로 인해 서버사이드 추적과 1st-party 데이터 운용의 중요성이 커진 지금, BigQuery 내 Raw 데이터의 품질이 곧 마케팅 경쟁력이 된다. 단순히 ‘연결만 해두고’ 샘플링 없는 분석을 한다고 해서 데이터 자산이 구축되는 것은 아니다. 이벤트 파라미터의 일관성, 사용자 속성의 표준화, 그리고 ETL 파이프라인을 통한 정제된 데이터 웨어하우스 구축이 없다면 그저 비싼 스토리지 비용만 나가는 쓰레기 데이터에 불과하다.
BigQuery 연동 기본 설정과 2026년 주의사항
BigQuery 연동은 GA4 관리 > 제품 연결 > BigQuery 연결에서 시작한다. 하지만 2026년 현재, 단순히 ‘연결’ 버튼을 누르는 것 이상의 체크포인트가 존재한다.
스트림 ID 설정과 리전 선택
연결 설정 시 가장 먼저 확인해야 할 것은 데이터 스트림의 물리적 위치다. 2026년 기준 한국 기업들은 주로 asia-northeast3(서울) 리전을 선택하지만, 이미 해외 CDN이나 글로벌 서비스를 운영 중이라면 데이터 소버린티 문제로 인해 multi-region 설정을 고려해야 한다. 한번 설정된 리전은 변경이 불가능하며, 데이터 이전 시 export/import 비용이 발생하므로 초기 설계가 중요하다.
Daily export와 Streaming export 중 선택할 때는 비용 구조를 명확히 이해해야 한다. Streaming은 실시간 분석이 가능하지만 1TB당 비용이 발생하는 반면, Daily export는 무료로 제공되나 24시간 이후 데이터 확인이 가능하다. 대부분의 마케팅 분석은 전날 데이터로도 충분하므로, 실시간 트리거가 필요한 경우에만 Streaming을 혼합 사용하는 것이 합리적이다.
데이터 딜레이 및 소급 분석 한계
GA4의 Raw 데이터는 실시간이 아니다. 일반적으로 24~72시간의 처리 지연이 발생하며, 2026년 현재도 이 구조는 변함없다. 또한 연결 설정 이전의 과거 데이터는 소급해서 BigQuery로 전송되지 않는다는 점을 명심해야 한다. 즉, 연동 시점부터 축적되는 데이터만 활용 가능하므로, 데이터 자산화를 위해서는 지금 당장 연결 설정을 완료하는 것이 유일한 해결책이다.
Raw 데이터 자산화를 위한 스키마 설계 원칙
BigQuery로 유입되는 GA4 데이터는 중첩된 반정형 구조로 되어 있다. 이를 분석 가능한 자산으로 변환하려면 unnesting(평탄화) 전략이 필수다.
| 데이터 유형 | 구조 특성 | 처리 방식 | 활용 예시 |
|---|---|---|---|
| events 테이블 | 중첩 레코드(event_params, user_properties) | UNNEST() 함수로 평탄화 | 이벤트 파라미터별 세그먼트 분석 |
| user_pseudo_id | 문자열 타입 | SHA256 해싱 처리 | 개인식별정보(PII) 마스킹 |
| event_timestamp | 마이크로초 단위 정수 | TIMESTAMP_MICROS() 변환 | 시간대별 추세 분석 |
| geo 및 device | 중첩 필드 | STRUCT 접근자 활용 | 지역별 디바이스 성능 비교 |
중첩 레코드 처리 전략
event_params는 key-value 쌍의 ARRAY 형태로 저장된다. SELECT * FROM unnest(event_params) 구문을 통해 개별 파라미터를 컬럼으로 전환해야 분석이 가능하다. 하지만 모든 파라미터를 unnest하면 데이터 용량이 기하급수적으로 늘어나므로, 필수 파라미터만 선별적으로 unnest하는 View를 생성하는 것이 2026년의 표준 관행이다.
특히 user_properties는 세션별이 아닌 사용자별 속성으로, LTV 산정이나 코호트 분석 시 핵심 키가 된다. 다만 user_properties 또한 중첩 구조이며, set_timestamp_micros를 통해 값이 변경되는 이력이 모두 저장되므로, 최신 값만 추출하는 window function 로직이 필요하다.
정교한 이벤트 택소노미 구축 절차
데이터 품질은 수집 시점에 결정된다. BigQuery에서 쓸모 있는 데이터를 얻기 위해서는 GA4 콘솔에서 이벤트 택소노미(분류 체계)를 엄격하게 설계해야 한다.
이벤트 명명 규칙 표준화
2026년 기준 추천하는 명명 규칙은 ‘객체_동사_목적’ 구조다. 예를 들어 ‘button_click_purchase’ 대신 ‘purchase_button_tap’은 직관성이 떨어진다. 대신 ‘ecommerce_purchase_initiated’처럼 도메인_액션_상태 형태로 구성하면, SQL 쿼리 시 WHERE event_name LIKE ‘ecommerce_%’ 구문으로 카테고리별 필터링이 용이하다.
Custom event는 최대 500개까지만 생성 가능하며, 자동 수집 이벤트와 중복되지 않도록 주의해야 한다. 특히 ‘page_view’나 ‘scroll’ 같은 자동 이벤트와 유사한 이름의 커스텀 이벤트를 만들면, 데이터 중복 집계로 인한 분석 오류가 발생한다.
이벤트 파라미터 계층화
파라미터는 전역 파라미터(Global)와 이벤트별 파라미터(Local)로 구분하여 관리한다. user_id, session_id 같은 공통 속성은 Configuration > Custom definitions에서 User-scoped로 설정하고, 특정 이벤트에만 국한된 속성은 Event-scoped로 설정한다. BigQuery에서 unnest할 때, User-scoped 속성은 user_properties에서, Event-scoped 속성은 event_params에서 추출하므로 설계 단계에서 명확한 구분이 쿼리 성능에 직접 영향을 미친다.
ETL 파이프라인 및 SQL 기반 정제 절차
Raw 데이터를 비즈니스 인텔리전스(BI) 도구나 머신러닝 모델에 적용하려면 정제 과정이 필수다. BigQuery 내에서 SQL만으로 ETL 파이프라인을 구축하는 방법을 단계별로 살펴본다.
데이터 클렌징 SQL 패턴
먼저, bot traffic을 필터링해야 한다. event_source, traffic_source.source 필드에서 ‘bot’, ‘crawler’, ‘spider’를 포함하는 세션을 제외하거나, engagement_time_msec이 0인 비정상 세션을 필터링한다. 다음은 기본적인 클렌징 SQL 템플릿이다.
WITH cleaned_data AS (
SELECT
user_pseudo_id,
event_name,
TIMESTAMP_MICROS(event_timestamp) as event_time,
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = ‘page_location’) as page_path
FROM `project.dataset.events_YYYYMMDD`
WHERE
_table_suffix BETWEEN ‘20260101’ AND ‘20260131’
AND (SELECT value.int_value FROM UNNEST(event_params) WHERE key = ‘engagement_time_msec’) > 0
)
이처럼 서브쿼리를 활용한 UNNEST는 컴퓨팅 비용이 높으므로, 가능한 한 물리적 테이블로 materialized view를 생성하여 캐싱하는 전략이 필요하다.
PII(개인식별정보) 마스킹 및 암호화
GDPR과 개인정보 보호법 준수를 위해, user_pseudo_id나 GA4에서 수집된 이메일, 전화번호 등은 반드시 해싱 처리해야 한다. BigQuery native 함수인 SHA256()을 활용하되, salt 값을 추가하여 레인보우 테이블 공격을 방지한다.
CREATE VIEW `project.dataset.sanitized_events` AS
SELECT
TO_BASE64(SHA256(CONCAT(user_pseudo_id, ‘YOUR_SECRET_SALT’))) as hashed_user_id,
event_name,
event_timestamp,
geo.country,
device.category
FROM `project.dataset.events_*`
WHERE NOT EXISTS (
SELECT 1 FROM UNNEST(event_params)
WHERE key = ‘page_location’
AND value.string_value LIKE ‘%admin%’ — 내부 관리자 IP 필터링
)
자주 묻는 질문
Q. GA4 BigQuery 연동 비용은 얼마나 드나요?
A. Google Analytics 360이 아닌 무료 GA4 버전도 BigQuery 연동 자체는 무료입니다. 다만 BigQuery 스토리지는 1GB당 약 $0.02/월이며, 쿼리 처리량은 1TB당 $6.25가 청구됩니다. Daily export 방식을 사용하면 스트리밍 비용이 없으므로, 스토리지 비용만 부담하면 됩니다. 2026년 기준으로 데이터를 정기적으로 파티셔닝하고 오래된 데이터는 Coldline 스토리지로 이동시키는 lifecycle policy 설정을 권장합니다.
Q. Raw 데이터와 GA4 콘솔의 집계 데이터가 차이가 나는 이유는 무엇인가요?
A. GA4 콘솔은 데이터 신속성( freshness)을 위해 샘플링이나 추정치를 사용하고, BigQuery는 원시(raw) 데이터를 제공하기 때문입니다. 특히 실시간 보고서와 BigQuery의 24시간 지연 데이터는 동기화 시점이 다릅니다. 또한 GA4 콘솔에서 필터링된 내부 트래픽도 BigQuery에는 그대로 남아있어, SQL에서 별도로 필터링하지 않으면 수치 차이가 발생합니다.
Q. 기존에 쌓인 데이터의 스키마를 변경하려면 어떻게 해야 하나요?
A. BigQuery는 schema-on-read 방식이므로, 기존 테이블의 스키마를 물리적으로 변경하는 것은 불가능합니다. 대신 뷰(View) 또는 머티리얼라이즈드 뷰(Materialized View)를 생성하여 원하는 컬럼 구조로 변환해서 사용하거나, 새로운 테이블로 CTAS(Create Table As Select)하여 마이그레이션해야 합니다. 데이터 자산화 관점에서는 cleansing 및 unnesting 로직을 포함한 뷰 레이어를 개발 환경으로 제공하고, 민감정보가 제거된 테이블만 마케팅팀에 공개하는 구조가 안전합니다.