# data[].attributes.headline
서비스 출시는 끝이 아닌 시작

# data[].attributes.body
서비스 출시는 끝이 아닌 시작

# data[].attributes.headline
전환율 파트에서 앱다운드로드 -&gt

# data[].attributes.body
전환율 파트에서 앱다운드로드 -> 회원가입 -> 휴대폰인증 -> 상품페이지 조회 -> 구매하기 클릭 -> 결재 완료 사이클을 가게 되는데 우리 서비스의 경우는 네이버로그인 및 회원가입제도가 있어서(전국민이 웬만하면 네이버가입자인경우가 많기에) 여기에서 전환율 걱정은 없는것일까요? 궁금했습니다 어찌보면 구매전환율 역시 네이버페이에 의존되어있는 것이 단점보다는 장점이 큰것일까요? 궁금했습니다!

# data[].attributes.headline
그로스해킹이란 크로스평서녈한 직군의 

# data[].attributes.body
그로스해킹이란 크로스평서녈한 직군의 멤버들이 모여서 우리 서비스의 성장 속도와 방향을 가늠할 수 있는 핵심 지표(AARRR)를 찾고 그 지표를 향상시킬수 있도록 실험하고 배우는 과정을 빠르게 반복(lean)하면서 서비스(MVP)를 성장시키는 것.

# data[].attributes.headline
처음부터 완벽한 서비스를 만들어서 출

# data[].attributes.body
처음부터 완벽한 서비스를 만들어서 출시하는게 아니라 핵심적인 구조만 갖춰서 일단 시장에 내보내고 그 뒤로 계속 성장시키는 방법이다.

# data[].attributes.headline
서비스를 적당히 좋아하는 1000명의

# data[].attributes.body
서비스를 적당히 좋아하는 1000명의 사용자보다는 서비스를 열렬히 사랑하는 100명의 충성 사용자를 확보했을 때 그 서비스가 성공할 확률이 높다

# data[].attributes.headline
데이터를 매번 요청하지 않고, 누구나

# data[].attributes.body
데이터를 매번 요청하지 않고, 누구나 필요한 시점에 원하는 조건으로 데이터를 확인할 수 있는 방법

# data[].attributes.body
린 스타트업 (Lean Startup) : 실패로 인한 비용 최소화하며, 제품 개발 > 지표 측정 > 학습 및 개선 반복
최소 기능 제품 (MVP) : 린 스타트업을 위해 최소한의 기능으로 고객의 피백을 반영
* 구현 난의도가 복잡한 기능을 한번에 내는 것보다 예측가능한 지점에 작은 기능을 적용해 서비스 활성화 flow를 강화한다. (pg.9)

# data[].attributes.body
제품-시장 적합성(Product-Market Fit)이란 좋은 시장에, 그 시장을 만족시킬 수 있는 제품을 갖고 있는 것. 마켓핏을 확인할 수 있는 지표는 1. 리텐션 2. 전환률 3. 순수 추천 지수(NPS).

시장 반응이 없을때,  MVP에 기능을 추가하는 것이 아니라 피봇팅을 해야한다.

# data[].attributes.headline
서비스가 제품-시장 적합성을 충분히 

# data[].attributes.body
서비스가 제품-시장 적합성을 충분히 만족하지 못할때 해서는 안 되는 것 :
- 브레인스토밍
- 새로운 기능 추가
- 잔존율이나 전환율을 개선하기 위한 실험
* 잔존율과 전환율은 이를 확인하기 위한 수단으로만 사용해야 한다. 자칫 리텐션, 전환율을 높이기가 '목적' 이 될 수 있기 때문 (pg.31)

# data[].attributes.headline
제품은 기능의 조합이 되어서

# data[].attributes.body
제품은 기능의 조합이 되어서는 안된다. 제품은 가설의 조합으로 이뤄져야 하며, 그러한 가설을 테스트하기 위한 최소한의 기능으로 이뤄져야 한다.

# data[].attributes.headline
AARRR은 사용자 흐름을 기반으로 

# data[].attributes.body
AARRR은 사용자 흐름을 기반으로 만들어진 프레임워크 기반 지표.
우선순위는 활성화> 유지율 > 고객유치, 추천 > 수익화

