야머는 새로운 기능을 개발할 뿐만 아니라 기존 기능을 개선할 수 있는 방안을 지속적으로 모색하고 있다. 많은 소프트웨어 회사들처럼, Yammer는 그들의 모든 고객들에게 그것들을 출시하기 전에 종종 이러한 기능들을 테스트한다. 이러한 A/B 테스트는 분석가와 제품 관리자가 어떤 특징이 사용자 행동과 전체적인 사용자 경험에 미치는 영향을 더 잘 이해할 수 있도록 돕는다.
이 사례는 Yammer의 핵심 "퍼블리셔" 즉, 사용자가 자신의 메시지를 타이핑하는 Yammer 피드의 맨 위에 있는 모듈을 개선하는 데 초점을 맞추고 있다. 이 기능을 테스트하기 위해 제품 팀은 6월 1일부터 6월 30일까지 A/B 테스트를 실시했다. 이 기간 동안 Yammer에 로그인한 일부 사용자에게는 이전 버전의 퍼블리셔("control group")가, 다른 사용자에게는 새로운 버전("treatment group")이 표시되었다.
**(1) 기능 : 메시지 타이핑 및 publish 하는 기능
(2) 기간 : 6/1 ~ 6/30
(3) 그룹 : 이전 버젼 - control / 새로운 버젼 - treatment
(4) 결과 : treatment group에서 메시지 포스팅이 50% 더 높다는 것을 알게 되었다.**
On July 1, you check the results of the A/B test. You notice that message posting is 50% higher in the treatment group—a huge increase in posting. The table below summarizes the results:
7월 1일에 A/B 테스트 결과를 확인하게 된다. 당신은 treatment group에서 메시지 포스팅이 50% 더 높다는 것을 알게 되었다. 이는 포스팅의 엄청난 증가였다. 아래 표에는 결과가 요약되어 있다.
각 칼럼의 의미를 봐야할듯.
쿼리 테이블 순서 : experiment → ex → a → b → c
SELECT c.experiment,
c.experiment_group,
c.users,
c.total_treated_users,
ROUND(c.users/c.total_treated_users,4) AS treatment_percent,
c.total,
ROUND(c.average,4)::FLOAT AS average,
ROUND(c.average - c.control_average,4) AS rate_difference,
ROUND((c.average - c.control_average)/c.control_average,4) AS rate_lift,
ROUND(c.stdev,4) AS stdev,
ROUND((c.average - c.control_average) /
SQRT((c.variance/c.users) + (c.control_variance/c.control_users))
,4) AS t_stat,
(1 - COALESCE(nd.value,1))*2 AS p_value
FROM (
SELECT *,
MAX(CASE WHEN b.experiment_group = 'control_group' THEN b.users ELSE NULL END) OVER () AS control_users,
MAX(CASE WHEN b.experiment_group = 'control_group' THEN b.average ELSE NULL END) OVER () AS control_average,
MAX(CASE WHEN b.experiment_group = 'control_group' THEN b.total ELSE NULL END) OVER () AS control_total,
MAX(CASE WHEN b.experiment_group = 'control_group' THEN b.variance ELSE NULL END) OVER () AS control_variance,
MAX(CASE WHEN b.experiment_group = 'control_group' THEN b.stdev ELSE NULL END) OVER () AS control_stdev,
SUM(b.users) OVER () AS total_treated_users
FROM (
SELECT a.experiment,
a.experiment_group,
COUNT(a.user_id) AS users,
AVG(a.metric) AS average,
SUM(a.metric) AS total,
STDDEV(a.metric) AS stdev,
VARIANCE(a.metric) AS variance
FROM (
SELECT ex.experiment,
ex.experiment_group,
ex.occurred_at AS treatment_start,
u.user_id,
u.activated_at,
COUNT(CASE WHEN e.event_name = 'send_message' THEN e.user_id ELSE NULL END) AS metric
FROM (SELECT user_id,
experiment,
experiment_group,
occurred_at
FROM tutorial.yammer_experiments
WHERE experiment = 'publisher_update'
) ex
JOIN tutorial.yammer_users u
ON u.user_id = ex.user_id
JOIN tutorial.yammer_events e
ON e.user_id = ex.user_id
AND e.occurred_at >= ex.occurred_at
AND e.occurred_at < '2014-07-01'
AND e.event_type = 'engagement'
GROUP BY 1,2,3,4,5
) a
GROUP BY 1,2
) b
) c
LEFT JOIN benn.normal_distribution nd
ON nd.score = ABS(ROUND((c.average - c.control_average)/SQRT((c.variance/c.users) + (c.control_variance/c.control_users)),3))
이 차트는 treatment group로 사용자당 게시된 평균 메시지 수를 보여준다. 아래 표에는 추가 테스트 결과 세부 정보가 수록되어 있다.
The test above, which compares average posting rates between groups, uses a simple Student's t-test for determining statistical signficance. For testing on averages, t-tests are common, though other, more advanced statistical techniques are sometimes used. Furthermore, the test above uses a two-tailed test because the treatment group could perform either better or worse than the control group. (Some argue that one-tailed tests are better, however.) You can read more about the differences between one- and two-tailed t-tests here.
Once you're comfortable with A/B testing, your job is to determine whether this feature is the real deal or too good to be true. The product team is looking to you for advice about this test, and you should try to provide as much information about what happened as you can.
그룹 간 평균 게시율을 비교하는 위의 시험은, 통계적 신호 전달을 결정하기 위해 간단한 Student's t-test을 사용한다. 평균에 대한 시험의 경우, t-검정은 일반적이지만, 다른 고급 통계 기법이 사용되기도 한다. 게다가 위의 테스트는 treatment group이 대조군보다 더 잘하거나 더 나쁘게 수행될 수 있기 때문에 two-tailed test를 사용한다. (그러나 일부에서는 한쪽꼬리 테스트가 더 낫다고 주장한다.) 여기서 한 꼬리와 두 꼬리의 t-검정 간의 차이점에 대해 자세히 알아볼 수 있다.
일단 당신이 A/B 테스트에 익숙해지면, 당신의 일은 이 기능이 real deal or too good to be true 판단하는 것이다. 제품 팀에서 이 테스트에 대한 조언을 구하고 있으며, 가능한 한 무슨 일이 일어났는지에 대한 정보를 제공하도록 노력해야 한다.
Before doing anything with the data, develop some hypotheses about why the result might look the way it does, as well as methods for testing those hypotheses. As a point of reference, such dramatic changes in user behavior—like the 50% increase in posting—are extremely uncommon.
If you want to check your list of possible causes against ours, read the first part of the answer key.
데이터로 어떤 것을 하기 전에, 왜 결과가 그렇게 보일 수 있는지에 대한 가설과 그러한 가설들을 시험하는 방법을 개발하라. 참고로, 게시물의 50% 증가와 같은 사용자 행동의 급격한 변화는 극히 드물다.
가능한 원인 목록을 확인하려면 정답 키의 첫 번째 부분을 읽어 보십시오.
This table shows which groups users are sorted into for experiments. There should be one row per user, per experiment (a user should not be in both the test and control groups in a given experiment).
이 표는 실험을 위해 사용자가 어떤 그룹으로 분류되는지를 보여준다. 실험당 사용자당 하나의 행이 있어야 한다(사용자는 주어진 실험에서 테스트 그룹과 제어 그룹 모두에 있어서는 안 된다).
This table is purely a lookup table, similar to what you might find in the back of a statistics textbook. It is equivalent to using the leftmost column in this table, though it omits negative Z-Scores.
이 표는 순전히 lookup table인데, 통계 교과서 뒷면에서 찾을 수 있는 것과 유사하다. 음의 Z-점수는 생략하지만 이 표에서 가장 왼쪽 열을 사용하는 것과 같다.
score: Z-score. Note that this table only contains values >= 0, so you will need to join the absolute value of the Z-score against it.
value: The area on a normal distribution below the Z-Score.
점수: Z-점수. 이 표에는 >= 0 값만 포함되어 있으므로 이에 대해 Z-점수의 절대값을 결합해야 한다.
value: Z-Score 아래의 정규 분포의 영역.
A/B tests can alter user behavior in a lot of ways, and sometimes these changes are unexpected. Before digging around test data, it's important to hypothesize how a feature might change user behavior, and why. If you identify changes in the data first, it can be very easy to rationalize why these changes should be obvious, even if you never would have have thought of them before the experiment.
It's similarly important to develop hypotheses for explaining test results before looking further into the data. These hypotheses focus your thinking, provide specific conclusions to validate, and keep you from always concluding that the first potential answer you find is the right one.
For this problem, a number of factors could explain the anomalous test. Here are a few examples:
A/B 테스트는 여러 가지 방법으로 사용자 행동을 변화시킬 수 있으며, 때로는 이러한 변화가 예상치 못한 경우도 있다. 시험 데이터를 조사하기 전에, 어떤 특징이 사용자 행동을 어떻게 변화시킬 수 있는지, 그리고 그 이유는 무엇인지 가설을 세우는 것이 중요하다. 만약 당신이 먼저 데이터의 변화를 식별한다면, 비록 실험 전에 이러한 변화를 전혀 생각하지 못했을지라도, 왜 이러한 변화가 명백해야 하는지를 합리화하기가 매우 쉬울 수 있다.
데이터를 더 조사하기 전에 시험 결과를 설명하기 위한 가설을 세우는 것도 마찬가지로 중요하다. 이러한 가설들은 당신의 생각을 집중시키고, 검증하기 위한 구체적인 결론을 제공하며, 당신이 찾은 첫 번째 잠재적인 답이 옳은 답이라고 항상 결론짓지 못하게 한다.
이 문제에 대해, 많은 요인들이 the anomalous test를 설명할 수 있다. 여기 몇 가지 예가 있다.
This metric is incorrect or irrelevant: Posting rates may not be the correct metric for measuring overall success. It describes how Yammer's customers use the tool, but not necessarily if they're getting value out of it. For example, while a giant "Post New Message" button would probably increase posting rates, it's likely not a great feature for Yammer. You may want to make sure the test results hold up for other metrics as well.
Posting rates은 전체 성공을 측정하기 위한 올바른 측정기준이 아닐 수 있다. Yammer의 고객이 이 도구를 사용하는 방법을 설명하지만, 이 도구에서 가치를 얻는다면 반드시 그렇지는 않다. 예를 들어, 거대한 "Post New Message" 버튼은 아마도 게시율을 증가시키겠지만, Yammer에게는 그다지 좋은 기능은 아닐 것이다. 시험 결과가 다른 측정 기준에서도 유지되도록 할 수 있다.
The test was calculated incorrectly: A/B tests are statistical tests. People calculate results using different methods—sometimes that method is incorrect, and sometimes the arithmetic is done poorly. A/B 테스트는 통계 테스트다. 사람들은 다른 방법들을 사용하여 결과를 계산한다. 때로는 그 방법이 틀릴 수도 있고, 때로는 산술적으로 잘 되지 않을 수도 있다.
The users were treated incorrectly: Users are supposed to be assigned to test treatments randomly, but sometimes bugs interfere with this process. If users are treated incorrectly, the experiment may not actually be random. 사용자들은 무작위로 시험 치료를 하도록 배정되어야 하지만, 때때로 버그가 이 과정을 방해한다. 사용자가 incorrectly 처리된 경우 실험은 실제로 무작위가 아닐 수 있다.
There is a confounding factor or interaction effect: These are the trickiest to identify. Experiment treatments could be affecting the product in some other way—for example, it could make some other feature harder to find or create incongruous mobile and desktop experiences. These changes might affect user behavior in unexpected ways, or amplify changes beyond what you would typically expect. 교란 요인 또는 교호작용 효과가 있다. 이것들은 식별하기에 가장 까다롭다. 예를 들어, 실험 처리는 다른 방식으로 제품에 영향을 미칠 수 있다. 예를 들어, 모바일 및 데스크톱 경험에 맞지 않는 다른 기능을 찾거나 생성하기가 더 어려워질 수 있다. 이러한 변경은 예상치 못한 방식으로 사용자 행동에 영향을 미치거나 일반적으로 예상할 수 없는 변화를 증폭시킬 수 있다.
First, the average number of logins per user is up. This suggests that not only are users sending more messages, but they're also signing in to Yammer more.
첫째, 사용자당 평균 로그인 수가 상승한다. 이것은 사용자들이 더 많은 메시지를 보낼 뿐만 아니라, 야머에 더 많이 로그인하고 있다는 것을 암시한다. → 로그인이 많다고 해서 메시지를 많이 보낸다는 결론이 가능한가?
Second, users are logging in on more days as well (days engaged the distinct number of days customers use Yammer). If this metric were flat and logins were up, it might imply that people were logging in and logging out in quick succession, which could mean the new feature introduced a login bug. But both metrics are up, so it appears that the problem with this tests isn't cherry-picking metrics—things look good across the board.
둘째, 사용자들은 더 많은 날짜에 로그인하고 있다(고객이 Yammer를 사용하는 뚜렷한 일수가 걸린 날짜). 이 메트릭이 flat하고 로그인이 실행 중이라면, 사람들이 빠르게 로그인하고 로그아웃하고 있다는 것을 의미할 수 있으며, 이는 new feature introduced a login bug. 그러나 두 측정기준이 모두 상향되어 있기 때문에 이 테스트의 문제는 체리픽팅 측정기준이 아니라 전반적으로 상황이 좋아 보인다.
The test, however, does suffer from a methodological error. The test lumps new users and existing users into the same group, and measures the number of messages they post during the testing window. This means that a user who signed up in January would be considered the same way as a user who signed up a day before the test ended, even though the second user has much less time to post messages. It would make more sense to consider new and existing users separately. Not only does this make comparing magnitudes more appropriate, be it also lets you test for novelty effects. Users familiar with Yammer might try out a new feature just because it's new, temporarily boosting their overall engagement. For new users, the feature isn't "new," so they're much less likely to use it just because it's different.
그러나 이 테스트는 방법론적 오류로 인해 어려움을 겪고 있다. 이 테스트는 신규 사용자와 기존 사용자를 동일한 그룹으로 묶고 테스트 기간 동안 게시하는 메시지 수를 측정한다. 이는 1월에 등록한 사용자가 두 번째 사용자가 글을 올릴 시간이 훨씬 적음에도 불구하고 시험이 끝나기 하루 전에 등록한 사용자와 같은 방식으로 간주된다는 것을 의미한다. 신규 사용자와 기존 사용자를 별도로 고려하는 것이 더 타당할 것이다. 이렇게 하면 비교 크기가 더 적절할 뿐만 아니라, 새로움 효과에 대해 테스트할 수 있다. Yammer에 익숙한 사용자들은 새로운 기능이 새롭다는 이유만으로 새로운 기능을 시도할 수 있으며, 일시적으로 전체적인 참여도를 높일 수 있다. 신규 이용자의 경우 기능이 '신규'가 아니기 때문에 단지 다르다고 해서 이용할 가능성이 훨씬 적다. → sign up user의 분포도를 보면 좋을 것 같다.
(3)
all new users were treated in the control group.→ 신규 유저가 control 그룹?
control과 test 유저들의 sign up이 언제 이루어 졌는지. → user 테이블 + experiment 테이블?