JOIN 1번 문제

안녕하세요.tp.id vs p.id 이 부분은 법칙이 있는 것은 아니고 데이터를 보는 목적에 따라 달라집니다.tp의 id는 trainer_pokemon의 id고, p.id는 pokemon의 id입니다. 즉, 트레이너가 포켓몬을 잡은 수를 알고 싶다면 tp.id를 세는 것이 더 맞을 수 있고, 포켓몬의 수를 알고 싶다면 p.id를 사용하면 됩니다. 두개의 차이를 제대로 이해하면, 어떤 차이가 있는지 이해할 수 있어요. p.id를 COUNT할 때는 포켓몬에 피카츄, 피카츄, 라이츄, 라이츄, 파이리 이렇게 있을 수 있는데 p.id는 포켓몬의 수를 세는 것이고, DISTINCT p.id로 하면 피카츄, 라이츄, 파이리만 남겠죠(더 정확히는 피카츄, 라이츄, 파이리의 id만 남아요). 반면에 tp.id는 트레이너가 잡은 포켓몬을 의미해서 DISTINCT tp.id를 해도 Unique하게 됩니다. 그래서 3개의 질문에 대한 답은 "지금 추출하려고 하는 것이 무엇인지 정확히 생각하고 그거에 맞게 사용해야 한다"고, "tp와 p의 id의 차이점을 제대로 이해하는 것이 필요합니다"라고 답변드릴게요. 그래서 보편적으로 뭘 선택한다 이런 관점보단 상황에 따라 다르다라는 관점으로 이해하시면 될 것 같아요. 지금 케이스는 tp.id와 p.id를 DISTINCT하지 않고 COUNT를 했고, JOIN 할 때 1:1 매칭을 했기 때문에 동일한 값이 나오는 상황이고 JOIN이 더 복잡해지거나 하면 id를 잘 선정하는 것이 중요합니다. 연습 문제 중에도 id를 잘 선정해야 하는 문제가 있으니 나중에 풀어보면서 익히시면 좋을 것 같아요(몇 번인지는 알려드리면 스포가 되어서 알려드리진 않을게요)

battle 테이블 생성 시 생성 오류

안녕하세요. 혹시 이미 배틀 테이블이 존재하나요? 존재한다면 기존 테이블을 삭제하고 해야 합니다. 설정을 어떻게 했는지 보여주셔야 원인 파악이 가능해요

5-6. 4번 문제 WHERE 조건의 위치 문의

안녕하세요. 지금 하신 방법이 쿼리 최적화 방식으로는 더 좋은 방법일 수는 있습니다. 미리 가공해서 필요한 것만 JOIN한 것이니 잘 생각하셨어요. 제가 Master를 마지막에 필터링한 이유는 JOIN한 결과를 어떻게 사용할 것인가? 관점에서 Master만 필터링하지 않고 다른 등급의 트레이너를 파악해야 하는 경우 쿼리의 맨 마지막에서 바꿔주는 것이 더 편하기 때문에 이렇게 작성했다고 보시면 됩니다. 단순히 쿼리를 짜는 것이 다가 아니라, 그 쿼리의 결과를 어떻게 사용할지 필터링을 잦게 해야 한다면 어디에 배치할지를 고민하는 것이 필요합니다. 그래서 인프님 쿼리나 제 쿼리의 의도의 차이가 있다고 생각해주시면 될 것 같아요.

5-6. 연습문제 4번, type2에 대해서는 고려하지 않아도 될까요?

인프님 안녕하세요. 현재 문제의 의도는 type1만 고려하는 것을 의도에 둔 문제긴 합니다. JOIN을 하고 집계를 할 수 있는가? 관점을 보기 위한 문제라서요 말씀하신 경우라면 CONCAT 함수로 type1, type2을 합치거나, UNION ALL을 사용해서 합집합으로 쓰는 방법, CASE WHEN을 사용해서 푸는 방법 등 다양할 것 같아요. 예시 쿼리도 드리면CONCAT 함수 사용 예시SELECT id, name, CONCAT(type1, IFNULL(CONCAT('&', type2), '')) AS combined_type FROM basic.pokemon UNION ALLSELECT type, COUNT(*) AS cnt FROM ( SELECT type1 AS type FROM basic.pokemon UNION ALL SELECT type2 AS type FROM basic.pokemon WHERE type2 IS NOT NULL ) GROUP BY type ORDER BY cnt DESC

