Ваша виручка росте тільки в гривні

Фінансовий директор на нараді показує графік: виручка за рік +22% у гривні. Зал задоволений. 📈 Але гривня за цей рік втратила частину купівельної спроможності — і якщо накласти на графік індекс інфляції, картина інша.

Приклад: роздрібна мережа звітує про +22% виручки р/р. Інфляція за той же період — близько 12%. Реальний приріст — трохи більше 8%, а не 22%. Якщо додати девальвацію гривні до валют закупівлі (імпортний товар дорожчає в доларах), маржа може взагалі просідати, навіть коли виручка в гривні росте.

Це класична пастка номінальних метрик: гривня — не стабільна одиниця виміру, а змінна, яка сама впливає на результат. 💸 Без дефлятора будь-яке «зростання» у звіті — суміш реального результату і інфляційного шуму.

Правило просте: кожен показник у гривні, який ви порівнюєте рік до року, спочатку дефлюйте на CPI (або PPI, якщо йдеться про закупівлі), а тоді вже рахуйте тренд. 📊

Яким дефлятором користуєтесь ви при оцінці динаміки виручки — CPI, курсом USD чи власним кошиковим індексом?

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

Ваша воронка конверсії рахує мертвих відвідувачів

Сесія без подій — це ще не людина, яка пішла. 📉 У GA4 та більшості BI-дашбордів крок воронки "зайшов на сайт → поклав у кошик → купив" рахує кожну сесію як окрему спробу живої людини. Але частина цих сесій — боти, що перевіряють ціни, передзавантаження прев'ю в месенджерах, повторні відкриття вкладки з того самого девайсу. Вони формально "зайшли", але фізично не могли "купити" — у них немає наміру.

Якщо такі сесії не відфільтровані, знаменник воронки штучно роздутий, і конверсія виглядає нижчою, ніж реальна купівельна поведінка. 🔍 Команда бачить "погану" конверсію 1.2%, запускає A/B-тест на кнопці "Купити", а насправді проблема в тому, що 30% трафіку на вхідному кроці — це шум, якого не можна конвертувати в принципі.

Перевірка проста: порахуйте частку сесій з тривалістю менше 2 секунд і без жодної взаємодії. Якщо їх більше 10-15% — ваша воронка рахує мертві душі, а не рішення покупців.

Хто у вас уже чистив вхідний трафік воронки від бот-сесій перед тим, як рахувати конверсію? 🤔

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

Більше кліків не означає більше заявок

Міф: якщо CTR вищий, а трафік на лендінг зростає — маркетинг працює краще, і можна сміливо масштабувати бюджет 📈

Факт: GA4 і будь-яка подієва аналітика рахують клік як намір, а не як людину з проблемою, яку розв'язує ваш продукт. Класичний приклад — креатив із провокаційним заголовком чи знижкою 90%: CTR злітає вдвічі, вартість кліка падає, звіт виглядає святково. А конверсія в заявку просідає, бо прийшла аудиторія, яка клікнула з цікавості, а не з наміром купити.

Я бачив кейс: канал із CTR 1,2% давав 40 заявок на 1000 кліків. Новий креатив підняв CTR до 3,1% — заявок стало 22 на ті самі 1000 кліків. Формально трафік "покращився", реально — погіршився якість. Якщо оцінювати кампанію лише за CTR чи вартістю кліка, ви оптимізуєте не під гроші, а під ілюзію ефективності.

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

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

Ваш BI-дашборд рахує середню зарплату неправильно

Уявіть офіс з десятьох людей: дев'ять отримують по 20 тисяч, один — мільйон. Середня зарплата — 118 тисяч. Формально правда, по суті — брехня. 📊 Так само влаштована половина звітів про "середню зарплату по Україні" чи "середній чек клієнта", які ви бачите в дашборді щоранку.

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

На практиці це означає: якщо ваш середній чек раптом виріс на 15% — перевірте, чи це не один корпоративний клієнт купив партію на мільйон. Якщо середня зарплата в галузі "зростає" — подивіться, чи не кілька топменеджерів тягнуть статистику. 🔍 Правильний звіт показує і середнє, і медіану поруч — різниця між ними і є головна інформація.

Яку метрику показує ваш дашборд за замовчуванням — середнє чи медіану, і чи знаєте ви, наскільки вони розходяться?

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

