✋🏾 Google BigQuery을 이용하여 쓰인 포스팅입니다.

BigQuery 조건식 중에 null을 이용하는 조건식은 대표적으로 3가지가 있다.

• COALESCE(expr1,expr2,expr3…….)
  
  • 인수로 들어간 표현식(expr) 중에 null이 아닌 첫번째 표현식 값을 반환한다.
    
  • 값이 반환되면 나머지 표현식은 평가되지 않는다.
    
  • 입력 표현식에는 모든 데이터 타입이 입력 가능하다.
    
• NULLIF(expr1, expr2)
  
  • expr1과 expr2가 값이 같으면, null을 반환하고 그렇지 않으면 expr1을 반환한다.
    
  • expr1과 expr2는 같은 상위 데이터 타입에 속해야하며, 비교 가능해야 한다.
    
• IFNULL(expr1, expr2)
  
  • expr1이 null이면 expr2를 반환한다. 그렇지 않으면 expr1을 반환한다.
    
  • expr1과 expr2에는 모든 데이터 타입이 입력될 수 있다.
    
  • COALESCE(expr1,expr2)와 같은 표현이다.
    
    

예시 데이터셋은 아래와 같다.

-- 예시 데이터 셋 제작 코드 
WITH ex_table AS 
( 
    SELECT 30 AS col1, 37 AS col2 , 55 AS col3
  UNION ALL SELECT null AS col1, 17 AS col2 , 1 AS col3
  UNION ALL SELECT null AS col1, null AS col2 , 1 AS col3
  UNION ALL SELECT 3 AS col1, 3 AS col2 , null AS col3 
)

SELECT 
  co11
  ,co12
  ,col3
FROM ex_table
;

위 예시 데이터에 null과 관련된 조건식( coalesce,nullif,ifnull)을 넣고 결과를 비교해보자
출력 결과는 테이블 맨 우측에 위치한 result 칼럼에서 확인할 수 있다.

• COALESCE 구문 예시
  
  

/*
coalesce 예시
*/
WITH ex_table AS ( 
SELECT 30 AS col1, 37 AS col2 , 55 AS col3
UNION ALL SELECT null AS col1, 17 AS col2 , 1 AS col3
UNION ALL SELECT null AS col1, null AS col2 , 1 AS col3
UNION ALL SELECT 3 AS col1, 3 AS col2 , null AS col3
)

SELECT
  *,
  coalesce(col1,col2,col3) as result_coalesce
FROM ex_table;

• NULLIF 구문 예시
  
  

/*
nullif 예시
*/
WITH ex_table AS ( 
SELECT 30 AS col1, 37 AS col2 , 55 AS col3
UNION ALL SELECT null AS col1, 17 AS col2 , 1 AS col3
UNION ALL SELECT null AS col1, null AS col2 , 1 AS col3
UNION ALL SELECT 3 AS col1, 2 AS col2 , null AS col3 
)

SELECT
  col1,
  col2,
 nullif(col1,col2) as result_nullif -- nullif는 expr 총 2개만 비교 가능
FROM ex_table

• IFNULL 구문 예시
  
  

/*
ifnull 예시
*/
WITH ex_table AS ( 
SELECT 30 AS col1, 37 AS col2 , 55 AS col3
UNION ALL SELECT null AS col1, 17 AS col2 , 1 AS col3
UNION ALL SELECT null AS col1, null AS col2 , 1 AS col3
UNION ALL SELECT 3 AS col1, 3 AS col2 , null AS col3
 )

SELECT
  col1,
  col2,
 ifnull(col1,col2) as result_ifnull
FROM ex_table

이처럼 null과 관련된 조건식 3가지를 알아보았다.

나는 특히 실무에서 IFNULL 구문을 주로 활용한다.
(거의 IFNULL만 사용한다)

데이터 추출시 LEFT JOIN을 이용하여 테이블끼리 매칭하고 집계하는 경우가 많은데,
이 때 매칭이 안되는 집계 결과(null)를 0으로 바꿔줄때 많이 사용한다.

ex) IFNULL(t2.won,0) AS won

