CMSLAB 프로젝트 전체그림

버전: v0.1
기준일: 2026-08-25
상태: Discovery 착수 — 고객 원본 데이터 수령 전
이전 기준선: 2026-08-24 착수보고 시점 자료

1. 현재 한 문장

현행 ERP와 업무시스템은 유지하면서 ERP·WMS·판매채널·업무시트·광고 등 분산 원천을 고객 소유 클라우드에 통합하고, 공통 SKU·채널·창고 기준으로 13개 업무 기능을 제공하는 프로젝트다.

현재는 기능 개발 단계가 아니라 각 원천의 실제 파일 구조, 정기 추출 가능성, 데이터 오너와 정책 기준을 확인하는 Discovery 단계다.

2. 확인된 것과 아직 확인되지 않은 것

3. 현재 데이터 흐름

[ERP / WMS·3PL / 판매채널 / 광고·대행사 / 부서별 파일]
                         ↓
        화면 다운로드 · 수기 취합 · 일부 API/BigQuery
                         ↓
 [도서관파일 / 공급계획 / 매출취합 / 개인·부서별 시트]
                         ↓
  부서별 숫자 불일치 · 재고 대조 · 월말 의존 · 이력 단절

4. 목표 데이터 흐름

원천 유지
ERP · WMS · 3PL · 채널 · 시트 · 광고
    ↓ API / DB / 배치 / 표준 파일 업로드
고객 소유 Raw 영역
    ↓ 품질검사 · 표준화 · 이력관리
공통 모델
SKU · 채널 · 거래선 · 창고 · 조직
    ↓
업무 Data Mart
매출 · 재고/공급 · 마스터 · 마케팅 · 품질/채권
    ↓
13개 업무 기능과 통합 조회

5. 13개 기능 묶음

6. 현재 가장 중요한 착수 게이트

1. 고객이 제공할 실제 자료 목록과 예상 전달일 확보
2. ERP의 정기 추출 경로와 기술 협의 담당자 확정
3. 이천 WMS 및 전체 재고 원천·보관 거점 실체 확인
4. 도서관파일·SCM 시트·제품/SKU 코드표 수령
5. 기존 BigQuery 자산의 접근과 재사용 가능성 확인
6. GCP/AWS 결정 주체·시점과 고객 소유 계정 개설 방식 확정
7. 매출 인식·재고 배정·SKU 오너십 우선 정책 결정

7. 현재 판단

• 요구사항은 상세하지만 구축 입력물인 실제 데이터가 아직 없다.
• ERP 조회 권한 확보는 완료가 아니라 추출 방식 검증의 시작이다.
• 기존 BigQuery 자산을 확인하기 전에 CSP를 확정하면 이중 관리가 생길 수 있다.
• 매출과 재고를 먼저 연결해야 다른 기능이 사용할 공통키와 품질 기준을 검증할 수 있다.
• 13개 기능을 같은 깊이로 동시에 구현하지 않고 공통 원천과 정책 의존성 순서로 묶어야 한다.

8. 다음 버전으로 올라가는 조건

다음 중 하나 이상이 확인되면 v0.2를 만든다.

• 고객 원본 파일이 실제로 도착해 데이터 구조·품질을 프로파일링함
• ERP·WMS·BigQuery 추출 방식이 확정됨
• CSP와 고객 소유 계정 방향이 결정됨
• 핵심 정책 3건(매출 인식·재고 배정·SKU 오너십)이 결정됨
• Discovery 범위확정서 초안이 작성됨

9. 근거와 연결 문서

• 고객 원본: 01_고객원본/
• 내부 파생분석: 04_분석설계/데이터분석/
• 상세 요구사항: 04_분석설계/요구사항/
• 자료 요청 현황: 03_실행관리/자료요청/
• 실행 일정: 03_실행관리/WBS/
• 회의 근거: 03_실행관리/회의록/, 03_실행관리/회의록_원문전사록/

변경 이력

CMSLAB 조직별 R&R — 고객 제공 기준

