41/ 50
＋ 데이터 한계와 인과 추론의 경계를 가장 정확히 짚었다.
－ 최종 질문이 지나치게 복합적이고 전체 답변도 다소 길다.
데이터로 답할 수 있는 질문으로 다듬는 프롬프트
"매출이 왜 줄었나" 같은 질문을 실제로 쿼리 가능한 형태로 좁힙니다.
| 분류 | 개발 › 데이터·DB |
|---|---|
| 태그 | 분석질문생성개발자 |
Turn this into a question the data can answer. Steps: 1. Restate what I am actually asking. Vague questions usually hide two or three separate ones — list them. 2. For each, make it answerable by fixing: **what is measured / what it is compared against / over what period / for which population**. A question missing any of these cannot be queried. 3. **What result would count as an answer**, and what result would mean "not this". *If no result would change the decision, say so — that question is not worth running.* 4. Which of my available data can answer it, and what is missing. 5. Confounders that would make an answer misleading: seasonality, a change in how something was recorded, a population that shifted, survivorship. 6. The order to investigate in — cheapest question that most narrows the possibilities first. Then: the sharpened question, in one sentence, with the comparison explicit. Rules: - *Do not write the query yet.* A query against a vague question produces a confident wrong number. - Say when the honest answer is that the available data cannot settle it. - Distinguish "what changed" from "why it changed". Data answers the first much better than the second.
붙여 넣으면 맨 아래에 채울 칸(알고 싶은 것 · 가진 데이터 · 이 답으로 내릴 결정)이 나옵니다
어떤 프롬프트인가
데이터 분석이 헤매는 건 질문이 흐릿해서다. 이 프롬프트는 무엇을 무엇과 비교하는지, 어느 기간인지, 어떤 값이 나오면 답이 된 것인지를 먼저 확정한다.
모델 비교
ChatGPT가 가용 데이터와 인과 한계를 가장 신중히 다뤄 우수하다. Gemini는 더 선명하지만 일부 데이터를 지어냈고, [C]는 누락됐다.
39/ 50
＋ 가설별 판정과 의사결정을 구체적으로 연결했다.
－ 보유가 불명확한 채널·버전·오픈율 데이터를 전제했다.
| 기준 | ChatGPT | Gemini | 앞선 모델 |
|---|---|---|---|
| 지시 준수 | 9 | 8 | ChatGPT +13% |
| 정확성 | 8 | 6 | ChatGPT +33% |
| 구체성 | 9 | 9 | 동점 |
| 구성·가독성 | 9 | 9 | 동점 |
| 분량 적정성 | 6 | 7 | Gemini +17% |
gpt-5.6-sol가 모델 이름을 가린 채 1~10점으로 채점했습니다 (2026-09-25). 측정값이 아니라 AI 심사 결과입니다.
답 전문 보기
같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.
알고 싶은 것: 이번 달 들어 앱 리텐션이 눈에 띄게 떨어진 이유가 뭔지 알고 싶어요 가진 데이터: GA4 이벤트 로그, 가입일 기준 코호트별 DAU/WAU/MAU 테이블, 앱스토어·플레이스토어 리뷰 텍스트, 최근 6개월 푸시 발송 이력 이 답으로 내릴 결정: 다음 스프린트에 리텐션 개선 기능을 최우선으로 넣을지, 아니면 마케팅 예산을 신규 유입에 더 투입할지 결정
1. 실제로 묻고 있는 것
“이번 달 앱 리텐션이 실제로 떨어졌는가?”와 “떨어졌다면 그 원인이 제품 문제인가, 신규 유입 구성·마케팅 변화인가, 측정 문제인가?”가 섞여 있습니다.
구체적으로는 세 질문입니다.
- 이번 달 리텐션이 이전 기간보다 유의하게 하락했는가?
- 하락했다면 어느 코호트·플랫폼·유입경로·앱 버전·행동군에서 발생했는가?
- 하락 원인이 제품 사용성 변화인지, 유입 사용자 구성 변화인지, 푸시·마케팅·측정 방식 변화인지?
3번은 “왜”에 대한 질문입니다. 데이터로 변화와 연관성은 확인할 수 있지만, 현재 데이터만으로 인과관계를 확정하기는 어렵습니다.
2. 질문을 쿼리 가능한 형태로 고정하기
| 질문 | 무엇을 측정하나 | 비교 기준 | 기간 | 대상 모집단 |
|---|---|---|---|---|
| 리텐션이 하락했는가 | 가입 후 D7 및 D30 재방문율 | 최근 3개월 신규 가입자 코호트의 동일 지표 | 완료된 코호트 기준, 이번 달과 직전 3개월 | 신규 가입자 전체, iOS/Android 분리 |
| 어디서 하락했는가 | 코호트별 D7/D30 리텐션 및 활성 사용자 비율 | 같은 플랫폼·유입경로·앱 버전의 과거 코호트 | 최근 3개월 대 이번 달 | 플랫폼, 유입경로, 앱 버전, 국가 등 데이터가 있는 세그먼트 |
| 제품 행동과 관련 있는가 | 핵심 이벤트 수행률과 이후 재방문율 | 핵심 이벤트 수행 사용자와 미수행 사용자 | 가입 후 첫 7일 또는 30일 | 해당 기간에 가입한 사용자 |
| 푸시와 관련 있는가 | 푸시 수신·오픈·미수신별 리텐션 | 과거 푸시 발송군 또는 미발송군 | 최근 6개월 | 푸시 대상 사용자 |
| 리뷰가 신호를 주는가 | 부정 리뷰 비율과 주요 주제 | 이전 기간의 리뷰 감성·주제 | 최근 6개월, 월별 또는 주별 | 앱스토어·플레이스토어 리뷰 작성자 |
단, 신규 유입경로, 앱 버전, 국가, 푸시 수신 여부가 GA4에 제대로 남아 있어야 위 비교가 가능합니다.
3. 무엇이 답이고, 무엇이 “이 가설이 아님”인가
질문 1: 실제 하락인가
답으로 볼 결과:
- 이번 달의 완료된 D7 또는 D30 리텐션이 직전 3개월 평균보다 의미 있게 낮고,
- 특정 한 플랫폼만의 문제가 아니라 전체 또는 주요 사용자군에서 반복되며,
- GA4 이벤트 수집량이나 정의 변경으로 설명되지 않는 경우
“이번 달 리텐션이 떨어졌다”고 판단할 수 있습니다.
다음이면 “실제 하락이라고 아직 말할 수 없음”입니다.
- 이번 달 코호트가 아직 D7/D30에 도달하지 않음
- 최근 3개월 평균 대비 차이가 일시적 변동 범위 안에 있음
- 이벤트 수집 누락, 이벤트명 변경, 앱 업데이트에 따른 측정 오류 가능성이 있음
- 전체 리텐션은 하락했지만 특정 대규모 유입경로 구성 변화만으로 설명됨
질문 2: 신규 유입 문제인가, 제품 문제인가
제품 문제를 의심할 수 있는 결과:
- 같은 유입경로·플랫폼·앱 버전 내에서도 이번 달 리텐션이 하락
- 핵심 기능 이벤트 수행률도 함께 하락
- 부정 리뷰에서 동일한 제품·오류 주제가 증가
- 푸시 노출 차이를 통제해도 하락이 남음
신규 유입 또는 마케팅 구성 문제를 의심할 결과:
- 전체 리텐션은 떨어졌지만, 각 유입경로별 리텐션은 거의 변하지 않음
- 이번 달에 저리텐션 유입경로의 비중이 증가
- 신규 유입 사용자의 초기 행동과 과거 코호트의 초기 행동이 달라짐
그 어느 쪽도 결정적으로 확인되지 않으면, “원인”은 현재 데이터로 확정할 수 없습니다. 이 경우 리텐션 개선 기능과 신규 유입 예산 중 하나를 데이터만으로 선택하는 것은 정당화하기 어렵습니다.
이 분석이 의사결정을 바꾸는 기준
- 제품 내부 하락이 확인되면: 다음 스프린트에서 리텐션 개선 기능을 우선
- 유입경로 구성 변화로 설명되면: 신규 유입 예산 확대 여부를 별도로 검토
- 측정 오류나 미완료 코호트 문제면: 예산·기능 우선순위 결정을 보류하고 계측부터 수정
- 두 원인이 모두 있으면: 기능 개선 전후를 측정할 실험과 유입 예산의 증분 효과를 함께 설계
4. 가진 데이터로 가능한 것과 빠진 것
가능한 것:
- GA4 이벤트 로그: 리텐션 계산, 초기 행동, 플랫폼·앱 버전·유입경로별 차이
- 코호트별 DAU/WAU/MAU 테이블: 전체 활성도 추세와 코호트별 변화 확인
- 리뷰 텍스트: 불만 주제와 발생 시점의 변화 탐색
- 푸시 발송 이력: 발송량·빈도·타이밍과 리텐션 변화의 동시 발생 확인
빠진 데이터 또는 확인이 필요한 것:
- D7/D30 리텐션 원시 코호트 데이터와 이번 달 코호트의 관찰 완료 여부
- 유입경로별 신규 가입자 수와 비용
- 광고 캠페인·타기팅·예산 변경 이력
- 앱 버전별 릴리스 날짜와 기능·장애 변경 내역
- 푸시 수신 여부·오픈 여부·메시지 내용·대조군
- 사용자별 국가, 플랫폼, 신규/기존 사용자 구분
- GA4 이벤트 정의 변경 및 누락 이력
- 오류 로그, 크래시율, 앱 성능 지표
- 기능 출시나 가격·정책 변경 기록
특히 푸시 “발송 이력”만으로는 푸시가 리텐션을 높였는지 판단할 수 없습니다. 푸시를 받은 사용자와 받지 않은 사용자가 원래부터 다를 수 있기 때문입니다.
5. 답을 오해하게 만들 수 있는 요인
- 기간 미완료: 이번 달 가입자는 D7/D30 관찰이 끝나지 않았을 수 있음
- 시즌성: 휴일, 방학, 월초·월말, 특정 이벤트로 사용 패턴이 달라질 수 있음
- 측정 변경: GA4 이벤트명, 세션 정의, 로그인 방식, SDK 버전이 바뀌었을 수 있음
- 모집단 변화: 광고 채널, 국가, 플랫폼, 캠페인 타깃이 달라졌을 수 있음
- 앱 버전 변화: 특정 버전의 오류나 온보딩 변경이 일부 사용자에게만 영향을 줄 수 있음
- 푸시 선택 편향: 활동성이 높은 사용자에게 푸시가 더 많이 발송됐을 수 있음
- 리뷰 편향: 리뷰 작성자는 전체 사용자 중 극히 일부이며, 불만이 있는 사용자가 과대표집됨
- 생존자 편향: MAU·WAU 같은 활성 사용자 지표만 보면 이미 이탈한 사용자의 문제를 놓칠 수 있음
- 상관관계와 원인 혼동: 리텐션 하락과 리뷰 악화가 함께 나타나도 어느 쪽이 원인인지는 별도 검증이 필요함
6. 조사 순서
계측과 코호트 완결성 확인
이벤트 누락·정의 변경·미완료 코호트인지 먼저 확인합니다. 가장 싸고, 잘못된 분석을 막습니다.실제 리텐션 하락 확인
완료된 D7/D30 코호트를 직전 3개월과 비교합니다. 플랫폼별로도 나눕니다.구성 효과 분리
유입경로·플랫폼·국가·앱 버전별로 분해해, 전체 하락이 사용자 구성 변화 때문인지 확인합니다.제품 행동과의 관계 확인
가입 후 핵심 이벤트 수행률과 리텐션을 비교합니다. 동시에 앱 버전별 오류·리뷰 주제를 확인합니다.푸시 영향 탐색
발송 시점과 리텐션 변화를 비교하되, 인과관계가 아니라 후보 신호로만 취급합니다.결정용 검증 설계
제품 가설이면 기능 실험이나 단계적 출시를, 마케팅 가설이면 유입경로별 증분 테스트를 설계합니다.
최종적으로 sharpen한 질문
“완료된 이번 달 신규 가입자 코호트의 가입 후 D7 및 D30 리텐션이 직전 3개월의 동일 플랫폼·동일 유입경로 코호트보다 하락했는지, 그리고 유입 구성 변화로 보정한 뒤에도 하락이 남아 핵심 기능 사용률·앱 버전·리뷰 악화와 함께 나타나는지를 비교해, 다음 스프린트에서 리텐션 개선 기능을 우선할지 신규 유입 예산을 우선할지 결정할 수 있는가?”
같은 분류의 프롬프트
| 대용량 텍스트 변환기 프롬프트 | |
| AI 데이터 추출 도구 기획 프롬프트 | |
| AI2sql 자연어 SQL 생성 프롬프트 | |
| 백엔드 아키텍트 역할을 맡기는 프롬프트 | |
| Base R 프로그래밍 프롬프트 |