план трекінгу (tracking plan)

Також називають: план подій, план трекінгу подій, tracking plan, таксономія подій

Документ, у якому перелічено питання, на які має відповісти фіча, події та властивості, потрібні для відповіді, де кожна з них записується і як її перевірять до запуску.

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

Для кожної події корисний план містить:

Поле	Що в ньому
Питання	Якому рішенню допомагає ця подія
Назва події	Єдина конвенція, наприклад `object_action` у snake_case і минулому часі: `reminder_sent`
Тригер	Точний момент спрацювання («після того, як сервер прийняв витрату», а не «по натисканню»)
Властивості	Назва, тип і допустимі значення: `channel`: push / email
Джерело	Клієнт чи сервер, і чому
Визначення метрик	Формули на основі події, з одиницями, вікнами й винятками
Власник і QA-перевірка	Хто підтримує, як перевіряють перед релізом

Найважливіші два рішення. Де логувати: серверні події надійні для того, що відбувається на сервері (платежі, регулярні рахунки, надіслані сповіщення), і їх не блокують блокувальники реклами, але вони не доводять, що людина щось зробила; клієнтські події фіксують, що користувач побачив і натиснув. Як називати: кілька подій із багатими властивостями (paywall_viewed із trigger) старіють набагато краще, ніж окрема подія на кожну кнопку.

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

Приклад

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

Подія	Джерело	Ключові властивості	Для чого
`reminder_sent`	сервер	`reminder_id`, `group_id`, `amount_usd`, `channel` (push / email)	знаменник частки відкриттів і розрахунків
`reminder_opened`	клієнт	`reminder_id`, `channel`	частка відкриттів
`settle_up_recorded`	клієнт	`settlement_id`, `amount_usd`, `reminder_id` (порожньо, якщо не було)	розрахунок протягом 7 днів після нагадування

Визначення метрики: частка відкритих нагадувань = кількість унікальних reminder_id із хоча б одним reminder_opened ÷ кількість унікальних reminder_id із reminder_sent, без акаунтів працівників, за календарний тиждень (UTC).

За перший тиждень сирі лічильники — 4 000 подій reminder_sent і 1 000 подій reminder_opened, що ніби дає 1 000 / 4 000 = 25% відкриттів. Але дехто відкривав те саме нагадування двічі: 1 000 подій відкриття належать 800 унікальним нагадуванням. За записаним визначенням частка відкриттів — 800 / 4 000 = 20%, а не 25%. Оскільки план зафіксував визначення і вимагав reminder_id в обох подіях, правильне число — це один запит, а не суперечка.

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

Писати план після запуску. Властивості, яких бракує, не відновиш заднім числом; перші тижні даних, часто найцікавіші, втрачено.
Події без питань. Логування кожного натискання створює шум і витрати; кожна подія має слугувати названому рішенню.
Розмиті тригери. «Коли користувач додає витрату» може означати натискання або підтвердження сервера; тоді невдалі збереження теж рахуються як витрати.
Непослідовні назви. expenseAdded, add_expense і Expense Added в одному проєкті ділять одну дію на три.
Без QA перед релізом. Порівняйте очікувані й отримані події в тестовій збірці; виправлення трекінгу після запуску коштує релізу і втрачених даних.