1. Acquisition(유입) : 최대한 유입경로를 누락없이 식별해야하고 채널별 성과를  파악해야한다.  #UMT, #어트리뷰션

2. Activation(활성화) : 유입된 유저가 핵심 가치를 경험하여 목표(가입, 결제)에 도달하게 한다. #개인화, #UXUI변경, #적절한 개입(CRM)

3. Retention(리텐션, 유지율) : 유저가 핵심 가치를 꾸준히 경험하게 한다. 전체 리텐션보다는 사용자의 코호트별(가입날, 첫구매날, 유입 채널별 사용자 그룹핑)로 쪼개 차이를 비교하는 것이 중요. 개선 방법은 1) 활성화 단계에서 이탈률이 많은 경로 개선 2) 정기적인 커뮤니케이션 등으로 오랜 기간 유지시키기

4. Revenue(수익화): 수익화 모델이 없다면 사랑받는 서비스는 될수 있어도 성공하는 서비스가 될 수 없다. 건강하게 성장하는 서비스는 LTR(고객 생애 매출)이 CAC(1명의 고객 유치에 사용한 예산)를 빠르게 따라잡고 5~20배 이상 높아져야한다.

5. Referral(추천): 친구 초대는 초대 맥락, 메시지/보상, 온보딩 프로세스가 중요하다. 좋은 예 카카오 뱅크 모임통장. 추천으로 유입된 사용자가 서비서의 가치를 경험하여 충성 유저로 남을 수 있도록 해야함.

# data[].attributes.headline
지표의 기준은 세우기 나름. 모

# data[].attributes.body
지표의 기준은 세우기 나름. 모든 부서가 공감할 수 있는 기준을 세워야한다.

좋은 지표는 actionable하다.

지표를 개선할때는 전체 서비스에대한 장기적인 영향을 고려해야한다. #심슨패러독스, #평균값의함정, #생존자 편향 주의!

OMTM(북극성 지표) 모든 구성원이 바라보는 방향성을 일치시킬수 있는 '지금 가장 중요한 지표' 설정이 중요.

# data[].attributes.body
<해야하는 것>
1. 사용자를 직접 만나서 이야기 듣기
2. 사용자 행동 데이터 분석
-> 사용자 인터뷰가 정답은 아니다. 하지만 맥락이다.
사용자 시나리오, 로그 확인하자
33 page

# data[].attributes.headline
데이터를 활용할수 있는 업무 환

# data[].attributes.body
1. 데이터를 활용할수 있는 업무 환경 만들기

2. 데이터 파이프라인 구축하기
#서비스로그, #행동로그, #이벤트속성, #사용자속성

3. 데이터를 활용하는 역량과 문화 갖추기. #교육, #스터디. 꾸준하고 정기적이고 실무에 적용할 수 있어야한다.

4. 성장 실험 (A/B테스트). #가설, #실험집단/통제 집단, #독립변수, #종속변수, #통제변수, #샘플크기, #실험기간

# data[].attributes.headline
PMF를 확인할 수 있는 질문

# data[].attributes.body
PMF를 확인할 수 있는 질문

1. 그 문제가 진짜로 있고 해결책에대한 수요가 있는가?

2.  우리가 만든 그 제품이 정말 그 문제를 해결하고 있는가?

3.  이 제품을 만들면서 세운 가설이 검증 되었는가?

# data[].attributes.body
앱에도 퍼널 적용해보고 싶네요

# data[].attributes.body
NPS(Net Promoter Score, 순수 추천 지수)
좋은 NPS의 기준은
0.3~0.7 이 좋고 0.7~1.0은 매우 좋음.
(적극 추천그룹-비추천그룹)/전체 응답자
결국 NPS는 팬에 대한 자료
-> 서비스를 적당히 좋아하는 1000명의 사용자보다는 서비스를 열렬히 사랑하는 100명의 충성 사용자를 확보했을 때 그 서비스가 성공할 확률이 높다
NPS를 높이자!

# data[].attributes.headline
그로스 해킹은 다양한 직국의 사

