Спрашивает меня как-то подруга-аналитик: «Слушай, как посчитать эффект от выкатки нового тарифа в новом городе? Чтобы посмотреть каннибализацию других тарифов». 

(Продукт существует, но в новом городе выкатили новый тариф, который уже раскатан в нескольких других городах)

😊 «А есть похожий город, где вы уже были раскатаны?» — спрашиваю я

👩‍💻 «Ну они сильно другие»

😊 «Окей, выкатывали ли вы на всех пользователей эту фичу?»

👩‍💻 «Исключали новичков — тех, кто сделал менее 10 пользований сервиса, — а так на всех, да»

😊 «Ага, супер. Тогда можно сравнить 2 группы и то, как они пользовались другими тарифами»

Тут важно сказать, что не стоит просто сравнивать пользователей «до порога» и «после порога». Человек, который пользовался сервисом 2 раза, и человек, который пользовался им 50 раз, очевидно, отличаются не только наличием нового тарифа. Они и без всякой выкатки могли бы по-разному пользоваться остальными тарифами.

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

8–10 использований ➡️ тарифа ещё нет
11–13 использований ➡️ тариф уже есть

Это уже гораздо более похожие пользователи. В идеальном мире единственное значимое отличие между ними — это доступность нового тарифа. А дальше смотрим, начали ли пользователи справа от порога реже выбирать старые тарифы.

И обязательно проверяем устойчивость результата: берём окно поуже — например, 9–10 vs 11–12, потом пошире — 7–10 vs 11–14. Если вывод каждый раз примерно один и тот же, доверия к нему становится сильно больше.

Если вам это что-то напоминает — да, это Regression Discontinuity Design, про который я уже писала в отдельном посте 👀

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

Спойлер, мой «псевдотест» не показал никаких аплифтов. Я проверила на разных границах (брала пользователей и поближе к границе, и подальше, разницы не было никакой), а у подруги-аналитика как раз такое исследование показало жёсткую каннибализацию других тарифов.

Дальше, конечно, стоит сделать обратный АБ, чтобы точно замерить негативный эффект на метрики других тарифов и получить данные для принятия решения. Ну или понять, что совсем всё плохо, и не катить тариф в этом городе :)

Вот так и поговорили.

Ну делитесь, а как бы вы попробовали обсчитать такой запуск?

1 октября пройдёт первый митап Trisigma в Ташкенте 🚀

Команда Trisigma собрала экспертов и коллег из TBC и Uzum, чтобы обсудить, как data-driven подход работает за пределами вайт-пейперов, в разных компаниях и разных контекстах.

➡️ Как культура экспериментов превращает продуктовую команду в data-driven, а не data-informed.

➡️ Как выстроить аналитику так, чтобы она помогала, а не мешала бизнесу.

➡️ Как в разных компаниях устроен процесс работы с данными — и почему в одной он работает как нужно, а в другой нет.

➡️ Как оценить экономический эффект от внедрения A/B-культуры в бизнесе.

И, конечно, будут говорить про A/B-инструменты в целом, в том числе про Trisigma: как она устроена, в каких компаниях используется уже сейчас. И к каким результатам эти компании пришли за последний год.

🔴 Регистрируйтесь на офлайн-встречу в Ташкенте или на онлайн-трансляцию 🔴

Я провожу собеседования аналитиков в Авито и часто вижу одну и ту же картину...

➡️ К нам приходят сильные ребята с интересным опытом, но переходим к кейсу — и аналитики начинают решать его с помощью метрик своего продукта, привычной логики и знакомых подходов.

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

➡️ Чтобы не стать заложником одного продукта, нужна насмотренность — та самая, про которую постоянно говорят стилисты.

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

С продуктовыми кейсами так же.

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

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

Самый очевидный способ прокачать насмотренность — это поработать в разных компаниях и с разными продуктами. Но менять работу ради этого совсем не обязательно.

➡️ Вот пара способов прокачки насмотренности от меня:
🔍 смотреть конференции и разборы кейсов других компаний;

🔍 подписаться на каналы с видео от аналитиков, например, на AvitoTech;

🔍 решать кейсы с собеседований и кейс-чемпионатов;

🔍 собирать собственное решение и только потом смотреть чужое;

🔍 разбирать не только выбранные метрики, но и логику: почему они подходят этому продукту именно сейчас.

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

Тогда привычный набор метрик перестаёт быть единственным приличным костюмом в шкафу 💅