위의 케이스처럼 IFNULL을 LEFT JOIN과 같이 활용하면 매우 유용하니 한번 활용해봐도 좋을 것 같다.

( 아래 데이터는 실제 데이터가 아닌 임의로 생성된 샘플 데이터 입니다. )

종합 이커머스 플랫폼의 데이터 분석가라 가정해보자.
분기 카테고리 포트폴리오 리뷰 회의를 앞두고 있고 마케팅팀이 아래 한장의 파이차트를 가져왔다.

마케팅팀 코멘트: 패션이 여전히 1등이고 포트폴리오 구성도 안정적입니다. 큰 변화 없이 잘 굴러가고 있어요.

나는 이 주장을 그대로 임원회의에 올릴지, 아니면 다르게 봐야 할지 판단해야 한다.

위 차트1 만으로는 매출 성장은 볼 수 없기때문에 아래 차트들을 보조 자료로 활용했다.

[요약]
포트폴리오 구성은 안정적이나 전월 대비 매출 성장률은 영역별로 차이가 있다.
식품,뷰티가 큰 폭으로 성장했으며 매출 포트폴리오 구성을 다각화하는데 기여할것으로 판단한다.

다만 전사 성장은 두 카테고리에 의존하고 있다. (식품,뷰티)
( 식품·뷰티: +11억 나머지: −5억 )

특히 주력 캐시카우인 패션의류가 전월 대비 매출이 -4.8% 감소했으므로 점검과 대책 마련이 필요하다.
패션의류가 버텨주면서 다른 영역이 성장해야 포트폴리오 구성이 다각화 될 수 있다.

[종합 의견]
당월 전체 매출은 전월 대비 3.7% 성장하였다.(6억 증가)
전월과 당월의 매출 포트폴리오 순위 구성은 동일하다.

패션의류 , 뷰티, 디지털/가전, 식품 , 리빙/홈, 스포츠/레저, 기타 순이다.
매출 순위 구성은 동일하지만 매출액 자체를 비교하면 전월 대비 당월 매출의
변화가 있어 상세 분석이 필요하다.

• 매출 상승 :
  • 식품 : 33.3% 성장 (+6억)
  • 뷰티 : 17.9% 성장 (+5억)
    
• 매출 하락 :
  • 패션의류 : -4.8% (-2억)
  • 디지털/가전 : -3.2% (-1억)
  • 리빙/홈 : -4.5% (-1억)
  • 스포츠/레저 : -8.3% (-1억)
    

뷰티,식품의 매출이 큰 폭으로 성장했다.
특히 뷰티의 당월 매출 비중이 전체의 19.6%로 약 20%선까지 성장했다.

패션의류에 집중되었던 매출 비중이 식품, 뷰티의 성장으로 집중도가 소폭 완화되었다.
포트폴리오 집중도를 재는 표준 지표인 HHI (허핀달-허시만 지수 : 점유율 제곱의 합)으로 판단 가능하다.
( 전월 HHI ≈ 0.173 → 당월 HHI ≈ 0.170 )

다만 1개월치 데이터를 기준으로 판단한 내용이므로 향후 2~3개월 데이터를 더 보고
매출 포트폴리오가 다각화되고 있는지 판단이 필요하다.

매출 포트폴리오가 다각화되었을때 패션의류와 뷰티,식품은 겹치는 제품군이
없으므로 카니발이 일어나는 영역은 아니라고 판단된다.
( 데이터 검증 : 동일 고객의 카테고리 교차구매율, 장바구니 동시구매 분석 )

특히 세 영역은 웰빙이라는 키워드로 시너지가 일어날 수 있는 영역이라고 생각한다.
( 데이터 추가 : 웰빙 브랜드들의 시장 점유율, 매출 성장율 )
세 영역을 지속적으로 성장시켜 웰빙 브랜드로 브랜딩하는 것도 좋은 전략이 될 것으로 보인다.

다만 주력 영역인 패션의류가 당월 매츨이 전월대비 5% 빠졌다는것은 점검이 필요해보인다.
원인 파악(외부 요인 , 내부 요인)과 대책 마련이 필요해보인다.
패션의류가 캐시 카우로써 버텨줘야 매출 포트폴리오 다각화가 되어도 의미가 있다.

