리저널 팀은 크리에이터 데이터가 부족한 것이 아니라 여러 에이전시, 시장과 캠페인 주기의 데이터를 감사 가능한 decision history로 연결하기 어렵습니다.
리저널 의사결정에서 역설계합니다
누구를 어떤 역할과 조건으로 다시 기용할 수 있는지, 어떤 권리·근거·시장 조건이 필요한지 답하는 구조여야 합니다.
관계형 구조를 사용합니다
| 테이블 | Primary key | 핵심 필드 |
|---|---|---|
| Creator | creator_id | 정체성, 언어, 시장, 대리인 |
| Channel snapshot | creator_id + channel + date | Follower, median view, 출처 |
| Booking | booking_id | Scope, 통화, 계약 주체 |
| Deliverable | deliverable_id | Format, deadline, version, rights |
| Performance | deliverable_id + date | View, valid action, 댓글 품질 |
| Risk/issue | issue_id | 근거, 결정, owner |
과거 근거를 덮어쓰지 않습니다
오늘의 팔로워 수가 이전 snapshot을 지우면 안 되고, 새 rate가 과거 booking scope를 대체하면 안 됩니다.
세 번의 업데이트 trigger
- Shortlist: channel, audience, risk, verification date
- Booking: scope, rights, entity, commercial conditions
- Close-out: performance, issue log, rebooking decision
접근권한을 분리합니다
공개 데이터, 비공개 audience evidence, 계약, 지급과 risk note에는 서로 다른 접근권한이 필요합니다.
| Data Field | 유용한 기록 | 오해를 만드는 기록 |
|---|---|---|
| View | 최근 10개 Median, Paid와 Organic 분리 | 가장 높은 영상 하나 |
| Engagement | 내용 있는 댓글과 짧은 Reaction 분리 | 전체 합계를 Quality로 표시 |
| Audience | Source, Capture 날짜, Channel Scope | 날짜 없는 비율 |
| 강한 주제 | Audience가 반응하는 이유 | 모두 Lifestyle로 표시 |
Profile뿐 아니라 운영·Risk 데이터를 저장합니다
Disclosure 습관, Category Conflict, 지연, 수정 횟수, 이슈 이력, Field 검증자를 기록합니다. 성과가 좋아도 운영 비용이 높거나 규제 Brief에 맞지 않을 수 있습니다.
업데이트 Owner를 지정합니다
현지팀은 로컬 검증을, 리저널팀은 Field 정의와 중복 규칙을 맡습니다. 중요 Field마다 업데이트 날짜와 검증자 이름이 있어야 합니다.
모든 정보를 한 행에 넣지 말고 테이블을 분리합니다
Creator Identity, Channel Metric, Commercial Term, Campaign History, Usage Rights를 연결 테이블로 관리해 과거 Rate나 Audience Snapshot을 덮어쓰지 않습니다.
세 가지 Trigger로 Database를 유지합니다
- Creator가 새 Shortlist에 들어가기 전
- Campaign 종료 후 실제 Delivery가 확정될 때
- Owner, Audience, Rate, Risk, 연락처가 바뀔 때
데이터베이스는 Regional KOL Scorecard를 지원하고 KOL 관리 AI의 근거층이 됩니다.
우선순위 시장의 active creator portfolio부터 시작한 뒤 대량 migration으로 넓히는 편이 안전합니다.
