인게임 유저 이탈 징후 머신러닝 감지와 리텐션 보상 푸시 자동화
Steam 출시 게임에서 플레이 세션, 튜토리얼 진행률, 결제·이탈 이벤트로 유저 이탈 확률을 예측하고 동의 기반 세그먼트별 리텐션 보상을 자동 발송하는 데이터 설계와 운영 절차를 정리합니다. 오탐과 보상 피로도를 줄이는 실험 지표도 다룹니다.
TL;DR
인게임 유저 이탈 감지는 최근 세션 빈도, 튜토리얼 진행률, 실패 반복, 결제 이력 같은 이벤트를 피처로 변환해 향후 일정 기간 내 미복귀 확률을 예측하는 방식으로 구현합니다. 예측 결과는 보상 정책 엔진과 연결하고 푸시 수신 동의·쿨다운·실험군 조건을 확인한 뒤 개인화된 리텐션 보상을 자동 발송해야 합니다.
핵심은 단순히 이탈 확률이 높은 유저에게 할인 쿠폰을 뿌리는 것이 아닙니다. 이탈 원인과 유저 가치, 보상 피로도를 함께 고려해 복귀 가능성이 높아지는 시점에 적절한 메시지를 보내고 증분 효과를 측정하는 것입니다.
인게임 유저 이탈 징후는 왜 발생하는가?
게임에서 유저 이탈은 보통 한 번의 종료 이벤트로 결정되지 않습니다. 첫 세션에서 튜토리얼을 중단하거나 반복 실패 후 재접속하지 않는 행동처럼 여러 신호가 누적된 결과로 나타납니다.
먼저 이탈을 측정할 기준을 고정해야 합니다.
- 관찰 구간: 유저의 행동 데이터를 수집하는 기간
- 예측 시점: 현재 상태를 스냅샷으로 만드는 시점
- 이탈 판정 기간: 예측 시점 이후 유의미한 세션이 없는 기간
- 유의미한 세션: 최소 플레이 시간이나 핵심 이벤트를 충족한 세션
예를 들어 예측 시점 이후 7일 동안 5분 이상 플레이하거나 핵심 콘텐츠를 진행하지 않으면 churned_7d = 1로 라벨링할 수 있습니다.
무료 게임과 프리미엄 PC 게임은 플레이 주기가 다르므로 1일, 7일, 14일 기준을 모두 비교하는 편이 안전합니다.
| 이탈 징후 | 측정 예시 | 해석 시 주의점 |
|---|---|---|
| 세션 감소 | 최근 7일 세션 수, 세션 간격 | 주말형 유저를 일반 유저와 분리해야 함 |
| 튜토리얼 중단 | 마지막 완료 단계, 중단 위치 | 첫 실행 오류와 콘텐츠 난이도를 함께 확인 |
| 반복 실패 | 같은 스테이지 실패 횟수, 사망 횟수 | 숙련도 차이를 고려해야 함 |
| 콘텐츠 미진행 | 최근 3일 핵심 퀘스트 완료 수 | 업데이트 직후에는 기준이 달라질 수 있음 |
| 결제 행동 변화 | 장바구니 취소, 구매 간격, 환불 | 결제 유도보다 불만 신호로 해석할 수 있음 |
| 소셜 활동 감소 | 파티 참가, 친구 초대, 클랜 활동 | 혼자 플레이하는 유저에게는 약한 신호일 수 있음 |
어떤 이벤트와 피처를 수집해야 하는가?
모델의 성능은 알고리즘보다 이벤트 설계에 크게 좌우됩니다.
클라이언트에서 발생한 이벤트는 event_name, event_time_utc, user_id, session_id, build_version을 공통 필드로 갖게 하고 이벤트별 속성은 별도 properties 객체로 관리하는 것이 좋습니다.
추천 이벤트는 다음과 같습니다.
| 이벤트 | 주요 속성 | 집계 피처 예시 |
|---|---|---|
session_start | 플랫폼, 지역, 유입 경로 | 최근 24시간 세션 수 |
session_end | 플레이 시간, 종료 사유 | 평균 세션 시간 |
tutorial_step | 단계, 완료 여부 | 튜토리얼 완료율 |
level_result | 스테이지, 결과, 실패 원인 | 최근 3회 실패 횟수 |
content_complete | 콘텐츠 ID, 난이도 | 최근 7일 핵심 콘텐츠 완료 수 |
purchase_complete | 상품 ID, 가격, 통화 | 최근 구매일, 누적 결제액 |
reward_claim | 보상 ID, 획득 경로 | 최근 보상 수령 횟수 |
notification_action | 캠페인 ID, 클릭 여부 | 최근 푸시 클릭률 |
피처를 만들 때는 원본 이벤트를 그대로 모델에 넣기보다 시간 창을 나누어 집계합니다.
예를 들어 sessions_24h, sessions_7d, hours_since_last_session, tutorial_completion_ratio, failures_3d, days_since_last_purchase처럼 행동의 최근성과 변화량을 함께 표현합니다.
특히 다음 세 가지는 반드시 관리해야 합니다.
- 시간 기준 통일: 모든 이벤트 시간을 UTC로 저장하고 리포트에서만 현지 시간으로 변환합니다.
- 라벨 누수 방지: 예측 시점 이후에 발생한 구매나 복귀 이벤트를 피처에 포함하지 않습니다.
- 식별자 분리: 광고 ID, 플랫폼 계정 ID, 내부 유저 ID를 목적별로 분리하고 원본 개인정보를 피처 테이블에 직접 저장하지 않습니다.
이탈 예측 모델은 어떻게 설계하는가?
초기에는 복잡한 딥러닝 모델보다 설명 가능한 기준선 모델을 먼저 구축하는 것이 좋습니다.
Python 3.12 환경에서는 scikit-learn의 LogisticRegression을 기준선으로 사용하고 데이터 규모와 비선형 관계가 확인되면 HistGradientBoostingClassifier를 비교할 수 있습니다.
로지스틱 회귀의 기본 형태는 다음과 같습니다.
여기서 은 이탈 확률이고 는 세션 수, 튜토리얼 완료율, 실패 횟수 같은 피처입니다. 보상 발송 여부를 결정하는 것은 확률 자체가 아니라 정책 기준을 적용한 최종 점수입니다.
1. 시간순으로 학습·검증 데이터를 나눈다
게임 서비스 데이터는 시간에 따라 콘텐츠, 가격, 패치, 유입 채널이 바뀝니다. 따라서 무작위 분할보다 과거 데이터를 학습에 사용하고 이후 기간을 검증에 사용하는 시간 기반 분할이 적절합니다.
from sklearn.linear_model import LogisticRegression
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler
features = [
'sessions_24h',
'sessions_7d',
'hours_since_last_session',
'tutorial_completion_ratio',
'failures_3d',
'days_since_last_purchase'
]
train = df[df['observed_at'] < '2026-05-01']]
valid = df[df['observed_at'] >= '2026-05-01']].copy()
model = Pipeline([
('scale', StandardScaler()),
('classifier', LogisticRegression(
max_iter=1000,
class_weight='balanced'
))
])
model.fit(train[features], train['churned_7d'])
valid['churn_probability'] = model.predict_proba(valid[features])[:, 1]실제 운영에서는 날짜별 검증 구간을 여러 개 두고 패치 전후 성능을 비교해야 합니다. 특정 업데이트에서만 잘 작동하는 모델은 캠페인 자동화에 사용하기 어렵습니다.
2. AUC보다 리텐션 캠페인에 맞는 지표를 확인한다
이탈 예측은 클래스 불균형이 자주 발생합니다. 이탈 유저가 전체의 10%라면 정확도 90%만으로는 유용한 모델인지 판단할 수 없습니다.
| 지표 | 확인 목적 |
|---|---|
| PR-AUC | 이탈 양성 클래스의 탐지 품질 확인 |
| Recall@Top-K | 상위 위험군 중 실제 이탈 유저 비율 확인 |
| Precision@Top-K | 발송 대상 중 실제 위험 유저 비율 확인 |
| Calibration | 예측 확률 0.8이 실제 약 80% 이탈을 의미하는지 확인 |
| Lift | 무작위 대상 대비 캠페인 대상의 복귀 성과 확인 |
| 비용 대비 증분 매출 | 보상 비용과 운영 비용을 반영한 사업성 확인 |
보상 캠페인은 모든 위험 유저에게 발송하지 않습니다.
예를 들어 하루 발송 가능량이 전체 활성 유저의 5%라면 Recall@5%와 해당 구간의 복귀율을 우선적으로 봅니다.
위험도와 유저 가치에 따라 보상 세그먼트는 어떻게 나누는가?
이탈 확률만으로 보상 등급을 정하면 문제가 생깁니다. 결제 가능성이 낮은 유저에게 고가 보상을 반복 제공하거나 이미 충성도가 높은 유저에게 불필요한 할인을 제공할 수 있습니다.
실무에서는 최소한 이탈 위험도와 유저 가치, 최근 보상 피로도를 함께 사용합니다.
| 세그먼트 | 조건 예시 | 권장 액션 |
|---|---|---|
| 저위험·고활성 | 이탈 확률 낮음 | 일반 업데이트 소식, 신규 콘텐츠 안내 |
| 중위험·튜토리얼 이탈 | 초기 진행 중단 | 다음 단계 힌트, 무료 체험 보상 |
| 고위험·콘텐츠 실패 | 반복 실패와 세션 감소 | 난이도 보조 아이템, 재도전 보상 |
| 고위험·고가치 | 결제 이력 있고 활동 급감 | 개인화 번들, 기간 제한 보너스 |
| 고위험·보상 피로 | 최근 캠페인 반응 없음 | 발송 보류, 설문 또는 제품 개선 대상 |
보상 정책은 코드에 하드코딩하기보다 버전이 있는 정책 테이블로 관리하는 편이 좋습니다. 정책에는 캠페인 ID, 대상 조건, 보상 원가, 유효 기간, 발송 채널, 쿨다운, 실험군 비율을 포함합니다.
보상 선택 로직의 단순한 예시는 다음과 같습니다.
def choose_offer(churn_probability, value_segment, reward_count_7d):
if reward_count_7d >= 2:
return None
if churn_probability >= 0.85 and value_segment == 'high_value':
return 'return_bundle_10'
if churn_probability >= 0.70:
return 'comeback_boost_3d'
return None위 코드는 정책의 출발점일 뿐입니다. 실제로는 환불 유저, 미성년자 계정, 제재 계정, 이미 보상을 받은 유저, 해당 지역에서 마케팅 수신을 거부한 유저를 발송 전에 제외해야 합니다.
리텐션 보상 푸시 자동 발송은 어떻게 구현하는가?
자동 발송 파이프라인은 다음 4단계로 나누면 운영과 장애 추적이 쉬워집니다.
- 스코어링: 배치 또는 스트리밍 방식으로 유저별 이탈 확률을 계산합니다.
- 정책 판정: 위험도, 유저 가치, 동의 상태, 쿨다운, 실험군을 검사합니다.
- 발송 큐 등록: 중복 방지를 위한
idempotency_key를 생성해 발송 큐에 넣습니다. - 성과 이벤트 수집: 노출, 클릭, 게임 실행, 보상 수령, 1일·7일 복귀를 다시 이벤트로 저장합니다.
flowchart LR
A[게임 클라이언트] --> B[이벤트 수집 API]
B --> C[(이벤트 저장소)]
C --> D[피처 집계]
D --> E[이탈 확률 모델]
E --> F{보상 정책 엔진}
F -->|대상| G[동의 확인 및 발송 큐]
F -->|제외| H[쿨다운 기록]
G --> I[푸시 또는 게임 내 우편]
I --> J[클릭 복귀 구매 이벤트]
J --> C발송 큐의 메시지는 특정 푸시 사업자에 종속되지 않도록 다음과 같은 공통 구조로 설계할 수 있습니다.
{
"campaign_id": "retention_2026_08_return",
"user_id": "internal-user-id",
"offer_id": "comeback_boost_3d",
"channel": "game_inbox",
"deep_link": "game://event/comeback",
"idempotency_key": "internal-user-id:retention_2026_08_return",
"expires_at": "2026-08-31T23:59:59Z"
}메시지 내용은 모델 점수를 그대로 노출하지 않고 유저의 마지막 행동에 맞춰 작성합니다.
- 튜토리얼 이탈:
다음 단계부터 바로 이어서 플레이해 보세요. - 반복 실패:
재도전을 돕는 3일 보너스를 준비했습니다. - 신규 콘텐츠 미진행:
새 챕터를 시작하면 한정 보상을 받을 수 있습니다.
할인이나 유료 상품을 제안할 때는 정가, 할인 기간, 환불 조건을 명확히 표시해야 합니다. 보상 만료를 과도하게 강조하거나 실제보다 큰 혜택처럼 표현하면 단기 클릭률은 올라가도 장기 신뢰와 브랜드 평판을 해칠 수 있습니다.
Steam 출시 게임에서는 어떤 푸시 채널을 사용할 수 있는가?
Steam 게임은 모바일 게임처럼 모든 유저에게 임의의 개인 푸시를 보낼 수 있다고 가정하면 안 됩니다. 채널별 역할을 구분하고 유저가 동의한 범위 안에서 운영해야 합니다.
| 채널 | 적합한 용도 | 운영 시 주의점 |
|---|---|---|
| 게임 내 우편함 | 다음 실행 시 개인화 보상 제공 | 실행 전 즉시 도달하지 않음 |
| PC 런처 알림 | 런처 재방문 유도 | 런처 설치와 알림 설정 필요 |
| 이메일 | 계정 기반 리텐션 캠페인 | 별도 수신 동의와 수신 거부 처리 필요 |
| 모바일 연동 앱 푸시 | 계정 연동 유저의 복귀 유도 | 앱 설치와 디바이스 토큰 관리 필요 |
| Steam 커뮤니티·이벤트 | 전체 또는 특정 이용자층 대상 공지 | 개인별 이탈 확률 기반 발송 채널로 보기는 어려움 |
| Steam 뉴스·업데이트 | 패치, 신규 콘텐츠, 세일 안내 | 개인화 보상보다 공식 공지에 적합 |
따라서 Steam 퍼블리싱에서는 다음 조합이 현실적입니다.
- 개인별 예측 결과: 게임 내 우편함 또는 계정 기반 동의 채널
- 전체 업데이트 소식: Steam 뉴스와 커뮤니티 이벤트
- 세일·가격 캠페인: Steam 할인 일정과 상점 페이지 메시지
- 다음 실행 유도: 런처 알림과 게임 내 보상 안내
개인정보와 마케팅 수신 동의는 모델 데이터와 별도로 관리해야 합니다. 한국 개인정보보호법, GDPR 등 서비스 지역에 적용되는 규정에 따라 수집 목적, 보관 기간, 제3자 제공, 철회 방법을 검토하고 처리방침에 반영해야 합니다.
오탐과 푸시 피로도를 줄이는 운영 지표는 무엇인가?
머신러닝 모델이 높은 위험도를 반환해도 유저가 실제로 이탈한다는 뜻은 아닙니다. 출장, 시험 기간, 대형 업데이트 대기처럼 게임 밖의 이유로 잠시 접속하지 않을 수도 있습니다. 그러므로 자동화 시스템에는 발송 제한과 실험군을 기본으로 넣어야 합니다.
권장 가드레일은 다음과 같습니다.
- 유저당 마케팅 메시지 최대 횟수 설정
- 캠페인 사이 최소 48시간 또는 72시간 쿨다운 적용
- 최근 접속 직후에는 발송하지 않기
- 보상 수령 후 일정 기간 동일 유형 캠페인 제외
- 발송 대상의 5~10%를 홀드아웃 대조군으로 유지
- 보상 원가와 월별 캠페인 예산을 정책 엔진에서 제한
- 모델 장애 시 기본 공지 또는 발송 중단으로 안전하게 대체
성과는 단순 클릭률이 아니라 대조군 대비 증분 효과로 판단해야 합니다.
| 측정 영역 | 핵심 지표 |
|---|---|
| 모델 | PR-AUC, Recall@Top-K, Calibration, 데이터 드리프트 |
| 메시지 | 노출률, 클릭률, 보상 수령률 |
| 리텐션 | D1, D7 복귀율, 세션 시간, 핵심 콘텐츠 재진입률 |
| 비즈니스 | 증분 매출, 보상 비용 대비 매출, 환불률 |
| 사용자 경험 | 알림 해제율, 신고율, 부정 리뷰 변화 |
대조군보다 복귀율이 높더라도 보상 비용과 환불률을 뺀 순효과가 음수일 수 있습니다. 특히 고가 할인은 구매 전환율보다 할인 없이도 복귀했을 유저의 비율을 함께 확인해야 합니다.
실무 적용을 위한 단계별 도입 순서
1단계: 규칙 기반 이탈 경보부터 만든다
최근 3일 미접속, 튜토리얼 중단, 특정 스테이지 3회 연속 실패처럼 설명 가능한 규칙을 먼저 운영합니다. 이 단계에서 이벤트 누락, 시간대 오류, 중복 발송 문제를 발견할 수 있습니다.
2단계: 라벨과 피처 파이프라인을 고정한다
churned_1d, churned_7d, churned_14d를 분리하고 각각의 관찰 구간과 예측 구간을 문서화합니다.
피처 스냅샷이 언제 생성됐는지도 저장해야 재현 가능한 학습과 검증이 가능합니다.
3단계: 기준선 모델과 정책 엔진을 연결한다
로지스틱 회귀 모델을 기준선으로 배포하고 모델 점수와 정책 판정 결과를 분리해 저장합니다. 그러면 모델을 교체해도 보상 정책과 캠페인 성과를 비교할 수 있습니다.
4단계: 홀드아웃 대조군으로 증분 효과를 측정한다
같은 위험 세그먼트 안에서 일부 유저에게만 캠페인을 보내고 나머지는 대조군으로 유지합니다. 캠페인 시작 시점, 콘텐츠 업데이트, 지역, 플랫폼을 함께 기록해야 결과를 해석하기 쉽습니다.
5단계: 자동화 범위를 점진적으로 확대한다
처음부터 모든 유저에게 자동 발송하지 말고 특정 지역이나 한정된 보상부터 시작합니다. 모델 드리프트, 보상 예산 초과, 중복 발송, 동의 상태 변경을 확인한 뒤 채널과 세그먼트를 확대합니다.
자주 묻는 질문(FAQ)
데이터가 많지 않은 초기 게임도 머신러닝을 사용할 수 있나요?
가능하지만 복잡한 모델보다 규칙 기반 경보와 로지스틱 회귀가 적합합니다. 표본이 충분히 쌓일 때까지 플레이어 행동을 세그먼트별로 집계하고 모델의 예측 확률보다 대조군 기반 캠페인 성과를 우선적으로 확인하세요.
이탈 확률이 높으면 반드시 보상을 보내야 하나요?
아닙니다. 수신 동의, 최근 발송 횟수, 보상 비용, 환불·제재 상태를 모두 통과한 경우에만 발송해야 합니다. 위험도가 높아도 제품 버그나 난이도 문제로 이탈하는 유저라면 할인보다 개선 안내와 지원이 더 적절할 수 있습니다.
Steam 유저에게 개인화 푸시를 바로 보낼 수 있나요?
Steam의 공식 공지 채널과 개인별 외부 푸시 채널을 구분해야 합니다. 개인화 메시지는 게임 내 우편함이나 계정 연동 후 동의한 이메일·앱·런처 채널을 활용하고 Steam 뉴스와 이벤트는 전체 업데이트와 출시 커뮤니케이션에 사용하는 방식이 안전합니다.
정리
인게임 유저 이탈 감지와 리텐션 보상 자동화는 이벤트 표준화 → 시간 기반 피처 집계 → 이탈 확률 예측 → 정책 판정 → 동의 확인 → 보상 발송 → 대조군 성과 측정의 연결 문제입니다.
가장 먼저 해야 할 일은 좋은 모델을 고르는 것이 아니라 이탈 라벨의 정의와 이벤트 시간을 고정하는 것입니다. 그 위에 쿨다운, 홀드아웃, 예산 제한, 수신 거부 처리를 넣으면 Steam 출시 게임에서도 과도한 푸시와 불필요한 할인 없이 데이터 기반 리텐션 운영을 시작할 수 있습니다.