디지털/가전,리빙/홈,스포츠/레저도 1억씩 매출이 감소했으나 이 현상이 단기적인 현상인지
지속적으로 하락하고 있는지 봐야한다.

전월과 당월만으로는 매출 하락이 일시적인 현상인지 , 대안이 필요한 현상인지 파악이 어렵다
특히 매출 외에도 고객 유형별 이용자수, 재구매자수 등 세부지표등을 추가로 봐서 점검이 필요해보인다.

분석을 보고 경영진,시니어 데이터 분석가가 던질 질문들을 아래와 같이 예상해봤다.
회의때 나올 질문을 미리 예상하고 대비하는것은 큰 도움이 된다.

경영진이 질문을 던졌는데 답변을 제대로 못한다면 나의 분석 전체에 대한 신뢰가 떨어질 수 있다.
완벽하게 대비는 못하겠지만 미리 어느정도 준비해서 그 내용을 기반으로 답변하자.

1. 패션의류의 매출이 하락한 이유는 무엇인가?
전반적으로 트래픽이 빠진것인지, 구매 전환율이 빠진것인지? 아니면 객단가가 줄어서 그런것인지, 원인이 무엇이냐?
원인에 따라 처방이 달라진다.
ex) 원인에 따른 처방

• 트래픽 문제 → 마케팅
• 구매 전환율 → 상세 페이지,가격
• 객단가 문제 → 상품 믹스

2. 매출 말고 이익으로 봐도 동일한 경향인가?
식품은 일반적으로 마진이 박한 카테고리다. 매출 다각화가 회사 전반으로 봤을땐 이익이 희석되는 것일 수도 있다.
마진도 고려해서 실질적으로 회사에 이익을 가져다 주는 부분도 봐야한다.

3. +3.7% MoM이 좋은 거 맞나? 우리 평소 MoM은? YoY로는? 목표 대비는?
기준선 없는 성장률은 해석 불가, 샘플 데이터에 기준선이 없기때문에 나올 수 있는 질문이다.

4. 디지털,리빙,스포츠카가 1억씩 빠졌는데 평소에도 일어나는 변동 범위 아닌가?
수치 변화가 단순 노이즈일수도 있다는 생각에 들어오는 질문일 것 이다. 비교 기간을 늘려서 변동성 확인이 필요하다.

메달리온 아키텍처는 데이터 마트를 점진적인 3개의 계층으로 나눠서 구축하는 방식을 말한다.
각 계층이 연쇄적으로 연결된 형태라 관리가 용이하다는 장점이 있다.

스포츠 경기에서 성적에 따라 메달을 상으로 주고 그 등급을 브론즈,실버,골드 3개의 계층으로 나누는데
이 체계에 빗대 메달리온 아키텍처라고 부른다. 짐작하다시피 Bronze, Silver, Gold 계층이다.
Bronze → Silver → Gold 로 연결되어있다.

Bronze를 이용해서 Silver 테이블을 구축하고 Silver 테이블을 이용해서 Gold 테이블을 만든다고 보면 된다.
일반적으로 Bronze는 원본 데이터, Silver는 정제 데이터, Gold는 최종 집계 형태를 띈다

• Bronze : 원본 데이터를 그대로 저장. 데이터의 형태를 변경하지 않고 나중에 문제가 생겼을때 추적할 수 있는 보관소 역할을 한다.
• Silver : 브론즈 데이터를 분석 가능한 형태로 다듬는 단계. 중복 제거, 결측치 처리, 타입 변환 , 필터링등으로 정제하여 데이터 분석에 적합하도록 품질을 높인 상태를 말한다. 이 시점부터 데이터 품질이 어느 정도 보장이 되며 분석가가 탐색용으로 가장 많이 참조하는 계층이기도 하다.
• Gold : 비즈니스 요구사항에 맞춰 최종 가공된 데이터를 만드는 단계로 최종 사용자가 쓸수있는 형태로 집계 , 요약된 데이터가 모인 단계다. 예를 들어 지역별 월매출, 고객 세그먼트별 이탈률 같은 비즈니스 지표가 이 단계에 위치한다.
  