• 기준일: 2026-06-23
• 출처: 01_고객원본/2026-06-23_CMSLAB_AI-Ready데이터시스템구축방안_고객원본.pdf 2페이지
• 성격: 고객 제공자료의 「내부 조직도 및 부서별 업무 분장」 전사본
• 주의: 현재 조직명·소속·담당 범위와 동일한지는 프로젝트 인터뷰에서 재확인한다. 아래 표는 프로젝트가 새로 정의한 RACI가 아니다.

고객 제공 조직별 핵심 R&R

프로젝트에서 우선 참조할 연결

사용 원칙

1. 이 표는 인터뷰 대상과 데이터 오너 후보를 찾는 출발점으로 사용한다.
2. 업무를 사용한다, 파일을 생성한다, 정본을 승인한다, 시스템을 운영한다를 같은 책임으로 간주하지 않는다.
3. 실제 데이터별 생성자·수정자·승인자·기술 오너는 자료 수령 후 별도 RACI로 확정한다.
4. 고객 문서의 팀명과 현재 인터뷰에서 사용하는 명칭이 다르면 최신 조직명을 확인하고 매핑 이력을 남긴다.

CMSLAB 마스터·재고 우선 실행전략

기준일: 2026-08-25
계획기간: 2026-08-25 ~ 2026-12-23
상태: 고객 원본 수령 전 가설 기반 실행안
목적: 제품·원료·LOT 기준을 먼저 세워 재고, 매출, 마케팅 데이터를 같은 언어로 연결한다.

1. 실행 판단

현재 13개 요구기능을 화면 단위로 동시에 개발하면 SKU·원료·LOT·창고·채널의 기준이 서로 달라 재작업이 생긴다. 따라서 다음 순서로 진행한다.

고객 자료 수령·실물 진단
        ↓
제품/SKU · 원료 · LOT · 창고 기준 확정
        ↓
재고 원천 수합 · 적재 규칙 교육 · 우선 원천 적용
        ↓
채널 특징·매출기준·가마감·손익
        + 프로모션·광고 데이터 공통기획
        + 제품·재고·매출 조인키 게이트
        ↓
┌───────────────────────┴───────────────────────┐
│ 트랙 A: 재고·매출                              │ 트랙 B: 마케팅
│ 창고/채널 기준 → 재고·입고 → 채널매출          │ 채널·캠페인 마스터 → 수집
│ → 가마감 → 손익 → 판매계획                     │ → 프로모션 → 광고×실적
└───────────────────────┬───────────────────────┘
                        ↓
                 ⑬ 외부 시장데이터(MI)
                        ↓
                통합 대사 · UAT · 운영 인계

핵심 원칙은 다음과 같다.

1. 화면보다 기준정보·원천·대사 규칙을 먼저 확정한다.
2. 자동연동이 늦어져도 표준 업로드 양식으로 업무 검증을 먼저 시작한다.
3. 데이터 제공일과 정책 결정일을 일정의 게이트로 관리한다.
4. 각 기능은 원천 수치와 재현 가능한 대사가 끝나야 완료로 본다.
5. 교육은 실제 마트와 적재 규칙이 준비된 뒤 해당 업무 데이터로 수행한다.
6. 프로모션·광고의 세부 구현은 뒤에 하더라도 데이터 요구와 매출·손익 연결키는 9월에 함께 설계한다.
7. 제품·재고·매출은 item_code·기준일·채널·창고·유효기간으로 실제 표본 조인을 통과해야 한다.
8. 인터뷰에서는 위시켓 데모 화면을 먼저 제시하지 않고, EDA와 업무가설을 바탕으로 실제 업무·데이터·판단 흐름을 확인한다.

2. 요구기능 번호 정정

사용자가 말한 “5, 6, 7, 8 재고·입고·제품·원료 마스터”의 업무 의미는 맞지만, 현재 요구정의서 번호는 아래와 같다.

따라서 본 계획의 기반 구간은 ⑤·⑥·⑦·⑪, 마케팅 트랙은 ⑧·⑨, 마지막은 ⑬으로 표기한다.

3. 단계 계획과 게이트

기간은 고객 자료 수령과 정책 결정이 예정대로 이뤄진다는 가정의 내부 기준선이다. 게이트가 충족되지 않으면 다음 단계의 화면 개발을 강행하지 않고, 확보 원천 기준의 PoC와 표준 업로드 방식으로 범위를 조정한다.

