Tracking plan шаблон: шість розділів, заповнений приклад і чеклист перевірки

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

Що таке план трекінгу?

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

Шаблон плану трекінгу

Скопіюй шість розділів у документ чи таблицю: один план на фічу або на частину продукту.

1. Шапка й запитання

2. Події

3. Властивості

Властивості події описують одну мить (суму, спосіб), властивості користувача — людину в усіх її подіях (канал реєстрації, платформу, часовий пояс). Швидкий тест: чи може значення відрізнятися у двох подіях із різницею в хвилину? Якщо так, воно належить події.

4. Визначення метрик

Для кожного числа, потрібного для рішення: подія, що зараховується, одиниця підрахунку (користувачі, групи, унікальні id), винятки, часове вікно й часовий пояс. Урок Метрика — це її визначення показує, чому без усіх п'яти частин двоє людей отримують різні числа.

5. Чеклист QA

Що запустити на тестовому акаунті й що шукати в сирих рядках (чеклист нижче).

6. Журнал змін

Дата, що змінилося (нова подія, перейменована властивість, виправлений баг), хто змінив і яких дашбордів це стосується.

Правила іменування подій: проста таксономія подій

• Об'єкт плюс дієслово в минулому часі, у snake_case: expense_added, group_created, receipt_scanned. Одна назва на всіх платформах: якщо один застосунок логує addExpense, кожен звіт показує дві половинки одного числа.
• Одиниці в назвах властивостей: amount_usd, duration_ms. Нікому не доведеться вгадувати.
• Закриті списки для категорій: entry_method — це manual, receipt_scan або recurring, і ніколи не вільний текст.
• Id, що зв'язують події: дай кожному об'єкту id і переноси його в пізніші події, щоб бачити, що саме спричинила фіча.
• Логуй рішення, а не кожен тап. Кожна подія має лишатися правильною в кожному релізі, тож кожна має відповідати на якесь запитання.

Приклад плану трекінгу: розподіл чека за позиціями

У Halves можна відсканувати чек, щоб додати витрату. Нова фіча читає кожен рядок чека, тож група може розділити вечерю за позиціями: хто їв суп, той за суп і платить. Сканування чеків входить у платний план Halves Plus.

Запитання

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

• Q1. Як часто сканер успішно читає чек?
• Q2. Яку частку успішно прочитаних чеків ділять за позиціями?
• Q3. Чи витрати, поділені за позиціями, редагують рідше за інші (менше суперечок)?
• Q4. Чи приводить фіча безкоштовних користувачів до пейволу Plus?

Події

Властивості користувача: is_internal, acquisition_channel, plan (free / plus), timezone. Дві події вже існували (expense_added, paywall_viewed), тож план додає до них властивості замість вигадувати нові події. Розпізнавання відбувається на сервері, тому receipt_parsed — серверна подія (server-side event): вона логується, навіть якщо телефон утратив зв'язок, і не є активністю користувача.

Одне визначення повністю

Частка прочитаних чеків: унікальні receipt_id з подією receipt_parsed і status = success, поділені на унікальні receipt_id з подією receipt_scanned, за календарний тиждень в UTC. Акаунти з is_internal = true або acquisition_channel = staff виключено.

Перший тиждень даних і що врятувало визначення

За тиждень бета-тесту лог показав:

• 1 240 рядків receipt_scanned, але лише 1 150 унікальних receipt_id: 90 рядків — повторні надсилання на повільній мережі, той самий скан двічі.
• 50 із 1 150 чеків відсканували акаунти QA-команди, тож лишається 1 100 справжніх чеків.
• 990 рядків receipt_parsed зі status = success, з них 44 — чеки QA, тож лишається 946 справжніх успіхів.

Якщо рахувати наївно, рядки на рядки:

990 ÷ 1 240 = 0,798, тобто 79,8%

Якщо за визначенням, унікальні справжні чеки:

946 ÷ 1 100 = 0,860, тобто 86,0%

