hmm06 님의 블로그

[SQL] HackerRank 문제 풀기 (Interviews)

hmm06 — Fri, 17 Jan 2025 17:35:18 +0900

해당 문제는 HackerRank에서 사용한 문제이며 모든 테이블의 자료와 출처는 Hackerank임을 밝힙니다.

해커랭크

해당 글에서는 많은 JOIN과 LEFT JOIN을 사용하여 푸는 문제로 난이도가 어느정도 있는 문제입니다.

해당 문제 원본을 확인 하시려면 해당 사이트를 들어가시면 될 것 같습니다.

시작하겠습니다

Samantha interviews many candidates from different colleges using coding challenges and contests. Write a query to print the contest_id, hacker_id, name, and the sums of total_submissions, total_accepted_submissions, total_views, and total_unique_views for each contest sorted by contest_id. Exclude the contest from the result if all four sums are 0.
Note: A specific contest can be used to screen candidates at more than one college, but each college only holds 1 screening contest.

사만다는 코딩 챌린지와 콘테스트를 통해 다양한 대학의 많은 지원자들을 인터뷰합니다. 쿼리를 작성하여 contest_id, hacker_id, name, 그리고 각 콘테스트를 contest_id별로 정렬한 총_submissions, total_accepted_submissions, total_views, total_unique_views의 합계를 출력합니다. 네 개의 합계가 모두 0인 경우, 결과에서 콘테스트를 제외합니다.

참고: 특정 대회는 여러 대학에서 후보자를 선발하는 데 사용할 수 있지만, 각 대학은 단 하나의 선발 대회만 개최합니다.

해당 문제는 테이블이 많습니다. 그래서 JOIN을 통해 묶어주었으며 계산이 필요한 테이블은 먼저 GROUP BY를 사용하여 계산을 해준 뒤 LEFT JOIN을 통해서 유저 중 챌린지를 하지 않은 것은 점수 부여를 0으로 해주었습니다.

이렇게만 해주면 간단히 풀 수 있을 것입니다.

1. 점수 관련 테이블 더해주기

select challenge_id, 
       sum(total_views) total_views, 
       sum(total_unique_views) total_unique_views 
from View_Stats 
group by challenge_id

 select challenge_id, 
       sum(total_submissions) total_submissions, 
       sum(total_accepted_submissions) total_accepted_submissions 
from Submission_Stats 
group by challenge_id

이렇게 두 개의 테이블을 challenge_id로 그룹화 해준 뒤 각 점수들을 모두 더해주었습니다.

이제 해당 데이터들을 모두 LEFT JOIN을 해줄 것입니다.

2. JOIN과 LEFT JOIN을 활용하기

select *
from contests a
join colleges b on a.contest_id = b.contest_id
join challenges c on b.college_id = c.college_id
left join (
    select challenge_id, 
           sum(total_views) total_views, 
           sum(total_unique_views) total_unique_views 
    from View_Stats 
    group by challenge_id
) d on c.challenge_id = d.challenge_id
left join (
    select challenge_id, 
       sum(total_submissions) total_submissions, 
       sum(total_accepted_submissions) total_accepted_submissions 
   from Submission_Stats 
   group by challenge_id
) e on c.challenge_id = e.challenge_id

이렇게 유저와 대학교 관련된 테이블은 INNER JOIN을 적용해줍니다.

그리고 점수 테이블과 유저 테이블을 INNER JOIN을 하지 않은 이유는 만약 유저와 challenge_id 서로 겹치지 않는 것이 존재 한다면 해당 유저는 사라지기 때문에 LEFT JOIN을 활용한 것입니다.

3. 최종적으로 유저가 풀은 문제들 점수 모두 합치고 문제 조건 넣기

select a.contest_id, 
   a.hacker_id, 
   a.name,
   sum(total_submissions),
   sum(total_accepted_submissions),
   sum(total_views),
   sum(total_unique_views)
from contests a
join colleges b on a.contest_id = b.contest_id
join challenges c on b.college_id = c.college_id
left join (
    select challenge_id, 
           sum(total_views) total_views, 
           sum(total_unique_views) total_unique_views 
    from View_Stats 
    group by challenge_id
) d on c.challenge_id = d.challenge_id
left join (
    select challenge_id, 
       sum(total_submissions) total_submissions, 
       sum(total_accepted_submissions) total_accepted_submissions 
   from Submission_Stats 
   group by challenge_id
) e on c.challenge_id = e.challenge_id
group by a.contest_id, a.hacker_id, a.name
having sum(total_submissions) != 0 OR
   sum(total_accepted_submissions) != 0 OR
   sum(total_views) != 0 OR
   sum(total_unique_views) != 0
order by a.contest_id

이렇게 GROUP BY를 사용하여 묶어 준 뒤 SUM()을 사용하여 각 점수들을 모두 더해줍니다.

이제 문제 조건 중 네 개의 점수 모두 0인 값은 제외 시키기 위해 HAVING절에 OR를 사용하여 제외 시켜주었습니다.

ORDER BY를 통해 정렬을 해주면 정답이 됩니다.

이상으로 Hacker Rank 문제 풀이를 마치도록 하겠습니다.

[SQL] HackerRank 문제 풀기 (SQL Project Planning)

hmm06 — Mon, 13 Jan 2025 16:43:27 +0900

해당 문제는 HackerRank에서 사용한 문제이며 모든 테이블의 자료와 출처는 Hackerank임을 밝힙니다.

해커 랭크

해당 글에서는 윈도우 함를 사용하여 푸는 문제로 난이도가 어느정도 있는 문제입니다.

해당 문제 원본을 확인 하시려면 해당 사이트를 들어가시면 될 것 같습니다.

시작하겠습니다

If the End_Date of the tasks are consecutive, then they are part of the same project. Samantha is interested in finding the total number of different projects completed. Write a query to output the start and end dates of projects listed by the number of days it took to complete the project in ascending order. If there is more than one project that have the same number of completion days, then order by the start date of the project.

작업의 종료일이 연속적이라면 동일한 프로젝트의 일부가 됩니다. 사만다는 완료된 다양한 프로젝트의 총 수를 찾는 데 관심이 있습니다.

쿼리를 작성하여 프로젝트를 완료하는 데 걸린 일수를 오름차순으로 나열한 프로젝트의 시작 및 종료 날짜를 출력합니다. 완료 일수가 같은 프로젝트가 두 개 이상인 경우 프로젝트 시작 날짜까지 순서를 정합니다.

해당 문제는 Window 함수(LAG, LEAD)를 이용하여 풀어보겠습니다.

하지만 생각해야 할 것은 LAG를 하며 내려갈 마지막 행은 사라진다는 것입니다. 그것을 고려하여 해당 테이블의 마지막 행을 UNION을 통해 합쳐줄 것을 꼭 기억해주십시오.

그리고 마지막에 LEAD를 이용하여 내렸던 날짜들을 다시 올려 줄 것입니다.

1. LAG함수와 UNION 함수 적용하기

select 
    Start_Date,
    LAG(End_DATE) OVER (ORDER BY Start_Date, End_Date) lag
from Projects
UNION
select Top 1
    Start_Date,
    End_Date
from Projects
order by Start_Date DESC, End_Date DESC

코드 결과

우선, LAG를 이용하여 End_Date를 한칸씩 내려 주었습니다.(모두 1일 간격이기 때문에 가능)

