[Yammer 분석 프로젝트]
1. WAU(Weekly Active Users) 하락 원인 분석
2. 검색 기능(Search Functionality) 분석
3. A/B Test 유의성 검정
- Yammer 검색 기능
상단에 검색창이 있고, 어떤 검색어를 검색했을 때 카테고리별로 검색어에 대한 결과를 확인할 수 있다.
또한 하단의 'See All Search Results'를 누르면 모든 결과를 확인 가능한 'Search Results' 페이지로 넘어간다.
그리고 기존의 검색어에 추가적으로 추가검색어, 특정 그룹, 날짜 설정이 가능하다.
- 검색 기능 분석을 하기 전에 생각해 볼 점
검색 기능이 분석할 만한 가치가 있는 기능인가? 애초에 많이 사용되지 않은 기능이라면? (가치비용 효율성의 측면)
만약에 가치가 있다면, 우리는 어떻게 검색 기능을 개선할 것인지?
1. 검색 기능의 목적
2. 그 목적을 달성하고 있는지 측정할 수 있는 방법
3. 검색 기능의 만족도를 어떻게 정량적으로 수치화 할 것인가 ★ (데이터 분석가로서 가장 중요하게 생각할 부분)
- 데이터셋 파악
검색기능과 관련된 event_name 값
search_autocomplete: 사용자가 자동 완성에서 검색 옵션을 클릭할 때
search_run: 사용자가 검색을 실행하고 'Search Results'페이지로 넘어갔을 때
search_click_X: 'Search Results'페이지에서 몇번째 결과를 클릭했는지 기록
- 가설 설정과 함께 같이 고려해보아야 할 것들
1. 현재 검색기능에 대한 사용자 경험 만족도 (혹시 만족도가 이미 충분히 높지는 않은지?)
2. 기능 개선을 위해 분석한 기능이 실제로 얼만큼 사용자 이용/만족에 향상을 시켰는지 측정할 수 있는 지표 설정
- 가설 설정
검색 기능 : 사용자들이 찾는 것을 보다 쉽고 빠르게 찾게 해주는 기능
[Yammer에서의 검색 기능의 중요도와 사용자들의 만족도를 측정해볼 수 있는 지표/가설 세우기]
1. 사용인원 : 전체 Yammer 사용자 중 얼만큼이 검색 기능을 사용하는지
검색기능을 사용하는 유저가 많을수록 검색기능은 Yammer에 꼭 필요한 핵심 기능이라고 볼 수 있다.
2. 사용빈도 : 얼만큼 자주 검색 기능을 사용하는지
마찬가지로, 사용빈도가 높을 수록 검색 기능의 중요도가 높음을 알 수 있다.
(단, 짧은 기간동안 검색을 여러번을 한다면 한번에 원하는 검색 결과를 얻지 못했을 가능성이 크므로 좋은 지표는 아님.)
3. 반복되는 검색어 횟수 : 유사한 또는 같은 검색어가 여러번 검색되는 경우가 있는지
이 가설은 텍스트 분석 필요. 시간이 오래 걸릴 수 있으므로 짧은 기간 동안 여러번 검색하는 것으로 먼저 분석을 진행하고 유의미한 결과가 나왔을 때 다음 단계로 진행해보는 것이 더 좋을 것으로 생각됨
4. 클릭률 : 검색어에 대한 결과를 클릭해보는 횟수가 얼만큼 되는지
검색어 결과 여러개를 클릭해본다면 원하는 결과가 없어서일 수 있음. 그러나 한번만 클릭한다고 해서 원하는 결과를 얻어냈다고 보기도 어려움(한 번만 클릭하고 바로 다른 검색어를 검색하는 등의 경우 존재) 따라서 클릭률로 사용자의 만족도를 알아보기에는 조금 어려움이 있다.
단, 몇번째 결과를 클릭했는지(event_name이 ' search_click_X ')에 따라 검색결과 순위에 대한 정확성을 검증해볼 수 있는 좋은 지표일 수 있다.
- 지표/가설 검증
Yammer의 세션 정의 : 10분
* 세션 시간은 서비스 제품에 따라 사용자들의 평균 이용시간을 고려해서 내부적으로 정하면 되는 부분이기 때문에 대중이 없다.
1. 검색기능 사용인원
SELECT DATE_TRUNC('week',z.session_start) AS week,
COUNT(*) AS sessions,
COUNT(CASE WHEN z.autocompletes > 0 THEN z.session ELSE NULL END) AS with_autocompletes,
COUNT(CASE WHEN z.runs > 0 THEN z.session ELSE NULL END) AS with_runs
FROM (
SELECT x.session_start,
x.session,
x.user_id,
COUNT(CASE WHEN x.event_name = 'search_autocomplete' THEN x.user_id ELSE NULL END) AS autocompletes,
COUNT(CASE WHEN x.event_name = 'search_run' THEN x.user_id ELSE NULL END) AS runs,
COUNT(CASE WHEN x.event_name LIKE 'search_click_%' THEN x.user_id ELSE NULL END) AS clicks
FROM (
SELECT e.*,
session.session,
session.session_start
FROM tutorial.yammer_events e
LEFT JOIN (
SELECT user_id,
session,
MIN(occurred_at) AS session_start,
MAX(occurred_at) AS session_end
FROM (
SELECT bounds.*,
CASE WHEN last_event >= INTERVAL '10 MINUTE' THEN id -- 세션 기준 10분
WHEN last_event IS NULL THEN id
ELSE LAG(id,1) OVER (PARTITION BY user_id ORDER BY occurred_at) END AS session
FROM (
SELECT user_id,
event_type,
event_name,
occurred_at,
occurred_at - LAG(occurred_at,1) OVER (PARTITION BY user_id ORDER BY occurred_at) AS last_event,
LEAD(occurred_at,1) OVER (PARTITION BY user_id ORDER BY occurred_at) - occurred_at AS next_event,
ROW_NUMBER() OVER () AS id
FROM tutorial.yammer_events e
WHERE e.event_type = 'engagement'
ORDER BY user_id,occurred_at
) bounds
WHERE last_event >= INTERVAL '10 MINUTE'
OR next_event >= INTERVAL '10 MINUTE'
OR last_event IS NULL
OR next_event IS NULL
) final
GROUP BY 1,2
) session
ON e.user_id = session.user_id
AND e.occurred_at >= session.session_start
AND e.occurred_at <= session.session_end
WHERE e.event_type = 'engagement'
) x
GROUP BY 1,2,3
) z
GROUP BY 1
자동완성기능은 전체 사용자의 25~26%, 전체 검색은 약 7~8%가 사용하는 것을 확인.
전체 사용자 중 약 33%가 검색 기능을 사용하는 것으로 보아 검색기능이 핵심 기능 중 하나라고 볼 수 있다.
2. 한 세션당 검색 횟수: 자동완성 기능 vs 전체 검색
검색어 자동완성과 직접 검색어 전체를 입력하여 검색한 두 요인을 더 뜯어보았다.
자동완성 기능은 77%가 한 세션당 1~2번을 사용한 반면, 전체 검색은 한 세션당 2번 이상 사용한 비율이 88.6%로 훨씬 높았다.
MODE 보고서는 이런 결과를 고려했을 때 검색 결과가 그다지 좋지 않거나 검색을 좋아하고 항상 사용하는 사용자 그룹이 매우 적다는 것을 의미한다는 결론을 내렸다.
그러나 아래와 같은 의구심이 들었다.
정말로 검색 결과가 안 좋다고 말할 수 있을까?
보통 사람들은 자동완성에서 원하는 검색어를 발견했을 때 클릭
→ 그러나 자동완성에서 원하는 검색어를 찾지 못했다면?
→ 검색어 전체를 직접 입력한다.
다시 말해 자동완성 기능을 먼저 접하게 되고, 검색어가 복잡하거나 보편적이지 않을 때 다음 step으로 검색어 전체 입력을 진행할 것이므로 전체 검색이 더 적게 사용되고, 한 세션당 검색횟수가 많은 것이 오히려 자연스러운 결과일 수 있다.
3. 전체 검색 결과 클릭률
앞서 전체 검색의 경우 한 세션에 2번 이상 검색이 이루어 지는 비율이 압도적으로 높았다. 그에 반해 클릭률은 전체 검색 시 어떤 검색 결과도 클릭하지 않은 세션이 1,684건(54.3%)으로 낮은 편이었다.
세션의 절반 이상이 결과를 클릭하지 않은 것이 현재 안좋은 상황이라고 말할 수 있을까?
검색엔진을 가지고 있는 구글, 네이버 등 사이트를 생각해봤을 때 검색을 하고 클릭을 하는 정도가 얼마나 될까를 함께 생각해보면 생각보다 결과 미리보기 정도로 원하는 정보를 충분히 얻을 수 있어 종종 결과를 한개도 클릭하지
않기도 한다.
따라서 54.3%라는 수치가 개선이 필요한 수치인지, 이미 충분히 잘 나오고 있는 수치인지 정확히 확인해보고자 한다면 비슷한 도메인/플랫폼과의 비교를 통해 적정여부를 판단할 필요가 있다.
3-1. '전체 검색'과 평균 클릭 수의 관계
SELECT runs,
AVG(clicks)::FLOAT AS average_clicks -- float 형식으로 지정
FROM (
SELECT x.session_start,
x.session,
x.user_id,
COUNT(CASE WHEN x.event_name = 'search_autocomplete' THEN x.user_id ELSE NULL END) AS autocompletes,-- 피봇팅
COUNT(CASE WHEN x.event_name = 'search_run' THEN x.user_id ELSE NULL END) AS runs,
COUNT(CASE WHEN x.event_name LIKE 'search_click_%' THEN x.user_id ELSE NULL END) AS clicks
FROM (
SELECT e.*,
session.session,
session.session_start
FROM tutorial.yammer_events e
LEFT JOIN (
SELECT user_id,
session,
MIN(occurred_at) AS session_start,
MAX(occurred_at) AS session_end
FROM (
SELECT bounds.*,
CASE WHEN last_event >= INTERVAL '10 MINUTE' THEN id
WHEN last_event IS NULL THEN id
ELSE LAG(id,1) OVER (PARTITION BY user_id ORDER BY occurred_at) END AS session
FROM (
SELECT user_id,
event_type,
event_name,
occurred_at,
occurred_at - LAG(occurred_at,1) OVER (PARTITION BY user_id ORDER BY occurred_at) AS last_event,
LEAD(occurred_at,1) OVER (PARTITION BY user_id ORDER BY occurred_at) - occurred_at AS next_event,
ROW_NUMBER() OVER () AS id
FROM tutorial.yammer_events e
WHERE e.event_type = 'engagement'
ORDER BY user_id,occurred_at
) bounds
WHERE last_event >= INTERVAL '10 MINUTE'
OR next_event >= INTERVAL '10 MINUTE'
OR last_event IS NULL
OR next_event IS NULL
) final
GROUP BY 1,2
) session
ON e.user_id = session.user_id
AND e.occurred_at >= session.session_start
AND e.occurred_at <= session.session_end
WHERE e.event_type = 'engagement'
) x
GROUP BY 1,2,3
) z
WHERE runs > 0
GROUP BY 1
다만, 전체 검색을 여러번 할수록 평균 클릭률이 상승하는 것을 확인할 수 있었다. (12회까지)
(13회 이상 부터는 모수가 적기 때문에 avg가 유의미한 수치라고 보기 어렵다고 판단)
3-2. 검색결과 배치에 따른 클릭 수
결과 : 상위 결과와 하위 결과의 클릭 수 차이가 크지 않다.
가능성1. 상단에 위치한 검색 결과가 사용자가 찾던 결과가 아닌 경우가 많아 하단에 위치한 검색 결과 클릭이 많이 일어난다.
가능성2. 상단에 위치한 검색 결과가 사용자가 찾던 결과가 아닌 경우가 많아 상/하단에 관계없이 여러개의 결과를 모두 클릭한다.
→ 결과 순서가 적절하지 않거나 적절한 결과가 조회되지 않는 등 검색 결과 성능이 그렇게 좋지는 않다는 것을 생각해볼 수 있다.
4. Feature Retention (검색기능 재사용) 확인
검색기능 첫 사용 후 한달 후 재이용한 사용자 수를 본 자료인데, 비율(%)이 아니라 건수라서 전체 검색 사용자와 자동 검색 사용자의 모수가 다르기 때문에 해당 자료로는 비교가 어렵다는 생각이 들었다.
- 결론
1. 자동완성 기능은 효율적으로 잘 운용되는 편이다.
2. 자동 완성이 원하는 내용을 제공하지 않을 때, 사용자는 전체 검색을 실행할 가능성이 높다.
3. 따라서 전체 검색 시 자동완성 때와 다른 검색결과(search results)를 확인할 수 있도록 순서 알고리즘을 개선할 필요가 있다.
'분석 프로젝트' 카테고리의 다른 글
| [E-commerce] kaggle Olist 분석 | 팀 프로젝트 후기 (0) | 2024.06.03 |
|---|---|
| [Yammer] A/B Test 유의성 검정 (0) | 2024.05.30 |
| [Yammer] WAU(Weekly Active Users) 하락 원인 분석 | 신규유저, 기존유저 Cohort WAU, Device별 WAU (0) | 2024.05.27 |