Як скласти план трекінгу для нової фічі

Maya

Нагадування про борги виходять за три тижні: Halves нагадує тим, хто винен гроші, а вони можуть відкрити нагадування й розрахуватися. Після запуску мені потрібні дві відповіді. Чи люди розраховуються швидше завдяки нагадуванням? І чи когось вони дратують?

Ви

Тоді складімо список подій: нагадування надіслано, нагадування відкрито, розрахунок. Щось іще?

Alex Tutor

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

Два питання Maya розпадаються на чотири. Скільки нагадувань доходять до людей і скільки з них відкривають? Скільки боргів після нагадування закривають і як швидко? Чи це швидше, ніж без нагадування? І скільки людей вимикають нагадування?

Maya

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

Alex Tutor

Питання 1

Розстав кроки створення плану трекінгу для нагадувань про борги в правильному порядку.

Торкніться пункту, а потім місця, куди його поставити. Можна перетягувати або користуватися стрілками.

Alex Tutor

Тепер події. Нагадування надсилає сервер, тож reminder_sent — серверна подія (server-side event): її записують, навіть коли пуш так і не дійшов. Як і з регулярними рахунками, це не активність користувача. reminder_opened записує застосунок, коли людина натискає на нагадування.

Для «як швидко» потрібен зв'язок. Кожне нагадування отримує reminder_id, і його додають до reminder_opened і до settle_up_recorded, коли розрахунок почався з нагадування. Без цього зв'язку розрахунки після нагадування нічим не відрізняються від решти.

Theo

А роздратування? Кнопки «мене це дратує» ніхто не натискає.

Alex Tutor

Ні, але люди діють. Записуйте reminders_muted, коли хтось вимикає нагадування, з властивістю scope: ця група чи всі групи. Вимкнення і люди, які перестали відкривати нагадування, — так роздратування виглядає в даних.

Alex Tutor

Питання 2

Зістав кожне питання про нагадування з подією, яка на нього відповідає.

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

Скільки нагадувань Halves намагався доставити?
Оберіть відповідь
На скільки нагадувань люди натиснули?
Оберіть відповідь
Які борги закрили після нагадування?
Оберіть відповідь
Скільки людей вимкнули нагадування?
Оберіть відповідь

Ви

А куди записати «нагадування вимкнено»? На подію чи на користувача?

Alex Tutor

І туди, і туди. Вимкнення — подія: воно сталося в певну мить. А те, чи ввімкнені нагадування зараз, описує людину, тож це ще й властивість користувача (user property) reminders_enabled. Сума боргу і те, перше це нагадування чи друге, описують одне нагадування: це властивості події (event property) на reminder_sent.

Одне правило: додавайте до кожної події все, за чим потім захочете фільтрувати чи групувати. До подій минулого місяця властивість уже не додаси.

Maya

Тоді я в перший же день спитаю: чи другі нагадування вимикають частіше за перші?

Alex Tutor

Питання 3

Maya питає: «Чи другі нагадування про той самий борг вимикають частіше за перші?» У чернетці плану є reminder_sent (reminder_id, recipient_user_id, group_id) і reminders_muted (scope). Що треба додати, щоб їй відповісти? Обери всі правильні варіанти.

Оберіть усі правильні відповідіapp_version на reminder_sentreminder_number на reminder_sent (1 для першого нагадування про борг, 2 для другого)amount_usd на settle_up_recordedreminder_id на reminders_muted: останнє нагадування, яке людина отримала перед вимкненням

Alex Tutor

Далі кожну метрику записуємо як визначення, як минулого уроку. Частка вимкнень: серед унікальних користувачів (unique users), які отримали нагадування цього тижня, частка тих, хто вимкнув їх протягом 7 днів. Люди, а не події: хто перемкнув п'ять разів, однаково одна людина.

Ви

А «швидше, ніж без нагадування»? Можна порівняти борги з нагадуванням і без.

Alex Tutor

Обережно: нагадування йдуть до боргів, які вже прострочені, тож групи різні від самого початку. Чесне порівняння потребує holdout-групи (holdout group): випадкової частки боргів, які мали б отримати нагадування, але не отримують. Заплануйте її вже зараз, із подією reminder_held_back.

Maya

