일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- DENSE_RANK()
- pmdarima
- splitlines
- Growth hacking
- 캐글 산탄데르 고객 만족 예측
- 그로스 해킹
- WITH CUBE
- 데이터 핸들링
- 컨브넷
- 부트 스트래핑
- XGBoost
- lightgbm
- 분석 패널
- 리프 중심 트리 분할
- 스태킹 앙상블
- 데이터 증식
- ImageDateGenerator
- 데이터 정합성
- 그로스 마케팅
- 그룹 연산
- 인프런
- 마케팅 보다는 취준 강연 같다(?)
- sql
- ARIMA
- 로그 변환
- 캐글 신용카드 사기 검출
- 3기가 마지막이라니..!
- tableau
- python
- WITH ROLLUP
- Today
- Total
LITTLE BY LITTLE
[16] 입력 양식 최적화하기 본문
목차
3. 데이터 가공을 위한 SQL 3-1. 하나의 값 조작하기 (5강) 3-2. 여러 개의 값에 대한 조작 (6강) 3-3. 하나의 테이블에 대한 조작 (7강)3-4. 여러 개의 테이블 조작하기 (8강)4. 매출을 파악하기 위한 데이터 추출 4-1. 시계열 기반으로 데이터 집계하기 (9강)4-2. 다면적인 축을 사용해 데이터 집약하기 (10강)
5. 사용자를 파악하기 위한 데이터 추출 5-1. 사용자 전체의 특징과 경향 찾기 (11강) 5-2. 시계열에 따른 사용자 전체의 상태 변화 찾기 (12강)
5-3. 시계열에 따른 사용자의 개별적인 행동 분석하기 (13강)
6. 웹사이트에서 행동을 파악하는 데이터 추출하기 6-1. 사이트 전체의 특징/경향 찾기 6-2. 사이트 내의 사용자 행동 파악하기
6-3. 입력 양식 최적화하기
7. 데이터 활용의 정밀도를 높이는 분석 기술
7-1. 데이터를 조합해서 새로운 데이터 만들기
7-2. 이상값 검출하기
7-3. 데이터 중복 검출하기
7-4. 여러 개의 데이터셋 비교하기
8. 데이터를 무기로 삼기 위한 분석 기술
8-1. 검색 기능 평가하기
8-2. 데이터 마이닝
8-3. 추천
8-4. 점수 계산하기
9. 지식을 행동으로 옮기기
9-1. 데이터 활용의 현장
※ Mysql 기준
6장. 웹사이트에서의 행동을 파악하는 데이터 추출하기
16강. 입력 양식 최적화하기
- 자료 청구 양식과 구매 양식과 같은 입력 양식의 항목이 너무 많으면 사용자가 중도이탈을 하는 데, 이러한 이탈을 막고 성과를 높이고자 입력 양식을 최적화하는 것을 EFO(Entry Form Optimization, 입력 양식 최적화)라 한다.
- 입력 양식 최적화에는 주로 다음과 같은 방법을 사용함
- 필수 입력과 선택 입력을 명확히 구분하여 입력 수를 줄임
- 오류 발생 빈도를 줄임
- 쉽게 입력할 수 있도록 만듦
- 이탈할 만한 요소를 제거
- 이러한 방법을 실시하기 이전에 어떤 문제가 있는지 파악하기 위해서 현재 얼마나 많은 사용자가 이탈하고, 수정했을 경우 얼마나 개선이 되고, 더 개선의 여지가 있는지 모두 수치화해야 한다.
16-1. 오류율 집계하기
SUM(CASE~), AVG(CASE~), 오류율
입력 양식 중 오류가 발생했을 때 페이지 열람 로그에 error라는 상태를 출력하는 로그 데이터(form_log)로 오류율을 집계
확인 화면에서의 오류율을 집계하는 쿼리
- /confirm 페이지에서 오류 발생
- 분모로 url 이 /regist/confirm인 경우로 지정
- 상태 오류를 case식을 사용해 플래그로 변환
- sum과 avg로 오류율을 집계
SELECT
COUNT(*) AS confirm_count,
SUM(CASE WHEN status='error' THEN 1 ELSE 0 END) AS error_count,
AVG(CASE WHEN status='error' THEN 1.0 ELSE 0 END) AS errror_rate,
SUM(CASE WHEN status='error' THEN 1.0 ELSE 0.0 END)
/ COUNT(DISTINCT session) AS error_per_user
FROM form_log
WHERE path = '/regist/confirm';
→ 오류율이 높다면, 오류 통지 방법에 문제가 있어 사용자가 이해하지 못해서 반복적으로 문제를 발생시키는 경우일 수 있다. 오류 통지 방법을 변경해볼 것
16-2. 입력~확인~완료까지의 이동률 집계하기
LAG함수, MIN함수, COUNT 윈도 함수, FIRST_VALUE 함수, 확정률, 이탈률
- 입력 양식을 최적화하기 위해서는 입력부터 확인, 완료까지의 폴아웃 리포트를 확인해야 한다.
- 입력 시작부터 확인 화면까지의 이동 비율을 '확정률'이라 부른다.
- 완료화면까지 이동한 비율은 'CVR'이라 부른다.
- 100%에서 '완료 화면까지 이동한 비율(CVR)'을 뺀 값을 '이탈률'이라 부름
입력 양식의 폴아웃 리포트
1. mst_fallout_step
: 양식 제출 과정의 각 단계를 나열한 마스터 테이블(입력-확인-완료)
WITH
mst_fallout_step AS(
SELECT 1 AS step, '/regist/input' AS path
UNION ALL SELECT 2 AS step, '/regist/confirm' AS path
UNION ALL SELECT 3 AS step, '/regist/complete' AS path)
2. form_log_with_fallout_step
- 실제 로그(form_log)와 마스터 테이블을 조인
- 각 세션의 각 단계에서의 min_stamp와 max_stamp 계산 (조건= status가 공백인, 오류가 없는 로그)
,
form_log_with_fallout_step AS(
SELECT
l.session,
m.step,
m.path,
-- 특정 단계 경로의 처음/마지막 접근 시간
MAX(l.stamp) AS max_stamp,
MIN(l.stamP) AS min_stamp
FROM mst_fallout_step AS m
JOIN form_log AS l
ON m.path = l.path
-- 확인 화면의 상태가 오류인 것만 추출
WHERE status=''
-- 세션별로 단계 순서와 경로 집약
GROUP BY l.session, m.step, m.path)
3. form_log_with_mod_fallout_step
- 이전 단계로부터의 첫 접근 시간 lag_min_stamp 계산
- 세션의 첫 단계 min_step 계산
- 누적 단계 수 cum_count 계산
,
form_log_with_mod_fallout_step AS(
SELECT
session,
step,
path,
max_stamp,
-- 직전 단계 경로의 첫 접근 시간
LAG(min_stamp) OVER(PARTITION BY session ORDER BY step)
AS lag_min_stamp,
MIN(step) OVER(PARTITION BY session) AS min_step,
COUNT(*) OVER(PARTITION BY session ORDER BY step)
AS cum_count
FROM form_log_with_fallout_step)
4. fallout_log
- 최종적으로 폴아웃 단계별로 필터링된 로그를 선별
- 첫 단계부터 시작하여 순차적으로 단계를 거친 로그만 포함
,
fallout_log AS(
SELECT
session,
step,
path
FROM form_log_with_mod_fallout_step
WHERE min_step = 1
AND step = cum_count
AND (lag_min_stamp IS NULL OR max_stamp
> lag_min_stamp))
5. 최종 select문
- 각 단계(step)와 경로(path)에 대해 세션의 수(count)를 카운트
- 첫 번째 단계부터 각 단계까지의 이동률('first_trans_rate') 계산 - 첫 번째 단계에서 시작한 전체 사용자 대비 현재 단계에 도달한 사용자의 비율
- 직전 단계에서 현재 단계까지의 이동률('step_trans_rate') 계산 - 각 단계에서 이전 단계의 사용자 수 대비 현재 단계에 도달한 사용자의 비율
SELECT
step,
path,
COUNT(*) AS count,
100.0 * COUNT(*) / FIRST_VALUE(COUNT(*))
OVER(ORDER BY step ASC
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)
AS first_trans_rate,
100.0 * COUNT(*) / LAG(COUNT(*)) OVER(ORDER BY step ASC)
AS step_trans_rate
FROM fallout_log
GROUP BY step, path
ORDER BY step;
→ 사용자가 입력 의사가 있었는지 없었는지는 판별할 수 없기에, 확인하고 싶다면 최초 입력 항목을 클릭할 때 추가 로그를 전송하게 만들어야 한다.
→ 확실하게 '입력 화면 출력~입력 시작~확인 화면 출력~완료 화면 출력'까지의 폴아웃 리포트를 작성할 수 있음
16-3. 입력 양식 직귀율 집계하기
SUM(CASE~), SIGN함수, 입력 양식 직귀율
- 입력 양식 직귀율: 입력 화면으로 이동한 후 입력 시작, 확인 화면, 오류 화면으로 이동한 로그가 없는 상태의 레코드 수를 센 것을 의미함
- 이 값이 높다는 것은 사용자가 입력을 중간에 포기할만큼 입력 항목이 많다거나, 출력 레이아웃이 난잡하다는 등의 이유가 있을 수 있음
- 혹은 입력 화면으로 이동하는 과정에서 사용자의 모티베이션 환기가 충분하지 않으면, 이유없이 입력 양식이 출력되는 인상을 주는 문제도 있을 수 있음
입력 양식 직귀율 (= 입력 양식 직귀 수 / 입력 화면 방문 횟수) 집계하기
1. form_with_progress_flag
- substring으로 날짜 부분만 추출
- 세션에서 input 경로에 접근이 있는 경우 1을 할당
- 세션에서 confirm 혹은 complete 경로에 접근이 있는 경우 1을 할당
- 세션과 날짜별로 각 세션이 입력 화면에 도달했는지, 폼 제출 과정에 진행이 있었는지에 대한 정보 계산
WITH
form_with_progress_flag AS(
SELECT
SUBSTRING(stamp, 1, 10) AS dt,
session,
-- 입력 화면으로의 방문 플래그 계산
SIGN(SUM(CASE WHEN path IN ('/regist/input') THEN 1 ELSE 0 END))
AS has_input,
SIGN(SUM(CASE WHEN path IN ('/regist/confirm', '/regist/complete') THEN 1 ELSE 0 END))
AS has_progress
FROM form_log
GROUP BY dt, session)
SELECT
dt,
COUNT(*) AS input_count,
SUM(CASE WHEN has_progress = 0 THEN 1 ELSE 0 END) AS bounce_count,
100.0 * AVG(CASE WHEN has_progress = 0 THEN 1 ELSE 0 END) AS bounce_rate
FROM form_with_progress_flag
WHERE has_input = 1
GROUP BY dt;
16-4. 오류가 발생하는 항목과 내용 집계하기
SUM 윈도 함수
입력 양식 오류 로그 테이블 사용
각 입력 양식의 오류 발생 장소와 원인을 집계하는 쿼리
- 입력 양식의 종류, 입력 항목, 오류 종류로 집약
- 오류 수와 전체에서 차지하는 비율 계산 ( 전체 오류의 수로 나눔)
SELECT
form,
field,
error_type,
COUNT(*) AS count,
100.0 * COUNT(*) / SUM(COUNT(*)) OVER(
PARTITION BY form) AS share
FROM form_error_log
GROUP BY form, field, error_type
ORDER BY form, count DESC;