Структура трафіку і сезонність

У порівнянні «до і після» першим треба виключити зміну того, хто прийшов. Утримання нових користувачів Halves на другому тижні впало з 37,0% у червні до 30,3% у липні, одразу після версії 5.0.0. Сама метрика в обох місяцях однакова (нові користувачі, дні 8–14, кожна когорта завершена), тож змінитися міг лише натовп усередині неї.

Це структура трафіку (traffic mix): частки нових користувачів за каналом і за типом першої групи. Сегменти утримуються дуже по-різному. У червні квартири мали 43,25% на 8–14-й день, пари — 40,29%, а поїздки — лише 16,46%, бо група для поїздки закінчується разом із відпусткою.

Тож дивися на частки раніше, ніж на підсумки. Поїздки становили 407 із 2033 червневих реєстрацій, 20,02%. У липні — 1095 із 2952, 37,09%: майже вдвічі більше.

Це зсув структури (mix shift), описаний в уроці Обсяг, якість і парадокс Сімпсона: підсумок рухається, хоча жоден сегмент не змінився. Тут виріс сегмент із низьким утриманням, тож середнє може впасти, навіть якщо кожен сегмент поводиться як раніше. Перевіряй це щоразу, коли метрика стрибає одночасно із сезоном, кампанією чи новим каналом.

Два тижні від 13 липня банк платив власникам студентських карток 5 дол. за реєстрацію в Halves і створення групи. Ці користувачі прийшли як partner_promo: 393 у тиждень з 13 липня і 395 у тиждень з 20 липня, разом 788. Від 2952 липневих реєстрацій це 788 ÷ 2952 = 26,69%, понад чверть місяця.

Це стимульовані реєстрації (incentivized sign-ups): люди, які прийшли по винагороду. Дехто справді мав оренду, яку треба ділити; багато хто створив групу лише заради умови. Лише 153 із 788 були активні на 8–14-й день, тобто 19,42%, менше, ніж у будь-якому звичайному червневому каналі (29–41%).

У червні такого каналу не було, тож цим користувачам немає з ким порівнюватися. Тому перший крок порівняння порівнюваного — відкласти їх: липень без рядків промоакції — це 741 ÷ 2164 = 34,24% проти 36,99% у червні.

Відкласти — не значить сховати. Промоакцію показують окремим рядком, оцінюють за її власним питанням (скільки користувачів, що досі тут, купили ці гроші?) і тримають поза порівнянням, яке вона лише спотворила б.

Без промоакції липень дає 34,24% проти 36,99% у червні: досі нижче. Розрив, що лишився, дають додаткові поїздки, тож наступний крок — порівнювати всередині кожного типу групи: квартири з квартирами, пари з парами, поїздки з поїздками.

Для квартир у липні (лише звичайні канали): користувачів 348 + 249 + 179 = 776, активних 177 + 104 + 62 = 343, тож 343 ÷ 776 = 44,20%. Квартири в червні: 436 ÷ 1008 = 43,25%. Інші сегменти рухаються так само: пари 40,29% → 43,68%, поїздки 16,46% → 19,63%.

Кожен сегмент у липні трохи вищий, а підсумок нижчий. Така картина — сегменти вгору, підсумок униз — характерна ознака зсуву структури. Це той самий ефект, що й у когортній таблиці, де випадіння слабкої когорти піднімає середнє; тут додавання слабкого сегмента його опускає.

Два застереження. Частки сегментів спираються на меншу кількість людей (пари в липні — 522 особи), тож невеликі різниці лежать у межах шуму; читай їх як «жоден сегмент не погіршився», а не як точні виграші. І обирай сегменти, які правдоподібно рухають метрику, як-от тип групи й канал, а не ріж дані, доки щось не стане цікавим.

Сезонна база — це підсумок, який слід було б очікувати, якби кожен сегмент зберіг стару частку, а змінилася лише структура. Вона дає число тому, наскільки сезон сам по собі мав би зрушити метрику.

Частки червня за типом групи: квартири 43,25%, пари 40,29%, поїздки 16,46%. Звичайні реєстрації липня (без промоакції): 35,9% квартир, 24,1% пар і 40,0% поїздок. Тож:

Очікуваний липень = 0,359 × 43,25 + 0,241 × 40,29 + 0,400 × 16,46 = 15,53 + 9,71 + 6,58 ≈ 31,8%

Сама лише структура опустила б червневі 37,0% приблизно на п'ять пунктів. Звичайні користувачі липня насправді мали 34,24%, вище за цю базу. Тож липневий спад сезон пояснює з запасом.

Це дзеркальне відображення показника з вирівняною структурою (ставки сегментів липня, зважені за червневою структурою). Один бере старі частки й нову структуру («що передбачає сезон»); інший — стару структуру й нові частки («яким був би липень за червневого трафіку»). Обидва питають, яку частину зміни дає структура.