메달리온 아키텍처의 장점은 크게 2가지를 뽑을 수 있다.

• 관리가 용이하다.
  • 연쇄적 구조라 파이프라인 관리가 용이하다.
  • 직관적인 구조라 테이블 명세서에 정리하기 편해 구조 파악이 쉽다.
• 지표 리소스를 줄일 수 있다.
  • BI툴을 통해 지표 제작시 추출할때마다 원본을 집계하지않고 바로 Gold 테이블을 이용하면 되기때문에 리소스를 줄일 수 있다.
  • Gold 테이블을 바라보면 배치 처리할때 한번만 집계하면 된다.

Silver 단계를 유저별 집계 테이블로 구성하여 활용도를 높이는 것을 추천한다.
특히 아래 세 항목을 고려하는것을 추천한다.

• 브론즈 : 원본 → 실버 : 유저별 집계 → 골드 : KPI 집계로 구현
• 실버 테이블간 조인이 될수있게 키값을 공유하도록 구성
• 특히 실버 테이블중에서 활용이 잦은 필드들을 모아놓은 마스터 실버 테이블을 만들어서 분석시 조인 최소화.
  ( 많은 조인은 쿼리 작성시 부담이 됨.)

실버를 유저별 일별 집계 테이블로 구성했을때 보는 관점에 따라서 골드로 볼수도 있다. 편의상 3단 구조이기 때문에 실버로 설명했지만
만약 정제 과정을 깊게 거쳐야한다면 골드를 2단계로 나눴다고 봐도 된다. 포인트는 유저별,일별 집계 테이블이 필요하다는 것이다.

깊이있는 데이터 분석을 위해서는 유저별로 쪼개서 보는 것 (드릴다운) 이 꼭 필요하다.

예를 들어 DAU가 50,000명에서 40,000명으로 감소했다고하자.이 지표를 보고 단순히 10,000명 감소했으니 위기다에서
끝나는게 아니라 감소한 DAU 10,000명이 어떤 유저인지? 신규 유저가 감소한것인지 , 복귀 유저가 감소한 것인지
그리고 그중에서 고레벨 유저가 감소한 것인지 저레벨 유저가 감소한것인지등 다각도로 데이터를 뜯어볼수있다.

이렇게 얼마나 상세하게 뜯어보느냐에 따라 현황 파악이 달라지며 대응 방안이 달라진다.

결국 데이터분석에는 드릴다운 분석이 꼭 필요하고 이를 효율적으로 하기 위해 유저별, 집계 테이블을 구축한다고 보면 된다.
특히 이는 점점 사용이 많아지고 있는 데이터분석 AI Agent의 답변 정확성을 올리고 효과를 극대화하는데에도 도움이 된다.

AI Agent가 최종 요약 집계된 테이블만 사용할 수 있다면 드릴다운 분석을 할 수 없고 이런상황임에도 답변 결과를 내야하기때문에
잘못된 테이블을 바라볼 가능성이 크다. 결국 할루시네이션으로 이어질수있다. Silver 테이블을 활용함으로써 이를 보완할 수 있다.

AI Agent 활용은 이제 필수인 시대가 되었다. 앤트로픽의 Claude, 오픈 AI의 Chatgpt, 구글의 Gemini처럼
다양한 AI Agent들이 서비스되고 있다. AI Agent가 일상생활에 깊게 스며들수록 이 Agent들을 어떻게 하면
잘쓸수있을지에 대한 고민도 깊어지고 있다.

1~2년전만에 해도 질문을 어떻게 하면 좋은 답변을 받을 수 있는지에 대해서 많이 나왔다.
프롬프트를 어떻게 입력하면 좋을지, 어떻게 수정하면 좋을지에 대한 많은 연구가 이뤄졌다.
이를 프롬프트 엔지니어링이라고한다. 예를 들어 아래와 같다.

• 맥락을 전달해라
• 구체적으로 질문하라
• 원하는 결과물의 예시를 전달해라

프롬프트 엔지니어링으로 AI Agent의 답변을 개선할수있지만 이내 이 방법만으로는 아쉬움과 한계가 있음을 알 수 있다.

