[인프런 워밍업 클럽] 4주차 회고

학습 내용

데이터 축적을 위한 기본 개념

  • 데이터는 투자가 필요한 자원 : 데이터 축적 정의, 코딩 작업, 툴 등등

Event based analytics

  • 기본개념 : event, property

  • event taxonomy 설계 과정

  • 이름짓는 규칙

     

PA 주요개념들

이벤트 베이스트 애널리틱스

  • 이벤트 기반 데이터분석

  • 유저와 제품 사이 일어나는 상호작용

    • 회원가입, 버튼 클릭, 결제 등등

툴을 갖추면 할 수 있는 것들

제품 툴을 쓰면 데이터 엔지니어링 역량이 뛰어나지않아도, 데이터 분석가가 없어도 데이터를 분석할 수 있음

이벤트 프로퍼티

  • 이벤트에 수반되는 상세 정보

  • 파라미터, 어트리뷰트라고도 불림

     

  • eg : 상품 카테고리, 세부 카테고리, 제품 이름, 제품 id, 쿠폰 적용여부 등등…

     

  • 데이터 드릴다운을 위해 필수적이다..

user property 유저의 세부정보

  • 유저 이름, 회원가입일, 나이, 사용 기기 등등

  • 상용pa툴에서 자동으로 수집되는 사용자 정보가 있으나 다른 유저 속성은 우리가 직접 정의 필요

  • 어느 시점에 업데이트할것인지 정의 필요

  • eg 이메일, 나이, 지역, 누적 구매금액 등등

  • 사용자가 행동하는 값에 따라 달라지는 유저 프로퍼티가 최신성을 유지하려면 언제 업데이트 할 것인지 시점도 정의해야한다.

DATA TYPES

  • 나이는 숫자 타입으로 저장한다 등등

  • numeric(숫자): 사칙연산 등 각종계산 가능

  • datetime 날짜와 시간

  • string 문자열 / 숫자로 이루어진 문자열도 있음

  • boolean : 예/아니오, t/f

  • Enumerated 제한된 집합 안에서 하나의 값을 택하는 경우 > string보다 효율적임

client side/server side

  • 데이터 트래킹을 위해 데이터 전송 작업 필요

  • client side : 유저 pc, 스마트폰에서 바로 툴 업체 데이터로 전송

    • 장점

      • 클라이언트 사이드에서만 발생하는 유저 인터랙션 트래킹가능

         

      • 익명 유저 트래킹가능

    • 단점

      • 광고차단으로 데이터 유실 가능

      • 수정사항 즉시 업뎃 어려움(배포해야됨..)

      • 서버 사이드에서만 일어나는 이벤트는 트래킹 불가함

  • server side : 유저 데이터 서버로 전송

    • 장점 : 데이터 유실안됨, 수정 즉시반영가능, 서버사이드 트래킹가능

    • 단점 : 유저 인터랙션 트래킹 어려움, 익명 유저 트래킹하려면 추가작업 필요

-> 그래서 결국 둘 다 쓴다

-> 이벤트데이터를 어디서 트래킹 할 것인지 정의해야함

 

Event taxonomy 설계

  • taxonomy : 분류 체계

  • Event taxonomy 설계 : 이벤트 트래킹 플랜 만들기

접근법

  • 탑다운 접근

     

    • 데이터 활용 목적 정의하기

    • 비즈니스 퀘스쳔

      • 목적 달성을 위해 알아야 할것, 답을 찾아야 할 질문 정의하기

    • 이벤트 및 이벤트 프로퍼티 정의하기

  • 바텀업 접근

    • 제품의 주요 이벤트는 무엇인가에서 시작

    • 핵심 이벤트(결제 조회 등등)

하지만 주로 탑다운으로 접근하는 것을 추천

데이터 설계할 때부터 나중에 어떻게 활용할까 염두해야 한다

