В биологии и медицине многие эксперименты на людях и других высших приматах, как известно, сейчас запрещены. Но в маркетинге и управлении продуктом это пока не возбраняется. Чем мы активно и пользуемся в ID Finance, проводя мультивариативные тесты ценностных предложений, продуктовых фич, интерфейсов и прочего.

А/Б тестирование в нашей компании отличается широкой распространенностью и особой извращенностью. Тесты у нас проводят все, за исключением разве что юристов и бухгалтерии. Но проблема в том, что эксперименты эти обычно намного сложнее того, что обычно понимают под А/Б тестированием — поменять цвет кнопки, подвигать поля, передизайнить лендинг — то, что можно легко сделать через фреймворки типа Google Analytics или Visual Website Optimizer. В нашем случае меняются большие куски customer journey, а зацепить такой тест может значительную часть основных бизнес-метрик.

В итоге, правильное проведение таких тестов, а, главное, правильное подведение их итогов стало своего рода искусством, доступным немногим просвещенным. Что, конечно, не есть хорошо. В итоге, мы решили начать собирать рекомендации и примеры, дабы помочь бизнес-аналитикам и менеджерам сделать все правильно. Ведь, ошибки стоят достаточно дорого: в лучшем случае мы потеряем время на сбор кривых данных и перезапуск теста, в худшем случае – можем принять ошибочное бизнес решение. При этом компания растет, приходят новые люди и хочется сократить learning curve насколько возможно.

На мой взгляд наш опыт и путь, который мы прошли, чтобы его накопить, может быть вполне применим и в вашей компании. Особенно если:

• у вас сложный customer journey;
• разные его части связаны между собой, причем зачастую ключевые метрики меняются разнонаправленно;
• вы хотите проводить комплексные эксперименты, имеющие комплексное влияние.

Дабы не переходить сходу к обобщениям я бы хотел сначала провести вас через последовательность избранных кейсов. Я постарался выбрать такие примеры из нашей практики, в которых очевидно напрашивающийся вывод не являлся верным. Рассмотрев таким образом проблематику, мы уже сможем более подготовлено перейти к выводам и рекомендациям.

Наш путь самурая пользователя

Чтобы задать контекст дальнейшему рассказу, рассмотрим кратко основные стадии жизненного пути нашего клиента.



Как и принято в любом приличном е-commerce, мы привлекаем клиентов через онлайн (а иногда и через оффлайн) каналы к нам на сайт, где они регистрируются и заполняют заявку на кредит. Заполнение заявки — это достаточно сложный и ответственный процесс, клиент должен предоставить довольно много информации, чтобы мы смогли принять взвешенное решение о (не)предоставлении ему кредита. Собственно, рассмотрение заявки и проверка клиента и составляет следующий шаг. После выдачи денег начинается «фандрайзинговая» кампания по их возвращению. Зато успешно выплатив кредит, клиент обычно приходит за следующим: возвращаемость на наших проектах находится в районе 80-90%.

В таблице ниже приведены несколько направлений для экспериментирования в разрезе этапов жизненного цикла клиента.



В общем, есть где разгуляться. Теперь давайте посмотрим, на какие грабли можно наступить.

Начинаем с простого: тест лендинга

Не буду отходить от традиций и приведу достаточно классический пример в нашем исполнении о тестировании лендинг-страницы в определенном маркетинговом канале.

Ниже представлены два варианта этого самого лендинга. Не читая далее, попробуйте догадаться, какой вариант дает наибольшую конверсию в следующий шаг?

Вариант А



Вариант В



А какой вариант мы выбрали для дальнейшего использования?

Фишка в том, что ответы на эти два вопроса различны. В этом можно убедиться, посмотрев на изменение конверсии по шагам воронки подачи заявки на кредит:



Конверсия в следующий шаг выше в варианте В, т.к. все что требуется от пользователя в этом случае – это нажать кнопку. Это просто и весело: нажал – и уже на следующем шаге. Но вот там будущего клиента уже поджидают многочисленные вопросы о его персональных данных. Ну и, собственно, одним шагом подача заявки не заканчивается. В итоге, имеем быстрое угасание мотивации клиента и ухудшение конверсии на всех остальных шагах, в то время как в варианте А заемщик, судя по всему, глубже осознал происходящее и получил больший запал, чтобы дойти до конца.