하지만 LAG를 이용하면 마지막 행까지 내려가긴 하지만 사라지는 것을 확인 할 수 있습니다. 그래서 UNION을 통해 마지막 행에 있을 값 하나를 UNION을 통해 묶어주었습니다.(MySQL이라면 LIMIT를 사용하면 되지만, MSSQL이라 TOP 1 사용.)

2. Start와 End_Date같은 것을 제외 후 LEAD 함수를 사용하여 다시 End_Date 올려주기

WITH CTE AS (
    select 
        Start_Date,
        LAG(End_DATE) OVER (ORDER BY Start_Date, End_Date) lag
    from Projects
    UNION
    select Top 1
        Start_Date,
        End_Date
    from Projects
    order by Start_Date DESC, End_Date DESC
)
SELECT Start_Date
        , LEAD(lag) OVER (ORDER BY Start_Date, lag) lead
FROM CTE
WHERE lag IS NULL OR Start_Date IS NULL OR Start_Date != lag

코드 결과

우선 End_Date가 Null인 값을 가져오는 이유는 맨 처음 날짜는 LAG 함수로 인해 END_Date가 없는 상태이기 때문입니다.

그리고 Start_Date와 End_Date의 같은 날짜를 제외하는 이유는 해당 프로젝트에서 연결되는 날짜이기 때문이며 저희는 첫 날과 마지막 날만 알면 되기 때문입니다.

이제 LEAD를 통해 End_Date를 올려주면 프로젝트의 첫 날과 마지막 날짜가 연결된 것을 확인 할 수 있습니다.

3. Null값 제외와 정렬해주기

WITH CTE AS (
    select 
        Start_Date,
        LAG(End_DATE) OVER (ORDER BY Start_Date, End_Date) lag
    from Projects
    UNION
    select Top 1
        Start_Date,
        End_Date
    from Projects
    order by Start_Date DESC, End_Date DESC
)
SELECT t.Start_Date, t.lead
FROM (
    SELECT Start_Date
        , LEAD(lag) OVER (ORDER BY Start_Date, lag) lead
    FROM CTE
    WHERE lag IS NULL OR Start_Date IS NULL OR Start_Date != lag
) t
WHERE t.lead IS NOT NULL
ORDER BY DATEDIFF(DAY, t.Start_Date, t.lead) ASC, t.Start_Date ASC

우선 왜 NULL을 제외시키는 것인지 설명하도록 하겠습니다.

LEAD 함수 사용으로 인해 End_Date를 위로 한 칸씩 올리는 바람에 마지막 행에서의 End_Date는 Null이 남게 됩니다. 그리고 저희는 처음에 UNION을 해서 마지막 행을 추가해주었는데 해당 값은 LAG로 인해 사라진 마지막 행의 End_Date를 대체 하기 위해 End_Date를 추가 한 것이며 해당 End_Date는 위로 한 칸 올라갔기 때문에 제거를 해도 무방합니다.

마지막으로 정렬을 할 때 날짜를 빼주어야 하기 때문에 DATEDIFF를 사용해주었습니다.

이상으로 Hacker Rank 문제 풀이를 마치도록 하겠습니다.

[SQL] HackerRank 문제 풀기 (Contest Leaderboard)

hmm06 — Sat, 11 Jan 2025 21:03:33 +0900

해당 문제는 HackerRank에서 사용한 문제이며 모든 테이블의 자료와 출처는 Hackerank임을 밝힙니다.

해커랭크

해당 글에서는 서브쿼리를 사용하여 푸는 문제로 난이도가 매우 낮은 문제입니다.

해당 문제 원본을 확인 하시려면 해당 사이트를 들어가시면 될 것 같습니다.

시작하겠습니다

You did such a great job helping Julia with her last coding contest challenge that she wants you to work on this one, too!
The total score of a hacker is the sum of their maximum scores for all of the challenges. Write a query to print the hacker_id, name, and total score of the hackers ordered by the descending score. If more than one hacker achieved the same total score, then sort the result by ascending hacker_id. Exclude all hackers with a total score of 0 from your result.

해커의 총 점수는 모든 도전 과제에서의 최고 점수 합계입니다. 쿼리를 작성하여 해커의hacker_id, 이름(name), 그리고 총 점수(total score)를 출력하세요. 결과는 점수를 기준으로 내림차순으로 정렬하세요. 만약 여러 해커가 동한 총 점수를 달성했다면,hacker_id를 기준으로 오름차순으로 정렬하세요. 총 점수가 0인 해커는 결과에서 제외해야 합니다.

해당 문제는 WINDOW 함수(ROW_NUMBER)와 GROUP BY를 활용하여 풀어보겠습니다.

우선, ROW_NUMBER를 통해 해커ID와 챌린지ID를 파티션으로 분할한 뒤 높은 Score 순으로 순위를 주고 시작 할 것입니다. 그 후, 1위인 순위들만 가지고 계산에 적용할 것입니다.

1. ROW_NUMBER 활용하여 순위 부여

select *
     , ROW_NUMBER() OVER (PARTITION BY hacker_id, challenge_id ORDER BY score DESC) rank
from Submissions

코드 결과

위의 이미지와 같이 해커가 20594라는 시험을 여러번 봤으며 여러번 본 시험에서의 높은 점수 순으로 순위를 부여 하였습니다.

이제 해당 데이터를 가상테이블로 만들어 주고 코드를 이어서 작성하겠습니다.

2. 제일 높은 점수로만 각 해커의 점수 구하기

WITH CTE AS (
    select *
         , ROW_NUMBER() OVER (PARTITION BY hacker_id, challenge_id ORDER BY score DESC) rank
    from Submissions
)

SELECT a.hacker_id, b.name, SUM(a.score) total
FROM CTE a
JOIN Hackers b ON a.hacker_id = b.hacker_id
WHERE rank = 1
GROUP BY a.hacker_id, b.name

코드 결과

이렇게 name을 가져오기 위해서 Hackers 테이블을 조인 해주었습니다.

저희는 각 해커가 풀었던 문제 중 제일 높은 점수만 원하기 때문에 WHERE절을 통해 1순위만 가져와주었습니다.

그리고 해커ID와 이름을 기준으로 GROUP BY를 해준뒤 score를 모두 더해주었습니다.

3. 총점이 0 제외 시키고 정렬해주기

WITH CTE AS (
    select *
         , ROW_NUMBER() OVER (PARTITION BY hacker_id, challenge_id ORDER BY score DESC) rank
    from Submissions
)

SELECT a.hacker_id, b.name, SUM(a.score) total
FROM CTE a
JOIN Hackers b ON a.hacker_id = b.hacker_id
WHERE rank = 1
GROUP BY a.hacker_id, b.name
HAVING SUM(a.score) != 0
ORDER BY total DESC, a.hacker_id ASC

WHERE 절에는 모든 총합의 점수가 0인 것은 확인 할 수 없으므로 HAVING 절을 사용하여 총점이 0인 값은 제외하고 출력하도록 해주었습니다.

마지막으로 총점과 해커ID를 정렬해주면 정답을 확인 할 수 있습니다.

이상으로 Hacker Rank 문제 풀이를 마치도록 하겠습니다.