처음부터 모든 이벤트를 트래킹하지말고 꼭 필요한 이벤트만 트래킹하자

  • 처음에는 30~50개부터 시작

  • 탑다운 접근법

  • aaerm측면에서 접근하기

naming convention

  • 일관성

    • 띄어쓰기 하이픈 대문자 명사동사 사용 등등

  • 명확성

    • 여러 사람이 보는 데이터기 때문에 한번에 알아볼 수 있어야함'

    • 국제 공용어인 영어 사용

이벤트 세분화 : 얼마나 잘게 쪼갤까?

정답은 없으나 각 행동이 구분되는 서로 다른 행동인지/본질적으로 같은 행동인지 판단해서 정의

이벤트 텍소노미 문서만들기

들어가야 할 항목

  • 네이밍 컨벤션 :

    이름 규칙,

    대소문자 띄어쓰기 하이픈 밑줄 등등

  • 이벤트 정보

    • 어떤 이벤트? 이벤트 이름, 클라이언트/서버사이드 구분

       

    • 현재 구현단계 등등

  • 이벤트 프로퍼티 정보

  • 유저 프로퍼티 정보

문서 작성, 관리 할 때

  • 기존 템플릿 활용하는 것을 추천

  • 데이터베이스 방식으로 정리하기

    • 노션처럼 문서에서 관계형 데이터베이스를 활용할 수 있는 툴 사용

    • 이벤트와 프로퍼티 사이 관계 정리하기 등등

사후관리

  • 제품 변화에 따라 이벤트 트래킹/업뎃 필요

  • 사후관리 실수…

    • 네이밍 컨밴션 규칙 어기기

    • 오탈자, 불필요한 공백 넣기 등등

    • 새로운 기능을 개발하면서 데이터 트래킹 계획을 세우지 않기

    • 이벤트 프로퍼티 넣어놓고 문서 업데이트 안하기

★데이터로 일하려면 : 데이터 축적 + 트래킹 + 사후관리 잘하기★

 

product discovery

  • 프로덕트 디스커버리 = 무엇을 만들지 결정하는 과정(decding what to duild)

  • 목표 : Valuable, usable, feasible, viable한 솔루션을 찾는 것

왜 디스커버리라는 단어를 썼을까?

  • 아이디어>제품로드맵>요구사항>디자인>개발이라는 구시대적 제품 개발 프로세스 비판을 위해 등장

  • 신약 개발에서 discovery라는 용어를 사용하는 것에 착안하여 사용하기 시작함

이터레이션과 실험

  • 큰 기회비용 발생 전 미리 assumption 검증해야함

  • 아이디어를 개발완료 후 마지막에 검증 X

  • A/B테스트, 사용성 테스트 들은 방법일 뿐 그 자체가 실험은 아님

문제 발견과 솔루션 발견

  • 솔루션 발견에 더 많은 리소스 투여하기

  • 아이디어 개발 완료 후 다음 프로젝트로 넘어가는 것이 아닌 지속적으로 성장시키기 위해 노력해야함

Assumptions 검증 방법

  • 종류에 따라 적합한 검증 방법이 달라질 수 있음

    • 인터뷰, 설문조사, 시제품, 데이터분석, A/B 테스트, 사용성 테스트 등등

  • 낮은 비용, 빠르게 검증할 방법을 찾는 것이 가장 중요함

  • 100% 확신 가능한 결과를 낼 수 있는 검증방법은 없음 -> 실행을 위한 결단력이 필요함

지양해야 할 전략

  • 자유롭게 아이디어를 낸다는 차원에서 난사하듯 아이데이션 하고 실행하는 것

  • 백로그..

  • ICE scoring

     

전략의 역할 : 판단과 의사결정의 기준이 되는 Guiding Policy가 된다. -> 전략에 맞는 액션에 선택과 집중 가능

  • 무엇을 하지 않을 것인가를 정하는 것