# data[].attributes.body
1. 그로스 해킹은 다양한 직국의 사람들이 각자의 전문성을 발휘하면서 협업하는 프로젝트성 업무에 가깝다. # 크로스펑셔널구조, #독립구조, #복합구조

2. 그로스 해킹은 제품 개발을 대체하는 것이 아니고 기존 제품 개발 프로세스를 보완하고 필요한 검증하며 디테일을 챙기는 보완재이다.

3. 경영진의 의지와 데이터가 흐르고 직군한 협업이 진행되는(OMTM이 중요) 문화를 만들어야한다.

# data[].attributes.headline
제품-시장 적합성이 충분하지 않다고 

# data[].attributes.body
제품-시장 적합성이 충분하지 않다고 판단되면 이어지는 그로스 실험을 급하게 진행하기보다는 제품 자체가 의미 있는 문제에서 출발하는지, 그리고 그 문제를 잘 해결하는 제품을 만들었는지를 다시 점검해볼 필요가 있다.

# data[].attributes.headline
전환율을 높이는 것보다 퍼널에 속한 

# data[].attributes.body
전환율을 높이는 것보다 퍼널에 속한 각 각 단계의 수를 줄이는 것이 더 효과적인 경우가 많다. ... 서비스 관점에서 필요 없는 단계를 없애거나 통합하는 과정이 반드시 필요하다 (pg.93)

# data[].attributes.body
다필요없고, activation과 retention을 먼저 해야한다. 준비 안된 서비스는 유저를 불러모아도, 팬이 아닌 안티를 만들 뿐

보통 revenue 보다, referral 이 먼저 오는 그림을 많이 봤어서 신기했음

# data[].attributes.headline
크로스펑셔널한 우리 스터디... 우리

# data[].attributes.body
크로스펑셔널한 우리 스터디... 우리 팀에 그로스해킹을 문화를 만들어나가기 딱이다!!

# data[].attributes.headline
퍼널 분석의 진정한 가치는 주요 퍼널

# data[].attributes.body
퍼널 분석의 진정한 가치는 주요 퍼널에서의 단편적인 전환율을 계산하는 데 있는 것이 아니라 전환율에 영향을 미치는 유의미한 선행지표를 발견하는 데 있다.
전환에 영향을 주고 있는 코호트를 발견할 수 있다면 전환율을 높이기 위핞 구체적인 액션을 하기가 훨씬 수월해진다.

# data[].attributes.headline
시장 반응이 없을때, 다음 MVP 플

# data[].attributes.body
시장 반응이 없을때, 다음 MVP 플러스 기능 개발이 아니라, 이악물고 피봇팅을 해야한다는 것.

# data[].attributes.headline
지표는 정해진 답이 있는 게

# data[].attributes.body
지표는 정해진 답이 있는 게 아니라 합의된 기준에 따라 사용되는 것이므로 정답이 있는 문제는 아니라고 할 수 있다.

# data[].attributes.headline
지표를 코호트로 쪼갤 수록 

# data[].attributes.body
지표를 코호트로 쪼갤 수록 더 많은 인사이트를 발굴할수 있다.

