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