4. 먼저 맞춰야 할 공통 기준

5. 트랙별 실행 내용

5.1 기반 트랙 — ⑤·⑥·⑦·⑪

1. 고객에게서 받은 제품, 원료, LOT, 재고 원본을 컬럼·건수·키·이력 기준으로 프로파일링한다.
2. LOT 마스터 초안을 협의판으로 사용하되, 모든 정보를 한 테이블에 넣지 않고 제품·원료·LOT·창고 매핑의 최소키를 먼저 정한다.
3. 재고 원천별 스냅샷 시각, 수량 부호, 상태, 단위, 정정·재처리 규칙을 문서화한다.
4. 표준 업로드 템플릿과 오류 리포트를 만든 뒤 SCM·물류 키맨에게 실제 파일로 적재 교육을 한다.
5. ERP와 우선 WMS/창고를 적용하고, 같은 기준시각의 수량 차이를 원인코드로 관리한다.

5.2 공통 데이터기획 — 채널 수익·마케팅

세부 구현 트랙이 갈라지기 전에 다음을 하나의 설계 패키지로 9월에 정리한다.

1. 채널별 판매·출고·정산·EDI·반품 기준과 채널 특성을 비교한다.
2. 도서관파일, 가마감 수기보정, 확정시점과 손익의 원가·수수료·할인·비용 배분 원천을 파악한다.
3. 프로모션·캠페인·광고 데이터의 필수필드와 입도를 정의하고, 채널매출·가마감·손익과 연결할 키를 정한다.
4. 채널·item_code·기간·promo_id/campaign_id를 중심으로 데이터 계약을 먼저 승인하고 수집·화면 구현은 후속 트랙에서 진행한다.
5. 인터뷰 전 동일기간 표본 EDA와 업무흐름 가설을 준비하고, 위시켓 데모·와이어프레임은 제시하지 않는다.

5.3 병렬 트랙 A — 재고·매출

③ 손익은 ② 확정매출과 비용 배분정책에 의존하므로 마지막에 둔다. ④ 판매계획은 재고 경보에 필요하므로 데이터 모델은 A2부터 병행하되, 화면 완료는 매출키가 안정된 뒤로 둔다.

5.4 병렬 트랙 B — 마케팅

1. 채널, 계정, 매체, 캠페인, 광고그룹, 소재, 프로모션, SKU의 최소 마스터 뼈대를 확정한다.
2. 계정 소유자와 대행사 반출 가능 범위를 먼저 확인한다.
3. API 가능 채널은 자동수집, 불가 채널은 표준 파일 업로드로 같은 Raw 구조에 적재한다.
4. ⑧ 프로모션 캘린더를 Campaign·채널·SKU·기간 기준으로 관리한다.
5. ⑨ 광고×실적은 집행액과 매출의 집계 수준이 맞는 구간부터 연결하고, 인과효과가 아니라 관측 가능한 상관·기여 지표로 표현한다.

5.5 별도 트랙: 9월 연결부 설계, 10월 선행협의·후반 구현 — ⑬ MI

MI는 계약상 사용권, 외부 카테고리 체계, 비용과 갱신주기가 내부 매출·마케팅 데이터와 달라 별도 트랙으로 둔다. 다만 나중에 연결되지 않는 일을 막기 위해 9월에 국가·채널·브랜드·카테고리·item_code·기준기간 연결 후보와 수용항목만 먼저 설계한다. 원천·사용권·샘플 협의는 10월 12일부터 시작하고 10월 30일까지 사용 가능 범위와 매핑 PoC 범위를 확정한다. 첫 구현은 범용 자동분류보다 다음에 집중한다.

• 표준 CSV 업로드
• 외부 카테고리·키워드와 내부 SKU 수동 매핑
• 매핑 이력·미매핑 목록
• 자사 매출·제품과 연결한 기회요약

6. 핵심 마일스톤

목표일은 고객 일정과 자료 제공일 확인 후 베이스라인으로 동결한다.

7. 고객 협조가 필요한 항목

8. 완료 정의

