Для того, щоб наша аналітика давала результат, ми не будуємо дашборди до тих пір, поки не маємо надійного потоку даних.
Відповідно, в першу чергу нам треба запевнити себе (та всіх навколо), що дані в усьому ланцюжку – коректні.
І нас цікавить саме весь ланцюжок – від рекламних кабінетів до Google Analytics, далі до CRM, в CRM від лідів до угод, потім – оплати та надходження грошей, в кінці – до PnL та валового прибутку.
Спойлер: буквально на будь-якому з цих переходів можуть (і будуть) відбуватися втрати чи викривлення даних.
Щоб мінімізувати шкоду для бізнесу, ми вводимо розуміння “контрольного тоталу”.
Це сума чогось, яка існує в двох (чи більше) етапах проходу наших даних і може використовуватись для звірки.
Якщо контрольний тотал співпадає – все працює правильно. Якщо ні, вводимо допустимий відсоток відхилення, після чого починаємо шукати та виправляти проблему.
Набір контрольних тоталів фіксується під кожний конкретний бізнес окремо та, в залежності від зрілості та ніші, може містити і проміжні стадії (співвідношення MQL/SQL, оплату/інвойси, маржу по продукту).
Для загального розуміння наведу базовий набір тоталів, який підійде більшості бізнесів:
- Витрати (Spend)
- Кліки (Clicks)
- Сесії (Sessions)
- Ліди (Leads)
- Угоди (Deals)
- Виручка (Revenue)
- Повернення (Refunds)
- Валовий прибуток (Gross Profit)
Цей набір, разом із допустимим відхіленням (умовно, ми кажемо, що готові жити з відхиленням не більше, ніж 5%), фіксується як стандарт компанії.
Приклади звірки контрольних тоталів:
– Витрати в рекламних кабінетах мають збігатися з витратами у зведеному звіті.
– Виручка в CRM звіряється з банком і бухгалтерією за узгодженими правилами визнання та датою (враховуючи інвойси, часткові оплати, акти).
По суті, звірка контрольних тоталів – наша сигналізація.
Це швидка перевірка на рівні “все/нічого”. Ми дивимось тільки на фінальні суми, щоб зрозуміти, чи можна вірити звіту в цілому.
Не плутай звірку тоталів зі звіркою даних, бо це вже інша штука – процедура пошуку причини. Там ми вже ліземо всередину даних, щоб зрозуміти, чому вони не зійшлися і чи допустима ця розбіжність.
Звірка даних відбувається через порівняння ключових пар між різними джерелами.
Якщо на рівні контрольних тоталів ми відповідаємо на питання “чи цифри збігаються?”, щоб зрозуміти – йдемо далі до звіту чи ні, то на рівні звірки даних наше питання вже “чому цифри різні і де саме дірка?”.
Тобто, ми йдемо з рівню “макро” (у тоталах ми дивимось тільки суми) до рівню “мікро” (де можемо дивитись вже конкретні розрізи, дні, ID тощо).
Приклад звірки даних по ключових парах між джерелами:
– Рекламні кабінети і GA4: кліки і сесії.
– GA4 і CRM: подія ліда (generate_lead або інший маркер) і нові ліди.
Як і з тоталами, поріг розбіжності задається на старті та фіксується. Його не переграють після отримання результатів. Цей поріг і допуски зберігаються окремо для кожної пари джерел (Ads-GA4, GA4-CRM) і для кожного типу трафіку.
Якщо розбіжність вища за норму – ми одразу ставимо на паузу всі рішення. Ця пауза стоїть допоки не знайдено місце втрати даних.
Цей текст – частина уроку “Глибока аналітика” з мого (ще не опублікованого) 4-го модуля безоплатного курсу по системному маркетингу “Маркетологія”.