- Головна
- /
- Архів розсилок
- /
- Дайджест з вебаналітики #61
від 3 Липня 2026р.
Привіт 🙌
Поки GTM приліг відпочити перед великим апдейтом, я підготував для тебе новий випуск розсилки, де розповім, що важливого і корисного з’явилося за останні два тижні.
План на сьогодні такий:
Наші новини:
🌟 Оновлення на курсі "Розширені конверсії для Google Ads".
🌟 Оновлення на курсі "Server-Side GTM Basics".
Новини Google Analytics:
🔹 Віддалений MCP для роботи з даними через LLM.
Новини Google Tag Manager:
🔹 Нова сторінка Overview в GTM та beta-функціонал для конверсій покупок у Google Ads.
Новини Google BigQuery:
🔹 Conversational analytics у BigQuery став загальнодоступним.
🔹 Можливість запускати пайплайни після оновлення таблиць.
🔹 Connected Sheets тепер підтримує моделі TimesFM з BigQuery ML.
Інші новини:
🔹 Google Ads об’єднує розширені конверсії для вебсайту та розширені конверсії для лідів.
🔹 Боти вже генерують більшість HTML-запитів до вебсторінок.
Корисні матеріали:
🔥 Чому якість даних в сучасному світі стає ще більш важливішою ніж раніше.
🔥 Чому вам варто звернути увагу на Open Knowledge Format v.0.1 від Google.
Розпочнемо як завжди з наших новин.
🎬 Як передавати email і телефон користувача в Google Ads через Google Tag Manager без розробника
На YouTube-каналі Analytics Tips з’явилося нове відео.
Цього разу у відео не я, а Женя Максимова, яка показує, як передавати email і телефон користувача в Google Ads через Google Tag Manager для налаштування розширених конверсій.
Як ти знаєш, інколи ми відкриваємо окремі уроки з наших курсів, щоб ти міг безкоштовно розібратися з важливими темами на практиці.
Тож приємного перегляду! Лайки й коментарі, як завжди, дуже вітаються.
А якщо ти ще не розібрався з темою розширених конверсій або передачею персональних даних у Google Ads — welcome на курс Розширені конверсії для Google Ads.
🔄 Оновлення на курсі "Розширені конверсії для Google Ads"
Цього тижня у Жені новин, здається, навіть більше, ніж у мене :) Окрім нового відео на YouTube з'явилось і нове відео на курсі про нову бету в Google Ads. Назвали ми це відео «Як покращити роботу тегу за допомогою додаткових джерел даних».
Ну а що це за оновлення, для чого воно потрібне і як із ним працювати можеш переглянути по лінку нижче. Дивись нове відео в 3 лекції під номером 3.3.6.
🔄 Оновлення на курсі "Server-Side GTM Basics"
Не тільки Женя додає оновлення на свій курс. Звісно, я теж слідкую за актуальністю матеріалу. Тільки забуваю писати тут про оновлення, але не сьогодні.
Як я вже писав в попередніх листах google оновив логіку роботи із завантаженням бібліотеки Google Tag Manager через Server-Side GTM.
Інформація на курсі Server-Side GTM Basics, вже відповідає актуальній реалізації. Переглядай нове відео в 6 лекції під номером 6.3.2.
На цьому наші новини все. Переходимо до новин сервісів, якими ми користуємось щодня.
👉 Новини Google Analytics
🚩 Віддалений MCP для роботи з даними через LLM.
Тепер до даних GA4 можна підключатися не тільки через більш звичні для розробників інструменти на кшталт VS Code чи Codex, а й через звичні маркетологам чати, наприклад, через ChatGPT.
Тобто працювати з даними GA4 стало ще простіше: одразу в чаті можна ставити питання, аналізувати показники й шукати відповіді. І для цього всього не потрібно встановлювати пайтон собі на ноут чи робити якісь інші технічні налаштування.
Просто створи нове підключення в блоці Програми в Налаштуваннях. Як URL адресу сервера вкажи https://analyticsdata.googleapis.com/mcp/v1 і далі в налаштуваннях в блоці Розширенні налаштування OAuth вкажи ідентифікатор та секрет клієнта.
Загалом, думаю, багато хто вже на повну використовує різні MCP для підвищення ефективності і зручності своєї роботи, тому детальний гайд про те, як це налаштувати поки не писав, наче як те ж саме ти мав би робити вже багато разів.
Але якщо для тебе це актуально і ти хочеш детальний гайд, як усе підключити, напиши мені після отримання цього листа у відповідь: “Хочу детальний гайд по налаштуванню віддаленого GA4 MCP”.
Якщо бачитиму, що тема цікавить більше ніж 20 людей, вже наступного тижня підготую окрему статтю на блозі.
👉 Новини Google Tag Manager
🚩 Нова сторінка Overview в GTM та beta-функціонал для трекінгу конверсій покупок для Google Ads
Ти, напевно, помітив, що останніми днями Google Tag Manager дуже сильно лагає.
Я вже писав раніше, що Google обіцяв великий апдейт GTM наприкінці червня. Як бачимо, трохи не встигли — оновлення плавно переїхало на липень. Але великий апдейт нас справді очікує, і перша його частина вже з’явилася.
Наразі найкорисніше оновлення в тому, що на сторінці Overview з’явилася схема передачі твоїх даних до сервісів Google. Тепер там можна побачити, куди саме передаються дані і скільки тегів задіяно для кожної системи. Дякую Google, тепер можна швидше прикинути вартість аудиту))
Також Google додав можливість “швидко і зручно” створювати конверсію покупки для Google Ads.
Але, думаю, у більшості випадків така конверсія може принести більше проблем, ніж користі. Все-таки такі важливі дії, як покупка, краще відстежувати через dataLayer, а не збирати дані зі сторінки за допомогою візуального конструктора.
Але якщо з якоїсь причини ти хочеш детальніше розібратися, як працює цей новий функціонал, уже є відео, де Julius Fedorovicius детально проходиться по новому інтерфейсу Google Tag Manager і показує, як працює налаштування Google Ads purchase conversion.
Рекомендую переглянути його на x2. Цього достатньо, щоб зрозуміти, як воно працює. Ну і якщо колись побачиш подібні назви тегів і змінних на проєкті в GTM, то одразу знатимеш, як це було зроблено і рівень спеціаліста, який це налаштовував.
👉 Новини Google BigQuery
Останнім часом апдейтів у сервісах стає все більше, тому я вирішив, що немає сенсу розповідати про все підряд. У розсилці буду акцентувати увагу тільки на тому, що, на мою думку, є найбільш важливим і корисним.
Тому цього разу пишу лише про три новини по BigQuery (звісно апдейтів за цей час було більше).
🚩 Conversational analytics у BigQuery став загальнодоступним.
Цей функціонал дозволяє створювати агентів на основі твоїх даних у BigQuery: таблиць, views, графів та інших джерел. Далі агенту можна задавати інструкції, додавати перевірені запити, терміни глосарію та інші налаштування, щоб він краще розумів контекст і точніше відповідав на запити.
Разом із переходом у загальну доступність з’явилися й додаткові можливості. Тепер можна змінювати режим мислення прямо під час розмови, агенти можуть ставити уточнювальні питання, а у відповідях з’явилися посилання на джерела, щоб було зрозуміло, на які саме джерела спирається відповідь.
Окремо варто відзначити підтримку параметрів у перевірених запитах і можливість використовувати AI-функції BigQuery, зокрема AI.KEY_DRIVERS, AI.IF, AI.SCORE, AI.CLASSIFY, AI.SIMILARITY та AI.SEARCH.
Загалом функціонал виглядає дуже перспективно: агент може допомагати будувати запити, аналізувати дані, працювати з таблицями об’єктів, а для нетехнічних користувачів є зручна інтеграція з Looker Studio — без потреби постійно відкривати Google Cloud Console.
Читати детальніше про Conversational Analytics >>>
Звісно, з таким функціоналом потрібно бути обережним: відповіді агентів усе одно варто перевіряти, особливо якщо йдеться про важливі бізнес-рішення або складну логіку аналізу.
Детальніше про налаштування агентів даних з нуля я вже говорив на одному з вебінарів, які проводив у травні. Якщо ти з якоїсь причини пропустив цей вебінар, але хочеш переглянути запис — напиши мені в особисті.
🚩 Можливість запускати пайплайни після оновлення таблиць.
Це оновлення особливо корисне для тих, хто працює з GA4-таблицями в BigQuery і будує навколо них регулярну обробку даних.
І це якраз вирішує дві класичні проблеми time-based запусків: або пайплайн стартує, коли дані ще не приїхали, або дані вже є, але пайплайн ще не відпрацював і звіти залишаються неактуальними довше, ніж потрібно.
На курсі BigQuery for Marketing я якраз пояснював один із варіантів вирішення: спочатку окремим запитом перевіряти, які таблиці були оновлені, і вже потім обробляти саме їх.
Але тепер у BigQuery з’явився більш зручний підхід: можна запускати пайплайни не за фіксованим часом, а після оновлення таблиці.
У налаштуваннях можна вказати, за якими таблицями потрібно стежити, і вибрати умову запуску: наприклад, стартувати після оновлення будь-якої таблиці зі списку або тільки після того, як оновляться усі потрібні таблиці.
Також можна налаштувати Min Execution Duration (від кількох хвилин до годин), щоб pipeline не запускався занадто часто, якщо таблиця оновлюється постійно, і Max Wait Duration, щоб він усе ж стартував, навіть якщо оновлень не було.
Для роботи з експортом GA4, де процеси часто залежать від моменту оновлення таблиць, це дуже корисне оновлення. Воно дозволяє будувати пайплайни, які одночасно більш актуальні по даних і менш затратні по ресурсах.
Єдине важливе уточнення: це не миттєвий запуск після зміни таблиці. BigQuery перевіряє оновлення приблизно раз на 3 хвилини, тому невелика затримка все одно можлива.
І ще момент — зараз функціонал у прев'ю, тобто може змінюватися і його краще тестувати перед використанням у продакшені.
Але загалом це сильний крок у бік зручнішої автоматизації для тих, хто працює з BigQuery, GA4-таблицями і регулярною обробкою даних.
🚩 Connected Sheets тепер підтримує моделі TimesFM з BigQuery ML.
Тепер ти можеш використовувати попередньо навчені моделі TimesFM з BigQuery ML безпосередньо з Connected Sheets. Це дозволяє створювати прогнози та виявляти аномалії в даних за допомогою функцій AI.FORECAST та AI.DETECT_ANOMALIES.
Для тих, хто не знайомий із Connected Sheets: це можливість працювати з даними BigQuery у звичному інтерфейсі Google Таблиць. Тобто ти можеш переглядати дані, будувати зведені таблиці, використовувати формули й створювати діаграми на основі всього набору даних із BigQuery.
Якщо ти ще не дуже впевнено працюєш із SQL, але хочеш використовувати можливості BigQuery, Connected Sheets може бути хорошим стартом. Ти підключаєш Google Таблицю до BigQuery і виконуєш частину задач у знайомому інтерфейсі Google Sheets, але джерелом даних при цьому залишається BigQuery.
А з підтримкою TimesFM, AI.FORECAST та AI.DETECT_ANOMALIES цей інструмент стає ще цікавішим для тих, хто хоче працювати з прогнозуванням і пошуком аномалій без повного занурення в інтерфейс Google Cloud.
👉 Google Ads об’єднує розширені конверсії для вебсайту та розширені конверсії для лідів
Google поступово об’єднує розширені конверсії для вебсайту та розширені конверсії для лідів в один спільний підхід.
І це не просто поєднання двох назв в одну: змінюється логіка роботи з джерелами даних. Раніше потрібно було обирати один спосіб налаштування: Google tag, Google Tag Manager або API. Тепер Google Ads може одночасно приймати дані користувачів із кількох джерел: тегів на сайті, Data Manager та API-з’єднань.
На мою думку, це логічний крок. На практиці дані часто приходять із різних місць: частина — із сайту, частина — через офлайн-імпорт, частина — через API. Тому об’єднання всього цього в один підхід виглядає природніше.
Читати детальніше в пості Matteo Zambon >>>
👉 Боти вже генерують більшість HTML-запитів до вебсторінок
Ця новина не зовсім зі світу аналітики, але вона точно впливає на нас як на аналітиків.
Matthew Prince із Cloudflare поділився статистикою, за якою боти вже обігнали людей за кількістю HTTP-запитів до HTML-сторінок. Тобто більшість таких запитів до сайтів тепер відбувається не з боку людей, а з боку автоматизованого трафіку.
Тут важливо правильно це трактувати: мова не про весь інтернет і не про те, що люди перестали користуватися сайтами. Мова саме про запити до HTML-сторінок, де частка ботів стала більшою за частку людей.
Якщо ти дивишся не тільки на дані в Google Analytics, а й на серверні логи, Cloudflare або інші технічні джерела даних, то, можливо, вже бачив це на своїх проєктах.
Наприклад, ми буквально 26–27 червня почали бачити дуже великий сплеск на наших сайтах. Для розуміння масштабу: за останні 24 години на сайті команди було приблизно 85 тисяч запитів, і з них близько 75 тисяч — це боти.
Звісно, це статистика Cloudflare, а не “середнє по всьому інтернету”. Але Cloudflare — достатньо великий гравець, тому ці дані добре показують загальний напрямок, у який рухається веб.
І тут у аналітиків одразу виникають логічні питання:
- як нам із цим жити, як це вимірювати і як розуміти?
- Раніше ми звикли не враховувати при аналізі бот-трафік. Але чи дійсно це правильний підхід в еру AI-агентів?
Повних відповідей в мене поки що немає, але я слідкую за рішеннями, які зараз пропонують різноманітні сервіси. Наприклад, буквально нещодавно Microsoft Clarity випустила оновлення, яке пропонує певне рішення для цього. У AI Bot Activity можна дивитися не просто факт наявності ботів, а й більш прикладні речі: скільки AI bot requests було на сайті, яку частку від загального трафіку вони займають, які сторінки сканують, які запити були успішними, перенаправленими або неуспішними.
Також у Clarity можна аналізувати бот-трафік на рівні доменів і шляхів, дивитися тренди в часі та краще розуміти, які сторінки найчастіше потрапляють у поле зору AI-ботів.
Окремо важливий пункт — CDN violations. Clarity може допомагати виявляти ботів, які звертаються до заборонених шляхів і порушують правила robots.txt. А завдяки трендам і фільтрації можна швидше знаходити проблемних сканерів і дивитися, як така активність змінюється з часом.
Найцікавіше, що ці дані Clarity бере з CDN, а не збирає JS кодом на сайті, а значить воно будуть досить точні. Зараз серед підтримуваних гравців — Fastly, Amazon CloudFront, Cloudflare, Azure Front Door та Akamai.
Звісно, це ще не універсальна відповідь на всі питання, оскільки сам підхід до аналізу AI-ботів тільки формується. Але це вже хороший крок у бік того, щоб бот-трафік був не просто “шумом у логах”, а зрозумілим шаром даних для аналізу.
І так, нам потрібно починати вчитись аналізувати цей шум, оскільки ми йдемо до світу, де значну частину покупок будуть робити не люди, а агенти (привіт Universal Cart і Universal Commerce Protocol від Google).
На цьому новини все - переходимо до корисних матеріалів
Сьогодні в корисних матеріалах поговоримо про два важливі моменти, які поки що не дають AI повністю розкритися в роботі з аналізом даних.
Перший — якість даних. Якщо дані зібрані погано, AI не зробить їх кращими. Він просто швидше масштабує ваші проблеми, які вже є в аналітиці.
Другий — бізнес-контекст. Навіть якщо схема і дані правильні, AI все одно потрібно пояснити, що означають метрики, як працює бізнес, які є нюанси в логіці продукту й чому ті чи інші дані потрібно трактувати саме так.
Про кожен із цих двох моментів — окремий корисний матеріал нижче.
🔥 Мовні моделі не мають імунітету до поганих даних
Кілька місяців тому я публікував картинку з простою, але дуже важливою думкою: мовні моделі не мають імунітету до поганих даних.
У травні я багато використовував цю тезу і в постах, і в презентаціях, і на вебінарах. Вона дуже добре пояснює, що насправді відбувається з AI в аналітиці.
AI дуже класно все масштабує.
От тільки нюанс в тому, що якщо твої дані зібрані якісно, структуровано й зрозуміло, ти, звісно, зможеш швидше отримувати корисні відповіді.
Але якщо дані погані, AI просто допоможе швидше отримувати більше відповідей, побудованих на неякісній основі (читай більше випадкових висновків, які далекі від реальності).
Радує, що не тільки я бачу цей тренд, про нього говорять зараз всі, хто більш-менш в темі.
Кріста Сейден, та сама, яка свого часу перейшла з Google до Amplitude, написала великий матеріал про те, чому data governance - тобто управління якістю, структурою та правилами роботи з даними - стає критично важливим в епоху AI-driven аналітики.
У статті вона також показує, як Amplitude намагається вирішувати цю проблему на рівні продукту: підсвічує можливі дублікати подій, допомагає знаходити відсутні описи й теги, пропонує AI-generated описи і загалом підштовхує команди до більш чистої таксономії даних.
Просто вдумайся, великі аналітичні сервіси вже створюють окремий функціонал для того, щоб допомагати компаніям систематизувати назви подій і покращувати якість даних. В нас зараз настільки велика проблема зі збором правильних даних, що під це будують окремі сервіси!
І я впевнений, що на них буде попит. На жаль, більшість людей не хочуть вчити як будувати систему нормально одразу, не хочуть витрачати час на створення
event map, узгодження назви подій, параметрів й логіки трекінгу. Всі хочуть швидких рішень.
Але питання в тому чи спрацюють ці рішення? Будувати систему, яка намагається нормалізувати криво зібрані дані виглядає як ще один костиль поверх вже існуючого. Набагато кориснішим було б провести навчальну роботу зі спеціалістами і навчити робити правильно одразу, але ж навчання продати набагато важче, ніж продукт, який "робить магію". Тому чекаємо більше "магічних" продуктів.
Як би там не було, хоч я й відійшов трохи від теми, статтю Крісти рекомендую прочитати. Навіть якщо ти слухав мої травневі вебінари, де я про це все говорив багато і детально, це буде хороше додаткове нагадування про те, чому якість даних зараз стає не просто технічною деталлю, а основою всієї AI-аналітики.
І я не втомлююся повторювати: аналітики, які вміють будувати надійні системи даних, будуть тими, хто зробить AI справді корисним для бізнесу. А значить — саме такі аналітики залишатимуться незамінними.
🔥 Як Google пропонує описувати бізнес-контекст для AI
Якість даних важлива проблема, але вона не єдина, яка заважає AI-аналітикам розкритись на повну. Є ще один великий фактор — бізнес-контекст.
Аналітик може поступово накопичувати потрібний бізнес-контекст просто виконуючи свої основні робочі задачі: десь через спілкування з колегами; десь через заглиблення в певний процес, чи через спілкування з клієнтами; прочитавши щотижневий звіт, чи ще один email і т.д. І потім усе це несвідомо використовувати, коли приходить пора написати SQL-запит чи підготувати ще один звіт, щоб максимально врахувати всі бізнес нюанси.
Але AI так не може. З ним ніхто не спілкується в коридорі. Його зазвичай не звуть на зустрічі, і на спілкування з клієнтами його теж не кличуть. Ніхто не передає йому цей контекст щодня як звичайному аналітику.
Тому зараз у світі даних стає дуже актуальним питання: як передавати AI не тільки схему таблиць, а й бізнес-логіку, значення метрик, зв’язки між сутностями та правила інтерпретації даних.
І тут Google запропонував цікаве рішення — Open Knowledge Format (OKF).
Якщо коротко, це відкритий формат для опису знань навколо твоїх даних. Така собі вікі для LLM, де можна описувати data model, бізнес-правила, метрики, зв’язки між таблицями й інші важливі нюанси, які потрібні AI для нормальної роботи з даними.
Якщо ти, як і я, любиш Obsidian, то ідея буде дуже знайомою: логіка, як і замітки в Obsidian записується у звичайних Markdown-файлах, які можна зберігати, редагувати, версіонувати й передавати далі.
Основна ідея OKF у тому, щоб зробити такий формат зрозумілим і для людей, і для AI-агентів. Тобто ти можеш один раз описати контекст своїх даних у нормальній структурі, а потім передавати його різним інструментам, які зможуть цей контекст прочитати й використати.
Поки що це тільки версія 0.1, тобто дуже ранній етап. Але початок виглядає дуже добре. І, здається, community уже починає це підхоплювати.
Наприклад, команда OWOX уже презентувала Model Canvas — інструмент, який дозволяє візуально збирати data model і працювати з нею у форматі OKF.
Загалом я дуже радий, що тема контексту для AI-аналітики починає рухатися в бік відкритих і зрозумілих форматів. Бо якщо ми хочемо, щоб AI нормально допомагав із SQL, аналізом і відповідями на бізнес-питання, йому потрібно давати не тільки доступ до даних, а й нормально описаний контекст навколо цих даних.
Будь в курсі актуальних новин зі світу аналітики!