[SQL] HackerRank 문제 풀기 (Ollivander's Inventory)

hmm06 — Fri, 10 Jan 2025 17:10:19 +0900

해당 문제는 HackerRank에서 사용한 문제이며 모든 테이블의 자료와 출처는 Hackerank임을 밝힙니다.

해커랭크

해당 글에서는 서브쿼리를 사용하여 푸는 문제로 난이도가 매우 낮은 문제입니다.

해당 문제 원본을 확인 하시려면 해당 사이트를 들어가시면 될 것 같습니다.

시작하겠습니다

Hermione decides the best way to choose is by determining the minimum number of gold galleons needed to buy each non-evil wand of high power and age. Write a query to print the id, age,
coins_needed, and power of the wands that Ron's interested in, sorted in order of descending power. If more than one wand has same power, sort the result in order of descending age.

헤르미온느는 각 비악한(non-evil)고위력(high power) 및 고연령(age) 마법 지팡이를 구매하는 데 필요한 최소 골드 갤리온 수(coins_needed)를 기준으로 선택하는 것이 가장 좋은 방법이라고 결정합니다. 다음 조건에 따라 id, age,coins_needed, 그리고power를 출력하는 쿼리를 작성

해당 문제는 groupby와 ROW_NUMBER(윈도우 함수)를 적용하여 풀어보겠습니다.

추가로 age, power로 묶어준 뒤 최소 금액을 구해줍니다. 그리고 ROW_NUMBER를 사용할 때 partition by를 power, age로 나눠준 뒤 가격이 낮은 순으로 랭크를 부여한 뒤 1위인 지팡이만 가져오면 됩니다.

1. 각 age, power 별 최소 골드 요구하는 지팡이 찾기

select a.id, b.age, MIN(a.coins_needed) coins_needed, a.power
from Wands a
JOIN Wands_Property ON a.code = b.code
where b.is_evil = 0
group by a.id, b.age, a.power

코드 결과

각 age, power 그룹 별 최소 금액을 가지는 지팡이를 찾을 수 있습니다.

이제 해당 지표를 테이블로 설정하고 이어서 답을 찾아가 보겠습니다.

2. ROW_NUMBER 활용하여 랭크 부여

WITH CTE as (
    select a.id, b.age, MIN(a.coins_needed) coins_needed, a.power
    from Wands a
    JOIN Wands_Property b ON a.code = b.code
    where b.is_evil = 0
    group by a.id, b.age, a.power
)
select *
     , ROW_NUMBER() OVER (partition by age, power order by coins_needed) rank
from CTE

코드 결과

맨 오른쪽에 power, age 같은 것 중 저렴한 순으로 랭크를 부여 해주었습니다.

이제 문제에서 요구하는 age, power 별로 최소 금액인 지팡이를 선별 할 수 있게 되었습니다.

3. rank가 1인 행만 가져오고 ORDER BY로 정렬

WITH CTE as (
    select a.id, b.age, MIN(a.coins_needed) coins_needed, a.power
    from Wands a
    JOIN Wands_Property b ON a.code = b.code
    where b.is_evil = 0
    group by a.id, b.age, a.power
)
select t.id, t.age, t.coins_needed, t.power
from (
    select *
         , ROW_NUMBER() OVER (partition by age, power order by coins_needed) rank
    from CTE
) t
where t.rank = 1
order by t.power DESC, t.age DESC;

이렇게 where 절을 사용하여 각 값들에서 rank가 1인 값을 가져와주면 age, power 별 최소 금액인 값만 가져오게 됩니다. 그리고 order by를 통해 내림차순 정렬을 해주게 되면 답이 되게 됩니다.

이상으로 Hacker Rank 문제 풀이를 마치도록 하겠습니다.

[기초 통계] A/B 테스트

hmm06 — Wed, 18 Dec 2024 13:24:02 +0900

A/B 테스트란?

두 개의 변형 A와 B를 사용하는 종합 대조 실험으로, 통계적 가설 검정 또는 2-표본 가설 검점의 한 형태입니다.

즉, 두 가지 서로 다른 옵션에 대한 사용자의 반응을 측정함으로써 어떠 옵션이 더 효과적인지를 검증하는 과정입니다.

A/B 테스트 설계하기

가설

A/B 테스트의 출발점은 가설입니다. A/B 테스트가 의미 있으려면 실험을 통해 무엇을 확인하고 싶은지가 명확해야 합니다.

실험 집단/통제 집단

전체 모수 중 실험 조건에 할당되는 사용자들을 어떤 기준으로 구분하고, 어떤 비율로 할당할 것인지 정의해야 합니다.

독립변수 / 종속변수

독립 변수는 설명 변수 또는 예측 변수라고도 합니다. 인과 관계에서 원인이 되는 변수, 즉, 종속 변수에 영향을 줄 거라고 기대되는 변수입니다.

종속변수는 독립변수에 의해 영향을 받을 것으로 기대되는 변수입니다. 즉, 인과 관계에서 결과가 되는 변수라고 볼 수 있습니다.

실험 설계 과정에서는 종속 변수의 현재 수준을 측정하고 실험을 통해 어느 정도의 변화를 기대하는지 정의하는 것이 필요합니다.

통제 변수

실험 결과에 영향을 미칠 수 있기 때문에 실험 집단/통제 집단 모두에서 동등한 조건을 가져야 하는 변수를 의미합니다.

즉, 독립 변수가 아니지만 종속 변수에 영향을 미칠 수 있는 제 3의 변수라 볼 수 있습니다.

이 통제 변수를 얼마나 잘 관리하느냐에 따라 A/B테스트의 성패가 달립니다.

실험 기간

샘플 크기를 고려했을 때 가설 검증을 위한 데이터를 수집하는데 필요한 기간을 정의 해야 합니다.

A/B 테스트 설계 시 유의 사항

실험 집단과 통제 집단 샘플링

랜덤 추출은 통제 변수가 잘 관리된 것을 전제로 모든 표본이 동일한 확률을 가진 상태에서 뽑는 무작위 추출을 의미합니다.

제 3의 변수(통제 변수)가 종속 변수에 영향을 미칠 수 있다고 판단된다면 이를 통제 변수에 포함해서 샘플링 과정에 반영함으로써 종속 변수에 미치는 영향을 차단해야 합니다.

즉, 테스트 하고 싶은 독립 변수 외에 종속 변수에 영향을 미치는 나머지 요소들을 얼마나 잘 식별하고 통제하느냐가 A/B테스트를 설계하는 과정에서 대단히 중요합니다.

순차 테스트와 동시 테스트

순차 테스트는 A조건으로 일정 기간 테스트를 한 다음, B 조건으로 바꿔서 연이어 테스트를 진행하고 이 두 가지 조건의 결과를 비교하는 식으로 진행하는 테스트입니다.

여기서 순차 테스트는 A/B테스트가 아닙니다!! 그리고 순차 테스트의 가장 큰 문제는 제대로 된 통제 변수 관리를 할 수 없다는 점입니다. 실험 기간이 달라짐에 따라 기대하지 못한 외부 효과가 개입할 여지가 있기 때문입니다.

A/B 테스트 결과를 분석하는 방법

p-value에 대한 이해

실험의 유의 수준을 판단하기 위해 통계학에서 사용하는 기준은 p값입니다. 하지만 p값만 체크한다고 하여 실험 결과를 정확하게 분석할 수 있는 것은 아닙니다.

p값은 귀무가설 하에서 관찰된 검정통계량 만큼의 극단적인 값이 관찰될 확률을 의미합니다.

여기서 검정통계량이 극단적인 값일수록 귀무가설을 반박하는 목소리를 크게 낼 수 있다고 생각하시면 됩니다.

테스트 비용과 효과 크기

p값이 A/B테스트의 결과를 판단하는 단 하나의 절대적인 기준은 아닙니다. 애초에 표본 크기가 커지면 p값은 낮아지는 특성이 있기 때문에 실험 집단의 규모가 매우 크다면 p값이 가지는 의미가 왜곡될 수 있습니다.

즉, A/B 테스트의 가치는 단순히 테스트 자체의 결과로 인해 얻어지는 p값 외에 실험이 실질적으로 효과를 미치는 크기나 영향력을 고려해서 판단해야 합니다.

A/B 테스트 진행시 주의 사항

무가설
통제 변수 관리 실패
단순 평균 비교(평균 만이 아니라 분포, 유의수준, 효과 크기 등을 종합적으로 고려해서 판단해야 함.)
엿보기 + 조기 중지(p값의 변화를 살펴보고 있다가 p값이 0.05이하로 내려가는 시점에 실험을 중단해 버리면 안됨.)
시간의 흐름에 따른 차이를 살펴보지 않는 것.
과거의 A/B 테스트 경험을 지나치게 신뢰하는 것
국지적 최적화의 함정

이상으로 A/B 테스트에 대한 포스팅을 마치겠습니다.

참고한 내용은 양승화님의 그로스해킹 책에서 도움을 많이 받았습니다.

이상입니다.

[AARRR] Referral(추천)

hmm06 — Thu, 5 Dec 2024 10:03:04 +0900

추천(Referral)이란?

오가닉(Organic) 유입의 하나로, 말 그대로 기존 사용자의 추천이나 입소문을 통해 새로운 사용자를 데려오는 것을 의미합니다.

추천을 위한 기능으로 흔히 볼 수 있는 것은 친구 초대 기능입니다. 그리고 동시에 친구초대를 할 때 일정한 보상을 지급하는 식으로 초대 프로그램을 운영합니다.

그럼 보상을 어느 정도 지급해야 좋은 것일까? 당연하게도 고객 획득 비용(CAC)에 따라서 달라집니다.

다른 마케팅 채널보다 저렴한 비용으로 새로운 사용자를 데려올 수 있고 초대를 통해 들어온 사용자들은 진성 유저가 될 가능성이 높다는 점에서 친구 초대는 굉장히 강력하고 중요한 추천 채널이라고 볼 수 있습니다.

친구 초대 플로 설계

친구 초대는 세세한 프로세스와 화면 단위의 사용자 경험이 얼마나 잘 설계됐느냐에 따라 그 효과가 크게 달라집니다.

예를 들어 '친구를 초대하고 25달러의 크레딧을 받으세요' -> '친구에게 25달러의 크레딧을 선물 하세요'라는 문구로 바꾸는 것처럼 어떤 문구와 톤으로 표현하느냐에 따라 친구 초대 성과는 크게 달라질 수 있습니다.

초대맥락

친구 초대의 효과를 극대화하려면 초대하는 맥락을 자연스럽게 잘 구성하거나 혹은 친구 초대 자체에 게임화 요소를 추가하는 것도 있습니다.

예를 들어 카카오 뱅크 모임통장은 소모임 등에서 회비 관리를 쉽게 할 수 있게 만든 통장입니다.해당 통장을 개설한 후 멤버를 초대하는 것은 특별히 보상을 바라고 하는 행동이 아니라 모임 통장을 원래 목적대로 활용하기 위해 자연스럽게 거치는 프로세스입니다.

여기서 어떻게 신규 가입자를 데려올 수 있는 것이냐면 친구를 통해 모임통장에 초대를 받게 되면 처음에 수락하기를 누르게 됩니다. 만약 카카오 뱅크 계좌가 없다면 여기서 카카오 뱅크 개설을 해야 모임 통장에 참여를 할 수 있는 프로세스이기 때문에 많은 이들은 카카오 뱅크의 예/적금 통장을 개설하는 진성고객으로 전환됩니다.(저도 경험을 해봤네요...이게 이 추천과 관련이 있을 줄은....ㅎㅎ)

메시지/보상

보상이 반드시 현금성이어야 하는 것은 아닙니다. 예를 들어 예전에는 드롭박스의 경우 친구 초대에 대한 보상을 추가적인 저장 공간을 제공하는 것으로 설계했었습니다. 당시 해당 보상으로 인해 많은 사용자들의 폭발적인 참여를 이끌어내기도 했습니다.

온보딩 프로세스

우선 온보딩 프로세스란 제품에 성공적으로 적응하고 정착하도록 돕는 체계적이고 계획적인 과정입니다.

그러므로 온보딩 프로세스를 세심하게 설계하면 친구 초대의 효과를 크게 높일 수 있습니다.

바이럴 계수

추천에서 가장 핵심이 되는 지표는 바이럴 계수 입니다. 각 서비스는 바이럴 계수를 통해 추천 엔진이 얼마나 효과적으로 동작하는지 확인할 수 있었습니다.

공식 : 바이럴 계수는 (사용자 수 X 초대 비율 X 인당 초대한 친구 수 X 전환율) / 사용자 수

10000명의 사용자가 있는데, 그 중 20%인 2000명이 인당 평균 5명씩의 친구를 초대한다고 가정하겠습니다.

만약 초대받은 친구의 30%가 신규 회원으로 가입했다면 새롭게 가입한 회원 수는 10000 X 0.2 X 5 X 0.3을 적용하여 3000명이 되고, 바이럴 계수는 3000 / 10000을 하여 0.3이 됩니다.

즉, 바이럴 계수를 높이기 위해서는 세가지 조건이 충족 되어야 합니다.

친구 초대와 같은 추천 액션에 참여하는 사용자 비율 높이기
한 사람이 평균적으로 초대하는 친구의 수 늘리기
초대받은 친구가 가입으로 전환되는 비율 높이기

즉, 친구 초대를 비롯한 바이럴 경로의 효과를 높이려면 위 세가지 조건에 대한 현재 지표를 확인하고, 무엇을 먼저 개선할지를 명확히 정의한 후, 그곳에 집중하는 것이 좋습니다.

이제 추천을 통해 늘어난 사용자가 다음 추천을 시작하는 모집단이 되기 때문에 추천 시스템은 복리의 특성을 갖게 됩니다.

그리고 추천 시스템에 대한 효과를 분석할 때는 바이럴 계수를 구하는 것과 함께 '초대의 주기가 얼마나 빠른가?'를 꼭 고려해야 합니다.

추천을 통해 가입하는 사용자 수 증가

바이럴 계수는 타깃 시장에 대한 포화 정도와 전혀 상관없이 계산되는 수치이기 때문에 시장의 크기나 서비스가 이미 확보한 사용자 규모 등을 종합적으로 고려해야 합니다.

유입된 사용자의 장기적인 경험 수준은 바이럴 계수에 잘 드러나지 않는다는 점도 유의해야 합니다. 즉, 이 말은 우리 서비스의 핵심가치를 잘 경험하고 만족했는지, 지속적으로 남아서 충성 사용자로 전환되는지 등은 바이럴 계수만으로는 체크할 수 없다는 것입니다.

그러므로 유입된 사용자의 전체 활동 주기에 대한 장기적인 관점이 필요하다는 점을 기억해야 합니다.

[AARRR] Revenue(수익화)

hmm06 — Wed, 4 Dec 2024 14:24:21 +0900

AARRR에 해당하는 모든 요소들은 모두 중요하지만 결국 사업의 성패를 가리는 것은 수익화(Revenue)다.

수익화 관련 주요 지표

ARPU(Average Revenue Per User)

수익화 측면에서 우선적으로 봐야 하는 중요한 지표는 ARPU(인당 평균 매출)입니다.

인당 평균 매출이란 개념은 전반적인 수익화 상황을 보는데 굉장히 유용합니다.

하지만, ARPU를 구할 때 사용자와 매출의 정의가 모호합니다. 사용자를 구할 때 사용되는 사용자는 전체로 할 것인가? DAU나 MAU로 봐야 하는 것인지 그리고 매출은 가입자가 아니라 결제자를 봐야할 것인가 마찬가지로 매출의 기준이 되는 기간은 언제부터로 설정해야 하는지 모호한 편입니다.

그러므로 ARPU를 구하려면 먼저 전사적으로 통용되는 명확한 기준을 세워야 합니다.(일반적으로 ARPU는 월 기준으로 집계)

ARPPU(Average Revenue Per Paying User)

ARPPU는 결제자 인당 평균 매출입니다. ARPU와 유사하지만 전체 사용자가 아닌 결제자만을 대상으로 합니다.

그리고 ARPPU 또한 ARPU와 마찬가지로 기간에 대한 정의가 필요합니다.

고객 생애 가치(Life Time Value, LTV)

고객 생애 가치는 한 명의 사용자가 진입하는 순간 부터 이탈하는 순간까지의 전체 활동 기간에 누적해서 발생하는 수익입니다.

고객 생애 가치 공식

M : 1인당 평균 매출 c : 1인당 평균 비용

r : 고객 유지 비율 i : 할인율

AC : 고객 획득 비용

매출에서 운영 비용을 제외한 수익을 먼저 계산하고, 이탈율을 고려해서 '고객 생애' 동안 반복적으로 기대할 수 있는 누적 수익을 구합니다.

고객 생애 가치는 논리적으로는 빈틈없이 완벽한 수식이지만 앞의 수식에서는 결정적인 단점이 있습니다.

바로 현실에서 이런 식의 계산은 사실상 불가능하다는 점입니다. 왜냐하면 고객 1인당 비용을 계산할 수 없으며 고객 1인당 평균 매출이 기간 마다 일정하지 않고 고객 유지 비율 또한 일정하지 않기 때문입니다.

고객 생애 매출(Lifetiem Revenue, LTR)

고객 생애 가치가 고객 한 명에 대한 기대 수익이라면, 고객 생애 매출은 고객 한 명에 대한 기대 매출입니다.

고객 생애 매출을 계산할 때는 따로 비용을 고려하지 않고 매출만 살펴보면 됩니다.

시점	가입자	활동회원	결제자	ARPPU	결제 금액	가입자당 결제액
2020년 1월	1000	1000	500	5000	2500000	2500
2020년 2월		800	300	4500	1350000	1350
2020년 3월		500	120	4000	480000	480

ARPPU는 결제자당 평균 결재액이고 여기서 가입자당 결제액을 계산할 경우 활동회원으로 나누는 것이 아닌 가입자인 1000으로 나눠 줘야 합니다.

이렇게 월별로 가입자당 결제액을 모두 합산하면 4330원이 나오는데, 해당 숫자가 1명의 가입자가 생겼을 때 기대할 수 있는 평균 매출입니다.

비용 VS 매출

비용 : 매출을 창출하기 위해서 소비한 모든 지출을 의미합니다.

매출 : 기업이 상품이나 서비스를 판매하거나 제공하여 발생한 총 수입을 의미합니다.

수익화 분석하기

고객 생애 매출 활용

고객 생애 매출을 활용할 때의 중요한 포인트는 우리 서비스의 전체적인 고객 생애 매출을 딱 떨어지는 숫자로 요약하는 것에 집착할 필요 없다는 것입니다.

코호트를 잘 나누고 코호트별 고객 생애 매출의 추이가 어떻게 변화하는지 살펴보는 것이 훨씬 더 유용합니다.

만약 코호트를 잘 나누고 각 코호트의 고객 생애 매출의 변화 그래프를 그려 보면 시간이 지남에 따라 고객 생애 매출이 증가하는 속도와 높이를 확인 할 수 있습니다.

이처럼 증가 추이를 구한 후 고객 획득 비용(Customer Acquision Cost, CAC)과 비교하면 서비스의 수익 모델이 잘 작동하고 있는지, 마케팅 비용을 적절하게 사용하고 있는지 등을 확인 할 수 있습니다.

데이터리안 LTR 분석

만약 건강하게 성장하고 있는 서비스라면 LTR이 CAC를 빠르게 따라잡고 장기적으로 CAC의 몇 배수까지 높아져야 합니다.

그리고 고객 생애 매출이 고객 획득 비용보다 충분히 크지 못하면 그 비즈니스는 유지될 수 없습니다.

즉, 수익을 높이기 위해서는 비용을 줄이는 것도 필요하지만 튼튼한 비즈니스 모델을 통해 사용자들이 지속적으로 결제하는 구조를 만드는 것이 더 중요합니다.

수익화 쪼개서 보기

아이템별 매출의 합계

: 매출에 기여하는 아이템과 그렇지 않은 아이템, 판매량이 증가한 아이템과 감소한 아이템 등을 파악합니다.

사용자별 매출의 합계

: 사용자 세그먼트를 분류한 후 각 세그먼트별 매출의 합계를 통해 전체 매출을 계산할 수 있습니다.

ex) 신규회원 매출 + 기존 회원 매출과 같은 식으로 나눠서 볼 수 있습니다.

