DW 유저 상태 Fact 모델링: First/Last 모델이 먼저 맞는 경우
이 글은 유저 상태 스냅샷 포스트 와 시리즈 개요편 에서 이어지는 내용입니다. 앞선 글을 아직 안 보셨다면 먼저 보고 오셔도 좋습니다.
스냅샷 모델링을 보고 아래와 같은 의문을 가지실 수 있습니다.
- 스냅샷이 너무 커지면 어떻게 하죠?
AU_30만 보고 싶은데 꼭 일별 스냅샷이 있어야 하나요?- 최근 활성 여부만 알면 되는데 더 단순한 모델은 없나요?
이 질문에 가장 먼저 답이 될 수 있는 것이 First/Last 모델입니다.
First/Last 모델은 무엇인가
이 모델은 유저별로 최소한의 상태만 남깁니다.
| user_id | first_active_day | last_active_day |
|---|---|---|
| 1001 | 2025-01-01 | 2025-03-07 |
| 1002 | 2025-02-10 | 2025-02-15 |
핵심은 단순합니다.
first_active_day: 처음 활동한 날last_active_day: 가장 최근에 활동한 날
즉 유저 상태의 전체 이력을 매일 쌓지 않고, 처음과 마지막만 남기는 방식 입니다.
이걸로 무엇을 할 수 있나
의외로 꽤 많은 것을 할 수 있습니다.
- 최근 7일 활성 유저
- 최근 30일 활성 유저
- 신규 유저
- 휴면 유저 후보
예를 들면 AU_30 은 아래처럼 볼 수 있습니다.
DATE_DIFF(target_day, last_active_day, DAY) < 30
이 정도 질문이라면 굳이 dense daily snapshot 을 만들 필요가 없는 경우가 많습니다.
장점
- 테이블이 작습니다
- 증분 적재가 단순합니다
- recency 중심 지표에 잘 맞습니다
즉 “상태를 전부 저장하자”보다 “꼭 필요한 최소 상태만 남기자” 쪽에 가깝습니다.
단점
물론 이것만으로는 부족한 것도 많습니다.
- 연속 활동일수를 바로 알기 어렵습니다
- inactive 날짜를 일별로 복원하기 어렵습니다
NEW -> RETAINED같은 전이 분석은 약합니다
즉 활성 여부 중심으로는 좋지만, 상태 변화 까지 가려면 부족합니다.
운영에서 특히 조심할 점
First/Last 는 단순한 대신, last_active_day 기준이 틀어지면 거의 모든 recency 지표가 같이 틀어집니다.
그래서 아래를 같이 챙기는 편이 좋습니다.
- 지연 로그가 들어올 때 최근 며칠 재계산할지
- 동일 유저 중복 이벤트를 어디서 제거할지
- 타임존 기준을 어떻게 고정할지
테이블은 작아도 기준이 흔들리면 숫자는 쉽게 흔들립니다.
언제 잘 맞는가
아래 상황이면 먼저 이 모델을 의심해볼 만합니다.
AU_N계열 지표가 핵심일 때- 저장량을 최대한 줄이고 싶을 때
- 전체 상태 이력이 꼭 필요하지 않을 때
상태를 모두 매일 저장하는 것이 부담스럽다면, First/Last 가 가장 현실적인 첫 번째 대안일 때가 많습니다.
참조 링크:
댓글 남기기
댓글 목록
관리자 보기