Таким образом, end-to-end конверсия, к сожалению, не улучшилась, несмотря на улучшение прохождения лендинга. Приходим к нашему первому выводу: необходимо смотреть на всю часть жизненного цикла, на которую влияет тест, а не только на конверсию непосредственно на выходе из эксперимента (того куска, который мы, собственно, и изменили).

Не хочу и не буду

Следующий кейс так же связан с попыткой увеличения конверсии (на примере нашего испанского проекта).



На некоторых странах у нас есть шаг загрузки фото документов (наподобие представленного выше). Эксперимент состоял в том, чтобы этот шаг, изначально находящийся в середине процесса подачи заявки, сдвинуть в конец и сделать необязательным. Расчет был на то, что прямо в данный момент у клиентов может не оказаться необходимого документа и они пришлют его позже.



В результате, как и ожидалось, конверсия воронки увеличилась на некоторую величину х%. Но, при этом, количество выданных займов увеличилось лишь на у% < x%. Откуда взялась эта разница? Дело в том, что часть клиентов, пропускающих шаг, так же и в дальнейшем, на стадии верификации не могли (не хотели) предоставить фото документов. В результате, уменьшилась метрика, которую мы называем «уровнем одобрения» — отношение числа выданных кредитов к запрошенным. Ситуация осложняется тем, что за конверсию воронки отвечает один отдел, а за уровень одобрения – другой.

Как и в предыдущем примере, здесь главное было определить часть жизненного цикла, на которую повлиял тест, и определить целевую метрику, на которую смотреть. В данном случае эффект от теста можно смоделировать следующим простым способом:

Кредиты = Лиды * Конверсия * Уровень одобрения

Т.е. если кумулятивный эффект на выдачу будет позитивным, то изменению – быть, а в противном случае – нет. Так мы обычно и решаем противоречия между отделами.

У кого есть стационарный телефон?

Вот и мы в какой-то момент подумали, что стационарный телефон сейчас есть далеко не у всех, и решили протестировать форму без него (далее на примере польского проекта).



Проблема в том, что стационарный телефон является хорошим инструментом достучаться до клиента (его не выкинешь так просто, он привязан к адресу и проч.). Поэтому, как и ожидалось, в вариации без телефона, возвращаемость кредитов немного падала.

Конверсия вырастает, а собираемость падает. Как в такой ситуации понять, какой вариант лучше? Для ответа на этот вопрос нам пришлось достаточно детально смоделировать юнит-экономику кредита.



На картинке выше много всяких непонятных цифр, и благодаря этому, полагаю, она хорошо иллюстрирует уровень сложности, с которым нам периодически приходится иметь дело, хотя все начиналось с такой, казалось бы, мелочи, как удаление одного поля с одного из шагов формы.

Если говорить кратко, то экономический эффект сводится к тому, что увеличение конверсии уменьшает долю маркетинговых затрат в юнит-экономике, что компенсирует (или нет) уменьшение прибыли из-за ухудшения контактности клиентов. Немного математики, и мы выяснили, какой вариант лучше. Хотя ждать этого пришлось почти два месяца – нужно было собрать статистику по собираемости после наступления даты 1-го платежа по кредиту.

Забытые клиенты

Однажды давным-давно, один из шагов регистрации клиента на нашем казахстанском проекте выглядел вот так:



Мы (так же как и вы только что) подумали, что эта простыня слишком длинная, и это может отпугивать морально неустойчивых клиентов. Альтернативным вариантом в эксперименте стал интерфейс, в котором каждый следующий блок показывался только после успешного заполнения предыдущего.



Конверсия по результату выросла, хоть и не так сильно, как мы рассчитывали, и мы переключили трафик полностью на новый вариант. Казалось бы, happy end, спектакль окончен и занавес опущен, но нет.

Через какое-то время мы случайно обнаружили, что есть часть пользователей, которые очень плохо конвертятся. Когда стали разбираться, выяснилось, что эти пользователи посещают какую-то странную страницу, которой вроде нет в воронке. Хотя, погодите-ка, где-то я уже видел этот URL….