# data[].attributes.headline
우리 서비스는 고객유치 (A

# data[].attributes.body
우리 서비스는 고객유치 (Acquisition) 데이터를 어느 범위까지 수집하고 있는지

# data[].attributes.body
Growth 해킹은
데이터를 다루는 사람 뿐만 아니라
서비스를 다루는 모든 사람이
모두 데이터에 대한 관심으로
의미를 생각해보고 일을 해나가야 한다고 생각.

이렇게 많은 사람들이 관심을 가지고
데이터 스터디를 한다고 하여
기대하는 마음으로 스터디에 참여하게 되었고
업무에서도 지속되었으면 좋겠습니다.

# data[].attributes.headline
제품이나 서비스를 성장시키기

# data[].attributes.body
제품이나 서비스를 성장시키기 위해서는 특정 분야의 스킬셋이 아니라 서비스를 만들고 운영하는 전체 프로세스에 대한 폭넓은 이해가 필요하다

# data[].attributes.headline
퍼널분석을 위해 우선적으로 해야할 일

# data[].attributes.body
퍼널분석을 위해 우선적으로 해야할 일은 사용자들이 핵심 가치를 경험하는 정확한 순간을 정의하는 것.

아하모먼트 or 머스트해브

우리 서비스를 이용하면서 목적했던 바를 달성하거나 기대를 충족하는 순간, 이때는 공급자가 아닌 사용자 입장에서 정의해야 함.

우리 서비스의 아하모먼트는?

# data[].attributes.headline
KPI에 관해 농담처럼 하는 이야기<

# data[].attributes.body
KPI에 관해 농담처럼 하는 이야기
"기획팀도, 개발도, 마케팅도 KPI를 달성했는데, 왜 올해 서비스 실적은 이것밖에 안되나?!"
(눈물...)

우리의 북극성 지표는?

# data[].attributes.body
WEB- UTM 파라미터를 통해 유저의 인입 경로를 알 수 있음
APP - 어트리뷰션 (attribution) 을 통해 유저의 인입 경로를 확인 (사용자가 앱을 설치하고 사용하는데 어떤 채널이 기여했는지를 식별함으로써 모바일 앱 마케팅 성과를 판단하는 과정)

우리 서비스에 적용한다면 개발 코스트가 얼마나 드나요?

# data[].attributes.headline
지식인과 엑스퍼트의 OMTM은?

# data[].attributes.body
지식인과 엑스퍼트의 OMTM은?

# data[].attributes.headline
MAU 를 따질때도 그냥 "우리 서비

# data[].attributes.body
MAU 를 따질때도 그냥 "우리 서비스의 MAU 가 얼마에요?' 라고 묻는 것보다 명확한 개념 정의를 해야한다는걸 배웠습니다. MAU를 집계하려면 MAU 를 어떻게 측정할지에 대한 명확한 기준이 필요.
(ex. MAU = 최근 30일간 우리 서비스에 로그인한 사용자라 정의. 그럼 정말 단순히 방문만 한 사용자는 집계하지 말아야함.  또는, 로그인 여부 상관없이 방문한 사용자 전체를 MAU 로 집계해야하는지 등)

# data[].attributes.headline
저자가 크로스펑셔널한 멤버 구성을 강

# data[].attributes.body
저자가 크로스펑셔널한 멤버 구성을 강조했는데 아폴로 UGC 데이터팀이랑 너무 소통이 없는것 아닌가하는 생각이 들었습니다.

# data[].attributes.headline
만약 주간 업무 보고를 팀의 막내 직

# data[].attributes.body
만약 주간 업무 보고를 팀의 막내 직원이 전담해서 작성하고 있거나 최근 6개월 이상 주간업무보고 포맷이 전혀 달라지지 않았다면 주간업무보고가 허무 지표로 가득 차 있을 확률이 매우 높다. 시간이 지나고 서비스가 성장하거나 시장 환경이 달라짐에 따라 중요한 지표는 달라지기 때문이다.(p.160)

# data[].attributes.headline
지표를 기반으로 성장 실험을 할 때는

# data[].attributes.body
지표를 기반으로 성장 실험을 할 때는 해당 지표를 어떻게 정의하고 측정할 것인가를 반드시 짚고 넘어가야 한다. 모호한 지표는 모호한 액션을 이끌 수 밖에 없기 때문이다.(p.158)
좋은 지표가 가져야할 조건 중 하나는 그 지표를 바탕으로 행동할 수 있어야 한다(actionable)는 것이다.(p.159)

# data[].attributes.headline
설치수, 가입자수라는 지표가 제품-시

# data[].attributes.body
설치수, 가입자수라는 지표가 제품-시장 적합성 확인에 좋지 않다. 제품 성공 확률과 거의 상관없다
라는 내용이 있었음.. 흔히 가입자수 늘리자! 설치수 늘리자! 이런것이 하나의 지표로 쓰이는 경우도 많았던것같다
작년에 별점수를 높이는 목표를 앱은 했었는데 이것에 대한 지표로써 가치가 나와있지 않아서 궁금하다

# data[].attributes.headline
전 직장에서 AARRR 기반의 프로젝

# data[].attributes.body
전 직장에서 AARRR 기반의 프로젝트를 진행해본 적이 있는데, 퍼널마다의 가설을 정하고 그 가설을 측정할 방법을 정하고 구축하는데 너무 많은 시간을 쓰게 되면서 일정이 늦어져, 너무 답답한 점도 있었어요!

주요 지표에 대한 이해와 그것을 측정할 인프라가 잘 갖춰져 있어야 낭비 없이 잘 액션할 수 있는 방법이라고 생각해요.

# data[].attributes.headline
린 스타트업 - 스프린터 형태 개선이

# data[].attributes.body
린 스타트업 - 스프린터 형태 개선이 좋다는 건 알고 있지만, 큰 조직에서 현실적으로 가능할까... 레거시가 많아서 큰 서비스는 빠르게 움직이기 어려운게 현실인데...

# data[].attributes.headline
그로스 조직이 일하는 방식- 

# data[].attributes.body
그로스 조직이 일하는 방식
- 데이터 기반으로 가설을 세우고
- 실험을 바탕으로 이를 검증하고
- 배움을 축적하는 과정을 빠르게 반복한다
1) 목표지표를 정의하고 측정하기
목표는 정서적, 개념적인 언어로 표현할 수 있다. 예시 '자주 방문하는 충성 고객을 늘린다.' (하지만 지표는 명확하게 측정 가능한 수준으로 구체화 해야함)
2) 아이데이션과 데이터 분석
좋은 아이디어는 여러 데이터와 시행착오를 거쳐서 조금씩 다듬어가는 과정을 통해 만들어진다
3) 플래닝
- 임팩트 : 이 실험이 성공하면 얼마나 큰 효과가 있을까?
- 자신감 : 이 실험을 성공할 거라고 얼마나 확신하는가?
- 난이도 : 이 실험을 하기 위한 리소스가 얼마나 드는가?
4) 실험준비, 진행, 분석
개요, 가설, 설계, 목표, 일정
5) 회고

