#marketing

Поговорим про задачу MMM (Marketing Mix Modeling). Итак, тут нам нужно ответить на простой вопрос - как влияет наш marketing mix (то есть набор наших маркетинговых воздействий) на продажи. И, желательно, еще и научиться предсказывать оптимальный набор таких воздействий на будущее.

Казалось бы, все просто - бери данные о продажах, плюсуй стоблец с показами/кликами/тратами -> linear regression goes brrr -> ... -> profit.

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

Поэтому и приходится придумывать разные изощренные описания реальности, дабы получить хоть какие-то полезные для нас оценки.

К примеру, можно использовать ранее описанную adstock историю. То есть хитренько добавить сглаживание и насыщение. А уж потом оценивать столь желанные коэффициенты.

Вот пара примеров реализации решения задачки MMM:
1. Вариант попроще;
2. Вариант посложнее (потому что Байесовская магия, ну куда же без нее).

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

​​На кого больше похожа дочь? Ненаучное исследование.

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

Я решил подойти к делу с позиций анализа данных: выбрал 3 фото для себя, жены и дочери. После чего, сравнил 3 * 3 для каждого родителя с помощью библиотеки face_recognition. Благо, там есть функционал для вычисления similarity между лицами. Логика такая: кто получит больший средний балл близости лиц - на того дочь и больше похожа.

В итоге *барабанная дробь* победила дружба. Оказалось, что распределения очень похожи (см. картинку к посту). И бутстреп разницы средних дает доверительный интервал (-0.017, 0.016
), что означает отсутствие статистически значимой разницы. Правда, распределение расстояния между моими фото и фото дочери было поуже, но это, вероятно, из-за того, что фоток было всего 3 и я не особо регулировал наклон головы, позицию на фото и т.д., а брал рандомные +- нормальные фото.

Конечно, это абсолютно ненаучно, зато весело ;)
Ну и результат отлично показал, что дочь в равной степени похожа на маму с папой (что и требовалось доказать).

Я закончил большое изучение материалов по теме Lifetime Value (LTV), так что ближайшие пару-тройку месяцев будут выходить материалы про LTV: что это такое, как считать, как моделировать, обзоры статей и т.п. Все это будет под единым тегом #ltv . Другие теги тоже будут, но этот позволит отыскать потом материалы по теме.

Список будущих постов:
1. Что такое LTV? Простые способы расчета;
2. RFM (Recency Frequency Monetary) анализ;
3. Оценка LTV с использованием Марковских цепей (Markov Chain);
4. Разбор статьи "Beyond Customer Lifetime Valuation: Measuring the Value of Acquisition and Retention for Subscription Services";
5. Оценка LTV посредством моделирования выживаемости;
6. Оценка с использованием Pareto/NBD и ее друзей;
7. Разбор статьи "Profitable Retail Customer Identification Based on a Combined Prediction Strategy of Customer Lifetime Value";
8. Customer2Vec. Обучение представлению пользователей;
9. Разбор статьи "A Deep Probabilistic Model for Customer Lifetime Value Prediction";
10. Разбор статьи "Improved Customer Lifetime Value Prediction with Sequence-To-Sequence Learning and Feature-based Models";
11. Проведение A/B тестов над LTV;
12. Использование суррогатных метрик в онлайн экспериментах. Разбор статьи “Online Experimentation with Surrogate Metrics: Guidelines and a Case Study”.
13. Интересные библиотеки.

#ltv

Что такое LTV и смысл этой метрики.

LTV (Lifetime Value), CLTV, CLV (customer lifetime value) — количество денег, которые приносит пользователь за свою “жизнь” в продукте. Может считаться немного по-разному (для всех привлеченных или только для пользователей или только для платящих пользователей), но общая суть остается той же.

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

