LITTLE BY LITTLE

[16] 입력 양식 최적화하기 본문

SQL/데이터 분석을 위한 SQL레시피

[16] 입력 양식 최적화하기

위나 2024. 3. 6. 22:42

목차

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, 입력 양식 최적화)라 한다.
  • 입력 양식 최적화에는 주로 다음과 같은 방법을 사용함
    1. 필수 입력과 선택 입력을 명확히 구분하여 입력 수를 줄임
    2. 오류 발생 빈도를 줄임
    3. 쉽게 입력할 수 있도록 만듦
    4. 이탈할 만한 요소를 제거
  • 이러한 방법을 실시하기 이전에 어떤 문제가 있는지 파악하기 위해서 현재 얼마나 많은 사용자가 이탈하고, 수정했을 경우 얼마나 개선이 되고, 더 개선의 여지가 있는지 모두 수치화해야 한다.

16-1. 오류율 집계하기

SUM(CASE~), AVG(CASE~), 오류율

 

입력 양식 중 오류가 발생했을 때 페이지 열람 로그에 error라는 상태를 출력하는 로그 데이터(form_log)로 오류율을 집계

table 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 윈도 함수

입력 양식 오류 로그 테이블 사용

table form_error_log

 

각 입력 양식의 오류 발생 장소와 원인을 집계하는 쿼리

- 입력 양식의 종류, 입력 항목, 오류 종류로 집약

- 오류 수와 전체에서 차지하는 비율 계산 ( 전체 오류의 수로 나눔)

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;



 

Comments