# data[].attributes.headline
사용자를 직접 만나서 이야기를 들어야

# data[].attributes.body
사용자를 직접 만나서 이야기를 들어야 한다고 하는데, 저희도 포커스 그룹 인터뷰나 1:1 사용자 인터뷰를 했었거나 할 수도 있나요?

# data[].attributes.body
<A/B 테스트 진행시 주의사항>
- 무가설 : 어떤가설을 검증하고 싶은지 명확해야함.
- 통제 변수 관리 실패 : 가설에 정의한 독립변수 외에 종속 변수에 영향을 미칠 수 있는 다른 변수가 없는지 신중하게 판단하고 샘플링해야함.
- 단순 평균 비교 : 평균 비교 외에도 분포, 유의수준, 효과 크기 등을 종합적으로 고려해서 판단해야함
- 엿보기/조기중지 : 중단하는것이 어뷰징 행위. 실험 초기 p값이 안정화 되지 않은 시점에 테스트를 조기 중지하면 실제로는 없는 효과를 있는 것처럼 판단할 수 있음.
- 시간의 흐름에 따른 차이를 살펴 보지 않는 것 : 시간이 지남에 따라 차이가 두드러지는 경우도 있고 그 반대도 있으니 시간에 흐름에 따라서도 꼼꼼하게 재확인 필요.

# data[].attributes.headline
최근 아폴로 테크톡에서 Gro

# data[].attributes.body
최근 아폴로 테크톡에서 Group & 쪽 A/B 테스트 사례를 공유해주셨었습니다.

AB Test 필요성과 도입 확대 전략(노지훈, Group&)

발표 자료만 남아있지만, 실제 사례와 도입을 위한 허들(?)에 대한 부분을 살펴볼 수 있습니다.

# data[].attributes.headline
지표를 개선하기 위해서는 측

# data[].attributes.body
지표를 개선하기 위해서는 측정할 수 있어야 하고, 측정하기 위해서는 해당 지표에 대한 조작적 정의가 필요하다.

# data[].attributes.headline
매출을 OMTM으로 정하는 것이 부적

