Фінальний кейс: незрозумілий сплеск

Коли метрика стрибає, першою на думку зазвичай спадає історія, яку хтось хоче розповісти. Розслідування сплеску (spike investigation) замінює її списком. Майже кожна раптова зміна походить з однієї з чотирьох родин:

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

Кожна родина лишає свій слід, тож для кожної є перша перевірка: трекінг розриває зв'язок між подіями й людьми (порівняй кількість подій з унікальними користувачами), трафік видно в одному каналі, зміна продукту видна там, де її випустили, і не видна деінде, а зовнішня подія змінює, хто приходить і коли.

Роби перевірки від найдешевшої, записуй, що кожна підтверджує чи відкидає, і продовжуй, поки не лишиться одне пояснення.

«+156%» нічого не каже, поки не відомо, відносно чого. Реєстрації мають тижневий ритм: вихідні й понеділки відрізняються від середини тижня. Чесна база порівнює кожен день сплеску з тим самим днем тижня в недавніх нормальних тижнях, усереднено.

Halves, субота 12 – понеділок 14 вересня: суботи 29 серпня й 5 вересня в середньому дали 269,5 нових користувачів, неділі — 272, понеділки — 244, тож база для трьох днів — 785,5.

Далі міряй людей, а не події: як показує урок Загальна кількість, унікальні користувачі й пастки підрахунку, рядки рахують дії, а унікальні id — людей. Дашборд рахує signup_events: 2 014, тобто 2 014 ÷ 785,5 − 1 = +156,4%. Унікальні нові акаунти, new_users: 485 + 478 + 431 = 1 394, тобто 1 394 ÷ 785,5 − 1 = +77,47%. Ці числа мали б збігатися; коли вони розходяться, сам розрив — підказка.

Зміна у відсотках = сплеск ÷ база − 1. Подавай її з базою, описаною словами: «+77% унікальних нових користувачів відносно тих самих днів тижня за два попередні тижні». Дві звички тримають число чесним: ніколи не порівнюй вихідні з буднями й ніколи не пускай в базу день, який уже може містити проблему.

База визначає розмір сплеску, тож обирай її, ще не бачивши відповіді, і пояснюй чому.

Три правила:

1. Ті самі дні тижня. Для сплеску із суботи по понеділок потрібні суботи, неділі й понеділки для порівняння. Середина тижня нижча чи вища з причин, які не мають стосунку до сплеску.
2. Чисті дні. База має бути з часу до того, як почалося будь-що з журналу змін. У Halves Android 5.2 почав розгортатися в четвер 10 вересня й уже дублював події 10-го й 11-го. Дні прямо перед сплеском забруднені.
3. Більше ніж один тиждень. Усередни два чи більше порівнянні тижні, щоб один дивний день не задавав планку.

Що буває інакше: порівняння 12–14 вересня із середою 9 – п'ятницею 11 вересня дає +91,5% нових користувачів і +141,2% подій. Перше змішує будні зі святковими вихідними; друге ще й пускає дублікати подій у базу.

Правильна база тут: ті самі дні тижня 29–31 серпня й 5–7 вересня, 785,5 в обох стовпцях, бо дублікатів тоді ще не було.

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

Halves, 12–14 вересня: iOS 1,00 у всі три дні, як завжди; Android 2,00 у всі три дні. Події мінус нові користувачі: 2 014 − 1 394 = 620 зайвих подій, усі на Android, проти нуля в базові дні. Це 620 із 1 228,5 надлишкових подій, 50,5% стрибка на дашборді.

Діагноз: новий екран реєстрації на Android надсилає signed_up двічі. Половина сплеску, який побачила Maya, — помилка підрахунку.

Двох речей варто уникати. Не зупиняйся тут: унікальних нових користувачів однаково стало на 77% більше на обох платформах, тож трекінг пояснює зайві події, а не зайвих людей. І не звинувачуй іншу платформу: стабільні 1,00 на iOS саме й показують, котра сторона зламана.

