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

> Безкоштовний tracking plan шаблон із шести розділів: запитання, події, властивості, визначення метрик, QA та журнал змін — і розбір на новій фічі.

- Джерело: https://productovi.com/uk/blog/tracking-plan-template
- Автор: Sergey Bruh
- Опубліковано: 2026-09-30
- Теми: План трекінгу, Події, властивості й користувачі

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

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

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

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

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

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

| Поле          | Що заповнити                                               |
| ------------- | ---------------------------------------------------------- |
| Фіча          | Назва й опис одним рядком                                  |
| Рішення       | Що вирішуватимуть на цих даних, хто і коли                 |
| Запитання     | 3–5 запитань, кожне пов'язане з рішенням                   |
| Відповідальні | Продакт, аналітик, розробник застосунку, розробник сервера |

### 2. Події

| Подія           | Тригер: коли саме спрацьовує      | Джерело (застосунок чи сервер) | Властивості        | Відповідає на |
| --------------- | --------------------------------- | ------------------------------ | ------------------ | ------------- |
| `object_verbed` | Після того як сервер підтвердив X | сервер                         | `id`, `amount_usd` | Q1, Q2        |

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

| Властивість  | Де (подія чи користувач) | Тип   | Допустимі значення чи одиниця | Приклад |
| ------------ | ------------------------ | ----- | ----------------------------- | ------- |
| `amount_usd` | подія                    | число | долари США, > 0               | 42,50   |

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

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

Для кожного числа, потрібного для рішення: подія, що зараховується, одиниця підрахунку (користувачі, групи, унікальні id), винятки, часове вікно й часовий пояс. Урок [Метрика — це її визначення](/uk/courses/product-analytics/metric-definitions/theory) показує, чому без усіх п'яти частин двоє людей отримують різні числа.

### 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?

### Події

| Подія             | Джерело    | Ключові властивості                                      | Відповідає на |
| ----------------- | ---------- | -------------------------------------------------------- | ------------- |
| `receipt_scanned` | застосунок | `receipt_id`, `group_id`                                 | Q1            |
| `receipt_parsed`  | сервер     | `receipt_id`, `status` (success / failed), `items_count` | Q1, Q2        |
| `expense_added`   | застосунок | `receipt_id`, `split_type` (equal / shares / by_item)    | Q2            |
| `expense_edited`  | застосунок | `expense_id`, `fields_changed`                           | Q3            |
| `paywall_viewed`  | застосунок | `trigger` (receipt_scan / currency / charts / settings)  | Q4            |

Властивості користувача: `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, з 1 240 рядків сканувань лишається 1 100 справжніх чеків, а з 990 успіхів — 946, тож частка прочитаних чеків — 86,0%, а не наївні 79,8%](/blog/tracking-plan-template/diagram-uk.png)

Дублікати були багом, а не особливістю даних: 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 у безкоштовному уроці [План трекінгу для нової фічі](/uk/courses/product-analytics/tracking-plan/theory). Якщо події та властивості для тебе нові, почни з уроку [Події, властивості й користувачі](/uk/courses/product-analytics/events-properties-users/theory). Коли дані вже йдуть, перетвори їх на ціль за допомогою допису [north star metric приклади](/uk/blog/north-star-metric-examples) і простеж шлях нових користувачів через фічу з [аналізом воронки](/uk/blog/funnel-analysis); ширша картина — у дописі [що таке продуктова аналітика](/uk/blog/what-is-product-analytics).

## Пов’язані уроки

- [План трекінгу для нової фічі](https://productovi.com/uk/courses/product-analytics/tracking-plan.md)
- [Визначення метрики: одне правило, одне число](https://productovi.com/uk/courses/product-analytics/metric-definitions.md)
- [Події, властивості й користувачі](https://productovi.com/uk/courses/product-analytics/events-properties-users.md)