Той самий тиждень, той самий лог — і різниця в 6,2 відсоткового пункту. Наївне число відправило б команду лагодити сканер, який насправді працює краще, ніж здавалося. Для Q2: 568 із 946 успішно прочитаних чеків стали витратами з split_type = by_item, отже 568 ÷ 946 = 60,0% прочитаних чеків поділили за позиціями.

Дублікати були багом, а не особливістю даних: QA мала помітити, що receipt_scanned спрацьовує двічі при повторному надсиланні. Команда це виправила й записала в журнал змін.

Чеклист QA перед запуском

На тестовому акаунті запусти кожну подію з плану й читай сирі рядки, а не дашборд:

1. Спрацьовує один раз. Одна дія — один рядок, зокрема при повторах, повільній мережі й подвійному тапі.
2. Властивості заповнені. Жодних порожніх id, одиниці як у назві, значення лише із закритого списку.
3. Однакові назви всюди. iOS, Android і сервер використовують ідентичні назви подій і властивостей.
4. Id зв'язуються. receipt_id зі скану з'являється в результаті розпізнавання й у витраті.
5. Тестові акаунти позначені. Кожен QA-акаунт має is_internal = true: це внутрішній трафік (internal traffic), а напівзаповнений прапорець — часте джерело хибних чисел.
6. Часовий пояс збережено. Події записано в UTC, а timezone користувача дає змогу побачити місцевий час, наприклад коли прийшло нагадування.
7. Серверні події відокремлено. Усе, що сервер робить сам, позначено як таке й ніколи не зараховується як активність.

Типові помилки

• Почати з екранів. Отримаєш сотню подій і однаково не відповіси на Q3.
• Додавати властивості після запуску. До подій минулого місяця властивість уже не додаси: перші тижні даних для цього запитання втрачено.
• План, що живе в голові однієї людини. Якщо плану немає там, куди дивиться команда, його не існує.
• Немає зв'язку з рішенням. Подія, яка не потрібна для жодного запитання, — шум, який хтось має вічно підтримувати правильним.
• Рахувати рядки замість одиниць. Повтори, двосторонні підтвердження й тапи QA роздувають кількість рядків; визначення мають рахувати унікальні id чи користувачів.

Головне

• Tracking plan шаблон складається з шести розділів: запитання, події, властивості, визначення метрик, QA і журнал змін.
• Починай із рішення та його запитань; кожна подія має відповідати хоча б на одне.
• Називай події як об'єкт плюс дієслово в минулому часі, пиши одиниці в назвах властивостей і зв'язуй події через id.
• Пиши кожне визначення метрики повністю: подія, одиниця, винятки, вікно, часовий пояс.
• Перевіряй сирі рядки до запуску: у прикладі з Halves визначення перетворило оманливі 79,8% на справжні 86,0%.

FAQ

Хто має відповідати за план трекінгу?

Продакт відповідає за запитання й рішення, аналітик — за визначення, розробники — за реалізацію і QA. Одна людина тримає документ актуальним, а кожна зміна потрапляє в журнал змін.

Таблиця чи документ?

Підійде і те, і те. Таблиця зручна для подій і властивостей, документ — для запитань і визначень. Головне, щоб місце було одне і на нього посилалася специфікація фічі.

Скільки подій має бути у фічі?

Стільки, скільки потрібно для запитань. Для типової фічі чотирьох-восьми подій, часто разом з наявними, до яких додали властивості, більш ніж достатньо.

Чим план трекінгу відрізняється від таксономії подій?

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

Спробуй на практиці

Склади план трекінгу для нової фічі Halves у безкоштовному уроці План трекінгу для нової фічі. Якщо події та властивості для тебе нові, почни з уроку Події, властивості й користувачі. Коли дані вже йдуть, перетвори їх на ціль за допомогою допису north star metric приклади і простеж шлях нових користувачів через фічу з аналізом воронки; ширша картина — у дописі що таке продуктова аналітика.