Дело в том, что система работала так, что если клиент сходу не прошел все шаги подачи заявки и ушел с сайта, а затем вернулся и хочет продолжить, то он отправится прямиком на тот шаг, с которого он ушел прошлый раз. И надо сказать, таких случаев достаточно много. Когда разыгрывался эксперимент, часть клиентов, попавших в контрольную стратегию, не осилила сходу длинную версию 2-го шага. Эти пользователи в тот момент ушли с сайта, а затем вернулись уже после «окончания» эксперимента. И тогда система, исходя из разыгранного ранее варианта эксперимента, отправила их снова на старую версию 2-го шага. Но ведь прогресс не стоит на месте, и вскоре забытый и неподдерживаемый старый 2-й шаг просто перестал быть совместим с бек-эндом и перестал нормально работать. Бедные клиенты оказались заложниками устаревшего кода.

Что мы здесь сделали неправильно? Мы не закончили эксперимент должным образом. В данном случае при окончании теста необходимо было обеспечить миграцию клиентов из контрольной группы в выигравшую группу, и, желательно, вычистить legacy код.

Матчасть

Пора, наверное, перейти от практики к теории. Структуру теста можно представить как-то так:



Красным выделена, собственно, та часть жизненного цикла, которая непосредственно подвергается изменению. Желтым – та часть, которая хоть и остается для всех одинаковой, но эксперимент оказывает на нее непосредственное влияние. Соответственно, для принятия решения о результате теста, мы должны анализировать ключевые метрики не только из «красной», но и из «желтой» частей. Дальше начинается часть пути, влиянием эксперимента на которую, как мы предполагаем, можно пренебречь. Но ведь тест – на то и тест, чтобы проверять предположения, поэтому смотреть надо на все основные метрики тоже. Статистически значимые отличия этих метрик могут означать что-либо из этого:

• Мы не учли какой-то эффект эксперимента – и тогда эту метрику надо принять во внимание при подведении итогов.
• В постановке эксперимента есть ошибка (может быть техническая – возникшая при реализации, может быть «идейная», возникшая еще на стадии проектирования). Эта ошибка смазывает результаты теста, и смещение проявляется различием метрик, которые различаться не должны. В такой печальной ситуации необходимо проверить, можем ли мы все-таки очистить данные от влияния ошибки – например, выделить какой-то подсегмент или период времени или исследовать не все показатели, которые хотелось. Если не получается – тест придется перезапустить в новой редакции.

Подведем итоги. Чтобы правильно поставить эксперимент, необходимо ответить на ряд вопросов. До его начала, конечно же.

• Зачем нам нужен этот тест. Что мы хотим улучшить.
• В чем, собственно, состоит улучшение – содержание одной или более экспериментальных стратегий.
• На ком тестируем, т.е. какой сегмент клиентов должен попасть в эксперимент.
• Точка входа в эксперимент – момент жизненного пути пользователя, когда разыгрывается стратегия эксперимента, и пути пользователей расходятся, согласно выпавшему варианту.
• Точка выхода из эксперимента – момент жизненного пути, начиная с которого пользователь может снова попасть в этот же эксперимент (и получить, например, другой вариант). Частный случай – «пожизненный» тест, когда однажды разыгранный вариант до окончания эксперимента закрепляется за пользователем.
• Предполагаемый эффект от эксперимента, и на какие метрики будем смотреть, чтобы этот эффект измерить.
• Оценка этого эффекта при позитивном и негативном раскладах.
• Критерии (не)успеха – пограничные значения метрик, при статистически достоверном пересечении которых мы можем принимать решение.
• Влияние этого теста на другие, и других на этот.
• Продолжительность теста и необходимый размер выборки.
• Окончание теста – как будем мигрировать систему и всех пользователей в новую реальность.
• Приостановка теста – если вдруг что-то пойдет не так, сможем ли мы приостановить тест для выяснения обстоятельств и накатывания исправлений?

Надеюсь, что эти примеры и методики помогут улучшить качество экспериментов также и в вашей компании.