광고 임프레션이 일어난 그 순간부터 BI 대시보드의 ROAS 한 숫자가 되기까지, 데이터는 5개 레이어를 거칩니다. 매체 → 트래커 → 데이터 웨어하우스 → 변환 → BI. 각 레이어에서 데이터가 어떻게 변하고 어디서 깨지는지 알면 보고서의 숫자가 다른 깊이로 보입니다. 시리즈 4 매체 기초의 마무리, 모든 광고 측정 글의 토대.
1. 5 레이어의 한 줄 흐름
광고 측정의 데이터 흐름:
매체(임프레션·클릭) → 트래커(어트리뷰션) → 데이터 웨어하우스(저장) → 변환·집계 → BI 대시보드
각 레이어가 다른 역할:
| 레이어 | 역할 | 도구 예시 |
|---|---|---|
| 매체 | raw 이벤트 발생 | 광고 매니저·SDK |
| 트래커 | 어트리뷰션·결합 | Adjust·AppsFlyer·GA4·Conversions API |
| DW | 영구 저장·통합 | BigQuery·Snowflake·Redshift |
| 변환 | 비즈니스 룰 적용 | dbt·Airflow·SQL |
| BI | 시각화·대시보드 | Looker·Tableau·Metabase |
각 레이어에서 데이터가 변형됨. 한 레이어라도 잘못되면 BI의 숫자가 가짜.
매체에서 raw 이벤트가 일어난 순간부터 BI의 ROAS 한 숫자까지 5 레이어. 각 레이어의 정합성이 보고서 신뢰의 토대.
📌 이 글에서 다루는 것
이 글은 광고 측정의 인프라 흐름·각 레이어의 역할·운영 표준에 집중. 마케터가 직접 인프라 구축할 일은 적지만 보고서 한 숫자가 어디서 어떻게 만들어졌는지 이해가 운영 깊이의 토대. 시리즈 4 매체 기초의 마지막.
2. 레이어 1 — 매체
광고 임프레션·클릭이 발생하는 자리. raw 이벤트:
- Meta·Google·TikTok 등 광고 매체
- SDK가 앱 안에서 이벤트 수집
- Pixel·태그가 웹에서 이벤트 수집
이 레이어의 데이터:
- 임프레션 — 누가·언제·어떤 슬롯
- 클릭 — 어떤 광고·어떤 사용자
- 전환 — 이벤트 발생 시점·종류
운영적 자리:
- 광고 매니저 화면이 사실상 매체 레이어의 사용자 인터페이스
- 보고서 데이터는 매체가 직접 집계해 제공
함정:
- 매체별 정의 차이 — Meta의 "전환"과 Google의 "전환"이 다른 정의
- 시간 zone 차이 — 매체별 보고 기준 시간 다름
- 어트리뷰션 윈도 — 매체별 1일·7일·28일 다른 룰
3. 레이어 2 — 트래커
매체 데이터를 통합·어트리뷰션. 모바일 앱 광고에선 MMP(Mobile Measurement Partner) 표준.
대표:
- 모바일 — Adjust·AppsFlyer·Singular·Branch
- 웹 — GA4·Adobe Analytics
- 서버 — Conversions API·Server-Side GTM
이 레이어의 역할:
- 매체별 데이터 통합
- 어트리뷰션 룰 적용 (last-click·multi-touch)
- 사용자 식별 (cookie·device ID·이메일 해시)
- 부정 클릭 필터링
함정:
- 매체와 트래커의 숫자 차이 (10-20% 일반)
- 어트리뷰션 윈도 정의 차이
- iOS 14.5 이후 device ID 매칭 약화
4. 레이어 3 — 데이터 웨어하우스
트래커·매체·CRM 데이터를 영구 저장. 운영 표준:
- BigQuery (Google 생태계)
- Snowflake (멀티 클라우드)
- Redshift (AWS)
- Databricks (ML 통합)
이 레이어의 역할:
- 모든 raw 데이터 저장 (수년)
- SQL·Python으로 분석 가능
- 다른 시스템과의 통합 자리
함정:
- 데이터 동기화 지연 (실시간 vs 일별 batch)
- 스키마 변화 — 매체 보고서 형식 변경 시 파이프라인 깨짐
- 비용 — 큰 데이터셋의 저장·쿼리 비용
5. 레이어 4 — 변환·집계
raw 데이터를 비즈니스 룰에 맞춰 변환. 운영 표준:
- dbt — SQL 기반 변환 표준
- Airflow — 작업 오케스트레이션
- SQL stored procedure — 단순 변환
이 레이어의 역할:
- 메트릭 정의 적용 (CAC·LTV·ROAS의 회사 정의)
- 어트리뷰션 룰 일관성 (last-click·multi-touch)
- 시간 window 집계 (일·주·월)
- 세그먼트 분해
함정:
- 메트릭 정의의 모호함 — "신규 고객"의 정의가 팀별로 다르면 보고서 차이
- 변환 룰의 변경 — 과거 보고서와 비교 어려움
- 누적 오류 — 한 변환의 오류가 모든 후속에 영향
6. 레이어 5 — BI 대시보드
최종 시각화. 운영자·의사결정자가 직접 보는 자리.
대표:
- Looker (Google)
- Tableau
- Metabase
- Power BI
- 자체 대시보드 (React·Streamlit)
이 레이어의 역할:
- 메트릭의 시각화
- 시간·세그먼트 필터
- 알람·조건부 알림
- 의사결정 지원
함정:
- 대시보드의 정의가 변환 레이어와 어긋남
- 캐시·동기화 지연으로 실시간 데이터 안 됨
- 너무 많은 메트릭 — 의사결정 산만
[매체] 임프레션·클릭·전환 raw 이벤트
↓
[트래커] 어트리뷰션·매체 통합·식별
↓
[DW] BigQuery·Snowflake에 영구 저장
↓
[변환] dbt로 메트릭·세그먼트 변환
↓
[BI] Looker·Tableau로 시각화
이게 본문에 박는 유일한 코드(텍스트 다이어그램)입니다.
7. 레이어 간 자주 깨지는 자리
7-1. 매체 ↔ 트래커 차이
매체가 직접 집계한 숫자와 트래커 숫자가 다름. 보통 트래커가 더 정확. 차이 10-20%면 정상, 50%+면 매칭 문제.
7-2. 트래커 ↔ DW 동기화 지연
실시간 데이터가 아니라 일별 batch. 어제 보고서가 오늘 아침에 들어옴. 실시간 의사결정 어려움.
7-3. DW ↔ 변환 메트릭 정의
변환 레이어의 SQL 룰이 운영팀 정의와 다름. CAC·LTV·ROAS의 정의 차이로 보고서 숫자 다름. 회사 안에서 정의 통일 필수.
7-4. 변환 ↔ BI 캐시
BI 대시보드의 캐시가 오래된 데이터 보여줌. 새로고침 안 하면 잘못된 숫자에 결정.
7-5. 통합 정합성
같은 ROAS가 매체·MMP·BI에서 다 다른 자리. 5개 레이어의 정의·시간·매칭이 모두 일치해야.
8. 운영 표준 — 정합성 확보
8-1. 일별 정합성 검증
5개 레이어의 핵심 메트릭(매출·전환·노출)을 매일 자동 비교. 차이가 일정 임계 넘으면 알람.
8-2. 메트릭 카탈로그
회사 안 표준 메트릭 정의 문서. dbt의 metrics.yml이나 Looker의 LookML로 코드 단위 정의. 사람이 텍스트로 풀어 쓰지 말고 코드로 통일.
8-3. 데이터 lineage
한 BI 숫자가 어떤 변환·DW·트래커·매체 데이터에서 왔는지 추적 가능. 보고서 의심 시 빠른 디버깅.
8-4. 분기 감사
분기마다 5 레이어 데이터 흐름·메트릭 정의·동기화 점검. 누적된 작은 차이가 큰 보고서 오류로 누적.
💡 정합성이 보고서 신뢰의 토대
BI 대시보드의 한 숫자가 신뢰받으려면 5개 레이어 모두에서 일관성. 한 레이어라도 깨지면 보고서 가치 떨어짐. 정합성 인프라 구축이 광고 측정의 가장 큰 운영 가치.
9. 마케팅 실무 적용
9-1. 보고서 차이 디버깅
"Meta 광고 매니저는 ROAS 5라는데 BI는 1.5예요." 5 레이어를 차례로 점검:
- 매체(Meta) — last-click·view-through 모두 포함
- MMP — 어트리뷰션 윈도·중복 제거
- DW — 데이터 도착 시점·완전성
- 변환 — ROAS 정의·필터
- BI — 캐시·필터 설정
각 단계의 차이를 분리해야 진짜 원인 발견.
9-2. 새 캠페인 측정 인프라
새 채널 도입 시 5 레이어 모두 사전 점검:
- 매체에서 어떤 이벤트 수집 가능?
- 트래커가 그 매체와 통합?
- DW에 데이터 흐름 설계
- 변환 룰에 새 채널 포함
- BI 대시보드에 추가
9-3. 메트릭 정의 변경
ROAS 정의를 last-click → incremental로 바꿀 때 5 레이어 모두 업데이트. 하나라도 빠지면 정합성 깨짐.
{/* TODO_HUNY: huny가 운영 중인 측정 인프라에서 5 레이어 중 가장 자주 깨지는 자리 한 가지 추가해주세요. 매체·MMP·DW·변환·BI 중 어디. */}
10. 데이터 흐름에 익숙해지면
이 토대가 잡혀 있으면 huny.log의 광고 글들이 다른 깊이로 읽힙니다.
- 어트리뷰션의 역사 — 측정 도구의 변화
- GA4 + BigQuery ROAS — 직접 파이프라인 구축
- CDP ID 그래프 — 1st party 데이터 통합
- RTB와 입찰 — 매체 레이어의 메커니즘
11. 시리즈 4 마무리 — 기초 체력 15편의 도구상자
이 시리즈 15편으로 마케터의 기초 체력을 정리했습니다.
11-1. AI 5편
- LLM 기초 — 토큰·다음 단어 예측·temperature
- 임베딩 기초 — 단어가 숫자가 되는 자리
- 트랜스포머 직관 — attention의 의미
- 도구 분기 — fine-tuning vs RAG vs prompting
- LLM 환각 — 자신 있게 틀린 답
11-2. ML 5편
- 회귀와 분류 — 두 모델 가족
- 손실 함수와 학습 — 모델이 배우는 방식
- overfitting — 외운 모델 vs 일반화
- 평가 지표 도구상자 — accuracy부터 AUC-PR
- Cross-validation — 진짜 성능 측정
11-3. 매체 5편
- 광고 생태계 지도 — DSP·SSP·DMP·CDP
- RTB와 입찰 — 0.1초의 경매
- 어트리뷰션의 역사 — 쿠키부터 클린룸
- 광고 KPI 한 그림 — 7개 KPI 관계
- 광고 측정 데이터 흐름 — 5 레이어
이 15편이 huny.log의 모든 시리즈 1·2·3 글의 토대. 처음 들어오는 마케터가 이 글들로 시작하면 그 다음 모든 도구가 자연스럽게 읽힙니다.
12. 마치며 — 기초가 깊으면 도구가 살아난다
마케터의 일은 도구의 일이 아니라 의사결정의 일입니다. 도구는 의사결정의 깊이를 만드는 토대. 기초 체력이 깊으면 같은 도구가 다르게 쓰입니다.
임프레션 → 트래커 → DW → 변환 → BI. 한 숫자의 5 레이어. 정합성이 신뢰의 토대.
다음 시리즈는 huny가 IDE에서 58편의 TODO_HUNY를 채워 시리즈를 완성하는 시간으로. 도구상자가 풍부해졌으니 이제 진짜 운영 경험으로 색을 입히는 자리.
참고
- Kimball & Ross (2013), The Data Warehouse Toolkit — DW 표준 교과서
- dbt 공식 문서 — 변환 레이어 표준
- Adjust·AppsFlyer 문서 — MMP 표준
- Google Marketing Platform — 통합 측정 표준
- LookML 문서 — BI 메트릭 코드화
- huny.log 내부 글: GA4 + BigQuery ROAS, 어트리뷰션의 역사, 광고 KPI, 광고 생태계 지도, RTB와 입찰