П'ять хвилин проти нового дашборда без хаосу

Команда просить новий дашборд «на вчора» — і це перевірка, чи у вас є процес, а не паніка з готовими графіками. Ось як пройти цей шлях без переробок:

1️⃣ Спочатку питання, а не метрика. Запишіть, яке рішення людина прийме, побачивши цифру. Немає рішення — немає сенсу в дашборді.

2️⃣ Знайдіть одну таблицю-джерело правди. Якщо дані для цього звіту вже лежать у трьох різних місцях — зупиніться й узгодьте визначення (що таке «активний користувач», яка валюта, який часовий пояс) ще до відкриття BI-інструмента.

3️⃣ Намалюйте на папері, перш ніж тягнути поле у Looker Studio чи Power BI. П'ять хвилин скетчу економлять дві години перебудови фільтрів.

4️⃣ Додайте один контрольний показник — число, яке має збігтися з уже існуючим звітом. Якщо не збігається, проблема в даних, а не в дизайні.

5️⃣ Покажіть чернетку одній людині з команди, яка ставила питання, до того, як оформляти фінал. Відгук на цьому етапі коштує хвилину, після релізу — день переробки 🔄

Швидкий дашборд без цих кроків — це просто гарна картинка, яка бреше впевнено 📊

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

Модель показала 94% — довіряєте цифрі

Уявіть ситуацію: ваш дата-сайентист презентує модель прогнозування відтоку клієнтів. Accuracy — 94%, ROC-AUC — 0.91, усі графіки красиві. Менеджмент готовий викатити модель у прод і автоматично відключати "ризикових" клієнтів від знижок 📊

Але є деталь: клас "відтік" у вибірці — лише 6% від усіх клієнтів. Модель, яка просто завжди каже "не піде", матиме ту саму accuracy 94% — і при цьому буде абсолютно марною.

Що б ви зробили на місці аналітика, який це помітив?

1️⃣ Мовчки переробили б метрику на precision/recall і показали керівництву нову презентацію — без пояснень, чому цифри "погіршились"

2️⃣ Відкрито сказали б, що попередня метрика нічого не означає, і попросили тиждень на повторну валідацію — ризикуючи виглянути як той, хто гальмує запуск

3️⃣ Запустили б модель як є, бо бізнес вже чекає результат, а виправити можна й після релізу "по факту даних з продакшену"

У моєму досвіді варіант 3 — це той момент, коли компанія платить за "довіру до дашборда" клієнтськими грошима 💸 Коректна метрика для незбалансованих класів — не бюрократія, а єдиний спосіб дізнатись, чи модель взагалі щось вміє.

Який варіант ваш і чому?

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

Перевір модель за пʼять хвилин до продакшена

Перед тим як викладати модель у прод, прожени її через коротку перевірку — це займе пʼять хвилин, а рятує тижні 🧪

Крок перший: розбий дані не випадково, а за часом. Якщо тренуєш на даних до вересня, тестуй на жовтні — так, як модель реально зустріне майбутнє.

Крок другий: перевір, чи немає одного й того самого клієнта чи користувача одночасно в трейні й тесті. Витік через ID — найчастіша причина «надто гарних» метрик 📊

Крок третій: порахуй baseline — просту евристику чи середнє значення. Якщо модель обганяє її лише на кілька відсотків, складність навряд чи виправдана.

Крок четвертий: подивись на розподіл помилок, а не тільки на середню. Модель може бути точною в середньому і катастрофічно помилятись на критичному сегменті — великих чеках, нових клієнтах, рідкісних класах.

Крок пʼятий: запусти модель на даних за останній тиждень, яких вона взагалі не бачила під час розробки. Якщо метрика просіла — маєш drift, і краще дізнатись про це зараз, а не від бізнесу через місяць ⚠️

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

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

BigQuery тепер розуміє питання, а не тільки SQL

Google розкотив conversational analytics у BigQuery на нові регіони — тепер можна питати дані людською мовою, і модель сама збирає SQL під капотом 🤖 Звучить як кінець професії аналітика. Насправді це кінець найнуднішої її частини.

