Steam Next Fest 준비: 세션 수, 위시리스트, 유저 피드백 분석
Steam Next Fest 데모 운영에서 세션 수를 해석하고 위시리스트와 유저 피드백을 함께 분석하는 방법을 정리합니다. 행사를 단순 노출 기회가 아니라 출시 준비를 위한 측정 실험으로 설계해 봅니다.

Next Fest를 데모 공개가 아니라 측정 실험으로 보기
Steam Next Fest는 짧은 기간에 데모 플레이, 방송, 커뮤니티 반응이 한꺼번에 쌓이는 행사다. 이때 플레이 수나 위시리스트의 절대값 하나만 보고 성패를 결론 내리기 쉽다. 하지만 장르, 가격, 데모 길이, 기존 커뮤니티 규모, 노출 시점이 서로 다르므로 다른 게임의 숫자를 그대로 기준으로 삼기 어렵다.
행사 전에 먼저 답할 질문을 정하자. 예를 들어 “첫 15분 안에 핵심 재미가 전달되는가”, “어떤 유입 경로가 위시리스트 전환에 기여하는가”, “반복해서 등장하는 불편이 출시 전 수정할 문제인가”처럼 행동으로 이어질 질문이 좋다. 일정과 참가 조건은 회차별로 달라질 수 있으므로 제출 전에는 Steamworks의 해당 회차 안내를 다시 확인해야 한다.

세션 수: 관심의 크기이지 만족도의 증거는 아니다
세션은 플레이어가 데모를 실행한 접점 지표다. 세션이 늘었다면 노출, 썸네일, 장르 관심사, 방송 등으로 진입이 발생했다는 뜻일 수 있다. 그러나 같은 사람이 재실행한 경우도 있고 실행 직후 이탈한 경우도 있으므로 세션만으로 게임의 반응을 단정할 수 없다.
먼저 볼 세 가지 묶음
- 유입량: 일별 세션 수와 유입이 크게 늘어난 날짜를 기록한다.
- 플레이 품질: 평균 플레이 시간, 완료율처럼 데모의 핵심 구간에 닿았는지 보여 주는 지표를 함께 본다. 사용 가능한 지표의 정의는 Steamworks 대시보드에서 확인한다.
- 행동 변화: 같은 날짜의 위시리스트 추가, 팔로우, 토론 글, 설문 응답 변화를 겹쳐 본다.
세션을 날짜별로 분해하면 무엇을 확인해야 할지 선명해진다. 특정 스트리머의 방송 직후 세션만 급증하고 위시리스트 추가가 평소와 비슷하다면 영상은 호기심을 만들었지만 상점 페이지나 데모 초반이 구매 관심까지 연결하지 못했을 가능성이 있다. 반대로 세션 규모는 작아도 위시리스트 증가가 꾸준하다면 타깃층과의 적합도가 더 좋을 수 있다.
간단한 전환율 계산
행사 기간의 일별 데이터를 한 덩어리로 보려면 다음과 같이 계산할 수 있다.
이 값은 인과관계를 증명하지 않는다. Steam의 추천 노출, 외부 캠페인, 기존 팔로워, 언론 보도 등이 함께 영향을 줄 수 있다. 따라서 “세션 100회당 위시리스트가 얼마나 늘었는가”라는 내부 비교용 기준으로 쓰는 편이 안전하다. 이전 데모 업데이트나 다른 행사와 비교할 때에도 같은 기간, 같은 집계 방식, 가능한 한 비슷한 데모 상태를 맞춰야 한다.
date,sessions,wishlists_added,avg_play_minutes,notes
YYYY-MM-DD,0,0,0,행사 시작 전 기준선
YYYY-MM-DD,0,0,0,방송 또는 업데이트 여부 기록
날짜에는 실제 집계일을 넣고 notes에는 방송 시작 시각, 패치 배포, 체험판 공지처럼 해석에 영향을 주는 사건을 남긴다. 나중에 숫자를 보며 기억에 의존하는 일을 줄여 준다.
위시리스트: 총량보다 변화의 원인을 추적하기
위시리스트는 출시 알림과 잠재 수요를 가늠하는 중요한 신호지만 매출 예측값으로 곧바로 바꿀 수는 없다. 국가, 가격, 할인 정책, 출시 시점, 게임의 인지도에 따라 출시 전환 양상은 달라진다. Next Fest 분석에서는 총 위시리스트만 캡처해 두기보다 일별 순증과 유입 사건을 연결하는 편이 실용적이다.
다음 흐름으로 보면 팀 회의가 숫자 나열에 그치지 않는다.
flowchart TD
A[일별 세션과 위시리스트 수집] --> B[변화가 큰 날짜 표시]
B --> C[방송·패치·공지와 대조]
C --> D[플레이 시간과 피드백 확인]
D --> E[상점 페이지·데모·마케팅 개선안 결정]
예를 들어 세션은 높고 위시리스트 전환은 낮다면 아래 가설을 검토할 수 있다.
- 상점 캡슐과 태그가 실제 플레이 경험과 다르게 기대를 만들었는가
- 데모의 첫 목표나 조작 안내가 늦어 이탈이 일어났는가
- 가격, 출시 예정일, 지원 언어처럼 결정에 필요한 정보가 상점 페이지에 부족한가
- 방송 시청자는 많았지만 게임의 핵심 대상층과는 거리가 있었는가
반대로 전환이 좋다면 무엇이 효과적이었는지도 구체적으로 남긴다. “반응이 좋았다”보다 “퍼즐 해결 과정을 짧은 영상으로 보여 준 날에 전환이 상승했고 설문에서도 같은 장면이 자주 언급됐다”처럼 관찰과 가설을 구분해 기록해야 다음 캠페인에 재사용할 수 있다.

