마케팅 분석이 실패하는 가장 흔한 이유는 “분석을 못해서”가 아니라 “같은 질문에 팀마다 다른 숫자가 나와서”입니다. UA는 MMP 숫자를 보고, CRM은 CDP를 보고, 재무는 결제 정산을 보고, 프로덕트는 이벤트 로그를 봅니다. 각자 기준이 다르니 ROAS, 신규, 매출, 리텐션 같은 핵심 지표가 회의 때마다 달라집니다. Single Source of Truth(SSOT)는 대시보드 하나를 만드는 일이 아니라, 데이터 파이프라인 레이어를 통해 ‘정의·정합성·재현성’을 강제하는 일입니다.
SSOT의 목표를 “하나의 DB”로 착각하지 말기
SSOT는 단일 저장소를 뜻하지 않습니다. 원천 데이터는 여러 곳에 존재할 수밖에 없습니다(Ads, MMP, 앱 이벤트, 결제, CRM). 중요한 건 어떤 숫자가 최종 숫자인지, 그 숫자가 어떤 규칙으로 계산되었는지, 그리고 동일한 조건이면 언제나 같은 결과가 나오도록 파이프라인이 설계되어 있는지입니다. 즉 SSOT는 기술보다 운영 규칙과 계약이 더 중요합니다.
- 레이어를 나누면 SSOT가 쉬워진다: Raw → Staging → Core → Mart
실무적으로 가장 강력한 구조는 4단 레이어입니다.
Raw(원본 그대로)
광고 플랫폼 리포트, MMP 포스트백, 앱 이벤트, 결제 로그 등 원천을 가공 없이 적재합니다. 원칙은 “변형 금지, 삭제 금지”입니다. 나중에 정의가 바뀌거나 버그가 발견돼도 재처리가 가능해야 합니다. Raw에는 적재 시각, 소스, 배치 ID 같은 메타데이터를 반드시 붙입니다.
Staging(정규화/클렌징)
포맷을 통일합니다. 타임존, 화폐, 캠페인 네이밍, ID 타입, 결측치 처리 같은 ‘기계적인 표준화’를 여기서 끝냅니다. 또한 dedup(중복 제거) 룰이 이 단계에 들어갑니다. 예를 들어 이벤트 로그는 재전송 때문에 중복이 흔하므로 event_id 또는 (user_id, event_name, ts, request_id) 같은 키로 중복을 제거합니다.
Core(핵심 엔티티 모델)
SSOT의 심장입니다. 마케팅 분석에 필요한 공통 엔티티를 “하나의 스키마”로 모델링합니다. 보통 아래 5개면 대부분 커버됩니다.
- user(또는 device)
- acquisition(유입: install/first_open + source metadata)
- session/engagement(활동)
- conversion(가입/구매/구독)
- cost_spend(채널 비용)
Core 단계의 목적은 “누가, 언제 들어왔고, 어떤 돈을 썼고, 어떤 결과가 나왔는지”를 조인 가능한 형태로 만드는 것입니다.
Mart(분석/대시보드용 집계)
최종 KPI 테이블을 만듭니다. ROAS, CAC, LTV, 리텐션, 코호트 등 리포트에 최적화된 형태입니다. 중요한 원칙은 Mart는 언제든 재생산 가능해야 하며, Core에 정의가 있지 않은 계산을 Mart에서 임의로 만들면 SSOT가 깨집니다.
- SSOT에서 가장 먼저 합의해야 하는 6가지 ‘정의’
파이프라인보다 먼저 합의해야 하는 것은 지표 정의서입니다. 특히 아래 6개는 마케팅/프로덕트/재무가 가장 자주 충돌합니다. - 매출의 소스 오브 트루스
앱 이벤트의 purchase? 결제 게이트웨이? 스토어 정산? 환불 반영은?
권장: 결제/정산을 최상위로 두고, 이벤트는 퍼널/UX용으로 활용합니다. - 신규 유저 정의
install 기준인지, signup 기준인지, first_purchase 기준인지. re-install/restore는 신규인가? - 시간 기준
타임존(UTC vs KST), 매출 인식 시점(결제 승인 vs 정산), 비용 인식 시점(집행일 vs 청구일). - 어트리뷰션 룰
MMP 기준인지, 내부 룰인지, 라스트 클릭/뷰스루 윈도우, 오가닉 처리. - 중복 제거와 ID 전략
anonymous_id→user_id 연결, cross-device, 웹/앱 통합 시 동일인 처리. - 환불/차지백/취소 처리
D0 매출로 잡고 나중에 마이너스 처리할지, 아예 확정 매출만 잡을지.
이 6가지가 문서로 합의되지 않으면, 어떤 SSOT도 ‘한 숫자’를 만들 수 없습니다.
- “ID 그래프” 없이는 SSOT가 없다
마케팅 분석은 결국 조인입니다. 조인이 깨지는 순간 숫자는 갈라집니다. 최소 전략은 다음과 같습니다.
- 모든 이벤트에 stable anonymous_id를 부여한다(앱 설치 단위)
- 로그인/가입 시 user_id와 매핑 테이블(identity_map)을 만든다
- 결제/구독은 user_id를 소스 오브 트루스로 갖고, anonymous와 연결한다
- 광고/어트리뷰션 ID(gaid/idfa), device_id는 보조키로 취급한다
이 identity_map은 SSOT에서 가장 “비싼 자산”입니다. 한번 잘 만들면 코호트/LTV/채널 분석 품질이 크게 달라집니다.
- 비용 데이터(cost)는 생각보다 어렵고, 그래서 더 표준화해야 한다
ROAS가 흔들리는 이유의 절반은 비용입니다. 플랫폼 비용은 다음 이슈가 있습니다.
- 통화/환율(캠페인 국가별)
- 세금/수수료 포함 여부
- 환불/크레딧 반영 시점
- 일별 리포트 지연/정정(backfill)
따라서 cost_spend 테이블은 필수 컬럼을 강제하세요.
(date, platform, account_id, campaign_id, adset_id, ad_id, currency, spend_local, spend_usd, fx_rate, impressions, clicks, report_updated_at)
그리고 비용은 “마지막 갱신 시각 기준으로 재처리”가 가능해야 합니다(정정 데이터가 들어오기 때문).
- 데이터 품질(Data Quality)과 관측(Observability)이 SSOT의 본체다
SSOT는 한 번 만들고 끝나는 게 아니라, 매일 신뢰를 유지하는 시스템입니다. 다음을 자동화하면 회의에서 숫자 싸움이 거의 사라집니다.
- Freshness: 원천별 적재 지연 모니터링(어제 데이터가 들어왔는지)
- Completeness: 필수 컬럼 누락률, 이벤트 발생량 급감/급증 탐지
- Consistency: 예) 결제 이벤트 합계 vs 정산 합계 차이 허용 범위
- Uniqueness: dedup 후 중복률 모니터링
- Lineage: 이 KPI가 어떤 테이블/로직을 거쳤는지 추적 가능
문제는 “발생했을 때 빨리 알리는 것”이 핵심입니다. 데이터 이슈는 늦게 발견할수록 의사결정 비용이 기하급수로 늘어납니다.
- SSOT를 조직에 ‘먹히게’ 만드는 운영 장치
기술적으로 SSOT가 있어도, 팀이 각자 엑셀로 따로 계산하면 SSOT는 실패합니다. 아래 3가지를 권합니다.
- Metric Contract: 핵심 지표는 정의서/SQL/테이블 위치를 고정하고, 임의 계산을 금지
- Change Management: 정의 변경은 버전업하고, 과거 지표가 어떻게 바뀌는지 영향도를 공지
- One-way door 최소화: “바꿨더니 숫자가 달라짐”이 나오면 원본→Core→Mart 재처리가 가능해야 함
실무 구현의 최소 MVP(가장 빠른 로드맵)
1주차: Raw 적재 + 타임존/통화/캠페인 네이밍 표준화(Staging)
2~3주차: Core 엔티티 5개(user/acquisition/session/conversion/cost) 구축
4주차: Mart로 ROAS·CAC·신규·리텐션 1차 대시보드 구성
동시에: 데이터 품질 알림(적재 지연, 이벤트 급감, 비용 정정)을 최소 3개라도 붙이기
이렇게 MVP를 돌리면, 이후 MMM/LTV/증분 측정 같은 고급 분석도 “같은 데이터 기반”에서 자연스럽게 확장됩니다.
결론적으로 SSOT는 데이터웨어하우스가 아니라 ‘결정 시스템’입니다. Raw부터 Mart까지 레이어를 분리하고, 지표 정의와 ID 그래프를 고정하며, 비용 표준화와 데이터 품질 관측을 자동화하면, 마케팅 분석은 “보고용”에서 “예산을 움직이는 도구”로 바뀝니다.