전략 방법

  • Opportunity solution tree

  • Northstar Frame work

  • 공통점

    • 성과를 위한 비구조적 문제를 구조화하는 방법

    • opportunity space, solution space 충분히 탐색하기

    • 의사결정에 도움을 주는 개념적 지도

전략 : Opportunity solution tree

  • 하나의 목표 정의하기

  • 기회(니즈, 욕구, 페인 포인트) 발굴하기

  • 기회 맵핑하기 : 그룹핑, 세분화

  • 집중할 기회 정하기

  • opportunity space 탐색

  • 솔루션 아이데이션 진행

  • 솔루션 assumptions 검증 및 실행

 

전략 : Northstar Frame work

  • output-input 지표를 연결하는 metric hirechy에서 확장된 버전

  • 6개월~1년 단위로 꾸준히 점검 필요

     

  • 구성 단계

    • North Star Metric

      • 제품 조직이 영향을 끼칠 수 있다고 믿어지는 레벨의 지표

      • 중장기적 사업성과, 고객 가치를 제공하지 못하는 지표는 제외

    • Input

      • 실험을 통해 인과관계 검증된 경우

      • 인과관계 확인 전 가정하여 설정 가능

    • Opportunity

      • 고객니즈 페인포인트, 욕구, 솔루션의 방향성

    • intervention

      • 솔루션

Product Growth

  • 전제 : 제품에 확실한 핵심 가치가 있는 경우

    • product worth solving 진행 필요

      • 중요한 문제인가?

      • 타당한 비즈니스 모델을 만들 수 있는가?

  • 시장에서 반응 있는 제품의 성장을 가속화 하는 방법

  • 그로스 <> A/B 테스트 여러번 하기

    • 실험이 성장에 기여하기 위해 탄탄한 기반이 필요함

      • 탄탄한 기반 : 그로스 레버, 그로스 모델에 대한 이해

      • 그로스 레버 : Acquisition, Retention, Monetization

그로스 레버 : Acquisition

  • 마케팅, 세일즈를 통한 획득을 주로 생각하지만 제품을 활용해서도 고객 획득 가능

방법

  • 레퍼럴 : 사용자들이 다른 사용들을 초대

    • eg : 페이스북, 링크드인 등 소셜미디어, 드롭박스, 에어비앤

    • 조건

      • 고객이 제품에 만족

      • 고객이 제품의 가치를 금방 실감할 수 있다(quick time to value)

      • 많은 사람에게 어필할 수 있는 제품(broad value proposition)

    • 모든 제품이 바이럴하게 성장할 필요는 없음을 염두하기

    • 네트워크 효과 : 사용자가 늘어날수록 사용자가 가치를 얻을 수 있음(eg : 전화, SNS)

  • 제품이 광고판이 됨

    • eg : calendly(일정을 잡으려다보니 서비스를 공유하게되고 자연스럽게 홍보가 됨)

       

  • UGC로 사용자 유입시키기

    • UGC : user generated content

    • 사용자가 제품을 이용하면서 자연스럽게 컨텐츠를 만듦

    • 사용자가 다른 사용자에게 공유

      • eg : 스티비 뉴스레터, 타입폼

    • 검색엔진 노출

      • eg : 핀터레스트, 트립어드바이저

         

  • 다름 제품과의 연동(integration)

    • eg

      • 세일즈포스 - 줌, 링크드인 등 연동 가능

      • grammarly - 웹프로그램에 확장프로그램으로 제공

      • 우버 - 구글 지도와 연동

  • B2B제품 : 제품 주도 성장(product-Led Growth, PLG)

    • 배경

      • 전통적 방식 : 영업자를 통해 고객를 획득해 탑다운 방식으로 유저들이 이용하게 됨

      • 최근 : 유저들이 제품 선경험 후 회사에 확산(바텀업)되어 공식 툴이 됨

        • self-serve 방식 : 슬랙, 노션 등

    • 단, 세일즈를 대체하지는 않음

    • 작은 기업들 확보에 효과

 

댓글을 작성해보세요.

채널톡 아이콘