기능은 화면이 보이는 것만으로 완료하지 않는다. 다음 조건을 모두 충족해야 한다.

• 원천, 오너, 갱신주기, 추출방법이 문서화됨
• 공통키 매핑률과 미매핑 예외가 측정됨
• 표본 기간의 원천 합계와 마트·화면 합계가 대사됨
• 수기보정과 재처리 이력이 남음
• 권한과 개인정보 범위가 검증됨
• 고객 키맨이 실제 업무 시나리오로 확인함
• 운영자가 적재 실패를 확인하고 재실행할 수 있음

9. 범위 공백과 결정 필요사항

현재 사용자가 제시한 실행 흐름에는 ⑩ VOC·품질과 ⑫ 메디컬 채권·거래처의 구현 순서가 포함되어 있지 않다. 기존 13개 요구기능에서 제외된 것으로 간주하지 않고, 9/11까지 아래 중 하나로 결정한다.

1. 이번 구축의 필수 범위로 유지하고 11월 병렬 슬롯에 배치
2. 원천 적재·모델 설계까지만 수행하고 화면은 후속으로 이관
3. 명시적 범위 변경 승인을 거쳐 후속 단계로 분리

또한 아래 사항은 개발 전 결정이 필요하다.

• ERP/WMS/시트 연동이 1회성인지 지속연동인지
• 기존 시트를 원천으로 유지할지 표준 입력폼으로 전환할지
• SKU·원료·채널 기준정보의 최종 결정권자와 변경 승인 절차
• 재고 가용·배정·락 정책과 공개 범위
• 매출 인식·가마감·손익 배분 기준
• 광고계정·MI 데이터의 제공권한과 사용범위

10. 운영 방식

• 매주 월요일: WBS, 자료제공, 결정, 리스크 상태 갱신
• 화~목요일: 원천 실사, 정책 워크숍, 설계·구현·표본 대사
• 금요일: 시연, 완료조건 점검, 다음 주 의존성 확정
• 결정사항은 구두 합의로 끝내지 않고 결정 로그에 오너·일자·영향을 기록
• 고객 자료가 도착하면 2영업일 내 프로파일링하고 WBS의 실착수일·예상종료일을 갱신
• 상세 진척은 CMSLAB_상세WBS_마스터재고우선_2026-08-25.xlsx를 정본으로 관리

변경 이력

CMSLAB 재고·아이템·원료·LOT 협의 기획

• 작성일: 2026-08-25
• 목적: 고객 자료 수령 후 화장품_제약_LOT_마스터_초안_v3.xlsx를 놓고 진행할 첫 기준정보·재고 협의 준비
• 성격: 내부 분석·회의 기획안. 고객 원본이나 확정 설계가 아님

1. 먼저 내릴 결론

현재 LOT 초안의 ITEM / LOT / BOM / LOT_RELATION / INVENTORY 구조는 첫 협의용으로 충분하다. CMSLAB 때문에 테이블을 크게 늘릴 필요는 없다. 다만 CMSLAB은 ERP·WMS·3PL·판매채널마다 품목코드와 창고가 다르고, 원료는 트레이드네임+제조사로 식별하고 있으므로 다음 세 가지만 보완하는 것이 좋다.

1. 서로 다른 품목코드를 연결하는 ITEM_CODE_MAP
2. 창고와 재고 원천을 식별하는 WAREHOUSE
3. 원료의 트레이드네임·INCI명·문서 위치를 담는 RAW_MATERIAL_DETAIL

그리고 기존 INVENTORY에는 기준시점(snapshot_at)과 원천시스템(source_system)을 추가해야 한다. 현재수량만 덮어쓰면 어느 시점의 어느 시스템 재고인지 설명할 수 없기 때문이다.

확정 여부: 위 내용은 제안이다. 실제 추가 여부와 필수값은 수령 자료 및 현업 협의 후 확정한다.

2. AS-IS와 TO-BE 구분

아래에서 AS-IS는 현재 업무·시스템 상태, TO-BE는 고객이 원하는 목표 상태 또는 내부 설계 제안을 뜻한다. 고객 문서에 기록된 사실과 아직 검증이 필요한 가설을 같은 수준으로 취급하지 않는다.