Гаразд, невелика holdout-група. А тепер запишіть мені ту, що мене цікавить: час до розрахунку.

Alex Tutor

Питання 4Коротка відповідь · Завдання з перевіркою ШІ

Запиши визначення метрики час до розрахунку після нагадування у 2–4 реченнях. Вкажи, з якої події вона починається і якою закінчується, кого виключено, що буває з нагадуваннями, після яких так і не розрахувалися, і яке число звітують.

Напишіть відповідь і отримайте оцінку та відгук від нашого ШІ-рецензента.

Увійдіть, щоб отримати відгук ШІ

Alex Tutor

Останній крок: перевірка (QA). На тестовому акаунті викличте кожну подію й подивіться на сирі рядки. Чи вона спрацьовує один раз, а не двічі при повторній спробі? Чи заповнені властивості, чи немає порожнього reminder_id?

Ще дві. Тестові акаунти мають бути позначені як внутрішній трафік (internal traffic), інакше натискання під час QA стануть «відкриттями». А час записується в UTC, тож зберігайте timezone користувача, щоб бачити, о котрій нагадування прийшло за місцевим часом.

Theo

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

Ви

Тобто QA перевіряє дані, а не лише те, чи працює фіча.

Alex Tutor

Питання 5

У чернетці плану від розробника для нагадувань одна подія, reminder_shown, яку записує застосунок, коли нагадування з'являється на телефоні. Частку відкриттів рахують як reminder_opened / reminder_shown. У чому головна вада?

Оберіть одну відповідьНазва події має бути в минулому часіНагадування, які сервер надіслав, але які так і не дійшли до телефона, невидимі, тож частка відкриттів виглядає вищою, ніж єЗастосунок нічого не може записати, поки він закритий, тож reminder_opened завжди буде нулемЧастку відкриттів треба рахувати за подіями, а не за користувачами

Maya

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

Alex Tutor

Тоді пройдіть ті самі п'ять кроків: питання, події й властивості з джерелом, одне записане визначення і перевірки перед запуском.

Ви

Починаючи з питань Maya, а не з екранів.

Alex Tutor

Саме так. Екрани змінюються, а дані збирають саме заради питань.

Alex Tutor

Питання 6Кейс · Завдання з перевіркою ШІ

Напиши короткий план трекінгу для бюджетів поїздок у Halves.

Halves додає бюджети поїздок. У групі з group_type = trip будь-який учасник може задати бюджет поїздки в доларах і потім його змінити. Усі учасники бачать, скільки бюджету лишилося, коли додаються витрати. Коли витрачено 80% бюджету, сервер надсилає всім учасникам пуш-сповіщення.

Через два місяці Maya вирішуватиме, чи лишити фічу, перенести її в Halves Plus чи прибрати. Вона хоче знати:

Чи групи в поїздках справді задають бюджети?
Чи групи з бюджетом продовжують додавати витрати протягом поїздки, а не кидають на півдорозі?
Чи корисне сповіщення про 80%, чи його вимикають?

Напиши план (200–350 слів):

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

Напишіть відповідь і отримайте оцінку та відгук від нашого ШІ-рецензента.

Увійдіть, щоб отримати відгук ШІ

Alex Tutor

Головне

План трекінгу йде від питань донизу: питання → події та властивості → де кожну записують → визначення метрик → перевірка до запуску.
Те, що робить сервер, записуйте на сервері (reminder_sent), а те, що робить людина, — у застосунку (reminder_opened). Серверні події — не активність користувача.
Пов'язуйте події ідентифікаторами (reminder_id на відкритті й розрахунку), інакше не зрозуміти, що спричинила фіча.
Властивості події описують одну мить, властивості користувача — людину. Додавайте всі властивості для фільтрів одразу: старим подіям їх потім не додаси.
Роздратування видно з поведінки: вимкнення і люди, які перестали відкривати.
Чесне «швидше, ніж без» потребує holdout-групи, закладеної до запуску.
QA перевіряє дані: подія спрацьовує раз, властивості заповнені, внутрішні акаунти позначені, часовий пояс збережено.

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

Alex Tutor

На цьому все. Ви відповіли на всі завдання — чудова робота.

Наступний урок: North star і дерево метрик