pile·
DB / 데이터·NC소프트 DANBINC소프트 DANBI·

아이템에 대한 만족도는 플레이어가 게임을 열심히 하는데 영향을 미칠까??

엔씨소프트 단비 팀이 "좋은 아이템을 얻으면 더 열심히 플레이한다" 는 앞선 인과 분석의 후속으로, 그 아이템에 만족했는지 여부가 플레이 변화를 가르는지 확인한 글이다. 만족도를 최초·최종 두 단계로 나눠 정의하고, 인과 다이어그램으로 통제 변수를 골라 효과를 추정한다.

핵심 포인트
  • 원인 변수는 획득한 영웅/전설 등급 전직에 대한 만족도다. 등급 변경 시스템이 있어 최초 만족도와 최종 만족도 두 단계로 측정했다.
  • 최초 만족도는 최초 획득분을 유지했는지(유지=만족), 최종 만족도는 최종 획득분이 기존에 쓰던 무기를 쓸 수 있는 직업인지(동일 무기 포함=만족)로 정의한다.
  • 최초 만족도는 집단을 나누는 기준으로, 최종 만족도는 실제 효과를 측정하는 기준으로 쓴다. 랜덤 변경이라는 노력을 들여 얻은 경우 애착이 달라질 수 있다는 가설 때문이다.
  • 결과 변수는 획득 전후 30일 접속 일수 변화, 결제 금액 변화, 1/2/3/4주 후 유저 그룹 지표 상향 여부 세 가지다.
  • 결과적으로 동일 무기 포함 여부에 따른 만족도는 접속 일수 변화에 유의한 영향을 주지 않았다. 능력치가 대폭 오르는 등급을 처음 얻은 것 자체가 지배적이라는 해석이다.
상세 정리
  • 문제의식: 기존에 원거리 무기를 쓰던 유저가 근거리 직업의 영웅/전설을 얻으면 무기·스탯·스킬을 다시 세팅해야 해 만족하지 못할 수 있고, 그러면 플레이 변화가 다르게 나타날 수 있다는 것이다.
  • 게임 시스템 배경: 영웅 등급 이상은 획득 후 동일 등급의 다른 전직으로 랜덤 변경할 기회가 주어지며, 변경 횟수 상한과 비용이 있다.
  • 만족도 조합을 case 로 나눈다. 최초 만족→최종 만족(변경 없이 사용)과 최초 불만족→최종 만족(랜덤 변경으로 획득)은 애착이 다를 수 있으므로 최초 만족 여부가 같은 유저끼리 묶어 각각 효과를 측정한다.
  • 통제 변수 후보 9개는 성장(희귀 등급 수, 컬렉션 완성 횟수, 스킬 습득 수, 인챈트 성공 횟수, 등급 합성 성공 횟수), 정체(사망 횟수), 매몰 비용(계정 생성 후 경과일, 레벨, 총 결제액)으로 분류돼 있다.
  • 대상 선정: 원인 변수가 만족 여부이므로 영웅/전설을 획득한 유저로 한정했고, 앞선 분석의 5개 기간에서 유사한 결과가 나왔기에 그중 한 기간만 썼다.
  • 세부 그룹 조정: 결제 금액 효과는 유저 등급 지표별 차이가 크지 않고 기존 결제 여부에서 차이가 컸으므로, 샘플 부족과 복잡도를 피하려 결제 여부만 기준으로 삼았다.
  • 인과 다이어그램 수정: '만족 여부' 노드를 추가하고 영웅/전설 획득 → 만족 여부 → 결과 변수 경로를 넣었다. 분석 대상을 획득자로 한정했으므로 '희귀 등급 수 → 영웅/전설 획득' 경로가 사라지고, 그에 따라 만족 여부로 흐르는 영향도 차단된다.
  • 통제 변수 선정 절차는 4단계다. 원인·결과에 직접 영향이 없는 인과 관계를 무시하기 위한 노드 통제, 원인 외에 결과에 영향을 주는 노드 통제, 원인과 결과 양쪽에서 영향을 받는 collider 식별, 그리고 앞 두 단계 결과에서 collider 를 제외한 최종 선정.
  • 접속 일수 모델의 통제 변수는 컬렉션 완성 횟수, 스킬 습득 횟수, 인챈트 성공 횟수, 레벨, 총 결제액, 사망 횟수다. collider 는 없었다.
  • 결제 금액 모델은 등급 합성 성공 횟수, 총 결제액, 사망 횟수를 통제한다.
  • 유저 그룹 지표 상향은 값이 0/1 이므로 로지스틱 회귀로 추정하고, 통제 변수는 앞의 두 모델에서 고른 것들의 합집합을 쓴다.
  • 결과 읽는 법: 신뢰 구간이 0 을 나타내는 점선 오른쪽에 있으면 만족한 경우 플레이 변화가 증가한다고 해석한다는 기준을 명시한다.
왜 읽나관측 데이터로 인과 효과를 재고 싶은 데이터 분석가에게 원인 변수 정의부터 통제 변수 선정까지의 판단 근거를 실제 사례로 보여준다.
NC소프트 DANBI
NC소프트 DANBI 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. DB / 데이터·여기어때 (GC컴퍼니)여기어때 (GC컴퍼니)·

    분석가가 직접 만든 마케팅 자동화 시스템 — 오디언스 빌더 제작기

    여기어때 데이터 분석팀(UB팀)이 개발 경험 없이 AI 에이전트 바이브 코딩으로 마케팅 자동화 시스템 '오디언스 빌더'를 구축한 과정이다. SQL 없이 UI에서 타겟 조건을 설정하면 BigQuery에서 수천만 행 대상자를 추출해 Kafka·S3를 통해 마케팅 도구로 전달하는 파이프라인을 직접 만들어, 캠페인 준비 시간을 2~3일에서 10분으로 단축했다.

    요약 이어보기
    #data-pipeline#kafka#postgres+2
  2. DB / 데이터·vercel-blogVercel Blog·

    모든 Vercel 빌드를 지탱하는 데이터베이스 마이그레이션 이야기

    Vercel이 빌드 웜 풀(warm pool) 상태 데이터를 Redis에서 DynamoDB로 마이그레이션한 과정을 다룬다. 빌드 풀의 청구 매핑 데이터가 Redis 장애 시 복구 불가능하다는 구조적 위험이 이주를 결정한 핵심 이유였고, 24/7 프로덕션 트래픽 속에서 다운타임 없이 5단계 점진적 전환을 완료했다.

    요약 이어보기
    #database-migration#zero-downtime#redis+2
  3. DB / 데이터·channel-talk채널톡·

    DynamoDB 핫 파티션을 해결하는 3가지 방법 (3): 조회를 인덱스 테이블로 옮기기

    채널톡이 DynamoDB 핫 파티션을 해결하려 GSI를 별도 인덱스 테이블로 떼어낸 연재의 마지막 편으로, 조회 경로를 GSI에서 인덱스 테이블로 옮긴 과정을 다룬다. 2편에서 쓰기 파이프라인이 완성돼 WriteThrottleEvents가 월 110만 회에서 0회가 됐지만, 조회 코드가 여전히 GSI를 읽고 있어 GSI를 지울 수 없었다. GSI가 읽기에서 대신해주던 키 해석·정확 일치·삭제 필터·페이지 채우기를 사내 공통 라이브러리의 조회 규칙으로 흡수해, 호출부는 GSI든 인덱스 테이블이든 같은 코드를 쓰게 만들었다.

    요약 이어보기
    #migration#dynamodb#hot-partition+5