BigQuery 활용편 18강 질문있습니다!

안녕하세요!강의 잘 수강해주셔서 감사합니다. 해당 부분은 매개변수를 만들기 위해서 시트1에 새로운 값을 작성하고, 그 범위를 지정한 것입니다. 그래서 지금 보이는 화면의 셀이 아닙니다.시트1에 값이 아무것도 없을텐데 저는 B3에 값을 넣었다고 지정하고, 제가 직접 2022-08-01을 입력한 거예요. 13:20분에 이렇게 말합니다 : "시트1이 아무것도 없는 칸이였는데 시트1에 start_date, end_date를 추가했어요" 이게 그 의미에요. 매개변수를 시트1 탭에 추가하고 연결된 시트의 쿼리 편집기에서 매개변수 -> 추가해서 해당 범위를 지정했다고 생각해주시면 됩니다!! 기술적이여도 궁금하신 것이 있으면 언제든 남겨주셔요! 강의 잘 들어주셔서 감사합니다!

리텐션 공부하다가 궁금한게 생겨 질문드립니다

안녕하세요!어제 질문의 답변이랑 결이 유사해서 이어서 설명을 해볼게요.https://inf.run/CcfjL 어제 답변에강의에서 일정 부분만 잡아서 보여드린 것은 계산하는 과정을 보여드릴 때 모든 데이터를 쓰지 않아도 괜찮아서 쿼리 탐색 비용을 줄이려고 기간을 설정했다고 생각해주세요! 이렇게 말씀드렸는데, 회사 데이터를 다룰 때 처음부터 전체 데이터를 한방에 쿼리하는 것보단, 작은 데이터를 범위로 지정해서 쿼리 작성 후, 로직이 정말 잘 맞았다고 확신할 때 데이터 기간을 넓히는 것이 비용적으로도 좋고, 시간적으로도 좋습니다.지금 강의에서 event_date BETWEEN "2022-08-01" AND "2022-11-03"이렇게 기간을 줄인 것은 여러분들의 BigQuery 비용을 줄이기 위함도 있지만, 제가 회사에서 일하면서 너무 자연스럽게 체득된 습관이라고 보시면 됩니다. 그리고 말씀해주신 부분은 gab1004님이 생각하신 것이 맞아요! 제가 조금 더 정리해서 말씀드릴게요지금 코드가 각 diff_week마다 남은 유저들을 전체 유저로 나눠서 아 몇주차쯤 되면 얼마나 남아있는지를 계산한 거 같은데 생각해보니까 예를들어 지금 기간이 11월 3일까진데 한 10월 중순에 들어온 유저 같은 경우엔 diff_week가 한 3 이상인 부분부턴 아예 데이터가 없는거 아닌가요? 데이터가 11월 3일까지 밖에 없으니까요분모로 사용하는 diff_week=0인 지점에서의 값은 그런 경우들까지 전부 포함된거고 그걸 그대로 모든 retention week마다 분모로 사용하면 위 예시 같은 경우 10월 중순 user들은 한 3주차쯤엔 전부 이탈하는 것 처럼 집계되는거 아닌가요? 그 경우 diff_week가 커질수록 실제 리텐션 보다 과소평가 되는게 아닌가 하는 의문점이 들어 문의 남깁니다 라고 해주셨는데, 코호트 리텐션 그래프가 삼각형으로 나오는 이유가 이런 상황 때문에 발생합니다. 그래서 어제 말씀드린 것처럼 데이터의 기간이 중요하고, 실제로 뽑을 때는 더 넓은 범위로 뽑습니다.해당 쿼리는 비용을 줄이고 로직을 확인하는 과정에 있어서 기간을 줄인거라고 생각하시면 됩니다. 그리고 " 위 예시 같은 경우 10월 중순 user들은 한 3주차쯤엔 전부 이탈하는 것 처럼 집계되는거 아닌가요? "라고 해주셨는데, 우리가 집계로 구하는 것은 이탈이 아니라 "잔존"입니다. 이탈은 명시적인 이벤트가 없어서 이탈 수를 COUNT하는 것이 아니라 잔존을 COUNT하고 잔존이 아니면 이탈했다라고 가정한 것입니다. 그래서 과소평가가 되는 것이 아니라 데이터가 없어서 아예 계산이 되지 않습니다. 값이 없어요. (사진)위 그래프에서 37일차가 지금 없지요?이럴 때 이탈했다라고 생각하는 것이 아니라, "아직 그 기간이 도래하지 않아서 데이터가 없구나", "또는 데이터 기간을 WHERE 조건에 설정해서 없나?" 라고 생각합니다. 데이터가 없는 것이지 이탈이라고 볼 수는 없습니다(잔존이 있어야 이탈을 산출할 수 있겠지요)즉, 데이터가 없다 = 이탈했다는 아닙니다. 데이터가 없으니 확인을 해보면 됩니다(기간이 도래하지 않았거나 WHERE 조건의 이슈가 있는지 확인하기) 이해 안되시거나 또 궁금하면 언제든 남겨주셔요!! 감사합니다!

