해결된 질문
작성
·
86
·
수정됨
0
안녕하십니까.
4-8 지표 정의 연습 문제에서 피드백받은 부분을 더하여 데이터 로그 설계를 하였습니다. 문제점이 있으면 지적해주시면 감사하겠습니다.
지표) CTR(기능 클릭 수 / 메인 페이지 호출 수)
보조 지표) CVR(기능 클릭을 통해 구매한 수 / 기능 클릭 수), 기능 클릭 비율(각 기능 클릭 수 / 전체 기능 클릭 수)
메인 지표: CTR은 기업이 설정한 사용자 행동 패턴을 원할하게 이행을 하고 있는지 파악할 수 있는 지표입니다. 즉, 사용자가 해당 기능에 흥미를 가지고 클릭을 하고 사용을 하는지를 확인할 수 있습니다.
보조 지표: CVR은 해당 기능을 통해 최종적으로 매출을 발생하는지를 확인할 수 있습니다. 또한, 기능 클릭 비율을 통해 사용자가 주로 사용하는 기능이 무엇인지 파악할 수 있습니다.
case1) CTR은 높으나 CVR은 낮은 경우 -> 구매까지의 프로세스 탐색(구매 프로세스 피로도 개선)
case2) CTR은 낮으나 CVR은 높은 경우 -> 기능 개선 방안 탐색(ex. 위치 조정, 메시지 문구 개선 등)
case3) 특정 기능 클릭 비율이 낮은 경우 -> 해당 기능 클릭을 높이는 방안 탐색
CTR
분자)
click_home_function
event_parameter
session_id
user_id
timestamp
home_function_id
home_function_type
분모)
view_home
event_parameter
session_id
user_id
timestamp
CVR
분자)
view_restaurant
event_parameter
session_id
user_id
timestamp
restaurant_id
restaurant_name
restaurant_category
use_home_function
use_home_function_type
분모)
click_payment
event_paramter
session_id
user_id
timestamp
payment_id
payment_amount
payment_type
use_home_function
use_home_function_type
지표) mAP(mean Average Precision)
보조 지표) CTR(검색 결과 클릭 수 / 검색 결과 페이지 호출 수)
메인 지표: mAP는 상위로 노출되는 순으로 가중치를 두어 사용자가 클릭을 한 위치를 점수화하여 평균을 낸 방법입니다. 즉, 클릭을 한 상품의 순서를 고려할 수 있습니다.
보조 지표: 사용자가 검색을 하고 원하는 검색 결과가 나왔다면 클릭을 할 것입니다. 즉, CTR을 통해 사용자가 얼마나 결과를 만족하고 클릭을 하였는지 비율을 확인할 수 있습니다.
case1) mAP가 낮은 경우 -> AP가 낮은 사용자를 분리하여 사용자 행동 탐색(사용자 특성 분석)
case2) AP가 모두 낮은 경우 -> 검색 알고리즘 개선 방안 탐색(ex. 배달료 가중치 조정, 사용자 선호 카테고리 조정 등)
case3) CTR이 낮은 경우 -> 검색 결과와 유사한 음식 추천 유도 기능 설계, UI 개선
mAP
with base as (
select
search_session_id,
search_list_rank,
case
when restaurant_id is not null then 1 else 0
end as is_relevant
from click_search_list
),
search_rank as (
select
search_session_id,
search_list_rank,
sum(is_relevant) over (
partition by search_session_id order by rank
) as rel_k
from base
where is_relevant = 1
),
search_table as (
select
search_session_id,
rel_k/rank as precision_k
from search_rank
),
precision_table as (
select
search_session_id,
round(avg(precision_k), 4) as average_precision
from search_table
group by search_session_id
)
select
round(avg(average_precision),4)
from precision_table;
CTR
분자)
click_search_list
event_parameter
session_id
search_session_id
user_id
timestamp
search_word
search_list_rank
restaurant_id
restaurnat_name
restaurnat_category
분모)
view_search
event_parameter
session_id
user_id
timestamp
search_word
지표) CTR(필터 기능 클릭 수 / 검색 결과 페이지 호출 수)
보조 지표) 필터 기능 비율(각 필터 기능 클릭 수 / 전체 필터 클릭 수)
메인 지표: CTR은 통해 사용자가 검색 결과 페이지에서 필터기능을 인지하고 사용하는지를 비율을 통해 확인할 수 있습니다.
보조 지표: 필터 기능 비율을 통해 사용자가 어떤 필터 기능을 많이 사용하는지를 확인할 수 있습니다. 이를 통해 사용자가 어떤 기능을 선호하는 지 알 수 있습니다.
case1) CTR이 낮은 경우 -> 필터기능을 모를 것으로 예상, 튜토리얼 기능을 넣어 필터기능을 인지 시키기
case2) 특정 필터 기능 비율이 낮은 경우 -> 특정 필터의 필요성 점검
CTR
분자)
click_filter
event_parameter
session_id
user_id
timestamp
filter_type
filter_values
분모)
view_search
event_parameter
session_id
user_id
timestamp
search_word
필터 기능 비율
with table as (
select
filter_type,
filter_values,
sum(filter_values) as score
from click_filter
group by filter_type,
filter_values
)
select
filter_type,
filter_values,
round(percent_rank() over (order by score desc) * 100, 2) as percentile
from table
order by percentile desc;
답변 2
0
병현님 안녕하세요. 로그 설계까지 하느라 고생하셨습니다!
지표 정의를 해주실 때, 분자와 분모도 같이 명시해주시면 더욱 좋습니다. CTR이나 CVR이 자주 사용되는 지표인데, 이런 지표를 여러 곳에서 활용할 때 어떤 관점의 CTR인지가 헷갈릴 수 있거든요. 저는 XXX CTR 이라고 쓰고, 분자와 분모 정의도 같이 하곤 합니다.
1번.
1번에서 case에 CTR이 낮고, CVR은 낮은 경우와 CTR은 높고 CVR도 높은 경우도 추가해보면 좋을 것 같네요.
clikc_home_function이란 이름을 보면 function이 무엇인지 궁금하게 되네요. funtion이란 것의 이름을 명시적으로 주시거나, 변수처럼 표시를 하면 좋을 것 같아요. click_home_{function}. 그리고 funtion에 들어갈 수 있는 것을 같이 추가해주면 사람들이 이해하기 더 수월할 것 같네요.
로그 설계할 때 이름에 funtion을 넣으면 파라미터로 funtion_type이나 id를 넣지 않아도 괜찮을 수 있어요. click_home_food_icon이란 이름으로 로깅을 하고, food_category를 추가하면 겹치는 부분이 없을 것 같아요. 로그 설계할 때 function 같은 추상적인 단어보단 조금 더 명시적이로 구체적인 단어를 쓰는 것이 더 이해하기 수월했어요.
그리고 event_timestamp, user_id는 이벤트의 파라미터로 들어가지 않고 모든 데이터(Row)에 적용되는 데이터입니다. 이벤트 파라미터에는 이벤트와 관련된 내용만 들어간다고 생각해주시면 더 좋을 것 같아요.
2번
오 mAP를 쓰셨네요. 2번의 경우 제품 관점의 지표와 알고리즘 관점의 지표로 나누어서 제품 관점의 지표는 CTR/CVR을 사용하고 알고리즘 관점의 지표로 mAP나 다른 지표들을 사용할 것 같아요. 제품이 바뀌지 않고 알고리즘이 바뀌어서 CTR이나 CVR도 바뀔 수 있거든요. 그래서 두개의 지표는 같은 카테고리로 두지 않고 나눠서 데이터를 보곤 합니다.
쿼리 작성해주신 것은 잘 작성하셨네요!
3번
3번도 잘 작성해주셨네요! 저라면 지표) CTR에서 필터 기능 클릭 수라는 명칭보다는 조금 더 구체적으로 쓸 것 같아요. 기능이란 단어가 자주 나오는데 넓은 범위라고 느껴지네요.
이렇게 쿼리 작성하시면서 지표 정의하신 것 넘 멋집니다. 계속 학습해주셔요! 고생하셨습니다
0
안녕하세요, 인프런 AI 인턴입니다.
황병현님께서 작성하신 데이터 로그 설계는 굉장히 잘 구조화되어 있으며, 각 기능별로 필요한 지표 및 문제 해결 방안까지 구체적으로 잘 정리되어 있습니다. 이를 기반으로 더 나은 분석과 운영이 가능합니다. 주요 지표와 보조 지표의 역할을 명확히하셨고, 이를 통해 실질적인 액션 가능한 인사이트를 얻을 수 있을 것으로 보입니다.
기능 동작 확인을 위한 로그 설계:
검색 만족도 지표의 활용:
검색 필터 기능의 활성화 지표:
질문에 대한 피드백은 로그 설계가 실제로 잘 적용되려면 지속적인 모니터링과 분석이 필수적입니다. 수집된 데이터를 기반으로 주기적으로 성과를 평가하고 문제가 있을 경우 신속히 대처하는 것이 중요합니다. 이를 통해 더 나은 사용자 경험을 제공할 수 있습니다.
유사한 사례나 추가적으로 도움이 될 링크는 아래와 같습니다:
📍 Data Logging and Monitoring Best Practices
📍 Understanding Conversion Rates and CTR
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.