우선 새 대화를 할때 다시 처음부터 정보를 입력해야한다는 점에서 번거롭다.
새 대화를 할때마다 매번 컨벤션(규칙)을 설정해야하고 컨텍스트(배경지식, 맥락)를 전달해야한다.
답변의 일관성과 연속성을 보장하기 위해 많은 토큰 비용을 써야하며 무엇보다 가장 큰 문제는 … 귀찮다는 점이다

“전에 입력해뒀던 컨벤션의 형태로 답변해줬으면 좋겠는데 ? 컨텍스트를 기억해서 답변해줬으면 좋겠는데?” 이런 생각이 드는것이다.

결국 프롬프트 엔지니어링에서 더 나아가 답변의 규칙(컨벤션)과 맥락(컨텍스트)을 고정해둘수있는 장치가 필요하다고 느끼게된다.
다행히도 클로드에서 스킬과 프로젝트라는 기능을 통해 이를 구현할 수 있다.

클로드 스킬과 클로드 프로젝트 모두 답변의 컨벤션(규칙)과 컨텍스트(맥락)을 미리 세팅해둘 수 있는 장치다.
그렇다면 이 두 기능의 차이는 무엇일까? 우선 클로드 스킬과 프로젝트가 무엇인지 각각 살펴보자.

• 클로드 스킬
  • 사전에 작성된 지침을 기반으로 동작함. 특정 작업 유형이 감지되면 자동으로 트리거되는 구조
  • 관련 키워드나 요청이 나오면 해당 스킬의 작성 규칙과 컨벤션을 불러옴
  • 지침은 SKILL.md 파일에 작성된 내용을 참고하며 이 내용은 언제든 수정 가능
• 클로드 프로젝트
  • 클로드 스킬과 마찬가지로 사전에 작성된 지침을 기반으로 동작함.
  • 특정 프로젝트 공간에 컨텍스트를 설정해두고 그 프로젝트 안에서 대화할때마다 자동으로 적용되는 구조
  • 즉, 이 프로젝트안에서는 항상 이 맥락이 적용된다

가장 큰 차이점은 스킬은 어떤 대화든 특정 작업 유형이 감지되면 트리거되는 구조이고
프로젝트는 특정 공간에서 동일한 지침을 적용한다는 점이다.
이로 인해 실질적으로 주제별로 컨텍스트 관리라는 목적은 둘 다 달성할 수 있지만 활용 방법에는 차이가 생기게 된다.

• 스킬
  • 하나의 대화 안에서 여러 컨텍스트를 필요에 따라 전환.
    • ex) 한 대화에서 ML분석을 하다가 경영진 보고 포맷으로 전환하고 싶을때 스킬을 통해 답변을 자연스럽게 전환시킬수있음
  • 서로 다른 프로젝트에 있는 대화이지만 같은 컨텍스트를 적용하고 싶을때 지침을 프로젝트별로 추가할 필요없이 스킬로 작업
    • ex) 게임 분석 프로젝트와 이커머스 분석 프로젝트에 PPT 출력 (원하는 출력형식이 지정되어있는 지침)이라는 스킬을 실행함으로서 출력 형식을 맞춤
• 프로젝트
  • 동일한 지침을 공유하는 대화를 아카이빙할 수 있다. 지난 대화를 찾아보기 쉬움
  • 지침을 세분화해서 관리하기 쉬움 : UI가 직관적이며 파일 업로드가 가능
  • 답변을 트리거하기 위한 별도의 명령어 없이 프로젝트안에서 대화는 지침이 유지됨
    

클로드 스킬과 프로젝트는 서로를 완전히 대체하는 기능이라기보다는
보완적인 역할로 보는게 좋으며 아래와 같이 조합하여 사용할 수 있다.

• 프로젝트로 지침과 컨텍스트를 설정하고 대화를 아카이빙하되 대화별로 지침을 세분화해야할때 스킬을 활용
• 서로 다른 프로젝트들에 동일하게 지침을 적용할때 스킬 활용
  

예를 들어 다음과 같이 활용할 수 있다.