안녕하세요 강사님 코호트 쿼리 공부하다가 의문점이 생겨서 문의드립니다

gab1004 님 안녕하세요!오 네 맞습니다. 말씀하신 것처럼 데이터 기간이 중요합니다.그래서 지금 같은 형태의 데이터에선 전체 데이터를 스캔해서 봐야 합니다. 데이터의 시작일 이후부터 다 봐야 정확한 데이터가 나오고, 그러지 않으면 말씀하신 것처럼 이슈가 생깁니다. 이런 문제를 해결하기 위해 현업에서는 여러 방법을 활용해요. 대표적인 세가지는 다음과 같아요.유저의 가입일 데이터를 DB에 넣고, 그 DB 데이터를 JOIN해서 가입일로 설정유저 로그 데이터에서 first_date를 확인해서 별도의 테이블에 저장(1번과 동일한데, 1번에서 가입일자랑 사용자가 첫 로그를 발생시킨 일자랑 다를 수도 있어서 이 방법을 쓰기도 합니다. 가입만 하고 추후에 쓰는 경우도 있어요)모든 데이터를 활용해서 리텐션을 계산함 : 강의에서 진행한 방법이라고 보시면 됩니다. 저희 데이터는 8월 1일부터 있어요. 8월 1일 이후라고 걸어주면 됩니다. 강의에서는 일부만 보여드린 것이라고 생각해주시면 되어요 강의에서 일정 부분만 잡아서 보여드린 것은 계산하는 과정을 보여드릴 때 모든 데이터를 쓰지 않아도 괜찮아서 쿼리 탐색 비용을 줄이려고 기간을 설정했다고 생각해주세요! 디테일하게 잘 생각해주셨네요 👍👍 그런 생각하는 과정이 데이터를 이렇게 보는게 맞나? 고민하게 되고 더 일을 잘하게 되더라구요. 계속 그런 생각을 해보셔요.

이미 배포가 확정된 기능에 대한 ABT 진행에 대한 문의

