O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

[NDC 2011] 게임 개발자를 위한 데이터분석의 도입

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio

Confira estes a seguir

1 de 73 Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (16)

Anúncio

Semelhante a [NDC 2011] 게임 개발자를 위한 데이터분석의 도입 (20)

Mais recentes (20)

Anúncio

[NDC 2011] 게임 개발자를 위한 데이터분석의 도입

  1. 1. 냉철하고 정확한 의사결정을 위한 데이터분석의 도입 부재 : 데이터분석팀 포스트모템
  2. 2. 이 발표의 내용은... 온라인게임에서 데이터분석의 필요성 데이터분석의 도입 및 활용사례 & 경험담 대상은 아래와 같은 분들 개발업무에 데이터분석을 도입하고자 하시는 분들 기획적 지식에 대한 정량화, 계량화에 관심이 있으신 분들
  3. 3. 초급의 난이도 데이터분석에 관련된 특정기술이나 기법에 대해서는 소개 하지 않습니다
  4. 4. 박 훈 hpark@nexon.co.kr 넥슨 데이터분석팀 팀장 - 기획자, DBA, 개발자 - 요약 하자면 잡케 -_-; - 2달 전 병특 끝남 - 서핑, 스노우보드, 자동차
  5. 5. 시작 합니다
  6. 6. 어느날...
  7. 7. 어딘가 아프면?
  8. 8. (종합)검사/검진
  9. 9. 원인을 알아야 정확한 치료가 가능 술을 좀 작작 쳐 드세요 ~
  10. 10. Data Analysis ?
  11. 11. (저장된) 데이터 속에서 유용한 정보를 발견하는 것
  12. 12. Online Game Data analysis
  13. 13. 어느날...
  14. 14. 동접 폭락..;;
  15. 15. 상황파악
  16. 16. 이번달은.. 고레벨의 보상에 관련한 유저들의 원성이 자자 하니 고레벨 컨텐츠를 추가 고 레벨의 보상증대 결정 !!
  17. 17. 이번 패치 감이 아주 좋아 !!
  18. 18. 올랐던 매출도 동접 따라서 딱~!! 분명 오를 것 같던 동접이 팍~!! 패치 결과는 ?
  19. 19. 다시 생각 해보기.. 고 레벨 유저의 원성은 실제로 얼마나? 양을 느낌으로 가늠 정량화의 부재
  20. 20. 이것만 해결 하면 될까?
  21. 21. 진짜는.. 문제에 대한 원인규명을 제대로 하지 않았기 때문
  22. 22. 이러한 현상들이 반복되면?
  23. 23. 운인데 실력으로 믿거나 실력인데 운으로 믿거나 동물적 감각, 센쓰, 통찰!? 사실은 “찍기”
  24. 24. 라이브가 아닌 신작의 경우, 더 위험
  25. 25. 3~5년 온라인 게임의 평균 개발기간 신입 > 파트장 > 팀장 > 디렉터 20~30년 평생 만들 수 있는 게임은 3~5개
  26. 26. 좋아, 이번엔 감이 좋아 !! 이번 신작 대박 난다에 우리팀 전원의 손목을 건다 !!!
  27. 27. 온라인게임의 데이터분석 - 현상에 대한 객관적 검진/진단 도구 - 합리적 의사결정을 지원하는 도구
  28. 28. 왜, 관심 받았을까?
  29. 29. “레드오션”의 도래
  30. 30. 매년, 수십개의 온라인게임이 출시되며 수십개의 온라인게임이 잊혀집니다 지켜야 하는자 vs 뺐어야 하는자 비교할 대상이 적음 vs 비교할 대상이 많음 만들줄 아는게 중요 vs 잘 만드는게 중요
  31. 31. 데이터분석에 대한 오해와 환상
  32. 32. “빠”& “까”
  33. 33. 환상 – “빠” Q. 우리게임 잘될까요? Q. 앞으로 어떻게 하면 잘될까요? 그걸 알면 제가 투자사 창업 합니다 -_-;; 대박은 나도 내고 싶다 !!
  34. 34. 오해 – “까” - “재미”를 정량화 할 수 있냐 ? - 데이터분석은 기획의 창의력(장인정신)을 저해한다 창의력을 저해 하는것이 아니라 예상 가능한 실수를 줄이는 것 나? 40년 이태리 장인
  35. 35. Data analysis Process
  36. 36. “개발자 관점”에서의 데이터분석 원본 데이터 Raw Data 변환/가공 Transform 자료분석 Analysis 패턴발견 Patterns 지식 구축 Knowledge Action !!!
  37. 37. 당췌 뭔 말인지..;;
  38. 38. 데이터 분석 그리고 신메뉴 개발 # 잠시 패밀리 레스토랑 주방장으로 빙의 되어 보자 데이터분석 과정과 신메뉴 개발과정은 아주 흡사하다구...
  39. 39. - 가설을 통한 분석(메뉴개발) - 구체적으로 궁금한 것 (먹고 싶은 것)을 나열 하기 어떤 것이 가능한가? Q. 하위 20% 유저의 튜토리얼 단계별 실패율 Q. 매력 아이템의 보상등급,수량에 따른 재 구매율 Q. 퀘스트 성공율과 이탈률은 반비례 하는가 ? Q. DT가 높은 유저들이 캐시아이템을 구매 하는가 ? 반대로, 캐시아이템을 구매하면 DT 증대 되는가 ? Q. SMS를 프로모션을 해야 하는데.. 문구는? 몇시에? 어떻게? 누구에게? Step1. 메뉴(분석주제)선택
  40. 40. 요리의 생명은 신선한 재료 데이터분석의 생명은 양질의 데이터 * Tip - 가능한 작은 데이터 부터 수집 (우선 보는것이 중요) - 양이 중요한 데이터와, 패턴이 중요한 데이터를 구분 - 초반부터 로그포멧에 너무 집중 하면 시작도 못하게 됨 Step2. 재료(데이터) 준비&손질
  41. 41. 조리 & 분석 가설(궁금증)에 부합하는 데이터를 이용, 분석(검증) 추가로, 뭔가 새로운 것이 더 있나 찾아 본다 * Tip - 넓은 범위에서 좁은 범위로 - 비교 대상을 만들면, 좀더 쉽게 접근 할 수 있다 - 조리시간이 필요이상으로 길어지면 손님이 짜증을 낸다 Step3. 조리(분석)시작
  42. 42. Good 개발한 음식이 맛있다 (시나리오가 맞다, 소득이 있다) Bad 이건 도저히 못 먹겠다 (시나리오랑 다르다, 소득이 없다) Lucky ! 의도하진 않았지만 새로운 맛의 발견 (새로운 경향을 발견) 도출된 결과를 기반으로 기획 & 적용 Step4. 음식(분석결과)를 시식
  43. 43. 분석의 주제, 진행상황, 결과를 가급적 Fact 위주로 상세하게 정리 요리사가 매번 같은 맛을 내기위해 메뉴의 레시피를 만드는 것과 동일 경험의 지식화 최종적으로는 사람이 바뀌었을 때 경험/통찰력이 리셋되는 것을 방지 하기 위함 Step5. 기록하고 정리 (레시피 작성)
  44. 44. 삽질을 통해 배우기 - 포스트 모템 -
  45. 45. ‘첨단성’이 아니라 “필요성” 거창하게 생각하면 길어질 뿐 할 수 있는 것부터 하나씩 하자
  46. 46. 목표를 미리 정하자 매장량(데이터)이 아무리 많아도 “광맥”을 찾지 못하면 아무 소용이 없다
  47. 47. 분석 도구에 연연하지 말자 (생각보다 높은 도입비용, Unreal 3 정도의 가격..;;;) 도구는 필요를 느끼고 환경이 뒷받침이 될때에 도입해도 늦지 않음 Excel, SQL 도 이미 훌륭한 도구 !!
  48. 48. 대용량 데이터에 지나치게 집착 하지 말 것 데이터분석의 목적은 “수집”이 아니라 “분석과 활용”에 있음
  49. 49. 분석은 다양하고 과감하게 결과의 적용에 있어서는 BabyStep !! 게임에 있어 이벤트는 “BabyStep”의 아주 좋은 수단
  50. 50. 듣기엔 쉬워 보이는데, 해보면 잘 안됨 게임 = 개발자에겐 자식과 같은 존재 야단치는 것에 어려움을 느끼는 것이 당연 굴욕쯤은 감수 할 수 있어야 한다
  51. 51. 순순히 활용 가능한 실용적인 예시를 내 놓는다면 유혈 사태는 일어나지 않을 겁니다.
  52. 52. 예시와 활용분야
  53. 53. 매출, 플레이 시간, 일별 방문자, 구매유저, 통화량, 킬 / 데스, 동접, 레벨업 속도, 평균 구매액, 어뷰져, 신규가입, 이탈율,1판 플레이시간, 단위 경험치, 퀘스트 성공율 평균의 함정
  54. 54. 평균의 함정  연못의 평균 깊이가 3ft 라고 쓰여 있다면 ??  반 평균이 높다고, 모두가 좋은 점수를 받은 것은 아님 평균값 해석에 있어 평균의 함정을 인지 항상 주의가 필요 * 분석결과의 수치를 맹신하면 안됨
  55. 55. 분류 기준을 다양화 하자 Segmentation = 쪼개어 살펴 보기 “레벨”은 가장 보편적인 사용자 분류 기준 “레벨”이 아닌 다른 관점으로 사용자를 쪼개 보자 어떤 것이 가능한가? 1. 이탈유저, 비이탈 유저 2. 부자유저, 가난한 유저 3. 플레이어(사람)의 실력 4. 유저의 가입기간에 따라
  56. 56. (증가) 신규 가입자 (감소) 장기 가입자 Case1. “가입기간”에 따른 유저의 반응 X = 일자 (월) Y=UniqueVisitor 전체 이용자 장기 가입자 신규 가입자 (증가) 장기 가입자 (감소) 신규 가입자
  57. 57. Case2. 실력과 승률의 상관관계 (1) 레벨(x), 승률(y) 레벨과 승률의 관계는 미약
  58. 58. Case2. 실력과 승률의 상관관계 (2) 레벨(x), 실력점수(y) 레벨과 실력의 관계는 약함
  59. 59. Case2. 실력과 승률의 상관관계 (3) 레벨(x), 승률(y)실력점수(x), 승률(y) 실력과 승률의 관계는 상당히 높음
  60. 60. 관계(Network)를 이용 플레이어의 실력, 능력, 경제력등의 지표가 아닌 사람들의 관계(Network)로 살펴보기 어떤 것이 가능한가? 게임의 업데이트나 변경 내용을 낮은 비용으로 빠르게 확산 시키기 당장엔 직접적인 수익(매출)의 도움이 안되지만 플레이어들 간의 중심이 되는 “키 사용자”를 관리 (동반 이탈방지)
  61. 61. Case3. 관계(Network)을 이용한 소문내기 소문내기 한 명을 이용해 소문을 낸다면 누구에게 알리는 게 가장 효과적인가? 네트워크는 크지만 고립 2~3차 전달력 없음 네트워크의 크기는 작지만 2~3차 전달력이 높음
  62. 62. DQA (Data-Driven Quality Assurance) 유저의 플레이 기록을 통해 이상현상을 감지 시스템을 이용한 감지가 가능, 좀더 빠른 발견속도 어떤 것이 가능한가? 1. 어뷰져 탐색 2. 해킹시도의 탐지, 해킹유저의 탐지 3. 서비스 중인 게임의 개발/기획적 오류(Hole) 발견
  63. 63. 판매자 구매자 어뷰저? 장사꾼? Case4. 거래 데이터를 통한 어뷰저 색출
  64. 64. 변화량 추적하기 (스토킹) 1.분류 기준을 활용하여 유저를 집단으로 묶음 2.묶인 집단의 변화량을 지속적으로 추적 관리 지표의 변화량을 집단별로 비교관찰 이벤트, 패치의 효과분석이 편리해짐 어떤 것이 가능한가? 1. 컨트롤 실력이 부족한 이용자 2. 방학 프로모션에 반응 이용자 3. 회귀촉진(귀환) 이벤트 반응한 이용자 4. 패치 후 7일 이내에 접속한 회귀 이용자
  65. 65. 온라인 게임에 있어 데이터 분석의 역할
  66. 66. 양준혁 (베트 꺼꾸로 잡고 3할) 2003 : 490 타석 / 49 삼진 = 10.0% 통 상 : 7332 타석 / 910 삼진 = 12.4% 안타타자, 안정적인 운영 낮은 삼진 확률, 그러나 주목을 받기는 어려움 이승엽 (홈런의 신, 승부사) 2003 : 596 타석 / 89 삼진 = 14.9% 통 상 : 5005 타석 / 827 삼진 = 16.5% 홈런타자, 한방을 노림 스타플레이어 이며 상대적 높은 삼진확률 최저점 (Baseline) 높이기 데이터분석은 “안타타자”를 지향
  67. 67. 최저점 (Baseline) 높이기 예를 들어, A 게임의 2011년 회귀율 목표는 +10% 현재, A 게임의 자연 회귀률이 1% 일 때 데이터 분석을 통하여 회귀율을 3%로 올리면 개발자는 7%의 추가 노력만을 하면 됨
  68. 68. 결과 예측을 위한 실험실 대규모 적용 전 실험을 통해 적은비용(Risk)으로 예상되는 문제를 미리 파악 할 수 있음 @Keyword A/B Test (실험군, 대조군) T-Test, ANOVA
  69. 69. 최종적으로는...
  70. 70. 기획적 지식의 체계화 기존에 생각지 못한 사실이나 원리에 대한 발견 가지고 있는 지식&감을 분석을 통해 검증, 재확인
  71. 71. 정말로 좋은데 어떻게 표현 할 방법이 없네;;

×