ПРАКТИЧНИЙ ПОСІБНИК / ВІДСТЕЖЕННЯ КОНВЕРСІЙ
Чому звіти про конверсії в iGaming не збігаються
Ділове спілкування — англійською
Спочатку переконайтеся, що в усіх системах порівнюєте ті самі події за один період і з однаковим статусом. Потім перевірте ланцюжок постбеків, щоб відрізнити розбіжності у звітності від проблем передавання даних.
Розглядаєте Джеймса на посаду медіабаєра?
Обговорити посаду з ДжеймсомЦей посібник показує, як я перевіряю визначення конверсій, шляхи postback і розбіжності у звітності. Для обговорення найму поділіться інформацією про посаду, канали та обов’язки з трекінгу, які ви хочете оцінити.
Робоче спілкування відбувається англійською мовою.
Хочете спочатку розібратися самостійно? Нижче — практичний посібник.
Перевірка S2S-постбеків за пропущених конверсій і розбіжностей у звітах
У бекенді подія є, а в трекері немає
Перевірте, чи надіслано подію, чи збережено click ID трекера та яку відповідь повернув одержувач. Якщо немає спільного ідентифікатора чи журналу доставлення, позначте розбіжність як нез’ясовану.
У трекері подія є, а в рекламній мережі немає
Спочатку переконайтеся, що для події налаштовано надсилання постбека до рекламної мережі. Потім окремо перевірте цей етап передавання: click ID джерела, зіставлення подій, відповідь одержувача та фільтри звіту мережі. Успіх першого етапу не підтверджує успіх другого.
Подія є в обох системах, але підсумки за день різняться
Узгодьте часові пояси, межі періоду, принцип групування за часом візиту чи отримання постбека, статус підтвердження та правила атрибуції. Дочекайтеся оновлення звітів з урахуванням відомої затримки й повторіть експорт, перш ніж змінювати налаштування.
1. Визначте конверсію перед порівнянням CPA
Реєстрація, підтверджена афіліатна конверсія та перший депозит (FTD) — різні результати. Статус підтвердження також може змінитися після першої фіксації події. Перш ніж порівнювати підсумки звітів, запишіть подію й умови її зарахування в кожному з них.
- Назвіть подію, умову її спрацювання та вимоги до підтвердження.
- Зафіксуйте, що саме рахує звіт: події, унікальних користувачів чи підтверджені дії.
- Обчислюйте CPA за витратами й погодженою кількістю конверсій для тієї самої вибірки кампаній і періоду; CPA реєстрації не є вартістю залучення першого депозиту (FTD).
2. Узгодьте дати, часові пояси й атрибуцію
День кліку, день конверсії та час надходження постбека можуть відрізнятися. Наприклад, Voluum підтримує звітність за часовою міткою візиту або постбека. Тому відкладена конверсія може відображатися під різними датами, хоча її не втрачено.
- Використовуйте однаковий часовий пояс і часові межі звітів у всіх вивантаженнях.
- Зафіксуйте, яку часову мітку, модель атрибуції та вікно атрибуції використовує кожна система.
- Запишіть час створення кожного вивантаження та врахуйте відомі затримки підтвердження або звітності перед повторним порівнянням.
3. Простежте шлях події через постбек
Міжсерверний постбек (S2S) передає дані про конверсії між системами. Перевіряйте кожну потрібну ланку окремо: від бекенду або афіліатної платформи до трекера, потім від трекера до рекламної мережі. Успіх на одній ланці не підтверджує успіху на наступній.
- Простежте вибірку записів, до яких маєте дозвіл на доступ, за відповідним click ID та ідентифікатором події або транзакції.
- Зіставте тип надісланої події з налаштуваннями зіставлення подій у системі-отримувачі та доступними журналами відповідей або помилок.
- Перевірте обробку дублікатів, оновлення статусів і затримки доставки за документацією конкретної інтеграції. Різні події від одного кліку не обов’язково є дублікатами.
Джерело: Voluum: параметри в URL постбеків · Voluum: користувацькі конверсії
4. Звірте дані, до яких маєте доступ
Почніть з однієї кампанії та визначеного періоду. Зіставляйте записи там, де є спільні ідентифікатори. Порівнюйте зведені показники лише після узгодження подій, фільтрів і часових налаштувань. Команда афіліатів може мати звіти про підтверджені конверсії, але не мати даних оператора про депозити; зафіксуйте це обмеження, а не робіть припущень щодо депозитів.
- Збіг: ту саму подію можна ідентифікувати в обох системах.
- Пояснена розбіжність: різницю зумовлюють час, статус, фільтри або визначення.
- Не з’ясовано: доказів недостатньо або потрібно дослідити конкретну проблему доставки чи зіставлення подій.
5. Перетворіть висновок на конкретну дію
Корисний аналіз містить висновок, його підтвердження, відповідального та наступну перевірку. Виправте підтверджену помилку зіставлення подій або узгодьте подання звіту, а потім порівняйте знову. Не змінюйте кілька налаштувань відстеження одночасно: так важче визначити, яка зміна вплинула на результат.
Не вважайте кожен незіставлений запис втраченим доходом і не збільшуйте витрати лише тому, що один дашборд показує нижчий CPA. Якщо причина ще не зрозуміла, зазначте, які дані допоможуть її з’ясувати.
CPA знизився після виправлення трекінгу: чи поліпшилася ефективність?
Зниження CPA у звіті після виправлення трекінгу може означати, що раніше пропущені конверсії почали враховуватися. Перш ніж вважати це підставою для збільшення витрат:
- Зафіксуйте зміну вимірювання. Запишіть, що виправили, коли внесли зміну та яких подій вона стосувалася. Порівнюючи показники до та після, зазначте визначення події, часову основу звіту й статус підтвердження: зміна методу підрахунку обмежує висновки з такого порівняння.
- Перевірте результати на стороні рекламодавця. Якщо доступні звіти рекламодавця, використовуйте повні звітні періоди однакової тривалості з тим самим набором кампаній, подією та правилами підтвердження. Порівняйте витрати й підтверджені конверсії, ураховуючи відомі затримки звітності або підтвердження. Більше врахованих реєстрацій не означає більше підтверджених перших депозитів.
- За наявності даних оцініть, що відбувається після першої конверсії. Перевірте дохід або утримання залучених користувачів, якщо ці звіти доступні. Інакше зафіксуйте обмеження, а не робіть висновок про поліпшення якості клієнтів лише за CPA.
- Визначте наступну дію на основі даних. Якщо дані рекламодавця не підтверджують поліпшення, не вважайте зниження CPA у дашборді сигналом до масштабування. Якщо дані дають підстави для тесту, погодьте обмежене збільшення бюджету й відстежуйте ті самі результати; оцінюйте тест окремо від зміни методу підрахунку.
Джеймс у LinkedIn: зміни трекінгу й CPA у звітах
Коли звіти стануть порівнюваними, оцініть вартість залучення з урахуванням цінності клієнта. Вартість залучення та цінність клієнта
Практичний перелік перевірок для звірки звітів
Виберіть одну кампанію та обмежений період. У внутрішньому журналі перевірки створіть рядок для кожної події з вибірки з такими полями:
- Кампанія та джерело звіту; час експорту й часовий пояс.
- Визначення події, одиниця підрахунку та статус підтвердження.
- Click ID трекера, click ID джерела та ID події або транзакції, якщо доступні.
- Час кліку, конверсії та отримання постбека, якщо ці дані доступні.
- Результат: збіг, пояснена розбіжність або нез’ясована розбіжність.
- Підтвердні дані, відповідальна команда, запропонована дія та дата наступної перевірки.
Умовний приклад, не результат клієнта: клік відбувається до опівночі, а конверсія надходить наступного ранку. Звіти з групуванням за датою візиту та датою отримання постбека можуть віднести подію до різних днів. Перш ніж вважати подію втраченою, знайдіть її в обох системах і перевірте, за якою датою її враховано.
Постбек успішний. Чому кількість конверсій у звітах різна?
Успішний запит сам по собі не доводить, що потрібну подію записано з правильним кліком і включено до відкритого звіту. Перевірте обидва етапи передавання, зіставлення подій, основу дат, фільтри й затримку оновлення.
Заповнений приклад: звірка 10 / 9 / 10 конверсій
Навчальний умовний приклад. Усі кількості, ідентифікатори, дати та посилання на докази вигадані. Це не результати клієнтів і не стандартні налаштування платформ. Назви полів залишено англійською, як у таблиці для завантаження.
1. Задайте параметри на аркуші Review
Перевіряється одна кампанія й одна подія реєстрації. Усі десять реєстрацій належать до вибраного джерела, відповідають однаковим правилам перевірки та вікну атрибуції. Дев’ять подій уже збігаються; десята потребує перевірки.
Показати всі заповнені параметри
| Поле таблиці | Заповнене значення |
|---|---|
| Campaign / market | DEMO-01 / hypothetical market |
| Conversion event / trigger | registration / backend validates a completed registration |
| Counting unit | One unique event ID per validated registration |
| Period start (inclusive) | 2026-10-11 00:00:00 |
| Period end (exclusive) | 2026-10-12 00:00:00 |
| Time zone | UTC for all fields |
| Owner | Media buyer (hypothetical role) |
| Review date | 2026-10-13 |
| Currency | N/A: event-count reconciliation; no spend comparison |
| Approval / rejection rules | Include validated registrations only |
| Attribution model / window | Scenario assumption: last eligible click / 7 days |
| Expected reporting delay | Scenario assumption: up to 24 hours; verify actual integration |
| Reference system | Backend export B01 |
| Exclusions (QA, duplicates) | Exclude test events and repeated event IDs |
| Maturity cutoff / rationale | Export 2026-10-13 09:00 UTC, more than 24 hours after period end |
| Access / evidence gaps | Scenario assumes permitted access to all event logs and exports |
2. Узгодьте звіти до розрахунку різниці
Усі початкові звіти вивантажено 13 жовтня о 09:00 UTC. Трекер спочатку групує за датою кліку, інші джерела — за датою конверсії. Для трекера вкажіть No у Comparable? і залиште різницю порожньою. Значення 9 і 10 потребують перевірки, але не доводять втрату конверсії.
| Джерело | Початкова основа дат | Початкова кількість | Можна порівнювати? | Після звірки / різниця |
|---|---|---|---|---|
| Рекламна мережа (N01) | Дата конверсії | 10 | Yes | 10 / 0 |
| Трекер (T01 → T02) | Дата кліку | 9 | No → Yes | 10 / 0 |
| Бекенд / еталон (B01) | Дата конверсії | 10 | Yes | 10 / — |
Узгоджене джерело порівняння — вивантаження бекенду. Після зіставлення ID та перегрупування подій трекера за часом конверсії всі три набори містять однакові десять ID подій. У трекера стає 10 подій і різниця 0. Якщо потрібні дані недоступні, розбіжність залишається невирішеною.
3. Заповніть Event log для події біля півночі
Клік стався 10 жовтня о 23:58 UTC, реєстрація — 11 жовтня о 00:06 UTC. Звіт за 11 жовтня за датою кліку виключає цю подію, хоча конверсія й обидва постбеки відбулися 11 жовтня. У прикладі записи одержувачів підтверджують правильну подію та клік; одного повідомлення про успіх недостатньо.
Показати заповнений рядок події
| Поле таблиці | Заповнене значення |
|---|---|
| Sample ID | S01 |
| Event / approval status | registration / validated |
| Tracker click ID | T001 |
| Source click ID | N001 |
| Event / transaction ID | E001 |
| Click time | 2026-10-10 23:58:00 |
| Conversion time | 2026-10-11 00:06:00 |
| Tracker receipt time | 2026-10-11 00:06:02 |
| Network receipt time | 2026-10-11 00:06:04 |
| Time zone | UTC |
| Match status | Explained difference |
| Evidence reference | DEMO B01 / T01 / N01: E001 mapped to T001 and N001; both receivers recorded registration |
| Finding | Click-date report excludes E001 from 11 October; conversion-date report includes it |
| Next action | Regroup tracker export by conversion time and compare the full event-ID set |
| Owner | Tracking analyst (hypothetical role) |
| Next check | 2026-10-13 10:00:00 UTC |
4. Запишіть висновок і закрийте завдання після перевірки
Показати заповнений рядок завдання
| Поле таблиці | Заповнене значення |
|---|---|
| Issue ID | D01 |
| Finding / evidence | Date-basis mismatch for E001; see DEMO B01 / T01 / N01 |
| Status | Closed |
| Next action | Use conversion-time grouping for this review; preserve original exports |
| Owner | Tracking analyst (hypothetical role) |
| Due date | 2026-10-13 |
| Verification evidence | DEMO T02 at 10:00 UTC: 10 event IDs match B01 and N01. All Comparable? = Yes. Network and tracker deltas = 0. |
| Closed date | 2026-10-13 |
Причина розбіжності — основа дат звіту. Це не підтверджує поліпшення кампанії, повернення доходу чи потребу збільшити бюджет. Однакові підсумки лише початок; доказом для закриття є збіг десяти ID подій.
Завантажте Excel і заповніть власну перевірку
Якщо після узгодження різниця залишається
Перевірте приймання потрібної події та збереження ID на обох етапах постбеку. Потім перевірте зіставлення подій, підтвердження, обробку дублів, фільтри й оновлення звітів. За браку доказів призначте наступну перевірку команді з доступом до даних.
Наприклад, PropellerAds описує окремі цілі конверсії та попереджає, що поява конверсії у статистиці може зайняти до 24 годин. Це правило конкретної платформи, а не універсальний строк очікування. Офіційна документація S2S (перевірено 13 жовтня 2026 р.)
FTD є у звіті. Чи справді кампанія оптимізується під FTD?
Не обов’язково. Бізнес-ціль, подію, яку надсилає трекер, ціль у рекламній мережі та сигнал оптимізації потрібно перевіряти окремо. Наявність стовпця FTD не доводить, що ця подія керує показами або що кампанія прибуткова.
Умовний діагностичний приклад. Ідентифікатори, числа й налаштування вигадані; це не результати клієнта та не типові налаштування платформи.
Оператор прагне залучати більше клієнтів із першим депозитом, прийнятим за погодженими правилами. Припустімо, команда перевірила наведену схему кампанії PropellerAds CPA Goal. Реєстрації та FTD передаються, але виконують різні ролі.
На вузькому екрані таблицю можна прокручувати горизонтально.
| Перевірка | Умовне підтверджене налаштування | Значення |
|---|---|---|
| Бізнес-ціль | Прийнятий FTD | Бажаний результат оператора |
| Трекер → основний постбек | registration | Основна подія для рекламної мережі |
| Трекер → додаткова ціль | first_deposit → goal=2 | Окремо врахована наступна подія |
| Сигнал оптимізації | Основний постбек | У цій конфігурації — реєстрація |
За документацією PropellerAds, на роботу кампаній CPA Goal впливають лише події основного постбека; додаткові цілі враховують наступні події. Це правило конкретної платформи й типу кампанії. Документація платформи; перевірено 14 жовтня 2026 р.: PropellerAds: S2S / CPA Goal.
Що перевірити далі
- Разом перевірте вихідне зіставлення подій і поточні налаштування кампанії. Самої назви події в трекері недостатньо; збережіть датоване підтвердження цілі отримувача.
- Порівняйте реєстрації та прийняті FTD для когорт однакового віку. Затримку або відсутність даних FTD спершу позначте як прогалину, а вже потім оцінюйте, чи виправдовують дешеві реєстрації більші витрати.
- Якщо сигнал відрізняється від бізнес-цілі, погодьте наступний тест із власником акаунта. До зміни налаштувань перевірте підтримку платформи, якість подій і доступний обсяг конверсій.
Які висновки підтверджені
Схема пояснює, який сигнал отримує кампанія, але не причину слабких депозитів. Вона не доводить проблему оплати, KYC чи якості трафіку. Запишіть поточне налаштування, пропоновану зміну, відповідального за погодження та умову повторної перевірки. Це не вказівка автоматично зробити FTD основною ціллю.
Чим може допомогти James
James може перевірити зіставлення подій і доступні звіти за джерелами та майданчиками, описати обґрунтований тест і відсутні дані. Доступ до налаштувань та самі зміни погоджуються окремо.
Порівняйте CPA реєстрації з прийнятими FTD
Запишіть докази в таблицю Tracking · Як я визначаю події перед порівнянням витрат на кампанії
У трекері є конверсія, а в рекламній мережі немає: якого ID бракує?
Click ID трекера та click ID джерела мають різні завдання. Перший пов’язує подію з візитом у трекері; другий може бути потрібен для зворотної передачі в рекламну мережу. Схожа назва не робить їх взаємозамінними.
Умовний діагностичний приклад. Ідентифікатори, числа й налаштування вигадані; це не результати клієнта та не типові налаштування платформи.
У бекенді й трекері є реєстрація E204, пов’язана з T204. Проте в доступному експорті не видно ID кліку джерела, а у звіті мережі немає відповідної події. Причину поки не встановлено.
На вузькому екрані таблицю можна прокручувати горизонтально.
| Де шукати | Умовне спостереження | Наступне питання |
|---|---|---|
| Подія бекенда | E204 / registration / accepted | Чи пов’язана вона з правильним візитом трекера? |
| Запис трекера | E204 пов’язано з T204 | Чи зберігся ID джерела під час входу? |
| Click ID джерела | Не видно в експорті | Його немає чи він не входить до цього звіту? |
| Вихідний запит | Ще не перевірено | Які ID та подію фактично надіслано? |
Voluum визначає cid як обов’язковий параметр click ID трекера. PropellerAds окремо описує токен ID джерела. Назви полів і зіставлення залежать від інтеграції. Документація платформи; перевірено 14 жовтня 2026 р.: Voluum: postback parameters · PropellerAds: S2S tokens.
Що перевірити далі
- Перевірте дозволений до використання запис входу та зіставлення токенів. Порожнє значення чи нерозкритий шаблон потребують перевірки; сама відсутність стовпця в експорті не доводить збій.
- Простежте ту саму подію у вихідному запиті та результаті приймання. Звірте отримувача, ID джерела, подію й час. Відповідь сервера та включення до звіту — різні докази.
- Якщо ID не зберігався, запитайте відповідальну команду, чи залишилося надійне зіставлення. Не вигадуйте ID та не прив’язуйте подію до іншого кліку. За браку даних залиште питання відкритим.
Які висновки підтверджені
Підтверджена помилка зіставлення дає підставу для обмеженого виправлення й дозволеного тесту, але не гарантує відновлення минулих конверсій. До повторного надсилання власник інтеграції або платформа мають підтвердити процедуру та обробку дублів. Тестові події виключаються зі статистики ефективності.
Чим може допомогти James
James може зібрати докази за етапами передачі та підготувати питання до трекера, мережі чи оператора. Недоступні дані бекенда й внутрішні збої платформи перевіряє команда з відповідними правами.
Запишіть докази в таблицю Tracking · Як я визначаю події перед порівнянням витрат на кампанії
Чотири постбеки: чотири конверсії, дві події чи один клієнт?
Рахуйте визначені бізнес-події, а не сповіщення. Повторна доставка, нова подія та оновлення статусу потребують різної обробки. Видалення всіх повторів за click ID також може прибрати коректні наступні події.
Умовний діагностичний приклад. Ідентифікатори, числа й налаштування вигадані; це не результати клієнта та не типові налаштування платформи.
Усі чотири сповіщення належать одному перевіреному тестовому шляху T031. Повтор реєстрації містить той самий ID і дані. Останнє сповіщення змінює статус початкової реєстрації, а не створює нову. У прикладі зв’язки між ID вважаються перевіреними.
На вузькому екрані таблицю можна прокручувати горизонтально.
| Сповіщення | ID / тип події | Як розуміти |
|---|---|---|
| 1 | E101 / registration / pending | Перше повідомлення про реєстрацію |
| 2 | E101 / ті самі реєстрація й статус | Повтор сповіщення 1 |
| 3 | D201 / first_deposit / accepted | Окрема наступна подія |
| 4 | E101 / registration / approved | Оновлення статусу початкової події |
RedTrack має різні режими обробки дублів: створення, ігнорування або оновлення конверсії. Перевірте фактичний режим та ідентифікацію події; цей приклад не задає універсального налаштування. Документація платформи; перевірено 14 жовтня 2026 р.: RedTrack: conversion types and duplicates.
Що перевірити далі
- Пов’яжіть спроби доставки з подіями. Тут чотири сповіщення, дві різні бізнес-події, одна реєстрація та один FTD — не чотири нові клієнти.
- Перевірте, як інтеграція розрізняє повтори та зміни статусу. Перехід pending → approved не обов’язково створює нову конверсію; однаковий click ID не завжди означає дубль події.
- Звірте трекер і систему-отримувача. Виправлення в одній системі не доводить оновлення кількості чи суми в іншій. Запишіть очікуваний результат і перевірте після передбаченої затримки.
Які висновки підтверджені
Для показника схвалених реєстрацій у прикладі результат — одна; для прийнятих FTD — також один. Не можна додати два типи подій і назвати їх двома залученими клієнтами. Без ID чи історії статусів кількість унікальних подій залишається невідомою.
Чим може допомогти James
James може розділити сповіщення, події та статуси в журналі розбіжностей і перевірити правила підрахунку. У таблиці виділіть рядок для кожної окремої події, а повтори й оновлення вкажіть у примітках до доказів. Не видаляйте записи лише заради однакових підсумків.
Запишіть докази в таблицю Tracking · Як я визначаю події перед порівнянням витрат на кампанії
Завантажити таблицю для перевірки трекінгу
Порівняйте звіти за однією кампанією та однією подією конверсії. Зберігайте підтвердні дані й наступні кроки в одному файлі.
Report downloads are not shared through this portfolio.
Англійською · XLSX · 9 КБ · Безкоштовно, без реєстрації
- На аркуші Review визначте подію, період звіту та правила порівняння. Вносьте підсумки трьох джерел після узгодження параметрів.
- На аркуші Event log запишіть вибрані події, час і підтвердні дані. Для невирішених розбіжностей призначте відповідального та дату наступної перевірки.
Порожня різниця означає неповні або непорівнювані дані. Нуль означає однакові підсумки, але не підтверджує збіг усіх подій. Файл містить чітко позначений умовний приклад.
Запитання про трекінг перед зміною кампанії
Постбек успішний. Чому кількість конверсій у звітах різна?
Успішний запит сам по собі не доводить, що потрібну подію записано з правильним кліком і включено до відкритого звіту. Перевірте обидва етапи передавання, зіставлення подій, основу дат, фільтри й затримку оновлення. Переглянути заповнений приклад 10 / 9 / 10
Чи можна порівнювати CPA реєстрації та першого депозиту?
Ці показники відображають різні результати. Порівнюючи CPA, використовуйте те саме визначення події, однакову одиницю підрахунку та однаковий набір даних у звітах. Зниження CPA реєстрації саме по собі не означає зниження вартості залучення першого депозиту чи зростання прибутковості.
Який контекст допоможе під час обговорення обов’язків із трекінгу?
Опишіть посаду, ринок, інструменти та відповідні обов’язки з трекінгу. Для першого обговорення достатньо загального анонімізованого прикладу; не надсилайте паролі, дані гравців або конфіденційні звіти.
Як цей метод пов’язаний із моєю роботою
Мій практичний досвід охоплює платний трафік у APAC і S2S-трекінг у RedTrack. Цей посібник показує, як я визначив би розбіжність у звітності, виявив невирішені питання та обрав наступні перевірки. Команда з найму може використати його для обговорення мого підходу до вимірювання та роботи з кампаніями.
Це діагностичний посібник, а не клієнтський кейс чи обіцянка однакових підсумків у всіх системах.
Обговорити посаду медіабаєра
Розкажіть про компанію, посаду, формат роботи та обов’язки щодо кампаній або трекінгу, які ви хочете обговорити.
Робоче спілкування відбувається англійською мовою.
For job opportunities, use the current contact page.
Discuss a role with James (English)