결제자 수 X ARPPU

: 결제자 수는 활동회원 중 얼마나 결제를 했느냐에 따라 달라지는 지표이기 때문에 한 번 더 쪼갤 수 있습니다.

활동회원 X 결제비율 X ARPPU

: 활동 회원은 가입자 중 남아서 활동하는 회원이 얼마나 되느냐에 따라 달라지는 지표입니다. 그러므로 한 번더 쪼갤 수 있습니다.

가입자 X 리텐션 X 결제 비율 X ARPPU

: 가입자는 앱설치자와 가입 전환율을 곱해서 또 구할 수 있습니다.

이런식으로 매출을 퍼널에 따라 쪼개 보면 매출이 증가하거나 감소하는 패턴을 세부적으로 파악할 수 있게 됩니다.

특히 가입 기간에 따른 월별 코호트 기준으로 매 코호트의 데이터를 이렇게 쪼개서 확인하면 기간에 따른 효과와 퍼널에 따른 효과를 결합해서 훨씬 더 입체적으로 매출을 분석할 수 있습니다.

수익화 정리

수익화 지표를 계산해보면 개인별 편차가 상당히 크게 나타납니다. 전체 사용자의 20%가 전체 매출의 80%를 결제하는 패턴을 흔히 볼 수 있으며, 서비스에 따라 이 비율이 더 극단적인 경우도 많습니다.