Понятное дело, что помимо основного смысла у нас есть некоторые дополнительные способы использовать метрику, например:
- Сегментация аудитории. Мы можем разбить наших клиентов на разные группы по уровню их прибыльности. Самым топовым клиентам можно дать персональные условия или какие-то дополнительные “плюшки”, чтобы не потерять столь полезного для нас клиента;
- Оптимизация удержания (выше уже упомянул это). Если у нас есть пользователь, которому мы можем дать скидку или иное поощрение, чтобы удержать его, то хорошо бы посмотреть “стоит ли игра свеч”. Возможно, мы просто потратим деньги зря на удержание бесполезного для нас пользователя;
- Понимание различных факторов, влияющих на поведение пользователя. Пересекается с сегментацией аудитории, где мы можем понять, чем отличается каждый отдельный сегмент. Но и внутри одной аудиторной группы могут быть различные клиентские пути и триггеры поведения, которые интересно было бы выделять (и понимать, какие есть проблемы на пути пользователей).

Как посчитать LTV?

В этом посте начнем наше погружение с простых способов посчитать LTV.

1. LTV = LIFETIME * ARPU
Где LIFETIME - среднее время “жизни” пользователя, которое можно вывести эвристически (как вариант, посчитать его в виде 1 / churn rate, то есть обратной величиной к оттоку). А ARPU - это средняя прибыль от клиента за период, которое можно посчитать в виде total_revenue / number_of_customers.

2. Повторение метода 1, но с учетом когорт пользователей. Когорта - это пользователи, объединенные по некоторому признаку (обычно - время их регистрации или иное начало “жизни” в продукте). Тогда можно посчитать LTV покогортно, учитывая показатели каждой конкретной когорты;

3. LTV = AVERAGE_ORDER_VALUE * REPEAT_PURCHASE_RATE * LIFETIME
Где AVERAGE_ORDER_VALUE - средний чек, REPEAT_PURCHASE_RATE - частота повторных покупок, LIFETIME - время “жизни” пользователя.

4. LTV = GML * (R / (1 + D - R))
Где GML - чистый доход от пользователя, то есть маржа * общую выручку с пользователя за время его “жизни”. R - это retention rate (доля остающихся в сервисе пользователей). D - ставка дисконтирования (деньги, полученные сейчас, чуть более ценны, чем деньги полученные через год). В итоге получаем учет возвращаемости и “стоимости” денег во времени.

​​#ltv

RFM анализ.

Когда речь заходит о сегментации пользователей применимо к LTV, часто вспоминают RFM анализ. Учитывая, что вещь это достаточно простая, давайте рассмотрим ее одной из первых. 

Итак, RFM анализ - это метод анализа, использующийся для разбиения базы клиентов на сегменты по частоте и сумме покупок и поиска клиентов, которые будут для нас наиболее прибыльными.

RFM можно разложить на следующие составляющие:
- Recency — давность (как давно ваши пользователи что-то у вас покупали);
- Frequency — частота (как часто совершаются покупки);
- Monetary — деньги (сумма покупок).

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

Очевидными минусами подхода будут:
- Достаточно искусственные границы (почему нужно делить именно на n групп?);
- Возможное отсутствие четкой разницы между близкими сегментами.

Но как базовое начало для анализа вполне себе подойдет.

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

Закончу рассказ парой примеров таких расчетов (раз и два). Можете позаимствовать оттуда код для RFM-анализа и попробовать его на своих данных.

​​#ltv

Оценка LTV с использованием Марковских цепей (Markov Chain).

Тут мы уже начинаем приближаться к чему-то более интересному. В данной заметке я сознательно возьму только простой случай использования Марковской цепи (пока не залезая в методы Монте-Карло, уж извините). 

Начнем с того, а что такое вообще эта ваша Марковская цепь? 

Для простоты определим Марковскую цепь в виде последовательности событий, в которой каждое последующее событие зависит от предыдущего (и только от него). То есть в каждый момент времени наш следующий шаг зависит только от нашего нынешнего положения (картинка для понимания).

Мы можем записать нашу матрицу вероятностей перехода между состояниями (она называется матрицей перехода, обозначим ее P). В качестве состояний могут быть время с последней покупки/частота покупок, тип подписки и т.п. (либо сочетание факторов). И мы можем записать вектор прибыль - маркетинговые затраты для каждого n-го состояния (обозначим G). То есть, если упрощать, то мы можем записать, сколько приносит каждый пользователь в некотором состоянии. Например, мы можем потратить какую-то сумму, чтобы сдвинуть пользователя в другое состояние. И можем оценить, сколько прибыли генерирует каждое состояние.