Проблема нашого BI завжди була не в тому, що хтось не вміє писати JOIN. Проблема в тому, що менеджер хоче відповідь за хвилину, а дешборд будується тиждень — і поки він будується, питання вже застаріло. Conversational-шар знімає саме цю затримку: продакт сам питає "чому впала конверсія в Києві у вівторок" і отримує цифру без тикета в черзі аналітики.

Але тут ховається пастка 🪤 Природна мова приховує знаменник. Людина спитала "скільки клієнтів купили повторно" — і не уточнила, повторно за тиждень чи за весь час існування акаунта. Модель мовчки вибере якийсь дефолт, видасть красиву цифру, і ніхто не перевірить логіку запиту, бо він згенерований "магією", а не живою людиною з іменем у коміті.

Висновок простий: роль аналітика не зникає, вона зсувається вище — від написання запитів до контролю за тим, які припущення модель закладає в кожен запит 📊 Хто зараз не документує бізнес-логіку метрик у вигляді, зрозумілому не тільки людям, той за рік буде розгрібати звіти, згенеровані ботом, що вигадав власну версію "активного користувача".

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

Python чи SQL для аналізу — хто кого

Питання "SQL чи Python" ставлять неправильно — це не вибір релігії, а питання де лежать дані і що з ними треба зробити. 🔧

SQL виграє, коли дані вже в BigQuery чи Postgres і завдання — агрегація, джойни, віконні функції. Запит на 50 млн рядків виконається за секунди прямо в базі, без переливання даних кудись ще. Якщо можеш описати задачу через GROUP BY і WINDOW — пиши SQL, це буде швидше й дешевше за будь-який pandas.

Python потрібен там, де SQL закінчується: статистичні тести, прогнозні моделі, текст і NLP, графіки для презентації, цикли з умовною логікою. Спробувати зробити когортний аналіз з лагами та експоненційним згладжуванням у чистому SQL — технічно можливо, але код вийде нечитабельним і його ніхто не підтримає через місяць.

Типова робоча схема: важку агрегацію й фільтрацію роблять у BigQuery — там дешевше рахувати на масиві даних, ніж тягнути сирі рядки в ноутбук. А вже агреговану таблицю на тисячі рядків забирають у Python для моделювання й візуалізації. 📊

Помилка, яку бачу постійно: тягнути необроблені дані в pandas і робити groupby там, сплачуючи і за BigQuery слот, і за памʼять ноутбука. Рахуй там, де дані лежать, аналізуй там, де потрібна гнучкість.

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

Третина трафіка ховається у Direct

Канал Direct у GA4 — це не аудиторія, яка вручну вбила адресу в браузер. Це кошик для всього, що система не змогла розпізнати 📊

Чотири факти. In-app браузери Instagram, TikTok і Facebook стирають referrer майже завжди — клік зі сторіз падає в Direct, хоча прийшов із соцмережі. Месенджери Telegram і Viber у більшості випадків теж не передають referrer header — ще один постачальник "прямого" трафіка. За індустрійними оцінками типовий сайт має 20–40% трафіка в Direct, і до половини цього обсягу — саме нерозпізнані джерела, а не реальні прямі заходи. Додайте сюди lookback window у GA4: мітка кампанії живе 6 місяців, а сесія рветься через 30 хвилин простою — тому навіть власна розсилка без utm осідає в тому самому кошику.

Висновок простий: якщо частка Direct зростає місяць до місяця — це не лояльна аудиторія повертається напряму, а хтось перестав маркувати посилання — пуші, QR-коди, офлайн-банери, email 🔗

Тримайте Direct як метрику якості розмітки, а не як окремий канал залучення. Різке зростання — привід перевірити, де саме загубились utm, а не привід радіти бренд-трафіку.

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

Шість цифр важливіші за заголовки новин

Поки обшуки в НБУ займають стрічки, справжній стан фінансів країни видно не в заявах нардепів, а в кількох цифрах з відкритих джерел 📊. Ось що можна перевірити самому за десять хвилин, не чекаючи чужих висновків.

Зайди на сайт НБУ й порівняй міжнародні резерви з минулим місяцем — падіння більш ніж на 5% за кілька тижнів це вже сигнал, а не цифра для звіту.

Звір офіційний курс із готівковим на Мінфін.ком.уа — спред понад дві гривні означає, що ринок готується до девальвації швидше за уряд.