매출에서의 평균값은 굉장히 주의해서 사용해야 합니다. 고액 결제자 몇 명의 행동 변화에 따라 ARPU나 ARPPU가 흔들릴 수 있기 때문입니다. 그러므로 서비스에 대한 충성도가 높고 매출 기여가 높은 사용자 층을 고려해서 기획하는 편이 훨씬 효과적이라는 점을 기억해야 합니다.

따라서 요약된 수익화 지표 하나만 보고 의사결정을 내리기보다는 사용자를 다양한 방식으로 그루핑하고 각 그룹에 맞는 운영 및 수익화 전략을 세우는 것이 중요합니다.

서비스를 출시하는 시점에는 수익 모델이 포함되지 않을 수 있지만 그런 경우라고 해도 어느 시기에 어떤 방식으로 수익화 할 것인가에 대한 로드맵은 명확하게 존재해야 합니다.

다음 글에서는 Referral(추천)에 대해 포스팅하겠습니다.

참고한 내용은 양승화님의 그로스해킹 책에서 도움을 많이 받았습니다.

이상입니다.

이미지 출처 : https://sungmooncho.com/2011/11/21/customer-lifetime-value/%EF%BB%BF(LTV 공식)

https://datarian.io/blog/lifetime-revenue(LTR 분석 그래프)