Тривале виправлення — визначення, що рахує людей (унікальні нові акаунти), плюс щоденне сповіщення про кількість подій на користувача за платформою й версією.

Підозрювана причина стає переконливою, коли ефект іде за нею в часі й у дозі: починається, коли починається зміна, росте, коли зміна охоплює більше людей, і зникає, коли зміну скасовують.

Реліз на Android — зручний випадок, бо він розгортався кроками. За журналом змін 5.2 10 вересня охопив близько 30% реєстрацій на Android, 11-го — 70%, а з 12-го — усі. Якщо кожна реєстрація в 5.2 записує дві події, подій на нового користувача має бути приблизно 1,3, 1,7, а потім 2,0. Дані: 138 ÷ 106 = 1,30 10-го, 182 ÷ 107 = 1,70 11-го, 2,00 з 12-го по 15-те, 1,50 16-го, коли опівдні вийшов 5.2.1, і знову 1,00 від 17-го.

Такий збіг — значно сильніший доказ, ніж «сплеск був після релізу». Той самий тест показує й те, чого реліз не зробив: iOS без релізу виріс у нових користувачах так само, як Android.

Користуйся ним щоразу, коли зміна розгортається поступово — відсотками, регіонами чи версіями.

Коли трекінг пояснено, питання стає таким: звідки прийшли справжні додаткові люди? Більшість відповіді дають два розрізи.

За каналами — щоб перевірити трафік. Кампанія чи розміщення в магазині видно в тому каналі, де вони працювали. У Halves майже весь надлишок дають запрошення, а платні канали стоять на місці (відносно бази: запрошення +555,5, соцмережі −2, пошукова реклама −2,5). Бюджети теж не змінювалися, тож жодна кампанія цього не зробила.

За платформами — щоб перевірити зміну продукту. Новий екран реєстрації вийшов лише на Android, тож iOS — природна група порівняння. Якби екран конвертував більше відвідувачів, Android зріс би більше. Не зріс: нові користувачі iOS +77,7%, Android +77,1%. Тож реліз пояснює зайві події, а не зайвих людей.

«У реєстраціях нічого не видно» — це не «екран нічого не дає»: малий ефект може ховатися всередині великого зовнішнього коливання, і виміряти його може лише A/B-тест екрана.

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

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

Halves, унікальні нові користувачі 12–14 вересня: 1 394 проти бази 785,5, надлишок 608,5. За каналами залучення:

• запрошення: 902 проти 346,5, +555,5;
• пошук у магазині: 225 проти 167,5, +57,5;
• соцмережі: 177 проти 179, −2;
• пошукова реклама: 90 проти 92,5, −2,5.

Чотири частини дають 608,5. Самі запрошення привели 555,5 ÷ 608,5 = 91,3% додаткових людей. Це вказує не на щось, що зробив Halves (бюджети не змінювалися, реліз не діяв), а на щось, що змусило людей створювати групи й запрошувати друзів.

Розрізай за тим виміром, що розділяє підозрювані причини: канал — для трафіку, платформа й версія — для продукту й трекінгу, тип групи чи країна — для зовнішніх подій. Подавай частки, а не лише найбільший рядок, і не викидай від'ємні частини: вони показують, які канали нічого не дали.

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

Halves: 12–14 вересня були святковими довгими вихідними в кількох його найбільших ринках. 47% нових користувачів днів сплеску почали в групі для поїздки проти 10% у базові дні, а 91% додаткових користувачів прийшли через запрошення. Це пасує до «друзі створювали групи для поїздок на свята й запрошували одне одного», але не доводить цього: того ж вікенду могло статися щось інше.

Добра записка розділяє три рівні впевненості:

• встановлено: 620 дублікатів подій з Android 5.2;
• відкинуто: платна кампанія, новий екран як джерело додаткових людей;
• найімовірніше, але не доведено: святкові вихідні, тож підвищувати через них осінній прогноз не варто.

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