안녕하세요.배포가 확정된 것이라고 해도 얼만큼의 차이가 있는지 파악해야 합니다. 만약 비슷한 종류의 실험을 해야하는 상황이 또 온다면, 과거의 경험이 있어야(AB가 어떤 차이가 있었는지) 그 때 판단을 더 잘할 수 있지요.실험을 해서 기존안이 더 좋다고 하면, 그럴 땐 저는 한번에 롤백을 하진 않습니다. 롤백 결정은 무거운 결정입니다. 개발한 동료들의 사기를 꺾는 일이라 한번에 롤백!으로 하진 않아요. 지금 기존안이 더 좋다고 하면 왜 그런 결과가 나왔는가? 사람들의 반응이 어떠한가?에 대해서 알아야 합니다. 이런 경험이 있어야 그 이후에 더 좋은 제품을 고민할 수 있는 계기가 됩니다. 읽다보니 배포가 확정되었다는 것은 어차피 100%로 배포할 것인데 뭐하러 실험을 해야 하냐?라는 관점일까요? 실험을 통해서 불확실성을 줄이기 위함이고, 100%로 배포하는게 위기인 경우도 있을 거예요(카카오톡 변화를 생각해보시면 됩니다) 어차피 100%로 배포할 것이다라는 관점을 계속 가지고 있으면 어차피 데이터 분석해서 뭐해~라는 입장으로 될 수 있어서, 실험에 집중을 해보시면 어떨까 싶어요. 그리고 어떤 세그먼트에서 더 많이 반응을 했는지도 살펴보는 것도 필요하겠지요. 기존안이 더 좋을 때, 세그먼트 별 지표를 보거나 자세한 분석을 통해 왜 사람들이 반응을 안했는지 질문을 던지고, 이걸 해결하기 위해 추가 기능을 더 만들어서 지표를 올려보자!라는 생각을 하는 사람이 조직에서 바라는 데이터 분석가의 역할이 아닐까 싶어요(물론 회사마다 다를 수 있고, 데이터 문화가 형성되지 않았다면 이런 기대를 하진 않을 것 같긴 해요) 실험을 단순히 배포를 하기 위한 수단으로 생각하는 것이 아니라, 제품과 사용자에 대한 이해를 깊게 하는 과정으로 바라보시면 좋겠습니다. 실험 결과 자체가 좋든 나쁘든, 그 과정에서 '우리 사용자는 이런 변화에 이렇게 반응하는구나'라는 학습이 남게 되고, 그게 쌓이면 다음 기능을 기획할 때 훨씬 더 좋은 판단을 내릴 수 있는 기반이 됩니다.

4-8 지표 정의 풀이 피드백 부탁드립니다🙇‍♂

