SQL/데이터리안 SQL 분석

실전반 4주차 예습

김초송 2022. 10. 20. 16:24

https://mode.com/sql-tutorial/understanding-search-functionality/

 

Understanding Search Functionality | SQL Analytics Training - Mode

In this lesson we'll cover: Before starting, be sure to read the overview to learn a bit about Yammer as a company. The product team is determining priorities for the next development cycle and they are considering improving the site's search functionality

mode.com

Analytics cases : Yammer

Yammer 

- 업무에서 쓰는 SNS 혹은 협업 툴

- 기능 : 문서/업데이트/아이디어 공유

- 개인 무료, 기업 유료 (행정 기능)

- 목표 : 고객들이 야머의 툴을 써서 데이터로 더 효과적이고 나은 비즈니스 의사 결정하게 함

- 조사 이해 : 프로덕트 팀에서 기능을 개선하려고 하면 그것을 바꾸는 게 맞는지, 그렇다면 뭘 바꿔야 하는지 파악

- A/B 테스트 : 타당성 검증


 

https://mode.com/sql-tutorial/understanding-search-functionality/

 

Understanding Search Functionality | SQL Analytics Training - Mode

In this lesson we'll cover: Before starting, be sure to read the overview to learn a bit about Yammer as a company. The product team is determining priorities for the next development cycle and they are considering improving the site's search functionality

mode.com

Understanding Search Functionality

  • 배경 : 프로덕트팀에서 검색 기능 개선을 결정. 

1. 웹사이트 모든 페이지 header에 검색 박스가 있음. person, groupgs, conversations 검색 가능

2. 검색 박스에 입력하면, 가장 관련있는 결과 순으로 드롭다운 리스트. 결과는 카테고리별(people, conversations, files, etc.)로 분류됨. 맨 아래에 모든 검색 결과를 볼 수 있음.

3. 엔터를 치거나 "view all results" 버튼을 누르면, 상단 탭에서 카테고리가 분류된 결과 페이지로 이동. 관련순과 최근순으로 정렬.

4. 그룹과 날짜를 상세 검색 할 수 있는 "advanced search" 칸 오른쪽에 배치되어 있음.

  • 문제 : 검색 기능을 최우선적으로 개선하는 것이 맞는지, 그렇다면 어떻게 바꿔야할까?
  • 지향점 : 분석하기 전에, 사용자들이 검색 기능을 어떻게 사용하는지 가설을 세워야 함
    1. 검색의 목적
    2. 검색 목적을 달성했는지 측정하는 법
    3. 개별 사용자 검색 경험의 일반적인 품질을 정량적으로 어떻게 이해할지?
  • 데이터
    1. 중요한 이벤트
      • search_autocomplete : 자동검색어 중 사용자가 클릭한 검색옵션
      • search_run : 사용자가 검색하고 검색 결과 페이지를 볼 때
      • search_click_X : X는 1-10 사이의 검색된 횟수 
    2. 테이블
      • 유저 테이블
        user_id / created_at / state / activated_at / company_id / language
      • 이벤트 테이블
        user_id / occurred_at /
        event_type
            "signup_flow" - 사용자 인증 과정 동안 발생하는 모든 것
            "engagement" - 가입 후 처음으로 일반적인 서비스 이용
        event_name 
            "create_user" - 계정 생성
            "enter_mail" - 이메일 주소를 통해 가입 시작
            "complete_signip" / "home_page"
            "like_message" - 메세지 좋아요 /  "login"
            "search_autocomplete" / "search_run" / "search_click_X"
            "send_message" / "view_inbox" - 메세지함 보기
  • 제안하기
    - 검색 경험이 일반적으로 좋은가 나쁜가?
    - 검색할 가치가 있는가?
    - 검색이 가치가 있다면, 무엇을 구체적으로 개선해야 하는가? 

run a search - enter 눌러서 검색한건지? 


 

https://mode.com/sql-tutorial/understanding-search-functionality-answers

 

Understanding Search Functionality: Answers | SQL Analytics Training - Mode

In this lesson we'll cover: Developing hypotheses Framing problems simply and correctly can often save time later on. Thinking about the ultimate purpose of search right off the bat can make it easier to evaluate other parts of them problem. Search, at the

mode.com

Understanding Search Functionality: Answers

가설 검증 