3. 같이 볼 부서와 데이터

3.1 첫 협의 필수 참석자

첫 회의는 아래 네 그룹이면 충분하다. 모든 영업부서를 한 번에 부르면 기준 정의보다 개별 화면 요구 논의로 흐를 가능성이 높다.

3.2 자료 제공 및 2차 검토 대상

3.3 이번 첫 회의에서는 후순위로 둘 부서

콘텐츠팀의 SKU-콘텐츠 연결, 디자인팀의 제품 사양·가이드, 마케팅의 캠페인 연결도 장기적으로 제품마스터를 사용한다. 하지만 재고·원료·LOT 기준을 먼저 닫는 회의에는 필수 참석자가 아니다. item_code가 정해진 뒤 별도 하위 테이블로 연결하면 되며, 처음부터 ITEM에 이미지·가이드·캠페인 컬럼을 넣지 않는다.

4. 데이터 종류별 묶음

5. LOT 초안 v3 검토

5.1 그대로 유지할 것

5.2 최소 추가 제안

A. 기존 시트에 추가할 컬럼

item.active_yn과 lifecycle_status가 중복될 수 있으므로 실제 적용 시에는 active_yn을 빼고 lifecycle_status 하나만 쓰는 편이 단순하다.

B. 새로 추가할 최소 시트 3개

1) item_code_map — 가장 먼저 필요

세트 구성수량은 처음부터 이 시트에 억지로 넣지 않는다. 실제 번들 분해가 필요한 채널부터 별도 구성행 또는 BOM으로 처리할지 협의한다.

2) warehouse — 재고 원천 목록의 기준

Rack·Bin·상세 Location은 현재 자료에서 요구되지 않았으므로 추가하지 않는다.

3) raw_material_detail — 원료에만 필요한 속성 분리

원료의 상세 시험항목·규격 상하한·COA 결과값은 첫 버전에 넣지 않는다. 필요가 확인되면 QMS 영역으로 확장한다.

5.3 이번에는 추가하지 않을 것

• 시험항목별 QC 결과 테이블
• 작업자·설비·공정조건·전자서명
• Rack/Bin 수준 위치관리
• 자동발주·안전재고 최적화 규칙
• 고객·출하처별 리콜 배포 관리
• 콘텐츠·이미지·캠페인 속성을 ITEM 한 행에 모두 추가하는 방식

이 항목들은 현재 협의 목적을 넘어가며 MES/QMS/WMS/마케팅 마트 영역을 불필요하게 섞는다.

6. 데이터를 쌓는 최소 규칙

1. 표준키와 원천키를 모두 보존한다. 원천 SKU·LOT·창고코드를 표준코드로 덮어쓰지 않는다.
2. 재고는 스냅샷으로 누적한다. 최소 입도는 snapshot_at × source_system × warehouse_id × item_code × lot_id(있으면)이다.
3. LOT를 제공하지 않는 원천은 억지로 생성하지 않는다. lot_id를 비우고 LOT 미제공 여부를 명시한다.
4. 가용재고는 원천값과 표준 계산값을 구분한다. CMSLAB 표준식 후보는 실재고 - 예약재고 - 보류재고이나, 글로비스·ERP의 정의를 확인한 뒤 확정한다.
5. BOM은 표준/계획, LOT_RELATION은 실제 투입이다. 두 데이터를 서로 대체하지 않는다.
6. 변경·단종은 삭제하지 않는다. SKU 매핑, BOM, 원료 스펙에 적용 시작·종료일을 둔다.
7. 품질 상태는 네 값부터 시작한다. PENDING / RELEASED / HOLD / REJECTED; CMSLAB 출하적부 표현과 매핑한다.
8. 원천 추적정보를 남긴다. 파일 수집이면 파일명·기준일·수집일, 시스템 수집이면 시스템명·추출시각을 기록한다.
9. 정본과 표시 정책을 분리한다. ERP/WMS 중 무엇이 정본인지와 영업부서에 얼마를 노출할지는 다른 결정이다.
10. 처방·전성분 권한은 별도로 적용한다. 연구소·RM 열람 범위는 고객 확정 전 전사 공개로 가정하지 않는다.