Сезонність (seasonality) — закономірність, що повторюється за календарем. Для Halves літо приносить групи для поїздок, а такі групи затихають, щойно відпустка скінчилася. Тож липневий спад утримання на другому тижні, найімовірніше, повертатиметься щороку, хоч із релізом, хоч без.

Це змінює, яке порівняння має сенс. Червень проти липня змішує реліз із сезоном. Три кращі варіанти, від найпростішого до найсильнішого:

1. Ті самі тижні рік тому. Липень 2026 проти липня 2025 мають спільний сезон; лишаються зміни за рік, і реліз серед них.
2. Зафіксуй структуру. Перезваж за еталонною структурою або порахуй сезонну базу, щоб прибрати зсув у бік поїздок.
3. Читай кожен сегмент окремо. Квартири проти квартир значно менш сезонні, ніж підсумок.

Порівняння рік до року має свої пастки: торішній липень міг мати іншу промоакцію, інший продукт чи іншу кількість тижнів із канікулами. Тож це краще порівняння, але не досконале.

Незмінне правило: не читай «в лоб» два сусідні місяці, якщо один із них — сезон.

Бонус за реєстрацію легко подати вигідно: 788 нових користувачів за два тижні, понад чверть липня. Але корисне питання — скільки користувачів, які досі користуються Halves, купили ці гроші.

З 788 користувачів промоакції на 8–14-й день були активні 153: 19,42%. Порівняй це з тим, що той самий бюджет купив би деінде, в утриманих користувачах, а не в реєстраціях, і угода може виглядати зовсім інакше.

Три звички спрощують читання наступної промоакції:

• Позначай її з першого дня. Дай пропозиції власний код реєстрації, щоб кожен користувач із бонусом мав partner_promo у даних. Без позначки користувачі промоакції змішуються зі звичайними каналами й непомітно тягнуть їх униз.
• Оцінюй за утриманими (активні на другому тижні чи пізніше), а якщо відомі витрати — за вартістю одного утриманого користувача.
• Не накладай її на реліз. Промоакцію й реліз, що стартують у ті самі два тижні, потім важко розділити; погоджуй дати з продуктовою командою.

Жодне з цього не каже, що промоакція була поганою: частина з цих 153 може стати постійними користувачами. Це каже, за чим угоду слід міряти.

Показник з вирівняною структурою (mix-adjusted rate) робить «до і після» чеснішим, але прибирає лише ті відмінності, за якими ти ділиш. Сам показник описано в уроці Обсяг, якість і парадокс Сімпсона: ставка липня в кожній клітинці, зважена часткою цієї клітинки в червні. Тут клітинки — канал × тип першої групи, рядки промоакції спершу відкладають (у червні таких клітинок немає), і липень дає 38,89% проти 36,99% у червні.

Більшу частку поїздок враховано, бо поїздки отримують червневу вагу. Хвилю промоакції враховано, бо її відклали. Усе, що не є стовпцем таблиці, лишається всередині числа:

• шкільні канікули й літня погода;
• кампанія конкурента чи будь-що інше на ринку;
• звичайна випадковість: у кожній липневій клітинці лише приблизно 120–380 користувачів.

Тож показник з вирівняною структурою — чесніше порівняння, але не причинне. Він може показати, що падіння пояснює зміна того, хто прийшов. Він не може перетворити порівняння «до і після» на виміряний ефект релізу.

Порівняння «до і після» часто досить сильне, щоб відкинути твердження, і надто слабке, щоб його довести. Тут без промоакції кожен тип групи в липні трохи вищий, а за червневої структури липень дає 38,89% проти 36,99%. «В лоб» липень виглядав на 6,7 пункта гіршим; при порівнянні порівнюваного — приблизно на 1,9 пункта кращим.

Твердження має відповідати доказам:

• Підтверджено: липневе падіння пояснює те, хто реєструвався (більше поїздок, хвиля промоакції); при порівнянні порівнюваного ніщо не вказує на шкоду від 5.0.0. На цих даних не відкочуємо.
• Не підтверджено: «5.0.0 додала 1,9 пункта». Відпустки, спека й випадковість досі всередині числа.
• Теж хибно: «без A/B-тесту таблиця нічого не каже». Вона не доводить причини, але може відкинути одну: що падіння спричинив новий екран.

Як це складається докупи: відклади те, що не має пари, порівнюй всередині сегментів, тримай структуру незмінною, перевір сезон — тоді «до і після» зможе відкинути історію, але рідко її доведе. Далі — Зміщення відбору: хто робить X, той краще утримується: коли користувачі самі обирають свою групу.