DW 유저 상태 Fact 모델링: Transition Table은 언제 필요할까
이 글은 유저 상태 스냅샷 포스트 와 시리즈 개요편 에서 이어지는 내용입니다. 앞선 글을 아직 안 보셨다면 먼저 보고 오셔도 좋습니다.
스냅샷 모델링을 보고 아래와 같은 의문을 가지실 수 있습니다.
- 유저가 어디서 어디로 이동했나요?
- churn 은 어느 상태에서 가장 많이 나오나요?
- reactivation 은 어디서 다시 붙고 있나요?
이런 질문에는 Transition Table 이 잘 맞습니다.
Transition Table은 무엇인가
이 모델은 상태가 변한 순간만 저장합니다.
예를 들면 이런 식입니다.
| user_id | from_state | to_state | change_day |
|---|---|---|---|
| 1001 | NEW | RETAINED | 2025-03-02 |
| 1001 | RETAINED | INACTIVE | 2025-03-03 |
| 1001 | INACTIVE | REACTIVATED | 2025-03-10 |
핵심은 이겁니다.
- 매일 상태를 쓰지 않음
- 변화가 생긴 날만 기록 함
그래서 상태보다 흐름을 보기에 좋습니다.
장점
- 저장량이 적습니다
- churn / resurrection 흐름 분석에 강합니다
- 어떤 경로가 많이 발생하는지 보기 쉽습니다
예를 들어 Retained -> Inactive 가 늘었는지, Inactive -> Reactivated 가 줄었는지 같은 질문을 바로 던질 수 있습니다.
단점
- 특정 날짜의 현재 상태를 바로 보기는 불편합니다
- 일별 대시보드용 상태표로는 직관성이 떨어질 수 있습니다
- 상태를 다시 복원하려면 추가 로직이 필요합니다
즉 오늘 상태 보다는 어떻게 움직였는가 에 더 맞는 모델입니다.
운영에서 특히 조심할 점
Transition Table 은 전이 이벤트가 빠지면 흐름이 바로 왜곡됩니다.
그래서 아래를 같이 보는 편이 좋습니다.
- 전이 계산 기준 시점이 일 단위인지 주 단위인지
- 동일 날짜 다중 상태 변경을 허용할지
Inactive전이를 배치에서 언제 확정할지
흐름 분석은 예쁘지만, 전이 발생 시점을 대충 잡으면 해석이 쉽게 어긋납니다.
언제 잘 맞는가
- 이탈/복귀 흐름이 중요할 때
- 상태 전이 분석이 핵심일 때
- 저장량을 줄이고 싶을 때
상태표보다 이동 경로가 더 중요하다면, Transition Table이 Daily Snapshot보다 훨씬 잘 맞을 수 있습니다.
참조 링크:
댓글 남기기
댓글 목록
관리자 보기