Перевір виконання дохідної частини бюджету на kazna.gov.ua — якщо податкові надходження відстають від плану більше місяця, секвестр уже на столі.

Знайди графік траншів МВФ і ЄС на цей квартал — пропущений транш каже більше, ніж будь-яка заява пресслужби 💬.

Подивись дохідність останнього аукціону ОВДП Мінфіну — зростання ставки це ціна довіри до держави, виміряна у відсотках.

Звір обсяг експорту зерна через порти Одещини за тиждень з минулим роком — реальна ціна блокади видна там, а не в заголовках.

Ці шість пунктів займуть десять хвилин і скажуть більше, ніж тиждень новин 🔍.

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

За банкрутствами стоїть кредитний бум

З початку року понад 1200 українців подали заяви про особисте банкрутство — на 37% більше, ніж торік, і це вже четвертий рік поспіль зростання 📈. На перший погляд виглядає як сигнал біди: війна, доходи не встигають за цінами, люди тонуть у боргах.

Подивився на структуру цифр, а не на заголовок. Дві третини банкрутів — люди 25-45 років, найактивніший вік для споживчих кредитів і покупок у розстрочку. Наймолодшому — 20, найстаршому — 77, але основна маса припадає саме на тих, хто активно брав картки й спліти у 2021-2023, коли банки масово роздавали ліміти під відновлення економіки після локдаунів.

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

1200 справ на мільйони активних позичальників — для банківської системи це некритично 💳. Для аналітики боргового навантаження — це маркер, що дивитись варто на 2021-2023, а не на поточний курс чи інфляцію.

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

Pandas чи Polars — коли міняти звичку

Pandas тягне датасет в один потік, і на 5 млн рядків groupby з'їдає хвилину й половину RAM. Polars той самий запит жене в кілька потоків через Rust-ядро і встигає за секунди, бо не копіює дані на кожному кроці 🐻‍❄️ Різниця не в красі синтаксису — вона суто фізична: lazy-виконання Polars будує план і виконує його один раз, а не рядок за рядком, як ваш звичний eager pandas-код.

Але міняти стек варто не завжди. Якщо аналіз — це Jupyter, 50 тисяч рядків і купа готових snippet'ів з Stack Overflow, pandas швидше доведе до висновку, бо екосистема (matplotlib, seaborn, statsmodels) зшита саме під нього. Polars виграє там, де дані вже не влазять у звичку: ETL на мільйони рядків, повторювані пайплайни, продакшн-скрипти, де секунди виконання рахують у гроші за compute.

Практичне правило: до 1 млн рядків і разового аналізу — pandas, бо швидше написати, ніж переписати. Понад 5 млн рядків, регулярний запуск або межа по пам'яті — Polars, і різницю відчуєте вже на першому запуску ⚡️ Міксувати обидва в одному проєкті — нормально: читання й важкі трансформації на Polars, фінальний df.to_pandas() — для візуалізації й звичних бібліотек.

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

Графік відключень став фічею прогнозу

Взимку 2024–2025 онлайн-рітейлер генераторів і павербанків почав системно помилятися з прогнозом попиту. Модель на Prophet рахувала сезонність і день тижня — класика. Але попит у Харкові, Одесі чи Сумах стрибав не за календарем, а за графіком відключень: день без світла — і замовлення на зарядні летять вгору за годину. ⚡️ Модель цього не бачила і або не завозила товар, або затарювала склад там, де відключень уже не було.

Data science команда зробила просте: витягла графіки ГПВ по регіонах як окрему змінну з лагом у 2–6 годин і перейшла з однієї глобальної моделі на LightGBM per-region замість Prophet. Сезонність лишили як фон, а не головний сигнал. 🔌

Результат за квартал: MAPE у проблемних регіонах впав з 38% до 14%. Stockouts на топ-20 SKU скоротились на 46%, надлишкові запаси на складах — на 23%. Головний висновок не про модель, а про фічі: та сама архітектура з правильною зовнішньою змінною дає більше, ніж будь-яке тюнінгування гіперпараметрів. 📊

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

Дашборд живе довше ніж ваша логіка розрахунку

У середньому BI-дашборд переживає три зміни бізнес-логіки, перш ніж хтось згадає перевірити формули всередині 📊 Оце і є корінь проблеми, яку рідко обговорюють.