7. 고객 자료 수령 후 회의 진행안

사전 정리

1. 수령 파일에서 원천별 품목코드·품목명·창고·LOT·수량·기준일 컬럼을 추출한다.
2. 같은 것으로 보이는 SKU 10~20개와 원료 5~10개만 표본 매핑한다.
3. ERP와 WMS가 다른 재고 사례, LOT 품질판정 사례, 원료 제조사 변경 사례를 각 1건 고른다.
4. LOT 초안의 예시데이터를 CMSLAB 실제 표본으로 교체한 회의용 사본을 만든다. 원본 v3는 보존한다.

90분 협의 순서

8. 회의에서 반드시 물을 질문

1. ERP, WMS, 채널에서 같은 제품을 연결하는 현재 공통 코드가 실제로 존재하는가?
2. 세트·번들·리뉴얼·국가별 상품은 표준 SKU와 어떤 관계인가?
3. SKU 생성·수정·단종의 승인자와 실제 입력자는 누구인가?
4. 재고의 공식 정본은 ERP인가? WMS와 차이가 나면 어느 숫자를 언제 확정하는가?
5. 가용·배정·보류·불량의 현행 정의와 계산식은 무엇인가?
6. 창고/채널 원천이 LOT·유통기한을 제공하지 않을 때 어떤 수준까지 조회해야 하는가?
7. 원료 고유코드는 누가 만들며, 제조사가 바뀌어도 같은 원료로 볼 판단 기준은 무엇인가?
8. 전성분표의 함량 계산과 BOM/처방의 관리 책임은 연구소·BM·SCM 중 누구에게 있는가?
9. 출하적부의 LOT 번호는 ERP LOT와 같은가? 다르면 매핑 근거는 무엇인가?
10. LOT가 HOLD/REJECTED가 되면 어느 재고와 어느 완제품까지 사용·출고를 막아야 하는가?

9. 이번 협의의 완료 기준

• 표준 ITEM과 원천 품목코드의 관계를 실제 표본으로 설명할 수 있다.
• 전체 창고·재고 원천 목록과 각 원천의 기준시점·갱신주기·정본 여부가 정리된다.
• 원료 1건이 BOM과 완제품 LOT까지 이어지는 정방향 예시를 만들 수 있다.
• 완제품 LOT 1건에서 사용 원료 LOT까지 역추적할 수 있다.
• 출하적부 상태값과 가용/보류 재고의 관계가 합의된다.
• SKU·원료·재고·품질 각 항목의 입력·승인·열람 책임자가 정해지거나, 미결정 항목의 결정자와 기한이 지정된다.

10. 참조 파일

• 고객 원본: 01_고객원본/2026-07-24_CMSLAB_요구정의서_고객원본.html
• 분석편집본: 04_분석설계/요구사항/2026-08-25_CMSLAB_요구정의_분석편집본_v0.1.xlsx
• 재고·공급 상세: 04_분석설계/요구사항/B_재고공급축_재고통합_입고생산.md
• 제품·원료 상세: 04_분석설계/요구사항/C_마스터축_제품마스터_원료마스터.md
• LOT·품질 상세: 04_분석설계/요구사항/E_품질채권축_VOC품질_메디컬채권.md
• CMSLAB 협의용 수정본: 04_분석설계/데이터분석/CMSLAB_LOT_마스터_스키마초안_v0.1.xlsx
• 검토 대상 초안: /Users/manager/Downloads/화장품_제약_LOT_마스터_초안_v3.xlsx (실제 파일명은 한글 자모 조합형일 수 있음)

CMSLAB 마케팅 채널 수집·마스터 설계 초안

상태: v0.1 / 후속 실사를 위한 최소 구조
내부 근거: 2026-08-25_CMSLAB_요구정의_분석편집본_v0.1.xlsx, D_마케팅축_프로모션_광고실적_MI.md

1. 목표와 범위

지금은 통합 마케팅 모델을 완성하는 단계가 아니다. 먼저 채널·대행사별 원본을 유실 없이 수집하고, 채널–계정–캠페인–제품–프로모션을 연결할 수 있는 최소 기준정보를 만든다.