Тогда получим, что значение P*G будет показывать нам вектор ожидаемых чистых прибылей через один период времени. P^2 * G через два и т.д. В итоге, получим, что LTV у нас будет суммой ожидаемых прибылей за несколько периодов времени. Добавив дисконтирование, мы получаем требуемую оценку с учетом “стоимости” денег для нас в каждый момент времени.

Финальная формула на картинке (там немного другое обозначение для вектора G, он там показан буквой ню). 

В дополнение прикладываю пример реализации расчета на основе Марковской цепи с использованием RFM анализа для получения состояний пользователей. Можете позаимствовать оттуда код и попробовать применить к своим данным.

Часто-заголядывающая рубрика в моем бложике - про карьеру.
Читая книжку Staff Engineer, зашел к автору в блог и наткнулся на клевую заметку про карьерные решения. Актуально в текущих условиях “кризиса”.

- Во-первых, вы же знаете, что сейчас рецессия, кризис, и не только в мире, но и в айтишке. Хоть дебаты идут, “а вообще мы в рецессии?” и “А сколько она продлится?”, статистика говорит о том, что такие события длятся ±15 месяцев. То есть ориентируемся на конец 2023 года. Что мы можем с этим сделать?

- На любой позиции можно сделать приоритетом деньги, “скорость и режим работы”, собственное обучение, престиж или работу с людьми. Возможно, если вам сейчас комфортно, стоит сфокусироваться на обучении и на работе с классными людьми, чем в неспокойное время менять работу ради максимизации собственной прибыли?

- Если все равно хочется максмимизировать свой доход, помните, что даже FAANG компании заметно потеряли в компенсации, ибо существенная часть их компенсаций это стоки, а стоки сейчас на дне. Престиж тоже сюда.

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

Combining the last few points: my general advice to folks would be to stay where you are as long as you’re reasonably happy day to day and feel like you’re learning at a good rate. Even if your effective compensation has declined a bit, it’s very hard to determine if the compensation at any other company will hold up either. Don’t get me wrong, if you’re unhappy for non-compensation reasons, then of course you should find another role. Well, unless you’re unhappy because the company is more focused on short-term profitability, because pretty much anywhere you go right now will have that orientation. Referring back to the first point, this isn’t the new normal, just a difficult ~15 month period to navigate

#ltv

Beyond Customer Lifetime Valuation: Measuring the Value of Acquisition and Retention for Subscription Services

В этот раз текст получился большой, потому привожу ссылкой на telegraph

https://telegra.ph/Beyond-Customer-Lifetime-Valuation-Measuring-the-Value-of-Acquisition-and-Retention-for-Subscription-Services-06-28

​​#ltv

Оценка посредством моделирования выживаемости.

При некотором размышлении, мы можем представить наш показатель LTV в таком виде, где для каждого момента “жизни” пользователя у нас есть вероятность того, что к моменту T он все еще с нами и прибыль от клиента к моменту T. 

Тогда мы можем использовать для вероятности “выжить” модели, типично применяемые в страховании, то есть оценить вероятность “дожития” пользователя до некоторого наперед заданного момента. А прибыль можно будет взять в виде усредненной прибыли для пользовательского сегмента, либо использовать некоторую регрессионную модель оценки.

Итак, давайте поговорим про анализ выживаемости.

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

Здесь стоит отметить, что обычно при анализе данных о “выживаемости”, мы имеем не совсем полные данные, т.к. мы не всегда видим для каждого пользователя момент наступления события (к примеру, отписки). Это может происходить из-за того, что на момент анализа мы еще не знаем исхода, либо из-за потери данных (к примеру, из-за того, что у пользователя потерлись cookies). Соответственно, такие данные называются “цензурированными” данными. 

Ок, с общими понятиями мы разобрались. Теперь начинается самое интересное. Мы должны записать функцию выживаемости, которая определяется, как вероятность, что человек “проживет” от начального момента до момента времени T. И вот здесь уже становится не так просто. Но давайте разбираться.