Перше: дашборд, зібраний рік тому на Looker Studio чи Tableau, досі показує "виручку" за формулою, яку фінансовий відділ змінив ще у лютому. Ніхто не ламав звʼязок — просто визначення змінилося, а візуалізація лишилась старою.

Друге: 70% дашбордів у типовій компанії не мають власника після запуску. Автор пішов в інший проєкт, і правити логіку вже боїться будь-хто — раптом зламає щось невидиме.

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

Четверте: дашборд, який оновлюється автоматично, створює ілюзію, що дані завжди правильні. Автоматизація прибирає ручну помилку, але не прибирає застарілу бізнес-логіку під капотом 🔍

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

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

Один SMS-крок зʼїдав чверть оплат

Команда мобільного застосунку доставки два тижні дивилась на графік і не розуміла, чому конверсія з кошика в оплату раптом просіла на 15%, хоча трафік і CTR реклами лишились на тих самих цифрах. Перше підозрюване — платіжний провайдер, але логи там чисті.

Подивились глибше: вивантажили events_* з GA4 у BigQuery і побудували покрокову воронку по user_pseudo_id замість агрегованих звітів в інтерфейсі. 📊 Виявилось, що тиждень тому додали обов'язкову верифікацію номера через SMS для всіх, хто оплачує картою вперше з цього девайса — захист від шахрайства. Проблема: на Android з повільним інтернетом код часто приходив після таймауту капчі, і юзер застрягав на екрані без помилки й без можливості повторити.

Рішення просте — подовжили таймаут з 30 до 90 секунд і додали кнопку «надіслати код ще раз» замість мовчазного зависання. ⚡️

Результат за тиждень: конверсія оплати повернулась з 71% до 86%, втрачені через капчу сесії впали в чотири рази. У виручці з мобільного трафіку це дало +9% без жодної копійки в рекламу — просто повернули те, що вже купувало.

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

SQL у BigQuery тепер пишеться як конвеєр

Google довів до GA pipe syntax у BigQuery — спосіб писати запити, про який аналітики просили роками. Замість вкладених підзапитів і купи CTE, через які доводиться скролити вгору-вниз, щоб зрозуміти логіку, тепер можна писати послідовно: FROM table |> WHERE ... |> AGGREGATE ... |> ORDER BY. Кожен оператор — окремий крок, і результат видно після кожного з них, а не лише в кінці всього запиту. 🧩

Для когортного аналізу чи воронки конверсій це не косметика. Раніше дебаг такого запиту означав розкручувати вкладеність ізсередини: яка умова на якому рівні фільтрує дані. З pipe syntax кожен крок можна виконати окремо, подивитись проміжний результат і зрозуміти, де метрика зламалась — та ж проблема, що й з парадоксом Сімпсона на дашбордах, тільки тепер її легше знайти в самому запиті. ⚙️

Головне: це не новий діалект і не нова оплата — звичайний Standard SQL, стару нотацію можна лишити там, де вона вже працює, і міксувати з новою в одному запиті. Почніть з однієї довгої аналітичної вибірки з трьома-чотирма рівнями вкладеності — перепишіть її на pipe syntax і порівняйте, скільки часу пішло на розуміння логіки колегою, який бачить запит вперше. 📊

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

Сім перевірок перед чорною п'ятницею

Трафік під час розпродажу зростає в 3-5 разів за кілька днів — і саме тоді аналітика найчастіше ламається непомітно, бо до цього все "ніби працювало" на звичайному навантаженні. 🛒 Ось що варто перевірити сьогодні, а не 28 листопада:

1. Event purchase шле transaction_id і спрацьовує рівно раз на замовлення — без дублів від повторного рендеру сторінки подяки.
2. UTM-мітки на email та push розсилках прописані вручну, а не "підхопляться автоматично" — автопідхоплення часто губить джерело.
3. GA4 real-time звіт витримує спайк без затримки понад 2-3 хвилини — якщо затримка росте, під навантаженням вона виросте ще більше.
4. Explore-звіти не йдуть у sampling при зростанні обсягу подій — перевір ліміт у властивостях акаунта.
5. Server-side tagging (якщо є) не впаде при піковому RPS — подивись, чи є автоскейлінг контейнера.
6. BigQuery має запас бюджету слотів на дні з піковими запитами дашбордів — інакше звіти зависнуть саме в момент, коли на них найбільше дивляться.
7. Алерти на аномалії продажів і конверсії налаштовані заздалегідь, а не "подивимось вручну" — руками за святковим трафіком не встежиш. 📊

