데이터 인프라·거버넌스 구축

GA4 BigQuery Export는 프로젝트 안에 analytics_<속성ID> 형식의 데이터세트를 만들고, 그 안에 일일 내보내기 결과를 events_YYYYMMDD 테이블로, 스트리밍 내보내기 결과를 events_intraday_YYYYMMDD 테이블로 적재한다. events_intraday_ 테이블은 매일 삭제되는 스테이징 성격의 테이블이다.

GA4 BigQuery Export 스키마의 주요 최상위 필드는 event_date, event_timestamp, event_previous_timestamp, event_name, event_value_in_usd, event_params(반복 레코드), user_id, user_pseudo_id, user_first_touch_timestamp, privacy_info, user_properties(반복 레코드), user_ltv, device, geo, app_info, collected_traffic_source, traffic_source, session_traffic_source_last_click, stream_id, platform, ecommerce, items(반복 레코드, item_params 중첩)이다.

GA4 BigQuery Export 스키마 문서는 traffic_source 필드를 '최초 접점(first-touch) 어트리뷰션 데이터'로 정의하며, 이 필드는 intraday(스트리밍) 테이블에는 포함되지 않는다고 명시한다.

구글 클라우드 공식 문서 '비용 통제 모범사례'가 제시하는 권장 항목에는 맞춤 쿼리 할당량 만들기(Create custom query quotas), 쿼리 실행 전 예상 비용 확인하기(Check the estimated cost before running a query), 쿼리당 청구 바이트 제한하기(Restrict the number of bytes billed per query), 클러스터링되지 않은 테이블에서 LIMIT 사용 피하기(Avoid using LIMIT in non-clustered tables), 테이블 데이터를 살펴보려고 쿼리를 실행하지 않기(Avoid running queries to explore table data), 쿼리 결과를 단계적으로 구체화하기(Materialize query results in stages)가 포함된다.

BigQuery에서 LIMIT 절은 클러스터링되지 않은 테이블의 쿼리 비용을 줄이지 못한다. 반환 행 수를 제한해도 스캔 대상 전체에 대해 과금되기 때문에, LIMIT 10을 붙여도 테이블 전체를 스캔한 만큼 청구된다.

BigQuery는 쿼리를 실제로 실행하기 전에 콘솔의 쿼리 검사기(query validator) 또는 드라이런(dry run)으로 처리 예상 바이트를 미리 확인할 수 있고, '청구 바이트 최대값(maximum bytes billed)' 설정으로 그 한도를 넘는 쿼리는 실행 자체를 실패시켜 예상치 못한 과금을 막을 수 있다.

BigQuery 요금은 컴퓨팅(분석)과 스토리지 두 축으로 나뉜다. 컴퓨팅은 쿼리가 처리한 바이트 기준으로 과금하는 온디맨드 모델과, 슬롯을 예약·약정하는 용량(에디션) 모델 중 선택한다. 스토리지는 액티브/장기 구분과 스토리지 청구 모델(논리 바이트/물리 바이트) 설정에 따라 달라진다. 구체적 단가는 리전과 시점에 따라 달라지므로 구글 클라우드 공식 가격표에서 해당 리전 기준으로 확인해야 한다.

BigQuery의 사전 정의 IAM 역할에는 BigQuery Admin(roles/bigquery.admin), BigQuery Data Viewer(roles/bigquery.dataViewer), BigQuery Data Editor(roles/bigquery.dataEditor), BigQuery Data Owner(roles/bigquery.dataOwner), BigQuery Job User(roles/bigquery.jobUser), BigQuery Metadata Viewer(roles/bigquery.metadataViewer), BigQuery Read Session User(roles/bigquery.readSessionUser) 등이 있다.

BigQuery는 데이터 접근 권한과 작업(쿼리) 실행 권한을 분리한다. Data Viewer 같은 데이터 역할만으로는 쿼리 작업을 실행할 수 없고, 프로젝트 안에서 쿼리를 포함한 작업을 실행하려면 Job User(roles/bigquery.jobUser) 역할이 별도로 필요하다. 이 분리는 최소권한 원칙을 강제하는 설계다.

BigQuery의 IAM 정책은 조직, 프로젝트, 데이터세트, 테이블·뷰, 루틴, 커넥션 수준에서 설정할 수 있다. 더 세밀한 통제로는 사용자가 접근할 수 있는 테이블 행을 제한하는 행 수준 보안(row-level security)과, 특정 열 접근을 통제하고 데이터 마스킹을 적용할 수 있는 열 수준 보안(column-level security)이 제공된다.

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는 프리뷰). 장애·공백 구간을 메우는 백필(backfill) 기능도 제공한다.

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

안드로이드 앱의 웹뷰 안에서 발생한 행동을 Google Analytics for Firebase로 측정하려면, 네이티브 코드에서 addJavascriptInterface로 'AnalyticsWebInterface'라는 이름의 자바스크립트 인터페이스를 등록하고, 그 클래스에 @JavascriptInterface로 표시된 logEvent(String name, String jsonParams)와 setUserProperty(String name, String value) 메서드를 노출한다. 웹 페이지는 window.AnalyticsWebInterface.logEvent(name, JSON.stringify(params)) 형태로 호출한다.

iOS 앱의 웹뷰 측정은 WKWebView에 'firebase'라는 이름으로 등록한 WKScriptMessageHandler가 메시지를 받는 구조다. 웹 페이지는 window.webkit.messageHandlers.firebase.postMessage()로 command: 'logEvent' 또는 command: 'setUserProperty'를 담은 객체를 전달하고, 네이티브 핸들러가 이를 받아 Firebase Analytics를 호출한다.

Firebase 웹뷰 측정 문서는 iOS에서 SDK가 가능한 경우 인앱 구매를 계속 자동 기록하며, 수동으로 기록한 인앱 구매 이벤트를 중복 제거(de-duplicate)하지 않는다고 명시한다.

GA4 BigQuery Export는 날짜별로 events_YYYYMMDD 테이블을 분리 생성하는 구조이므로, 조회 시 대상 날짜 테이블만 지정하거나 _TABLE_SUFFIX 조건으로 날짜 범위를 좁히면 스캔 대상 자체가 줄어든다. 이는 구글이 비용 통제 모범사례에서 권장하는 '스캔 바이트를 줄이는 설계'와 같은 원리다.

국내 공식 기준이 없는 성과·품질 지표는 자사 데이터로 기준선을 세워 판단한다. 절차는 ①최소 4주치 기준선 확보 ②한 번에 한 항목만 변경 ③같은 요일끼리 비교 ④가능하면 홀드아웃 그룹을 남겨 대조하는 순서다.