Обычно, для оценки функции выживаемости используется оценка Каплана-Мейера. Предположим, что события у нас независимы (что логично, вряд ли пользователи имеют зависимое друг от друга поведение). Мы можем записать вероятность “выжить” в некоторый момент времени t, как 1 - (число наступивших событий / число оставшихся “в живых”). Соответственно, мы можем построить оценку суммарной вероятности “выжить” от начального момента до момента T, которая будет произведением вероятностей для каждого момента до T. То есть на шаге 0 у нас будет 1, на шаге 1 уже 1 - (число наступивших событий / число оставшихся “в живых”) для шага 1, для шага 2 это уже будет вероятность шага 1 * (1 - (число наступивших событий / число оставшихся “в живых”) для шага 2) и т.д. вплоть до нуля.

Тут мы подходим к понятию функции риска. По сути, функция риска описывает противоположное - не риск “выживания”, а риск наступления события. Функцию риска можно записать через функцию выживаемости, в виде H(t) = -log(S(t)). 

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

Возвратимся к исходной теме. Весь этот мат. аппарат можно применить для описательного сравнения “выживаемости” и оценки LTV разных групп, а также для прогнозирования “выживаемости” на основе модели Кокса и выявления наиболее важных для этого признаков.

В итоге, по признакам пользователя мы сможем предсказывать его LTV (оценив вероятность того, что он с нами останется и прибыль от него за все периоды времени). Здесь добавлю ссылку на код с примером анализа.

#ltv

Оценка с использованием Pareto/NBD модели и ее друзей.

Чтобы сделать пост более читабельным, добавлю его ссылкой на telegraph.

https://telegra.ph/Ocenka-s-ispolzovaniem-ParetoNBD-modeli-i-ee-druzej-07-24

500!

Спасибо всем, кто меня читает. Мне очень приятно ;)

* картинка сделана посредством stable diffusion (модно, стильно, молодежно) *

АБ-тесты - это не только ценный мех… Но еще и процессы.
Цикл постов про АБ-тестирование. Пост 1.

О математических нюансах АБ-тестирования есть много замечательной литературы, подборку которой мы дадим в конце этой серии постов.

Но почти нигде нет информации о том, каким образом в компаниях выстраивать сам процесс применения АБ-тестирования. За исключением отдельных отраслей (игры, интернет-коммерция), где уже сформировались зрелые практики.

При этом для офлайн-бизнеса внедрение АБ-тестирования во многом организационная, а не математическая проблема.

На первый взгляд, кажется, что достаточно отработать методику АБ-тестирования на уровне объектов тестирования (например, точек продаж для офлайн ритейла). Но на практике правильно выстроить бизнес-процесс применения АБ и позиционирования его внутри компании едва ли не сложнее, чем создать правильную статистическую методологию.

С точки зрения бизнес-процессов компании АБ-тестирование - часть инвестиционного цикла проектов и продуктов, за который отвечает финансовое подразделение. Внутри инвестиционного цикла АБ-тестирование – это один из способов дизайна и оценки пилотных экспериментов компании для того, чтобы принять решение о дальнейших инвестициях в проект.

Обобщенно инвестиционный цикл можно разбить на этапы:

- Заявка на проект. Процедура отбора проектов, в которые компания готова инвестировать. Здесь АБ-тестирование может участвовать, дополняя критерии отбора проектов возможностью проведения статистически корректного АБ-теста.

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

- Инвестиционный комитет по процедурам компании для решения о том, идет ли проект дальше по циклу.

- Разработка MVP. Разрабатывается прототип решения.

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

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

Как тут помогает АБ тестирование: математически корректная методика дизайна и оценки результатов экспериментов дает возможность сделать правильные выводы о ценности разработанного MVP.

- Инвестиционный комитет по процедурам компании для решения о том, идет ли проект дальше по циклу.

- Ролл-аут. Осуществляется внедрение проекта на все целевые объекты в масштабе компании.

- Пост-инвест анализ. Чтобы отслеживать эффективность инвестиционной деятельности, компании нужно оценить итоговый финансовый эффект ролл-аута. Какие статистические инструменты доступны?

Прежде всего - контрфактические методы причинно-следственного анализа. Мы писали о них в начале года (тут, тут и тут).

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

Эту структуру полезно иметь в виду при интеграции АБ-тестирования в бизнес-процессы компании.

В следующих постах цикла речь пойдет о детальном бизнес-процессе дизайна и оценки пилота, а также о том, какие этапы в нем закрывает математическая методика АБ-тестирования, а какие этапы нужно дополнительно продумать и упорядочить при ее внедрении.