좋은 검색은 최소한의 작업으로 빠르게 목표(찾는 것)에 도달하는 것

  • search use : 검색 기능 사용자 여부
  • search frequency : 짧은 시간에 반복적으로 사용한다면, 원하는 결과를 처음에 찾지 못했기 때문
  • repeated terms : 검색어들의 유사성 비교. 검색 횟수를 세는 것 보다 훨씬 느리고 어렵기 때문에, 무시하는 것이 나음
  • clickthroughts : 검색 결과에서 많은 링크를 클릭했다면, 좋은 경험이 아님. 
                              그렇다고 적은 클릭인 반드시 좋은 경험이 것도 아님.
                              상세 검색을 했다면 좋은 경험 아님.
                              사용자가 low result를 자주 클릭하거나 페이지를 스크롤 했다면, 랭킹 알고리즘 조정 필요.
  • autocomplete clickthroughts 

 

검색 상태

두 이벤트 사이에 10분 단절이 있으면 세션 종료 -> 새로운 세션

  1. 사용자들은 autocomplete 기능을 실질적으로 검색 페이지로 연결되는 검색보다 많이 사용함.
    + autocomplete 기능은 25% 세션에서 사용되지만, 검색은 8%에 불과.
    -> autocomplete의 25% 사용은 사용자가 Yammer 네트워크에서 정보를 찾을 필요가 있음. (?)
  2. autocomplete는 한 세션 당 1번 혹은 2번 사용 (1번이 2번보다 2배 많음)
    전체 검색을 할 경우, 대부분 한 세션에 멀티 검색 이용
    -> 검색 결과가 좋지 않거나 검색을 좋아하는 소수의 사용자 그룹이 있음. (?)
    View Mode Analysis
  3. 검색한 대부분의 사용자가 검색 결과에서 한번도 클릭하지 않음
    -> 검색 성능이 특히 좋지 않음!
    + 많은 검색 =/ 많은 클릭 (?)
  4. 검색 결과들의 클릭수가 균등한 편 -> 검색 순위가 좋지 않음
    만약 성능이 좋다면, 1-3번째 결과만 클릭수가 현저하게 높아야 함
  5. autocomplete 기능을 쓴 유저는 첫 번째 검색 이후 더 자주 씀
    Sessions with Search Autocompletes in Month after Users' First Search (?)

 

결론

autocomplete는 성능 굿, 검색은 구림.

검색 결과 ordering 개선에 집중해야 함.

autocomplete에서 원하는 결과를 얻지 못한 사용자가 전체 검색함 -> autocomplete 결과와 다른 결과를 제공하도록 검색 순위 알고리즘을 변경해야 함

전체 검색 결과를 향상하는 것에 집중할 것

 

 


코드분석

SELECT DATE_TRUNC('week',z.session_start) AS week, 
	   -- 세션 시작 날짜가 있는 주의 첫 날 반환
       -- DATE_TRUNC(unit, date): date가 있는 unit의 첫 날 반환
       COUNT(CASE WHEN z.autocompletes > 0 THEN z.session ELSE NULL END)/COUNT(*)::FLOAT AS with_autocompletes,
       -- autocomplete 세션수 / 전체 세션수 = autocomplete 기능을 쓴 세션의 비율
       COUNT(CASE WHEN z.runs > 0 THEN z.session ELSE NULL END)/COUNT(*)::FLOAT AS with_runs
       -- run 세션수 / 전체 세션수 = 검색 기능을 쓴 세션의 비율
  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
              -- id, session, 세션 시작시간, 세션 종료시간
         FROM (
              SELECT bounds.*,
              		    CASE WHEN last_event >= INTERVAL '10 MINUTE' THEN id
              		         WHEN last_event IS NULL THEN id
                             -- 직전 이벤트가 없거나 세션이 다르면 id (세션 시작)
              		         ELSE LAG(id,1) OVER (PARTITION BY user_id ORDER BY occurred_at) END AS session
                             -- 세션이 같으면 직전 이벤트 id (세션 끝)
                        -- 컬럼명 세션
                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
                            -- session 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 
        -- user_id, session : 유저+세션별
       ) 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
 -- 4월 마지막 주부터 8월까지 4개월 간 주별 autocomplete / 검색 기능을 쓴 세션의 비율
 ORDER BY 1

결과 : 마지막 주 기준 autocomplete 26%, 검색 8%