1차 완료 기준은 다음 세 가지다.

1. 메타·구글·틱톡·채널 어드민·대행사 리포트의 계정과 수집 경로가 한 곳에 정리된다.
2. 플랫폼 원본 ID를 유지한 채 일별 비용·노출·클릭·전환을 적재한다.
3. 캠페인·프로모션을 CMSLAB 제품/SKU와 연결하되, 연결할 수 없는 경우는 상품군·Product ID 단계를 그대로 표시한다.

2. CMSLAB 채널·부서별 먼저 할 일

3. 최소 마스터·성과 테이블

아래 7개면 착수에 충분하다. 원천 파일은 별도 Raw 영역에 보존하고, 아래 테이블은 공통 조회와 매핑을 위한다.

관계 구조

채널·계정
  └─ 캠페인
       └─ 광고그룹/광고세트
            └─ 광고·소재
                 └─ 일별 성과

캠페인·광고·프로모션 ─ 제품 매핑 ─ CMSLAB 제품/SKU 마스터

구글 광고는 캠페인·광고그룹·광고 등 자원 단위에서 전환 지표를 조회할 수 있고, TikTok도 보고서 단위를 advertiser·campaign·ad group·ad로 제공한다. 따라서 위 계층은 특정 매체에 종속되지 않는 최소 공통분모다. Google Ads 전환 보고 문서, TikTok API for Business 통합 보고서

4. 수집 규칙

1. 이름보다 ID를 보존한다. 캠페인명이 바뀌어도 external_campaign_id는 변하지 않는다. 원천 ID가 없는 수기 시트만 CMSLAB 내부 키를 발급한다.
2. Raw는 덧쓰지 않는다. 수집일·원천·파일명을 남기고 원본을 보존한다. 틱톡샵의 현재 BigQuery 덧쓰기 구조는 이력 적재로 바꾸는 것을 우선 검토한다.
3. 일자·화폐·타임존을 같이 저장한다. 현지 일자를 유지하고 통합 보고서에서만 환율과 표준 타임존을 적용한다.
4. ROAS는 저장보다 계산한다. conversion_value / spend로 계산하고, 매체 전환값과 CMSLAB 확정매출은 서로 다른 지표로 표시한다.
5. 조인 입도를 솔직하게 표시한다. mapping_level 값은 SKU, PRODUCT, BRAND, CHANNEL, UNMAPPED 중 하나다. 틱톡 GMV Max처럼 Product ID까지만 가능하면 SKU로 임의 확장하지 않는다.
6. 전환 정의를 고정한다. 매체별 기여 기간·클릭/노출 기준·전환 이벤트가 다르므로 metric_definition_version을 운영 메타데이터에 남긴다. 구글도 전환 성과가 즉시 완성되지 않을 수 있음을 명시한다. Google Ads 전환 보고 문서
7. GA4는 광고매체 전환과 섞어 합산하지 않는다. GA4의 캠페인 차원·세션·구매·매출은 독립 원천으로 수집하고 검증 후 조회에서만 연결한다. GA4 Data API는 차원과 지표를 분리해 제공하며, 구매매출·광고비·ROAS 등의 정의도 각각 제공한다. GA4 Data API 차원·지표

5. 채널 수집 체크리스트

각 채널마다 아래만 채운다. 채널별 API 전체 필드 조사는 실제 액세스가 확정된 뒤에 한다.

6. 아직 하지 않는 것

• 모든 매체의 세부 지표를 하나의 거대한 테이블에 미리 추가하지 않는다.
• 인플루언서·PR 노출과 매출의 인과관계를 확정 지표로 약속하지 않는다.
• 매체 전환매출, GA4 구매매출, 채널 sell-out, 재경 확정매출을 하나의 매출로 합산하지 않는다.
• 외부 Product ID를 근거 없이 ERP SKU로 간주하지 않는다.
• MI 자동 크롤링·자동 제품 매핑은 1차 범위에 넣지 않는다.

7. 실사 후 업데이트할 결정

핵심자료

프로젝트 전체 판단에 필요한 원본·정본·실행 작업본만 연결했습니다. 고객 원본과 내부 파생자료를 구분해 사용합니다.