#business #ab_testing

#ltv #AB #statistics

Проведение A/B тестов над LTV.

Учитывая, что LTV - метрика с достаточно долгим сроком прогнозирования (от месяцев до лет), очевидным образом у нас может возникнуть вопрос - а как это тестировать то? Кажется, что при скорости A/B тестов 1 раз в полгода-год, конкуренты легкой лунной походкой обойдут нас на всех поворотах и вырвутся в лидеры. Потому надо что-то делать. 

В принципе, проблему A/B тестирования LTV можно свести к более общей проблеме оценки Long-term эффектов. Этой проблеме даже посвятили отдельный раздел в paper’е Рона Кохави и Лукаса Веермеера “Top Challenges from the first Practical Online Controlled Experiments Summit”. Давайте посмотрим на предлагаемые индустрией решения этой проблемы.

Итак, что же нам предлагают исследователи из разных компаний:

- Отложенная выборка.
Нам предлагается “отложить” на достаточно долгое время некую часть пользователей, на которую мы не будем применять воздействий. В принципе, подход рабочий (мы на одном из предыдущих мест работы его применяли), но сложно реализуемый, если у вас есть хоть какой-то сетевой эффект. Например, часть пользователей будет видеть рекомендательную систему и расскажет своим друзьям. А у них такой системы нет. И тогда поддержке придется туго, если они захотят объяснить, отчего же такое произошло.
Вторая проблема - ротация пользователей. Если мы все не решимся “замораживать” пользователя на год, то у нас должна появиться логика ротации пользователей, то есть перемещения их в “заморозку”, последующего возвращения и правил попадания в эту группу, что может быть не так просто.

- Прокси-метрики.
Простой вариант - мы смотрим не на основную метрику, а на какой-то промежуточный показатель, который, как нам кажется, хорошо определяет поведение основного показателя. Например, для LTV это может быть retention, или user-engagement. То есть, вовлеченность пользователя может неплохо отражать его склонность тратить на нас деньги.
Но минус тут очевидный - “correlation may not imply causation”. Т.к. зависимость между метриками может и не быть реальной причинно-следственной связью. И тогда выводы на proxy не будут вести к улучшению главного показателя. 

- Моделирование на основании частичных данных.
Такой подход используется в Google. Давайте запускать кусочки эксперимента через некоторые периоды времени. И потом сравнивать, как постепенно затухает наша метрика при удалении во времени от эксперимента. А дальше мы можем выучить какую-либо кривую, которая аппроксимирует наше затухание, и учитывать это при предсказании эффектов от экспериментов.
Тут тоже не без проблем. Процесс такого запуска весьма непростой и сделать очень большие временные лаги между запусками вряд ли выйдет. Плюс, у нас добавляется еще и моделирующая составляющая, то есть тут нужно все делать аккуратно. Ну и не забывать о смещении, ибо есть вероятность обучить что-то и нарваться на смещенные предсказания.

- Суррогаты.
Можно сказать, что это своего рода расширение над прокси-метриками. В данном случае, мы ищем статистические суррогаты, которые находятся в графе причинно-следственных связей между treatment и outcome. И, что главное, имеют следующее свойство: treatment и outcome условно независимы при условии суррогата. При этом, нам не обязательно использовать только одну прокси-метрику для построения суррогата - мы можем построить вектор прокси-метрик, который будет иметь требуемое свойство.
Соответственно, из минусов у нас то, что нам надо строить какую-то причинно следственную модель, отбирать прокси-метрики в суррогат, пытаясь учесть все нужные прокси (что не так просто, как может показаться на первый взгляд).

Чтобы чуть углубитьcя в тему, давайте рассмотрим какой-нибудь из вариантов решения проблемы оценки Long-term эффектов. В следующей заметке я опишу использование статистических суррогатов на основе статьи от LinkedIn.

АБ-тесты. Интеграция в процесс пилотирования. Как выглядит типовой бизнес-процесс без АБ.
Цикл постов про АБ-тестирование. Пост 2.