“나는 산업별로 데이터 분석 프로젝트를 하고 싶다. 산업별로 데이터 성격이 다르기때문에 별도 지침을 설정하려고한다.
프로젝트마다 지침에 맞춰 답변을 받되 보고서 형식은 통일된 레이아웃으로 받고 싶다. 이 경우 어떻게 할까?

• 산업별 데이터 분석에 관한 프로젝트를 생성 : 게임,이커머스,스포츠,금융
• 각 프로젝트마다 산업에 맞는 지침과 참고 자료 설정
• 보고서 형식은 스킬로 지정 ( 트리거 : ppt 만들어줘 )
  위와 같이 세팅해놓으면 각 프로젝트에서 대화하고 대화 끝에 ppt만들어줘라는 트리거 입력하면 된다.

신규 유저들이 어느 단계에서 이탈하는지 살펴보기 위해 퍼널 분석을 진행하고자 한다.
( 샘플 데이터 )

첫번째 차트는 각 단계별 진행 유저수 , 두번째 차트는 단계별 이탈률 , 세번째 차트는 플랫폼별 단계별 전환률이다.
이 차트들을 활용해 어느 단계에서 유저들이 많이 이탈하는지 , 개선 지점은 어디일지 살펴보자.

Q1. Tutorial 개선과 첫 구매 개선 중 먼저 개선이 필요한 것은 무엇인가?

A1.
장기적인 관점에서 고려했을때 튜토리얼 개선이 우선적이다.

• 튜토리얼 시작에서 완료까지 빠지는 유저 : 80,000 -> 60,000 ( -20,000명 , 약 25% 빠짐 )
  
• 상점 오픈부터 첫 구매까지 빠지는 유저 : 20,000 -> 6,000 ( -14,000명, 약 70% 빠짐 )
  

이전 단계 대비 빠지는 비율을 봤을때 첫구매 전환 단계가 튜토리얼 완료 단계보다 더 크다.
또 튜토리얼과 첫 구매 둘다 5%p 개선이 가능하다고 가정하고 첫 구매 증가량이 얼마나 나오는지 보면
(다른 전환율 고정)

• 튜토리얼 (tutorial Start→ tutorial Complete)를 +5%p 개선: +약 467건의 첫 구매
  
• 첫구매 (Store→Purchase)를 +5%p 개선: +1,150건의 첫 구매
  

첫 구매 전환 단계 개선이 튜토리얼 완료 단계 개선보다 더 많은 첫 구매를 발생시킨다.
이렇게 보면 첫 구매 전환 단계 개선이 우선적으로 필요하다고 생각할 수 있다.

다만 매출과 튜토리얼의 특성을 봐야한다. 튜토리얼은 누구나 거쳐야하는 과정이고
다음 단계로 넘어가지않으면 플레이 자체를 안해버리는 순수 이탈이다.

반면 구매는 나중에 다시 기회가 있는 행동이라 첫 구매 실패가 곧바로 이탈로 연결되지않을 수 있다.
즉 튜토리얼은 유저층을 잡을수있는 기회가 한번뿐인 단계이고 첫 구매는 다음에 다시 기회가 있는 단계이다.

미래 결제 가능성과 향후 트래픽까지 같이 고려했을때 LTV 효과는 튜토리얼 개선이 첫구매 개선보다 더 높을 가능성이 크다.
따라서 튜토리얼 개선이 우선적이라고 판단한다.

Q2. Android에서 Store-> Purchase 전환이 특히 낮은 이유를 가설로 써보자.

A2.
Android와 ios의 두 플랫폼의 차이점 때문에 전환율이 달랐다고 예상할 수 있다.
Android가 ios보다 약 10%p 적은 전환율을 보인다. 두 플랫폼의 차이점으로는 다음 2가지를 예상할 수 있다.

( 이용자층 )
android는 일반적으로 ios보다 구매력이 낮은 유저층의 비율이 더 높다.
구매력이 낮다고 판단할 수 있는 저가 단말을 사용하는 유저들의 비율이 높고
작업장 운영을 위한 단말기로 사용하는 경우도 많다. (일반적으로 작업장 계정은 결제를 하지않는다)

