마케팅 데이터
여러 플랫폼의 광고 데이터를 매일 자동 갱신하는 파이프라인으로
Google Ads, Meta Ads, 광고 소재, 고객 리드 데이터를 BigQuery로 모아 분석할 때마다 수동으로 내보내던 과정을 줄였습니다.
문제
광고 성과가 여러 플랫폼에 나뉘어 있었고 계정, 필드, 갱신 방식, 기여도 정의도 달랐습니다. 수동 내보내기로 임시 보고서는 만들 수 있었지만 안정적으로 재실행하기 어려웠습니다. 하루치 데이터가 빠져도 API, 권한, 일정, 스키마 중 어디가 원인인지 알기 어려웠습니다.
제약 조건
- Google Ads와 Meta Ads는 인증 방식, 할당량, 데이터 구조, 갱신 시점이 다릅니다.
- 토큰이 만료되거나 변경될 수 있고 플랫폼의 필드도 별도의 주기로 바뀝니다.
- 실제 광고비, 고객명, 캠페인, 광고 소재는 공개할 수 없습니다.
우리가 한 일
분석용 가공 전에 원본 보존
플랫폼 데이터를 먼저 BigQuery의 추적 가능한 원본 구조에 저장한 뒤 변환 계층에서 공통 차원과 지표를 맞춥니다.
채택하지 않은 대안 추출 단계에서 하나의 일반 보고서로 합치면 플랫폼 고유의 의미와 재계산 근거가 사라지므로 그 방식을 선택하지 않았습니다.
작업 흐름을 관찰 가능한 시스템으로 구성
Cloud Workflows로 일일 실행을 관리하고 플랫폼별 추출, 소재 처리, 고객 리드 수집을 구분 가능한 단계로 나눴습니다.
채택하지 않은 대안 모든 작업을 하나의 장시간 프로세스에 넣으면 장애 위치를 찾기 어렵고 재실행 비용이 커지므로 피했습니다.
반복 실행에도 일관된 쓰기 설계
소스와 날짜 범위로 갱신 대상을 제한해 같은 배치를 재실행해도 일관된 결과가 나오도록 했습니다.
채택하지 않은 대안 성공을 가정하고 계속 추가하는 방식은 일시적인 API 장애 복구 시 중복이나 누락을 만들 수 있어 사용하지 않았습니다.
접근 오류와 데이터 오류 구분
인증, 할당량, 스키마 문제를 별도의 신호로 남겨 원인을 더 쉽게 파악하도록 했습니다.
채택하지 않은 대안 만료된 권한은 시간이 지나도 복구되지 않으므로 모든 API 오류를 동일한 재시도 대상으로 처리하지 않았습니다.
성과
- Google Ads와 Meta Ads 데이터를 매일 BigQuery에 적재합니다.
- 여러 플랫폼의 분석을 수동 파일 모음 대신 하나의 쿼리 계층에서 시작할 수 있습니다.
- 소재 처리와 고객 리드 수집이 추적 가능한 클라우드 작업 흐름에서 실행됩니다.
기술
- Google Ads API
- Meta Marketing API
- BigQuery
- Cloud Workflows
돌아보며
다시 시작한다면 데이터 신선도 기준과 스키마 계약을 더 일찍 정하겠습니다. 데이터가 들어오는 것과 쓸 수 있는 것은 다릅니다. 지연, 과거 데이터 보충, 플랫폼 필드 변경을 보고서에 반영되기 전에 파악해야 합니다.