Весенняя эра открыта 😎

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

Такс пойдем теперь за вопросы продуктовые поговорим 👇

Тебе дают две таблицы - users и events. И 20 минут на задачу:

«Посчитай батенька retention по когортам M0–M3»

И вот на этом ловят ступор.
А с чего вообще стартовать? 🤔

Проще всего - не с SQL, а с картинки в голове. Представь спортзал.
100 человек купили абонемент - это твоя когорта.
Дальше обычно эту когорту принимают за 100%. Это и есть M0.
Но вот нюанс: это не закон природы, а просто негласное соглашение.
На следующий день пришли 60 человек - Day 1 = 60%.
Через неделю пришли 40 - Day 7 = 40%.

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

1️⃣ Junior-уровень - понять, сколько людей вообще пришло в каждую когорту

SELECT
  DATE_TRUNC('month', registration_date) AS cohort_month,
  COUNT(DISTINCT user_id) AS new_users
FROM users
GROUP BY 1
ORDER BY 1;

Если уже здесь ошибка, все суши весла. Потому что DATE_TRUNC и DISTINCT - это база продуктового блока.
Хотя бы для PostgreSQL и похожих диалектов.

2️⃣ Следующий уровень - понять, кто вернулся

WITH cohort_dec AS (
  SELECT user_id, registration_date
  FROM users
  WHERE registration_date >= '2023-12-01'
    AND registration_date < '2024-01-01'
)
SELECT
  COUNT(*) AS cohort_size,
  COUNT(DISTINCT CASE WHEN event_date = registration_date + 1 THEN user_id END) AS day1,
  COUNT(DISTINCT CASE WHEN event_date = registration_date + 7 THEN user_id END) AS day7
FROM cohort_dec u
LEFT JOIN events e ON u.user_id = e.user_id;

Тут под ноги бросаются грабли 🤔

Такой код нормален, если даты у тебя хранятся как DATE, без времени.
Но если это TIMESTAMP, простое равенство может ломать расчёт.
Потому что у одного событие в 2023-12-08 00:01, у другого в 2023-12-08 19:42, и формально это уже не то же самое значение.

Значит, нужно либо приводить к дате, либо считать через диапазоны.
То есть логика всегда одна и та же:
✅ зафиксировал когорту → посмотрел, кто вернулся

Для M1, M2, M3 всё почти то же самое, но есть принципиальный момент:
👉 сравнивают не просто даты, а смещение по календарным месяцам относительно месяца регистрации ( да сложно звучит сейчас объясню )

То есть не +30 дней. Месяцы разной длины, поэтому такой расчёт съезжает.
Для месячного retention смотрят смещение по календарным месяцам, а не просто прибавляют 30 дней.

❌ Где еще грабли поджидают

1️⃣ Считают события вместо людей
Один пользователь сделал 5 событий.
И внезапно retention у тебя больше 100%.
Значит, ты считаешь не возврат людей, а активность.

2️⃣ Ставят INNER JOIN
И в выборке остаются только те, кто вернулся.
Все, кто отвалился, просто исчезают.
Получается красивая цифра. И полностью фальшивая картина.

3️⃣ Не фиксируют базу расчёта
Размер когорты обычно принимают за 100%, и уже от него считают всё дальше.
Если база у тебя гуляет, проценты превращаются в мусор.

А дальше начинается главная беда... тест на мышление и софты. Вот уж где самая тернистая тропа если мало опыта.
Потому что на собесе тебя не спросят:

«Как посчитать retention?»

А спросят:

«D30 упал. Почему?»

Приехали...И вот тут SQL уже никого не впечатляет.

✅ Нормальный ход мысли такой:
- разложить retention по когортам
- посмотреть каналы привлечения
- проверить activation
- понять, не ломался ли онбординг
- сравнить поведение до и после релизов
Можно копать еще глубже, но для старта достаточно этих основ.

❌ Ответ который сразу поставит крест на вашем диалоге

«Ну… retention снизился, потому что пользователи стали хуже возвращаться..»

Спасибо товарищ Капитан. Но это не ответ аналитика, а догадка.

Если простыми словами:
Retention - это не про SQL, это про поведение.
SQL - это просто лопата, которой ты выкапываешь цифру.

Если ты не можешь объяснить, почему люди перестали возвращаться,
то сами по себе твои проценты ни о чем не расскажут 🤷‍♀️

У вас бывали проблемы на продуктовом блоке? И вообще любо ли вам продуктовое направление или больше нравиться инженерная часть ? 👇

#собесы

@data_dzen 🙂

Магическое A/B-тестирование 😎

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

Но на практике именно тут и скрывается одна из главных ловушек.

Смысл A/B-теста не в одном лишь ответе на вопрос, выросла метрика или нет.
Куда важнее понять: можно ли вообще считать сей рост полезным для продукта 🤔

Разберём на простом примере.
Допустим, в городе есть кофейня. Долгое время она работает с одним меню, а потом решает его обновить. После этого выручка растёт 🔥

На первый взгляд всё ладно: хозяин доволен, цифры стали лучше.
Но если копнуть глубже, может оказаться, что выручка выросла только за счёт новых гостей, постоянные посетители стали приходить реже, а средний чек поднялся вместе с количеством жалоб 🤦‍♂️

И тут открывается истинна: смотреть только на одну метрику опасно.

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

Потому в A/B-тестах важно смотреть шире.
Вот несколько вещей, которые действительно нужно проверять.

1️⃣ Не сломали ли вы что-то рядом

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

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

2️⃣ Держится ли эффект во времени

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

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

С продуктом ровно та же история.
Посему важно смотреть не только на первые дни после запуска изменений, но и на то, что происходит дальше.

3️⃣ Одинаков ли эффект для разных групп пользователей

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

Именно поэтому полезно сегментировать результаты.

На что обычно стоит смотреть:
- Давность регистрации.
- Уровень активности.
- Пол и возраст.
- Тип пользователя или род деятельности, если платформа это позволяет.

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

Но и тут важно не переусердствовать ❗️

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

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

В итоге сильный анализ A/B-теста не сводится к выводу в духе «метрика выросла, значит всё хорошо».
Сильный анализ это ответ сразу на несколько вопросов:
- у кого именно выросла метрика;
- за счёт чего произошёл рост;
- не сломали ли вы что-то рядом;
и можно ли после этого раскатывать решение на весь продукт.

Вот тогда тест и впрямь радует глаз, а не создаёт красивую иллюзию роста.

А у вас от слова A/B тесты трясутся поджилки, али наоборот воодушевление испытываете ? 👇

#собесы

@data_dzen 🙂