유저 피드백을 결함 목록이 아닌 증거로 정리하기
피드백 채널은 Steam 토론, 데모 내 설문, 버그 신고 폼, 방송 채팅, 소셜 미디어 등으로 분산된다. 모든 의견을 같은 무게로 처리하면 목소리가 큰 소수 의견에 흔들릴 수 있다. 원문을 보존하되 관찰 가능한 문제 단위로 정규화해 보자.
추천하는 분류 표
| 분류 | 기록할 내용 | 우선순위 판단 예시 |
|---|---|---|
| 진행 막힘 | 발생 지점, 재현 절차, 저장 데이터 여부 | 다수가 같은 구간에서 멈추면 높음 |
| 조작·가독성 | 입력 장치, 해상도, 화면 요소 | 기본 조작을 방해하면 높음 |
| 난이도·학습 | 실패 이유, 튜토리얼 이해 여부 | 의도한 긴장과 혼란을 구분 |
| 재미·차별점 | 기억에 남은 장면, 비교 대상 | 마케팅 메시지 검증에 활용 |
| 기술 문제 | 사양, 오류 로그, 재현 빈도 | 크래시와 진행 불가는 즉시 분리 |
각 항목에는 원문, 증거, 가설, 조치를 분리해 둔다. “보스가 너무 어렵다”는 원문이고 “세 명이 같은 공격의 예고가 안 보인다고 언급했다”는 증거다. 여기서 “예고 효과가 배경과 섞인다”는 가설이 나오며 대비 강화나 타이밍 조정은 조치 후보가 된다. 이 구분이 없으면 한 번의 인상적인 댓글이 확정된 요구사항처럼 바뀐다.
{
"feedback_id": "nf-001",
"category": "progression",
"location": "tutorial-combat-02",
"summary": "회피 입력을 알아차리지 못해 진행이 멈춤",
"evidence": {
"reports": 3,
"reproducible": true,
"playtime_context": "초반 10분 이내"
},
"hypothesis": "회피 안내의 시각적 대비가 부족함",
"decision": "튜토리얼 UI와 실패 피드백을 수정 후 재검증"
}
행사 전·중·후의 운영 리듬
행사 전: 기준선과 계측을 만든다
데모의 첫 실행부터 핵심 재미에 닿는 구간까지 직접 다시 플레이한다. 크래시, 컨트롤러, 해상도, 언어, 저장과 재시작을 최소한의 체크리스트로 점검한다. 분석에는 행사 시작 전 며칠의 기준선도 함께 저장한다. 그래야 행사 때문에 생긴 변화와 평소 변동을 구분할 수 있다.
설문은 길게 만들기보다 행동을 묻는 질문 위주로 구성한다. 예를 들면 “어느 구간에서 멈췄나요?”, “다음에 무엇을 해야 할지 알 수 있었나요?”, “가장 기억나는 장면은 무엇인가요?”가 좋다. 이메일 주소 수집처럼 개인정보가 들어가는 항목은 목적과 보관 방침을 명확히 하고 선택 사항으로 둔다.
행사 중: 하루 한 번 같은 형식으로 기록한다
실시간 숫자에 반응해 큰 방향을 자주 바꾸기보다 하루 단위로 같은 시각에 데이터를 기록한다. 긴급 크래시나 진행 불가 문제는 별도 경로로 즉시 대응한다. 그 외 의견은 반복 빈도와 영향도를 확인할 때까지 보류할 수 있다.
커뮤니티 답변은 짧고 구체적으로 쓴다. 재현 정보가 필요한 버그에는 운영체제, 입력 장치, 발생 구간, 로그 위치를 요청한다. 수정이 확정되지 않은 제안에는 약속 대신 검토 중인 사실만 알린다.
행사 후: 숫자를 결정으로 번역한다
종료 직후에는 다음 네 문장으로 회고 초안을 만든다.
- 어떤 날짜와 경로에서 관심이 가장 크게 늘었는가.
- 그 관심은 위시리스트와 플레이 지속으로 얼마나 이어졌는가.
- 반복적으로 확인된 가장 큰 마찰은 무엇인가.
- 출시 전 반드시 할 일, 검증이 필요한 일, 하지 않기로 한 일은 무엇인가.
마지막 문장이 특히 중요하다. Next Fest는 모든 피드백을 구현하는 기간이 아니라 출시 품질과 메시지를 개선할 근거를 얻는 기간이다. 세션 수는 관심의 폭을 위시리스트 변화는 관심의 방향을 피드백은 그 숫자 뒤의 이유를 보여 준다. 세 신호를 같은 날짜와 같은 맥락에서 읽으면 다음 데모 업데이트와 출시 계획을 훨씬 덜 감으로 결정할 수 있다.
마무리 체크리스트
- 행사 시작 전 기준선 데이터를 저장했는가
- 세션, 위시리스트, 플레이 품질을 날짜 단위로 함께 기록하는가
- 방송, 패치, 공지 같은 외부 사건을 같은 표에 남기는가
- 피드백 원문과 팀의 가설, 결정 사항을 분리했는가
- 진행 불가·크래시와 취향 차이를 같은 우선순위로 다루지 않는가
- 행사 종료 후 실행 가능한 다음 작업 목록으로 회고를 마쳤는가