[AARRR] Retention(유지율) - 2

hmm06 — Tue, 3 Dec 2024 09:59:43 +0900

리텐션 지표

DAU(Daily Active User)를 MAU(Month Active User)로 나눠서 인게이지먼트(Engagement) 지표를 구하게 되면 서비스의 리텐션 수준을 알 수 있습니다.

인게이지먼트 지표는 매일 동일한 사용자가 반복적으로 들어오는지 혹은 날마다 새로운 사용자가 들어오는지를 빠르게 가늠할 수 있게 해줍니다.

DAU/MAU 지표가 어떻게 달라지는지를 나타낸 라인그래프를 보면 날짜에 따라 인게이지먼트가 어떻게 달라지는지 변화 추이를 살펴보는 것은 전반적인 리텐션 수준을 요약해서 살펴보는데 큰 도움이 됩니다.

리텐션 분석하기

기간별 리텐션 수치를 계산한다고 해서 특별한 인사이트를 얻을 수 있는 것은 아닙니다. 또한 리텐션은 쪼개서 볼 때 의미 있는 지표라는 점입니다.

일반적으로 리텐션을 분석할 때 활용하는 코호트의 기본은 날짜! 입니다. 왜냐하면 날짜를 기준으로 한 리텐션의 추이를 살펴보면 리텐션이 시간 흐름에 따라 좋아지고 있는지 나빠지고 있는지 판단 가능하기 때문입니다.

즉, 어떤 채널을 통해 들어온 사용자들이 오랜 기간 남아서 활동하면서 충성고객으로 전환되는 비율이 높은지 확인도 가능합니다.

리텐션 차트

리텐션 차트는 코호트, 볼륨(위의 이미지에선 볼륨이 빠졌다.), 기간, 리텐션 4가지 요소로 이루어집니다.

코호트 : 각 행의 첫 번째 열에 작성합니다. 위의 이미지에서는 7일 기준으로 나누고 있습니다.
볼륨 : 각 코호트의 크기를 기록합니다.
기간 : 유지율을 구분해서 보기 위한 날짜 기준을 기록합니다. 위의 이미지에서는 0주째, 1주째로 나뉜 것을 보니 주별로 정한 것 같습니다. 사용자들의 평균 서비스 방문 주기를 고려해서 정하면 됩니다.
리텐션 : 각 코호트별로 집계된 기간별 리텐션을 기록합니다.

리텐션 개선하기

2가지 개선방법이 있습니다.

초기에 리텐션이 떨어지는 속도를 늦추기.
리텐션이 안정화된 이후에는 기울기를 평평하게 유지해서 오래 유지되게 하기.

리텐션 커브

초기에 떨어지는 속도를 늦추는 것은 활성화 프로세스의 영향을 많이 받습니다. 그러므로 사용자가 서비스에 처음으로 들어와서 가입하는 동선, 서비스 핵심 기능을 사용하는 프로세스 등을 단계별로 쪼개서 살펴보는 것이 좋습니다.

이처럼 활성화 단계에서 이탈이 많은 경로가 어디인지를 살펴보면 초기 유지율이 떨어지는 것을 보완하는데 도음이 됩니다.

가파르게 떨어지는 구간을 지난 후 안정화되는 단계에서는 사용자와의 관계를 잘 유지하는 것이 중요합니다. 정기적인 커뮤니케이션 플랜이나 CRM 마케팅 활동, 주기적으로 진행하는 프로모션 등이 도움이 됩니다.

또는 복귀 명분을 만들어주는 리마케팅 등을 꾸준히 할 필요가 있습니다.

높은 리텐션 유지하는 방법

서비스를 통해 '축적되는' 가치를 만들고 이를 사용자에게 지속적으로 전달하는 것.
후발주자로 시작하는 서비스들은 경쟁 서비스의 사용자들을 데려오기 위해 그동안 축적해 놓은 가치를 손실 없이 이전하는 기능을 제공.

예를 들어, 노션에서는 에버노트 등 경쟁사에 저장해 둔 사용자의 노트를 쉽게 가져올 수 있는 기능을 제공합니다.

또는 노래 어플 플로(FLO)는 후발 주자인 만큼 특별한 서비스를 제공합니다. 바로 다른 노래 어플에서 자신이 모아둔 노래 플레이리스트를 똑같이 만들어주는 것입니다.

이렇게 이전하는 기능을 잘 만들게 되면 높은 리텐션 비율을 보이던 경쟁 서비스의 고객도 어렵지 않게 데려올 수 있는 것입니다.

리텐션 정리

1. 단순히 리텐션 지표만 보지 말고 전반적인 사용자 경험을 고려해야 합니다.

특히, 앱 푸시 등의 촉발제(Trigger)를 반복적으로 사용하면 당연하게도 복귀할 고객도 만들지 못할 뿐더러 앱 삭제나 탈퇴라는 부작용이 증가할 수 밖에 없습니다.

그러므로 메시지의 빈도나 총량이 너무 많아지지 않도록 유의해야 합니다.

2. 리텐션은 단기적인 이벤트보다는 장기적으로 꾸준히 진행하는 활동을 통해 점진적으로 개선되는 지표입니다.

3. 서비스에 따라 각자 목표하는 리텐션 수준이 달라야합니다.

4. 마지막으로 리텐션이 늘 일관되게 유지되지 않는다는 점입니다. 같은 서비스라도 유입되는 사용자 특성에 따라 리텐션 추이가 얼마든지 달라질 수 있고 때로는 경쟁사 출현 등 외부요인이 리텐션에 영향을 미치기도 합니다.

즉, 리텐션을 한 번 측정하고 끝내는게 아닌 기간에 따른 코호트 분석을 꾸준히 해야 하는 것도 바로 이러한 이유 때문입니다.

다음 글에서는 Revenue(수익화)에 대해 포스팅하겠습니다.

참고한 내용은 양승화님의 그로스해킹 책에서 도움을 많이 받았습니다.

이상입니다.