안녕하세요! 문제 푸느라 고생하셨습니다! #1. 기능이 잘 동작하고 있는지 확인하려면?배달 서비스를 담당하는 PM입니다. 배너 영역, 메뉴 카테고리, 이런 음식 어때요, 동네 맛집 기능이 잘 동작하고 있는지 확인하려면 어떤 지표를 확인해야 할까요? 지표를 정의하고, 지표가 어떤식으로 움직이면 잘 동작한다고 볼 수 있을까요?각 기능의 목적을 생각한 뒤, 목적을 달성하고 있는지를 파악할 수 있는 지표로 설정했습니다.목적배너: 이벤트 등 홍보하기 위한 기능메뉴 카테고리: 사용자가 어떤 음식을 먹을 지는 정해진 상황. 어떤 가게에서 먹을지를 도와주는 기능이런 음식 어때요 & 동네 맛집 기능: 어떤 음식을 먹을지 고민하는 상황에서 추천해주는 기능지표 - 배너메인 지표: CTR(배너 카테고리 클릭/home UV) 사람들이 관심을 많이 가지는지를 파악하기 위해 CTR을 설정하겠습니다.지표 - 메뉴 카테고리메인 지표: CTR(메뉴 카테고리 클릭/home UV),CVR(food_detaul 카트 담기 버튼 클릭 수/메뉴 카테고리 클릭 수)사람들이 메뉴 카테고리를 많이 사용하는지 파악하기 위해 CTR을, 실제로 가게를 선택해 주문까지 이어지는지 보기 위해 주문 담기 버튼 클릭 CVR을 설정했습니다. 메뉴 카테고리의 목적이 음식은 정해졌지만 어떤 가게에서 먹을지 고민인 사람을 도와준다고 생각했기에 실제 가게를 선택해 주문이 발생하는지 파악해야 된다고 생각했기 때문입니다.지표- 이런 음식 어때요 & 동네 맛집 기능메인 지표: CTR(각 기능 클릭/home UV), CVR(food_detaul 카트 담기 버튼 클릭 수/각 기능 클릭 수)유저가 해당 기능에 관심을 가지는지를 파악하기 위해 CTR을, 추천이 주문으로 이어지는지 파악하기 위해 CVR을 설정했습니다. 피드백 : 목적 고민하신 부분 잘하셨습니다! 목적을 작성하고 고민하면 더 좋은 지표를 선택할 수 있어요.지금 1번 문제에서는 같은 지표인데 분자에 다른 것이 들어간다고 보시면 될 것 같아요. 그래서 같은 지표로 볼 수 있고, 같은 지표여야 비교가 가능합니다. 예를 들어 배너와 메뉴카테고리 중 어떤 것이 더 많은 사람들이 반응하냐? 라는 질문이 온다면 같은 지표를 사용해야 가능하지요.배너에서든 배너의 특징에 따라 CVR이 어려울 수 있어서 지금 하신대로 해도 괜찮고, 배너의 타입별로 CVR이 나올 수 있는 것과 아닌 것을 구분해서 생각해보셔도 좋을 것 같아요. CTR, CVR 중에 메인 지표를 무엇으로 할지 고민하는 것도 필요합니다. 두 지표 중 어떤 것을 제일 중요한 지표로 보시겠어요? #2. 검색 만족도 지표배달 서비스를 담당하는 PM입니다. 고객이 검색 기능에 만족했는지 확인하려면 어떤 지표를 봐야 할까요? 검색하는 흐름을 떠올려보면서 그 안에 있는 이벤트를 조합해보세요.목적사용자가 원하던 메뉴, 매장을 정확하게 찾아주거나 제안하는 것이 기능의 목적이라고 생각했습니다.지표메인 지표: search_result 페이지 -> restaurant CTR(restaurant 1번 이상 클릭수/search_result UV)보조 지표: search → cart CVR, search_result 상위 10개 restaurant CTRsearch_result 페이지에서 실제 가게를 구체적으로 보는 것을 목적 달성으로 봤습니다. 추가로 검색한 결과가 주문으로 이어저야 된다고 생각해 cart로의 CVR을, 검색이 정확하면 검색 결과 상위 10개 내에서 클릭되었을 것이라 생각해 보조 지표를 설정했습니다.문제를 풀면서 검색 기능에서 cart로의 CVR을 같이 봐야 할 지가 고민이었습니다. 전 검색이 주문에 도움이 되어야 제대로 작동한다고 생각해서 포함시켰는데, 카일님의 의견을 여쭙고 싶습니다! 피드백 : 잘 작성해주셨어요. 다만 보조 지표에 search_result 상위 10개 restaurant CTR이 애매합니다. 이 지표는 메인 지표와 비례할 것 같아요. 굳이 필요하지 않을 것 같아요.이 지표를 생각한 이유가 추천 알고리즘의 성능 지표 관점으로 생각하셔서 그런 것 같은데, 이런 상황엔 제품의 지표와 모델의 지표를 나누면 됩니다. 제품의 지표는 정의하신대로 쓰고, 모델의 성능 지표는 이미 정의가 되어있는 경우가 많습니다https://techblog.musinsa.com/map-416b5f143943이런 글을 보면 지금 궁금해하셨던 내용에 대한 지표를 볼 수 있을 거예요. 밑에 질문주신 내용은 검색 기능이 검색을 잘 작동하는 것을 기대하면서도 매출 견인에 도움이 되면 좋기 때문에 저도 CVR을 추가할 것 같아요. 다만 검색 퍼널 관점에서 CVR의 지표 상승/하락의 변동이 크지 않을 수 있음을 인지해야 합니다.#3. 검색 필터 기능의 활성화 지표배달 서비스를 담당하는 PM입니다. 검색 필터 기능은 잘 사용되고 있을까요? 필터 기능의 활성화 지표를 정의하면 어떻게 할 수 있을까요? 검색 필터를 사용하는 흐름을 떠올려보면서 그 안에 있는 이벤트를 조합해보세요목적필터 기능의 목적을 잘 달성하고 있는지search_result 화면에서 사용자가 얼마나 쓰는지지표메인 지표: 필터 사용 안한 경우의 restaurant CTR 피드백 : 여기선 메인 지표가 무엇인지 헷갈리네요. 예)메인 지표- 1) 필터 클릭 CTR = (분자)/(분모) 보조 지표- 1) - 2)이런 식으로 정리하면 더 좋을 것 같아요. 지금은 헷갈리네요. 그리고 각 지표를 선택한 이유도 같이 넣어주시면 좋습니다.지표를 CTR/CVR로 많이 생각하시는 것 같은데(실제로 많이 쓰이는 것은 맞아요) 필터 기능의 목적은 필터링이 잘 되었는가?라서 필터 사용률을 보면 됩니다. 필터의 각 버튼이 얼마나 클릭되고 있는지, 그 비율은 얼마나 되는지를 확인하는 것이 좋습니다. 검색 필터의 기능 자체는 해당 기능을 얼마냐 쓰는가?로 확인할 수 있다고 생각해주시면 됩니다. #4. 배달 서비스에서 가장 중요한 지표는?배달 서비스를 담당하는 PM입니다. 배달 서비스에서 가장 중요한 지표는 무엇일까요? 왜 그 지표가 중요할까요? 그것을 어떻게 늘릴 수(줄일 수) 있을까요?목적고객이 배달 주문을 하는 것.지표메인 지표: 주간 주문수보조 지표: WAU, 주문 CVR(order_success UV/home UV), 주간 재주문율결국 고객이 배달을 시켰을 때 플랫폼의 목적이 달성된다고 생각해 메인 지표를 주문수로 설정했고, 배달 특성상 매일 사용하는 것보다는 주별로 사용한다고 생각해서 기간을 7일로 설정했습니다.주간 주문수 = WAU * 주문 전환율이라고 생각해서 보조 지표를 설정했고, 유저 경험이 만족스러웠는지를 파악하기 위해 재주문율을 추가로 설정했습니다. 피드백 : 주간 주문수를 더 자세히 생각해보면, 주문 요청 이벤트가 있고 실제로 배달을 받은 이벤트가 있습니다. 단순히 주간 주문수라고 할 수도 있지만, 회사의 DB상에는 주문 요청하고 주문 상태 status가 "배달 완료"인 것만 봐서 지표를 구할 거예요. 이 주문수라는 것도 구체적으로 정의하는 것이 필요합니다(만약 배달 기사님이 없으면 주문이 실패하는 것이니!)WAU나 주문 CVR은 왜 추가를 했는지도 써보시면 좋을 것 같아요! 물론 이 지표들은 이해가 됩니다. 다만 주간 재주문율이라는 것은 정의를 구체적으로 해보는 것이 좋을 것 같아요.26년 1주차에 쓴 사람이 2주차에 또 쓴 경우 재주문에 포함되나요? 혹은 전주엔 주문을 안하고 1달 전에 주문한 사람은 재주문율에 포함되나요? 재주문, 리텐션 같은 지표가 정의하기에 따라 다양하게 해석이 되기 때문에 정의까지 작성해주셔야 좋아요.#5. 추천 알고리즘의 성능 지표여러분은 이커머스 서비스에서 추천 알고리즘을 만드는 조직의 PO입니다. 추천 알고리즘은 유저의 정보와 유저 로그를 토대로 구매할 것 같은 제품을 보여줍니다. 추천 알고리즘의 성능을 확인하기 위해 어떤 지표를 파악해야 할까요? 왜 해당 지표일까요?목적추천 알고리즘으로 구매 허들을 낮춘다.지표핵심 지표: 일반 상품 구매 전환율 보조 지표: 일반 상품 리뷰 평점 추천 상품이 매력적이었는지를 판단하기 위해 알고리즘 추천 상품이 일반 상품보다 구매 전환율이 높은지 파악하려고 합니다. 또한 추천 상품이 실제로 만족스러웠는지 파악하기 위해 리뷰 평점도 같이 확인하겠습니다. 피드백 : 여기서도 위에 검색과 유사하게 추천 시스템도 알고리즘 관점의 지표가 있습니다. 이건 검색을 한번 해보면 좋겠다는 바람에 넣은 문제에요.https://sungkee-book.tistory.com/11#6. 여러분들이 자주 사용하는 서비스의 지표여러분들이 자주 사용하는 서비스에서 제일 중요한 지표는 무엇일까요? 왜 해당 지표가 제일 중요할까요? 그 외에 확인해야 하는 지표를 2개 더 뽑는다면 무엇이 있을까요?지표 - 당근핵심 지표: DAU(활성화 기준: 앱 접속)보조 지표: 평균 체류 시간, 월 평균 거래액플랫폼이고, 메인 BM이 광고인 점을 고려해 얼마나 많은 사람들이 앱에서 활동하는지가 가장 중요하다고 생각했습니다. 또한 당근페이로 추가 수익을 창출한다는 점과 앱 내에서 거래가 중고 거래, 로컬 비즈니스 등의 기능의 활동을 파악할 수 있어서 월 평균 거래액을 설정했습니다.핵심 지표는 해당 서비스를 왜 사용하는가?에 대해서 이야기를 할 수 있어야 하는데, DAU는 후행 지표입니다. 그래서 저라면 핵심 지표로 DAU를 선택하진 않을 것 같아요. 물론 DAU를 쓸 수는 있는데, 더 쪼개서 중고거래를 신청한 수 또는 중고거래 페이지에서 어떤 이벤트를 한 수 같이 특정 카테고리의 지표까지 같이 볼 것 같아요. 중고거래의 User 수, 동네생활의 User 수 이런 지표들을 토대로 당근 전체의 DAU가 나오게 되겠지요. 핵심 지표는 Input 지표로 삼는 것을 추천해요.월 평균 거래액이라고 한 것도 어떤 의미인지 중요한데, 당근페이로 거래한 것을 의미할까요? 당근에서 만원에 올린거 네고해서 8천원으로 바뀌면 그건 거래액을 8천원으로 해야 할까요? 일반적으로 DB에 Transaction이 일어나야 거래액으로 포함하는데 당근은 플랫폼 역할을 해서 거래를 직접 DB에 넣진 않아요. 이 부분도 고민해보시면 좋을 것 같아요.#7. 퍼널 개선 프로젝트여러분들은 가입 퍼널을 개선하라는 미션을 받았습니다. 현재 가입 퍼널 프로세스의 전환율은 약 20%며 가입 퍼널에서 온보딩을 더 진행하는 기능을 만들었습니다. 온보딩의 효과를 파악하려면 어떤 지표를 봐야할까요? 상상이 어렵다면 여러분들이 자주 사용하는 서비스를 가정하고 말씀하셔도 좋습니다 일반적인 커머스를 가정하고 생각해봤습니다.목적회원가입을 유도한다.서비스에 대한 기대를 만든다.서비스의 핵심 기능을 경험한다.지표회원가입 전환율첫 주문 전환율(회원가입 후 2주 이내 첫 구매자 수/회원가입 수)피드백 : 지표는 잘 정의해주셨고, 이 문제는 실험에 대한 감을 기르기 위해 낸 문제입니다. 실험 파트를 보신 후 다시 이 문제를 보시면 이해가 가실 거예요!! 문제 푸느라 고생하셨습니다!

이미 배포가 확정된 기능에 대한 ABT 진행에 대한 문의

안녕하세요. 제가 답변이 늦어지고 있어서 미리 답변을 달아요. 내일까지 답변드릴게요!!