В предыдущем посте цикла мы верхнеуровнево разобрали инвестиционный цикл проектов в офлайн-бизнесе и кратко поговорили о том, в какие его этапы и каким образом встраивается математическая методика АБ-тестирования.

В частности, мы определились, что наиболее важный этап инвестиционного цикла для АБ-тестирования - это этап пилотирования для понимания финансового эффекта от MVP какого-либо проекта.

Теперь предлагаем сделать zoom в этот этап и разобрать его детально, поняв, как именно в него может быть встроена методика АБ-тестирования, и что нужно предусмотреть в рамках интеграции.

Итак, бизнес-процесс пилота - еще до всяких АБ-тестирований - как правило, выглядит так:

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

- Согласование ожиданий бизнеса по пилоту с финансовой службой. Все ожидания должны пройти контроль подразделения, отвечающего за инвестиционный цикл подобных проектов в финансовой службе.

- Определение географии пилота и выбор объектов для тестирования (пилотная группа, внедряем MVP) и сравнения (контрольная группа, ничего не внедряем). Как правило, выбирается экспертно, из соображений удобного и наименее затратного проведения пилота. Для небольших проектов может использоваться 1 выделенный для пилотов объект.

- Согласование запуска пилота с операционной службой. Изменения в пилотной группе объектов должны быть согласованы с операционным подразделением. Коллегам непосредственно на местах необходимо будет обеспечить исполнение пилота.

- Проведение пилота. Реализация MVP на местах в пилотной группе при отсутствии изменений в контрольной группе. Если эти понятия, конечно, выделяются при отсутствии АБ-тестирования. Надо сказать, что чаще всего, выделяются.

- Оценка результатов пилота. При отсутствии АБ, чаще всего применяется простая разность результатов пилотной группы с контрольной по целевой метрике (продажи, количество клиентов, маржа, и т.п.). Используются как темпы роста, так и абсолютные значения. Почему подобное ручное сравнение это плохо и что должно улучшить АБ (и как объяснить это бизнесу!), мы поговорим в дальнейших постах цикла. Сейчас для нас важно то, что без применения статистики (aka внедрения АБ) компания берет на себя огромный риск финансовых потерь за счет некорректных оценок пилотных экспериментов. Фактически, идет по инвестиционному циклу вслепую.

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

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

#business #ab_testing

АБ-тесты. Интеграция в процесс пилотирования. Риски типового бизнес-процесса без АБ
Цикл постов про АБ-тестирование. Пост 3

Бизнес-процесс, описанный в предшествующем посте цикла, связан со значительными рисками для компании:

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

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

- Нет единой базы пилотов. При проведении пилотов далеко не всегда контролируется отсутствие изменений в контрольной группе объектов. А если эксперименты проводятся в 1м объекте, выделенном для тестов, нередка ситуация, когда в одно время может проходить и два, и три, и пять пилотов. Результаты проведения каждого из них по отдельности, как нетрудно догадаться, в такой ситуации, оценить будет невозможно.

- Нет единой методики/правил экстраполяции результатов пилота для расчета финансового эффекта на все объекты. Даже при суперкорректной статистической оценке результатов пилота на основе АБ, финальное решение об инвестициях в проект может оказаться некорректным, если нет правил его масштабирования на всю сеть. Получили +1% к выручке на 5 объектах. Можем ли сказать, что при ролл-ауте проекта, для всей сети будет +1% к выручке? Была ли выборка репрезентативна для всей сети? Можем ли назвать результаты пилота робастными? Например, 5 объектов пилота могли быть расположены в Сибири, а основные объекты компании расположены в Центральных регионах.

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

В следующем посте цикла мы поговорим о том “А что делать-то?”. Как подумать о рассмотренных рисках при интеграции АБ-тестирования, а также учесть особенности бизнес-процесса.

#business #ab_testing

Подытожим в одной картинке выводы последних двух постов цикла про АБ-тестирование: о бизнес-процессе пилотирования и его рисках.

P.S. Хочется выразить большую благодарность моим замечательным коллегам Анастасии Комович и Эдуарду Григоряну, которые вместе со мной в разное время долгие часы формировали концепцию внедрения АБ-тестирования в бизнес-процессы компаний. Без них понимания бизнес-процессов и того, что со всем этим делать, не состоялось бы.

#business #ab_testing