Перевірка займає години, а ціна помилки — втрачена статистика найважливіших днів року.

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

Гугл вчить BI рахувати замість малювати

Google додав до Looker Studio Pro генерацію даних агентом прямо з промпту — "порахуй відтік по когортах" замість двадцяти кліків по фільтрах і калькульованих полях 🤖 Для когось це виглядає як кінець ручної аналітики, та різниця в деталях. Агент непогано справляється з описовими запитами: суми, частки, динаміка. Але щойно треба врахувати специфіку бізнесу — як саме визначити "активного користувача", чи рахувати повернених клієнтів в LTV, що робити з тестовими акаунтами в базі — модель бере найочевидніше припущення, а не правильне для вашого продукту.

Практичний висновок: роль аналітика зміщується з побудови запитів на формулювання бізнес-логіки заздалегідь. Якщо у вас немає чіткого глосарія метрик — документа, де "активний користувач" чи "конверсія" визначені однозначно — агент видаватиме красиві, але неузгоджені між собою цифри в різних звітах 📊 Компанії, які вже мають data dictionary в BigQuery чи dbt, отримають від таких інструментів реальне прискорення. Ті, хто визначає метрики на льоту в головах окремих аналітиків, отримають просто новий спосіб плодити розбіжності — тільки швидше й з виглядом авторитетності.

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

П'ять джерел, де цифри не бояться брехати

Офіційна статистика під час війни — завжди переговори між точністю і доступністю даних 📊 Ось що реально читати, а не просто цитувати.

Дашборд НБУ з інфляційними звітами — єдине місце, де цифра 11% за жовтень і прогноз 12,5% на кінець року не розходяться з методологією розрахунку, яку можна перевірити.

Міністерство фінансів і щомісячні звіти про виконання бюджету — там видно касові розриви раніше, ніж про них напишуть новини.

Open Budget — держреєстр, де бюджетні видатки розписані по розпорядниках, а не по красивих агрегатах з пресреліза.

Державна митна служба з відкритою статистикою зовнішньої торгівлі — найшвидший спосіб перевірити, чи справді впала металургія на ті самі "90%", про які пишуть.

Trading Economics або CEIC для крос-перевірки українських цифр із тим, як їх бачать зовнішні інвестори — розбіжність у трактуванні часто важливіша за саму цифру.

Жодне з цих джерел не замінює аналітика 🧮 Вони лише дають сировину, з якої видно, де журналісти округлили, а де уряд обрав вигідну базу порівняння.

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат

Банер без кліку коштував магазину 12% виручки

Онлайн-магазин електроніки готувався до чорної п'ятниці і бачив у GA4 стабільну картину: трафік з головного банера йшов, конверсія не падала, усе виглядало нормально 📊 Але менеджер з продажів помітив розбіжність — виручка з промо-категорії відставала від плану на старті акції минулого року, хоча цифри в дашборді казали «все за графіком».

Підняли сирі події BigQuery і порівняли click на банері з session_start у тій же сесії. Виявилось: 40% «переходів» — це користувачі, які вже були на сайті з органіки, банер просто з'являвся в полі зору і трекер рахував impression як session source override, підміняючи канал атрибуції. Банер забирав чужу заслугу, а реальний referral traffic занижувався вдвічі.

Переналаштували атрибуцію: розділили view-through і click-through події, прибрали оверрайд джерела для вже активних сесій 🔧 Запустили той самий банер повторно — і цифри в дашборді впали, зате бюджет на медіапланування перерахували тверезо.

Результат: магазин зняв $8 тис. місячного бюджету з каналу, який насправді не приводив нових людей, і перекинув їх на ретаргетинг з реальним click-through 📈 Виручка з промо за тиждень акції зросла на 12% — не тому, що зʼявився новий трафік, а тому, що гроші нарешті пішли туди, де був справжній результат.

🛎Приєднуйтесь до ProАналітика 📊:
🌐 Канал | 💬 Чат