Визначення метрики: одне правило, одне число

Дашборд Maya показує 6 активних користувачів у середу, 3 червня; таблиця Theo — 7. Звичний рефлекс — шукати запит із багом. Зазвичай його немає.

«Активні користувачі в середу» — це назва. Вона звучить точно, але лишає відкритим кожен вибір, що змінює число:

• яка дія зараховує людину: будь-яка подія чи відкриття застосунку;
• що рахують: людей, пристрої чи рядки;
• які акаунти не враховують, як-от акаунти команди й тестові;
• яке вікно і коли саме воно починається;
• чий годинник визначає, де починається середа.

Maya рахувала всіх, хто мав будь-яку подію в дату за UTC. Theo рахував відкриття застосунку в місцеву дату кожного користувача. Жоден не прибрав акаунти команди. Обидва запити правильні: вони відповідають на два різні запитання з однаковою назвою.

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

Визначення метрики, яке неможливо прочитати двозначно, має п'ять частин, і кожна закриває пастку з даних Halves.

1. Цільова дія: подія, яка зараховує людину. Для «активних» це app_opened, а не будь-яка подія, бо серверні регулярні рахунки робили б людей «активними».
2. Одиниця підрахунку: унікальні користувачі, групи чи розрахунки. Розрахунок записують обидві сторони, тож розрахунки — це різні settlement_id, а не рядки.
3. Винятки: кого не враховують і як їх знайти: is_internal = true або acquisition_channel = staff, бо одну позначку лишили порожньою.
4. Часове вікно: день, тиждень чи місяць із точним початком і кінцем.
5. Часовий пояс звітності: чия північ ділить дні — UTC чи користувача.

Разом визначення DAU для Halves звучить так: унікальні user_id з app_opened, без акаунтів команди за позначкою чи каналом, один календарний день 00:00–23:59, UTC.

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

Часове вікно каже, за який період рахують метрику, і йому потрібні точний початок і кінець, а також часовий пояс, у якому вони задані.

Спокуслива скоротка — вікно відносно «зараз»: «останні 7 днів», «останні 24 години». Для живого моніторингу це нормально, але для числа у звіті — пастка. Результат залежить від моменту, коли хтось запускає запит. Запусти його в четвер о 09:00 і о 17:00, і вікна відрізнятимуться на вісім годин даних, тож двоє людей отримають два числа, і ніхто не відтворить слайд минулого тижня.

Для звітів використовуй календарні вікна: «з понеділка, 1 червня, 00:00 до неділі, 7 червня, 23:59, UTC». Будь-хто й будь-коли отримає ту саму відповідь.

Ще дві подробиці варто записати:

• з якого дня починається тиждень, понеділка чи неділі; у різних команд по-різному;
• чи завершений останній період. Тиждень, який закінчується завтра, ще наповнюється, тож його число зростатиме. Познач його як неповний або не показуй на графіку.

Коли визначення зафіксовано, перерахунок середи стає механічним. Кроки по черзі:

1. Спершу вікно й часовий пояс. За UTC дата — це саме те, що написано в event_time, тож залишаємо рядки від 2026-06-03T00:00 до 23:59.
2. Цільова дія. Залишаємо лише app_opened.
3. Винятки. Шукаємо кожен user_id у таблиці користувачів і прибираємо акаунти з is_internal = true або acquisition_channel = staff: u019 і u002.
4. Одиниця. Рахуємо унікальні user_id, щоб людина, яка відкрила застосунок двічі, рахувалася один раз.

3 червня за UTC застосунок відкрили шестеро: u011, u002, u019, u004, u018 і u021. Обидва акаунти команди відкривали його по двічі. Без них лишається 4 справжні користувачі.

Порядок кроків важить менше, ніж те, щоб жодного не пропустити, але якщо спершу відфільтрувати вікно, список буде коротшим. Корисна самоперевірка — порахувати те саме двома способами: унікальні користувачі до винятків мінус виключені, що трапляються (6 − 2), мають дорівнювати унікальним після винятків (4).

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

До кожної події додай зсув користувача від UTC до event_time і візьми дату результату. У червні: Нью-Йорк — UTC−4, Лісабон — UTC+1, Київ — UTC+3, Бангкок — UTC+7.

• u012 у Бангкоку відкриває застосунок о 23:10 UTC 2 червня: 23:10 + 7 год = 06:10 3 червня. Входить.
• u017 у Нью-Йорку відкриває його о 01:40 UTC 4 червня: 01:40 − 4 год = 21:40 3 червня. Входить.
• u011 у Нью-Йорку відкриває його о 02:30 UTC 3 червня: це 22:30 2 червня. Не входить.

З тими самими винятками місцеве 3 червня має 5 справжніх користувачів: u004, u012, u017, u018, u021. Перевірка від підрахунку за UTC: 4 − 1 + 2 = 5.

Бери зсув, чинний саме на ту дату: літній час зсуває багато поясів на годину, тож таблиця зсувів має вказувати сезон.

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

Для 6 від Maya: беремо всі рядки з датою 2026-06-03 за UTC, хоч яка подія і хоч який користувач. Їх 16. Рахуємо серед них унікальні user_id: 6. Це саме її дашборд.

Для 7 від Theo: беремо app_opened, переводимо кожен час на місцевий годинник користувача, залишаємо місцеве 3 червня й рахуємо унікальних користувачів разом з акаунтами команди: 7.

Тепер можна показати різницю крок за кроком, а не оголошувати переможця: «6 = будь-яка подія, UTC, з командою; без команди — 4. 7 = відкриття застосунку, місцева дата, з командою; без команди — 5».

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

Перенеси те саме мислення з дня на тиждень 1–7 червня (UTC), і отримаєш драбину чисел, де кожне — окреме визначення:

• 22: унікальні користувачі з будь-якою подією, без винятків;
• 19: лише app_opened, що прибирає 3 користувачів, чиї єдині події — регулярні рахунки від сервера;
• 18: ще й без is_internal = true, що прибирає u019;
• 17: без is_internal = true або acquisition_channel = staff, що прибирає й u002, у якого позначку лишили порожньою.

Лише 17 — це узгоджене правило DAU, розтягнуте на тиждень. Решта — не хибні числа, а відповіді на інші запитання, як-от «скільки акаунтів узагалі щось зробили?»

Звідси дві звички. Перша: коли бачиш кілька версій однієї метрики, вишикуй їх так і назви крок, що відрізняє кожну пару; різниці підкажуть, про що забула кожна команда. Друга: пиши визначення під графіком як підпис. Тоді 17 на одному слайді й 22 на іншому не зможуть обидва називатися «щотижневими активними користувачами».

Визначення змінюються, і так має бути, коли з'являється краще правило: нова ознака акаунтів команди, перехід на місцеві дати, краща цільова дія. Небезпечна тиха зміна.

Якщо DAU рахують за датами UTC до 30 червня, а з 1 липня — за місцевими, графік за рік поєднує дві різні метрики. Стрибок у момент переходу може бути через правило, а не через користувачів, і читачі цього не розрізнять.

Три безпечні способи змінити визначення:

1. Перерахувати історію за новим правилом, щоб увесь графік мав одне визначення.
2. Якщо не вдається, позначити розрив на графіку й у підписі («місцеві дати з 1 липня») і ніколи не порівнювати через нього.
3. Якийсь час показувати обидві версії поруч, щоб люди бачили, наскільки саме правило змінює число.

У кожному разі веди у визначенні журнал змін із датами: що змінилося, коли й чому.

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