이미지 출처 : https://datarian.io/blog/retention-analysis (리텐션 차트, 리텐션 커브)

[AARRR] Retention(유지율) - 1

hmm06 — Mon, 2 Dec 2024 10:12:14 +0900

리텐션이란?

활성화 과정을 통해 경험한 핵심 가치를 꾸준히 경험하게 하고, 그 수준을 측정할 수 있는 지표를 정의하고 관리해야 합니다.

리텐션은 서비스의 성공을 예측할 수 있는 가장 기본적이면서도 중요한 지표입니다.

즉, 리텐션은 대표적으로 잘 하고 있을 때 일수록 더 세심하게 측정하고 관래해야 하는 지표에 속합니다.

그리고 리텐션의 기준이 되는 행동을 꼭 접속으로 한정할 필요는 없습니다. 일반적으로 접속이나 로그인을 기준으로 리텐션을 측정하는 이유는 사용자가 서비스에 진입하는 것이 유의미한 행동이며, 이러한 행동이 반복되는지 살펴보는 것이 중요하기 때문입니다.

리텐션을 측정하는 세 가지 방법

클래식 리텐션

특정일에 이벤트를 발생시킨 유저의 비율을 계산하는 방식이기 때문에 'Day N 리텐션'이라고도 합니다.

클래식 리텐션 = Day N에 서비스를 이용한사람 / Day 0에 처음 서비스를 이용한사람

클래식 리텐션은 이벤트가 처음 발생한 날짜를 기준으로, 하루하루 시간이 지남에 따라 몇 명이 해당 이벤트를 반복했는지를 집계하는 방식입니다.

추가적인 내용으로 거의 접속하지 않다가 우연히 특정일에 접속했는데, 그 날을 기준으로 하는 리텐션 집계에 포함되는 사례도 발생할 수 있습니다.

클래식 리텐션에서 노이즈를 줄이려면 기준일을 여러 개 두고 각 기준일에 따른 Day-N 리텐션을 각각 측정한 후 이 값의 평균을 계산하여 N일 기준의 리텐션 지표를 구하는 방법을 사용할 수 있습니다.

클래식 리텐션

위의 이미지를 해석하자면 Day 7을 보았을 때 해당 날짜에 접속한 인원은 총 6명입니다. 그리고 Day 0에 이용한 사람은 총 10명입니다. 그러므로 6/10을 하여 60%라는 결과를 얻을 수 있는 것입니다.

일반적으로 클래식 리텐션은 매일 접속해서 사용할 것으로 기대되는 서비스에서 활용하기에 적절한 지표입니다.

즉, 짧은 주기로 반복적으로 사용하는 것이 보편적인 전화나, 메신저, SNS 같은 서비스가 여기에 해당합니다.

범위 리텐션

특정 기간에 이벤트를 발생시킨 유저의 비율을 계산하는 방식으로 리텐션을 측정합니다. 클래식 리텐션과 유사하나 개별 날짜가 아닌 특정기간(ex. 7일이나, 1개월)을 기준으로 한다는 것입니다.

즉, 특정기간 범위 내에 접속했는지를 여부를 바탕으로 리텐션을 계산하는 형태입니다.

클래식 리텐션 대비 측정일에 따른 노이즈가 크지 않다는 장점이 있습니다. 다만 기준이 되는 기간이 길어질수록 리텐션이 과대 추정 될 수 있다는 문제가 있고, 의미 있는 결과를 보기 위해서는 어느 정도 기간이 축적돼야 하기 때문에 리텐션 트렌드를 확인하는 데 비교적 오랜 시간이 필요하다는 단점이 있습니다.

범위 리텐션 = Range N에 서비스를 이용한 사람 / Range 0에 처음 서비스를 이용한 사람

범위 리텐션

위의 이미지에서 Range1을 보시면 특정 기간(8~14일) 동안 접속하지 않은 유저는 2명입니다. 그러므로 접속한 사람은 8명이고 Day 0에 처음 서비스를 이용한 사람은 10명이므로 8/10 = 80%가 되는 것입니다.

즉, 범위 리텐션은 클래식 리텐션에 비해 사용 주기가 길고 주기적인 서비스에서 많이 활용 됩니다. 예를 들어 일정 간격으로 사용하는 가계부나 음식 배달 서비스 등이 있습니다.

롤링 리텐션

더 이상 해당 이벤트가 발생하지 않는 비율은 얼마인가?를 살펴봄으로써 리텐션을 계산하는 방식입니다.

클래식 리텐션과 범위 리텐션은 접속을 기준으로 '몇 명이 들어왔는가?'에 초점을 맞추지만 롤링 리텐션은 '몇 명이 나갔는가?'에 초점을 맞춥니다.

즉, 떠나버린 유저를 집계하여 리텐션을 계산하는 것입니다. 쉽게 말하자면 '마지막 로그인 날짜'를 활용해 리텐션을 계산한다!!

하지만 한 번이라도 로그인 하는 경우 그 이전까지의 모든 기간을 활동한 기간으로 인정한다는 특성 때문에 유지율이 과대 추정되는 경향이 강하게 나타나므로 이상치의 영향을 크게 받는다는 특성이 있습니다.

그리고 문제가 리텐션 수치 자체가 계속 변한다는 점입니다. 예를 들어, 롤링 리텐션을 80%라 계산했는데 1년 후 어느 날 접속하게 되면 리텐션 수치는 변하게 되는 것입니다.(절대적인 수치보다 지표의 움직임 추이에 초점을 맞춰 활용)

롤링 리텐션 = After N day에 서비스를 이용한 유저 / Day 0에 처음 서비스를 이용한 유저

롤링 리텐션

위의 이미지에서 Day 14를 기준으로 리텐션을 확인 할 때 저희는 표의 전체를 보고 계산해야 합니다. 해당 특정일에 접속을 하지 않으면서 그 이후로도 접속을 하지 않은 것을 봐야합니다.

user 1은 14일에 접속을 하지 않았으나, 그 다음 날에 접속을 하였으므로 해당 유저는 접속을 한 것이고 user 7은 어제 접속을 하였으나 14일 기준으로 접속을 한 번도 하지 않았으므로 접속하지 않는 유저로 판별하게 됩니다.

그러므로 위의 예시를 참고하여 계산을 해보면 6 / 10 = 60%라는 값을 얻을 수 있습니다.

롤링 리텐션은 사용 빈도가 높지 않은 서비스에서 유용하게 활용됩니다. 의류 쇼핑 서비스, 여행 서비스 등 사용 빈도가 드물게 나타나는 서비스라면 유지율을 관리하는 데 롤링 리텐션이 유용하게 활용 될 것입니다.

다음 글에서는 Retention(고객 유지)에 대한 리텐션 지표에 대해 포스팅하겠습니다.

참고한 내용은 양승화님의 그로스해킹 책에서 도움을 많이 받았습니다.

이상입니다.

이미지 출처 : 인프런 양승화님 그로스해킹 강의

[AARRR] Activation(활성화) - 2

hmm06 — Fri, 29 Nov 2024 09:55:33 +0900

Cohort

우선 전환율 지표는 전체 사용자 대상으로 확인할 때보다 여러 그룹으로 쪼개서 볼 때 훨씬 더 강력한 의미를 지닙니다.