# data[].attributes.body
매출을 OMTM으로 정하는 것이 부적절한 이유
1. 매출은 서비스의 핵심 가치가 사용자에게 잘 전달됐는지와 비례해서 증가하지 않는다. ... 즉, 매출이 늘어나고 줄어드는 것은 서비스의 성장과 항상 일치하지 않는다.
2. 매출은 후행지표이다. 매출은 그자체가 다른 것의 원인이 되기보다는 어떤 원인에 의해 결과적으로 드러나는 성적표에 가깝다.
---
매출은 성장을 목표로하는 지표보다 퍼포먼스지표, 평가를 위한 지표(KPI)에 가까움

# data[].attributes.body
186~189p. 행동 로그 설계
현재 단순 이벤트 집계 중인데 (클릭 수만 확인) 저희도 클릭코드 정의할때 이벤트 속성 추가할 수 있지 않을까요?
+
무작정 많은 이벤트를 수집하려고 하기보다는 '필요한' 이벤트를 '정확하게' 수집하는 것이 중요하다는 것을 기억하자. ... 발생하는 모든 이벤트를 기록해야 한다는 생각을 버리고 분석에 필요한 이벤트를 정확하게 적재하는 것이 이 단계의 핵심이다.

# data[].attributes.headline
아이디어-개발-측정-개선. 피드백 순환고리

# data[].attributes.subject
아이디어-개발-측정-개선. 피드백 순환고리

# data[].attributes.body
많은 시간과 노력을 투자해서 만든 제품이 알고 보니 아무도 원하지 않는 제품이라는 점을 뒤늦게 발견하는 것만큼 나쁜 일은 없다.

서비스 개발하면서 제일 무서운 점...
지인들이 왜 매달 업데이트하냐고 물어볼 때 ㅠㅠ

# data[].attributes.body
친구 초대는 굉장히 강력하고 중요한 추천 채널
동일한 기능이라고 하더라도 어떤 문구와 톤으로 표현하느냐에 따라 친구 초대 성과는 크게 달라질 수 있다.

지식인/엑스퍼트도 이용해볼 수 있을까?

# data[].attributes.body
191p. 단 한 번의 요청으로 추출 목적에 딱 맞는 잘 정리된 데이터를 뽑아내는 것은 거의 불가능하다. 실제로 쓸 만한 인사이트나 아이디어는 여러 가지 데이터를 다양한 각도에서 살펴보면서 수없이 반복되는 질문과 답 속에서 찾아지는 경우가 많다.하지만 요청하는 사람과 추출하는 사람이 다른 경우 이러한 질문과 데이터의 반복되는 사이클을 충분히 진행하기 어렵다. 요청하는 사람은 미안해지고 추출하는 사람은 귀찮아져서 적당한 선에서 타협하게 된다. (뭐든 쉽지 않네요 ㅠㅠ)

# data[].attributes.headline
데이터 기반의 환경데이터 관련

# data[].attributes.body
데이터 기반의 환경
데이터 관련 개개인의 이해도
협업 문화 및 조직

여러 가지 필요한 것들과
넘어야 할 산들이 있지만
이 스터디가 시작점이 되면 좋겠습니다.

# data[].attributes.headline
천재 한 명과 그를 따르는 

# data[].attributes.body
천재 한 명과 그를 따르는 사람들이 필요한 게 아니라 각 분야에서 자기 몫을 할 수 있는 프로페셔널 구성원들이 필요하다.

# data[].attributes.headline
그로스 해킹은 제품 개발 프로세스 자

# data[].attributes.body
그로스 해킹은 제품 개발 프로세스 자체를 대체하는 것이 아니다.
그로스 해킹은 기존의 제품 개발 프로세스를 보완하고 필요한 부분을 검증하면서 디테일을 챙기도록 해 주는 역할을 한다. 그래서 일반적으로는 그로스 해킹을 한다고 해서 제품 개발 속도가 빨라지지는 않는다. (오히려 제품 개발 속도 자체는 느려질 수도 있다.)

# data[].attributes.headline
공부를 해야 겠다! 난 너무

# data[].attributes.body
공부를 해야 겠다! 난 너무 모르는 게 많구나..라고 생각했습니다 : ) 같이 공부해요!