만약 패키지 상품의 가격대가 전반적으로 높다면 구매력이 낮은 유저들이 쉽게 지갑을 열지않았을 것이고
이로인해 android에서 더 낮은 결제전환율을 보였음을 예상할 수 있다. 이 케이스라면 플랫폼 전체 유저를 모수로 삼지말고
모수에 보정을 가해서 구매력이 있는 유저들을 한정하고 그 안에서 전환율을 비교하는 것이 정확한 진단을 내릴 수 있을 것이다.

( 결제 모듈 연동 )
android에 탑재된 결제 모듈이 ios에 탑재된 모듈보다 결제 절차가 복잡할 경우 이용자들은 구매에 불편함을 느낄 수 있다.
또 모듈 차이로 지원하는 결제 수단이 다를 수 있다. ex) 카카오페이는 ios에서는 되나 android에서는 지원 안함.

( 결제 실패/지연 )
android 단말기에서 결제창 진입은 했는데 구매 완료 이벤트 (purchase_success)가 안찍히는 케이스가 많을 수 있다.
purchase_fail_reason, error_code, latency, crash_before_success 같이 원인을 확인할 수 있는 이벤트를 심어서 어느 구간에서 꺾이는지 확인하면 될 것이다.

Q3. Store Opened 이벤트 정의가 너무 넓으면 생기는 문제는? (퍼널 해석이 어떻게 왜곡될까)

A3.
퍼널 분석은 일방향의 연속된 단계하에서 다음 단계로 넘어갈때 유저들이 얼마나 남아있는지를 볼 수 있는 분석이다.
유저들이 어느 단계에서 다음 단계로 넘어갈때 어려워하는지 알 수 있다.

퍼널 분석에서 단계의 정의가 너무 넓으면 유저가 정확히 어느 지점에서 어려워하는지 특정하기 어려워진다.
예를 들어 store opened라는 이벤트가 있다고 가정하자. 1일내 첫 접속인지,2일내 첫 접속인지 아니면 로그인하고 첫번째 방문인지
아니면 store를 방문할때마다인지등 store opened가 정의가 너무 넓다면 유저가 어려워하는 구간이 정확히 어떤 지점인지 알기 어렵다.

요약하자면 이벤트 정의가 넓으면 아래 케이스들처럼 어느 지점이 문제인지 확인이 어렵다.

• 이벤트 중복 (재방문)으로 분모가 과집계 되거나 반대로 유니크 처리로 정확한 분석을 할 수 없음
  
  • store opened가 방문할 때마다 찍히면 세션 기반/유저 기반 집계에 따라 숫자가 흔들림
    
  • 유니크로 유저수를 처리해도 첫 오픈인지 N번째 오픈인지 섞이면 인사이트가 흐려짐
    
• 윈도우 구간 불일치 (시간 불일치)
  
  • Store Opened는 D7까지 포함인데 Purchase는 D1만 보면 스토어는 열었는데 구매가 없다가 과장되어 보일 수 있음
    

1. 분석 대상

• 대상: 신규 유저 7일 코호트(샘플 데이터)
  
• 퍼널: First Open → Tutorial Start → Tutorial Complete → Account Created → First Match Played → Store Opened → First Purchase
  

2. 현황

• 핵심 병목(상대 이탈 1위): Store Opened → First Purchase
  
  • 이탈 70.0% (전환 30.0%)
    
  • 플랫폼: iOS 33.9%, Android 25.5%
    
  • 최대 손실(절대 이탈 1위): Tutorial Start → Tutorial Complete
    
    • -21,500명 (이탈 26.1%)
      

3. 액션 플랜

• 튜토리얼(절대 이탈 1위)을 1차 개선 대상으로 두되, Store→Purchase(상대 이탈 1위)는 결제 직전 마찰/오류 가능성이 커서 병행 점검 권장.

• 튜토리얼 구간 검증 체크리스트
  
  • 튜토리얼 스텝별 이탈(세부 이벤트), 완료 소요시간 분포, 로딩/크래시 여부.
    
• 안드로이드 전환률 낮은 원인 파악 및 개선
  
  • 유저 구매력차이
    
  • 결제 UX/결제수단 차이
    
  • 결제 실패율/오류코드/지연