예를 들어, '광고를 통해 가입한 사용자의 결제 전환율이 40%이고, 친구 초대를 통해 가입한 사용자의 결제 전환율이 60%입니다.' 이런 식으로 그룹별 전환율을 비교할 때 훨씬 더 큰 인사이트를 얻을 수 있습니다.

이처럼, 공통적인 특성에 따라 여러 집단으로 분류한 사용자 그룹을 코호트(Cohort)라고 합니다.

제가 만든 코호트별 전환율 지표입니다.

코호트 예시

1. 가입 시점에 따라 결제 전환율에 차이가 있는가?
2. utm_source, utm_medium, utm_campaign에 따라 결제 전환율에 차이가 있는가?
3. 특정 이벤트 경험 유무에 따라 결제 전환율에 차이가 있는가?
4. 시간이나 요일, 계절이나 날씨 등 외부 변수에 따라 결제 전환율에 차이가 있는가?
5. 사용자 성별이나, 나이 등 인구통계학적 정보에 따라 결제 전환율의 차이가 있는가?

이렇게 다양한 형태로 코호트를 만들어서 전환율을 비교해 보면 서비스 개선 방향이나 핵심 유저 타기팅, 마케팅 채널 운영전략 등 다양한 주제에 대한 인사이트를 얻을 수 있습니다.

퍼널의 전환율을 높이는 방법

개인화

서비스의 주요 화면들을 개인화해서 사용자 개개인의 맥락에 맞는 정보를 보여준다면 전환율을 높일 수 있습니다.

예를 들어, 사용자들의 이름을 명시하는 것 부터 사용자 개개인의 서비스 사용 내역을 참고한 데이터를 보여주는 것(최근에 본 상품이나 비슷한 상품을 본 사람들이 구입한 상품)등 이 있습니다.

특히, 추천 영역은 개인화의 효과를 크게 볼 수 있는 부분입니다. 하지만 해당 영역은 데이터 사이언티스트가 필요 하므로 단기간에 이러한 추천 시스템을 구축하기는 어렵습니다.

또는 규칙 기반 추천(Rule-Based Recommendation)도 활용하면 큰 효과를 볼 수 있습니다.

UI/UX 개선

주요 화면의 디자인을 변경하거나 구성요소를 바꾸는 것은 전환율을 변화시키는 대표적인 방법입니다.

하지만 UI/UX 개선 프로젝트를 할 때 새로운 화면이 항상 더 좋다는 근거 없는 낙관을 가져서는 안됩니다. 그래서 반드시 변경 전과 변경 후의 효과를 면밀하게 측정하고 검증해야 합니다.

적절한 개입

CRM(Customer-Relationship-Management) 채널이라고 알려진 이메일, 푸시, 인앱 메시지 등을 적절히 활용하면 주요 단계의 전환율을 높일 수 있습니다.

예를 들어, 장바구니에 상품을 넣어두고 결제하지 않은 사용자에게 푸시 알림을 보내거나, 회원 가입 후 활동하지 않는 사용자에게 일정 기간 사용가능한 쿠폰을 문자 메시지로 발송하는 것들이 있습니다.

여기서 주의할 점은 메시지를 발송하는 맥락(context)에 따라 효과가 극적으로 달라질 수 있다는 점이 있습니다.

만약 맥락 없이 푸시와 이메일 발송을 마구잡이로 남발하게 되면 오히려 사용자를 떠나보내게 될 수도 있습니다. 그러므로 적절한 시기, 상황에 맞춰서 메시지를 보내야 합니다.

활성화(Activation) 정리

핵심 가치를 정의하고, 단계별 퍼널을 정의하고, 코호트 기반으로 쪼개서 보는 각 단계를 충실하게 진행하는 것 외에 쉽게 갈 수 있는 지름길은 없다는 것!

퍼널 개선을 하다 보면 전환율을 높이는 것보다 퍼널에 속한 각 단계의 수를 줄이는 것이 더 효과적인 경우도 많다!

즉, 개별 단계의 전환율을 하나하나에 살펴보기에 앞서 서비스 전체 관점에서 불필요한 단계를 없애거나 통합하는 과정이 반드시 필요합니다!

또는 퍼널 자체를 재설계하는 것도 새로운 대안이 될 수 있습니다.

높은 활성화 지표는 이후 리텐션(Retention)의 든든한 바탕이 될 수 있습니다! 그리고 활성화는 우리 서비스의 기본을 끊임없이 되새기게 만드는 단계입니다.

다음 글에서는 Retention(고객 유지)에 대한 내용을 포스팅하겠습니다.

참고한 내용은 양승화님의 그로스해킹 책에서 도움을 많이 받았습니다.

이상입니다.

hmm06 님의 블로그

[SQL] HackerRank 문제 풀기 (Interviews)

1. 점수 관련 테이블 더해주기

2. JOIN과 LEFT JOIN을 활용하기

3. 최종적으로 유저가 풀은 문제들 점수 모두 합치고 문제 조건 넣기

[SQL] HackerRank 문제 풀기 (SQL Project Planning)

1. LAG함수와 UNION 함수 적용하기

2. Start와 End_Date같은 것을 제외 후 LEAD 함수를 사용하여 다시 End_Date 올려주기

3. Null값 제외와 정렬해주기

[SQL] HackerRank 문제 풀기 (Contest Leaderboard)

1. ROW_NUMBER 활용하여 순위 부여

2. 제일 높은 점수로만 각 해커의 점수 구하기

3. 총점이 0 제외 시키고 정렬해주기

[SQL] HackerRank 문제 풀기 (Ollivander's Inventory)

1. 각 age, power 별 최소 골드 요구하는 지팡이 찾기

2. ROW_NUMBER 활용하여 랭크 부여

3. rank가 1인 행만 가져오고 ORDER BY로 정렬

[기초 통계] A/B 테스트

A/B 테스트란?

A/B 테스트 설계하기

가설

실험 집단/통제 집단

독립변수 / 종속변수

통제 변수

실험 기간

A/B 테스트 설계 시 유의 사항

실험 집단과 통제 집단 샘플링

순차 테스트와 동시 테스트

A/B 테스트 결과를 분석하는 방법

p-value에 대한 이해

테스트 비용과 효과 크기

A/B 테스트 진행시 주의 사항

[AARRR] Referral(추천)

추천(Referral)이란?

친구 초대 플로 설계

초대맥락

메시지/보상

온보딩 프로세스

바이럴 계수

추천 정리

[AARRR] Revenue(수익화)

수익화 관련 주요 지표

ARPU(Average Revenue Per User)

ARPPU(Average Revenue Per Paying User)

고객 생애 가치(Life Time Value, LTV)

고객 생애 매출(Lifetiem Revenue, LTR)

비용 VS 매출

수익화 분석하기

고객 생애 매출 활용

수익화 쪼개서 보기

수익화 정리

[AARRR] Retention(유지율) - 2

리텐션 지표

리텐션 분석하기

리텐션 차트

리텐션 개선하기

높은 리텐션 유지하는 방법

리텐션 정리

[AARRR] Retention(유지율) - 1

리텐션이란?

리텐션을 측정하는 세 가지 방법

클래식 리텐션

범위 리텐션

롤링 리텐션

[AARRR] Activation(활성화) - 2

Cohort

코호트 예시

퍼널의 전환율을 높이는 방법

개인화

UI/UX 개선

적절한 개입

활성화(Activation) 정리