- Головна
- /
- Архів розсилок
- /
- Дайджест з вебаналітики #60
від 19 Червня 2026р.
Привіт 🙌
Сьогодні почнемо з веселої ноти.
Нещодавно ми підготували відео про біль, який знайомий багатьом спеціалістам, що працюють із Google Tag Manager.
«Пірати аналітичного моря: Прокляття GTM-контейнера» 🏴☠️
Так, в кінці відео є заклик піти на курс PRO GTM. І так, курс вже стартував, але це не змінює головного: більша частина відео — це веселий матеріал про дуже реальні болі вебаналітиків, маркетологів і всіх, хто працює з GTM. Тому дуже рекомендую подивитись — і отримати додаткову хвилинку веселощів в цей день.
👉 Переглянути відео в Telegram >>>
👉 Переглянути відео у Facebook >>>
Сьогодні в розсилці:
Наші новини:
🌟 Як відслідковувати 404 і JavaScript-помилки на сайті через GTM
🌟 Як зрозуміти на якому етапі взаємодії з формою ми втратили користувача
Новини Google Analytics:
🔹 Фільтр по домену в GA4.
🔹 Новий параметр Source Group і оновлення Source Platform.
🔹 GA4 + Google Business Profile: нова нативна інтеграція.
🔹 Нова інтеграція GA4 з Shopify.
Новини Google Tag Manager:
🔹 Google Tag Gateway тепер можна налаштувати через Amazon CloudFront.
🔹 Server-side GTM: контроль browser calls для Google Ads і Floodlight tags.
Новини Google BigQuery:
🔹 Оновлення Gemini Cloud Assist у BigQuery.
🔹 Continuous queries тепер підтримують ARRAY_AGG і STRING_AGG.
🔹 Щоденні квоти на токени для GenAI-функцій.
Новини Power BI:
🔹 Оновлений Date picker для слайсера.
🔹 Колір іконки вибору в слайсері.
🔹 Таблиця результатів у перегляді запитів DAX із фільтрацією та сортуванням.
🔹 Карта фігур стала загальнодоступною.
🔹 Невеликі покращення для точкових, стовпчастих і лінійчастих діаграм.
🔹 Ефекти при наведенні курсора на зображення у візуалі картки.
🔹 Нові можливості для спливаючих підказок.
🔹 DAX UDF стали загальнодоступними.
🔹 PBIR — майбутнє формату коду звітів у Power BI.
🔹 Агент для повного циклу створення звітів: від плану до публікації звіту.
🔹 Відповіді на основі даних у Fabric Skills, Cowork та чаті M365.
🔹 Power BI Desktop Bridge: AI-рішення тепер можуть працювати напряму з Power BI Desktop.
🔹 Додатки Fabric для семантичних моделей: Power BI все ближче до повноцінних data apps.
Інші новини:
🔹 Google Ads API розширює product reporting.
Корисні матеріали:
🔥 М’яч, який передає дані 500 разів на секунду: що футбол може нагадати нам про аналітику.
🔥 Як Anthropic будує self-service аналітику з Claude.
🔥 Amplitude через GTM шаблон: продуктова аналітика стає ближчою.
📰 Які помилки варто відстежувати на кожному сайті: покроковий гайд із налаштування через GTM.
За останні два тижні на нашому блозі я опублікував дві статті, які об’єднані однією темою — відстежування помилок на сайті через Google Tag Manager.
І хоча на ці матеріали мене частково надихнули певні нещодавні консультації, які я проводив з людьми, що вайбкодять свої сайти, проблеми, які я підсвічую в них, з’явилися не вчора. Вони існували дуже давно. І деякі з рішень, про які я розповідаю, я почав застосовувати на проектах ще в далекому 2017 році, але зараз вони набувають нової популярності.
У першій статті я розбираю, як відстежувати 404 і JavaScript-помилки на сайті через GTM. Це ті помилки, які часто залишаються “за кадром”, але можуть ламати взаємодію користувача із сайтом: кнопками, формами, сторінками, оплатою або іншими важливими елементами. І як наслідок напряму впливати на конверсії, заявки та гроші.
👉 Як відслідковувати 404 і JavaScript-помилки на сайті через GTM >>>
У другій статті мова йде про те, як побудувати повноцінний funnel для форми, щоб бачити не просто факт відправки, а розуміти, на якому саме етапі ми втрачаємо користувачів.
👉 Відслідковування взаємодії з формами за допомогою Google Tag Manager >>>
На цьому наші новини все. Переходимо до новин сервісів, якими ми користуємось щодня.
Почнемо, як завжди, з Google Analytics. Давно команда GA4 так нас не радувала, як за ці два тижні :)
👉 Новини Google Analytics
Загалом апдейтів було не так багато, але цього разу серед них є одразу два дуже корисні оновлення, які закривають важливі й давно знайомі проблеми.
Почнемо з першого.
🚩 Фільтр по домену в GA4
Нарешті в Google Analytics 4 почали з’являтися фільтри для вхідних даних. Перший фільтр, який став доступний, — фільтр за доменом.
Звісно ком'юніті вже давно придумало обхідне рішення - налаштовувати обмеження на стороні GTM, але воно покривало не всі кейси. Тому добре, що команда GA4 нарешті підготувала повноцінний спосіб блокування спам трафіку з інших доменів.
🚩 Новий параметр Source Group і оновлення Source Platform.
Наступна новина теж закриває давній біль: мова про всі ці instagram, ig, insta і т.д. У Google Analytics 4 з’явився новий параметр Source Group, який має закрити це питання, а також оновлюється логіка роботи з Source Platform.
Параметр Source Group автоматично об’єднує різні варіанти source в одне нормалізоване значення. Тобто замість купи різних варіантів Facebook у тебе буде один зрозумілий Facebook. Замість різних варіацій Instagram — один Instagram. І так далі.
А Source Platform допоможе краще класифікувати саму платформу. Наприклад, різні варіанти Instagram можуть бути зібрані в Instagram як Source Group, а на рівні Source Platform — віднесені до Meta Ads.
Це має зробити звіти по джерелах трафіку значно чистішими і зручнішими, особливо коли ти аналізуєш ефективність різних рекламних платформ, розподіл бюджету або attribution.
Ще один цікавий момент — Google одразу закладає логіку для нових джерел трафіку, зокрема ChatGPT / OpenAI та Perplexity. Тобто вони вже готують цю класифікацію не тільки під класичні рекламні платформи, а й під нові AI-джерела.
Більше того, обіцяють, що Source Group працюватиме ретроактивно, тобто цей параметр можна використовувати не тільки для нових даних, а й для історичних.
Звучить це все дуже багатообіцяюче, тепер залишилось дочекатись коли цей апдейт долетить до ресурсів з якими я працюю, щоб спробувати.
🚩 GA4 + Google Business Profile: нова нативна інтеграція.
Ще одна важлива новина від Google Analytics 4 — з’явилась нативна інтеграція з Google Business Profile.
Тепер Google Business Profile можна підключити прямо в GA4 через Admin → Product links → Google Business Profile links.
Як результат, тепер частину важливих дій із Google Business Profile можна бачити безпосередньо в Google Analytics.
Наприклад: interactions, website clicks, calls, directions, messages, bookings, menus.
Тобто якщо користувач навіть не перейшов на сайт, а просто взаємодіяв з твоїм Google Business Profile то частину цих даних тепер можна буде бачити і в GA4.
Звісно, є обмеження. Наприклад, дані доступні тільки за останні 6 місяців, а якщо підключено кілька профілів, то метрики агрегуються разом.
Але сам факт появи такої інтеграції — це дуже хороший крок. Особливо для бізнесів, де Google Business Profile реально впливає на заявки, дзвінки й офлайн-відвідування.
🚩 Нова інтеграція GA4 з Shopify.
Починаючи з липня 2026 року, Google Analytics автоматично почне отримувати дані про події, такі як покупки, безпосередньо із серверів Shopify. Обіцяють, що глибша інтеграція зробить вимірювання більш стійким, відновлюючи втрачені сигнали конверсій через прямий зв'язок між серверами.
Від нас ніяких дій не потрібно. Якщо ти вже налаштував додаток Google і YouTube на Shopify, ця інтеграція буде ввімкнена автоматично.
Якщо ти не бажаєш використовувати цю інтеграцію, ти можеш будь-коли вимкнути її безпосередньо в додатку Google & YouTube на Shopify.
👉 Новини Google Tag Manager
🚩 Google Tag Gateway тепер можна налаштувати через Amazon CloudFront.
Google продовжує активно переводити всіх на first-party рішення, і тепер з’явився ще один спосіб швидко налаштувати Google Tag Gateway — цього разу через інфраструктуру AWS, а саме Amazon CloudFront.
Тобто якщо твій сайт уже використовує Amazon CloudFront як CDN, тепер ти можеш налаштувати Google Tag Gateway через цей інструмент і завантажувати Google tag зі свого домену.
І з кожною такою новиною, я не втомлююсь нагадувати: server-side GTM — краще рішення для побудови first-party логіки, бо він відкриває значно більше можливостей і одразу дозволяє будувати first-party рішення не тільки для Google, а й для інших рекламних систем.
Водночас якщо з якоїсь причини у тебе немає бюджету або ресурсу на server-side GTM, вся реклама крутиться тільки в Google Ads, і так склалось, що на проєкті уже використовується Amazon CloudFront, то тут, можна сказати, зірки зійшлися і цей апдейт саме для тебе.
👉 Server-side GTM: контроль browser calls для Ads і Floodlight tags
Simo Ahava звернув увагу на важливий апдейт для server-side GTM: з’являється контроль, який дозволяє блокувати browser calls при використанні Ads і Floodlight tags.
Це важливо в контексті того, як Google зараз змінює логіку роботи рекламних даних, consent state і Google Signals при зв’язці GA4 з Google Ads.
По суті, це ще один крок до того, щоб server-side GTM давав більше контролю над тим, як саме дані проходять між браузером, серверним контейнером і рекламними системами.
І це якраз одна з причин, чому я продовжую вважати server-side GTM більш гнучким рішенням, ніж “швидкі” first-party варіанти тільки для Google.
Бо тут мова не просто про те, щоб прокинути запит через свій домен. Тут мова про контроль логіки збору, обробки й передачі даних.
👉 Новини Google BigQuery
Команда BigQuery цього разу справді багато попрацювала, але загалом усі новини, які варті нашої уваги, можна скласти в кілька основних блоків.
- По-перше, це оновлення Gemini Cloud Assist.
- По-друге, це повернення AI.KEY_DRIVERS.
- І по-третє, це оновлення в continuous queries.
Але давай про все по порядку.
🚩 Оновлення Gemini Cloud Assist у BigQuery
Тепер за допомогою Gemini Cloud Assist у BigQuery можна:
- планувати запити;
- аналізувати походження даних;
- відстежувати продуктивність, аналізувати потужності й оптимізувати витрати;
- аналізувати SQL-запити й отримувати рекомендації щодо оптимізації продуктивності.
Окремо з’явилась можливість використовувати Gemini Code Assist прямо на сторінках BigQuery Jobs explorer, Job details, Job history та Capacity management, щоб простіше розбиратись із проблемами продуктивності.
Загалом це все продовжує той самий рух: BigQuery поступово стає не просто інструментом, де ти сам пишеш SQL і сам розбираєшся з усіма проблемами, а середовищем, де AI все більше допомагає в щоденній роботі і стає по суті твоїм напарником.
🚩 AI.KEY_DRIVERS повернулась.
Цю функцію можна використовувати, щоб знаходити сегменти даних, які викликають статистично значущі зміни в підсумковому показнику.
Якщо простіше: вона допомагає швидше зрозуміти, що саме могло вплинути на зміну метрики, а не просто дивитися на факт росту або падіння.
Функція зараз доступна в режимі Preview.
🚩 Continuous queries тепер підтримують ARRAY_AGG і STRING_AGG.
Тепер безперервні запити BigQuery підтримують агрегатні функції (Preview):
🚩 Щоденні квоти на токени для GenAI-функцій.
8 червня в BigQuery з’явилась дуже корисна можливість — керувати витратами на generative AI functions через щоденні квоти на токени. Тобто можна було налаштувати daily token quotas і таким чином обмежувати витрати, пов’язані з генеративними AI-функціями в BigQuery.
Але вже 15 червня цю можливість тимчасово відключили. Можливо, щось пішло не так. А можливо, зрозуміли, що з квотами на токени люди почнуть витрачати трохи менше 🙂
Якщо серйозно, то шкода, що функцію відкликали, бо така можливість дуже потрібна. Особливо зараз, коли AI-функцій у BigQuery стає все більше, а питання контролю витрат стає все актуальнішим. Чекаємо повернення.
👉 Новини Power BI
Здається, всі вже звикли, що команда Power BI зазвичай публікує свої великі апдейти в 20-х числах місяця, і тому за логікою ми мали б говорити про них уже в наступній розсилці.
Але щось пішло не за планом — і нові апдейти вийшли раніше, а значить в розсилці знову великий блок оновлень від Power BI.
Загалом весь червневому апдейт я для себе розділив на два великі блоки новин:
- Перший — це оновлення, які стосуються AI, Copilot і нових можливостей роботи з Power BI про які раніше ми й не уявляли.
- Другий — це речі, які, здається, користувачі Power BI чекали вже дуже давно.
Оскільки в Power BI зараз дуже багато різних оновлень, я буду намагатися виділяти мій ТОП-3, а по всіх інших — проходитися коротко.
🚩 Оновлений Date picker для слайсера.
Новина цього місяця — це, звісно, оновлений Date picker.
Мені здається, за весь час, поки я працюю з Power BI, найчастіше від студентів, клієнтів і в обговореннях спеціалістів, я чув два питання:
— чи можна зробити в Power BI нормальний Date picker;
— і чи можна запускати Power BI на Mac.
Чесно кажучи, я думав, що жодного з них команда Power BI так і не зробить 🙂
Люди вже давно почали робити свої власні Date pickers, через кастомні візуалізації та обхідні рішення. У нас в команді, наприклад, теж є свій власний Date picker. Але щось сталося — і команда Power BI нарешті випустила нормальний Date picker для вбудованого слайсера.
Тепер можна зробити більш зручний вибір дат через стандартний віжуал: з календарем, ручним вибором діапазону, а також з відносними датами, які можуть автоматично оновлюватися з часом. Ще б швидкі пресети додали і було б ВАУ!
Якщо в наступному апдейті раптом з’явиться Power BI для Mac — я, здається, буду до цього морально готовий 🙂
🚩 Колір іконки вибору в слайсері.
На цьому вау-новини для slicer не завершились.
У Power BI нарешті додали можливість форматувати колір іконки вибору в slicer — тобто чекбоксів або radio buttons.
Звучить як дрібниця, але на практиці це дуже важлива штука. Якщо ти намагався робити звіти з темною темою ти мене зрозумієш.
Раніше такі елементи могли просто погано читатися на темному фоні, і доводилось або миритися з цим, або шукати якісь обхідні рішення. Тепер можна нормально налаштувати колір іконки вибору так, щоб слайсер виглядав органічно і залишався зрозумілим для користувача.
🚩 Таблиця результатів у перегляді запитів DAX із фільтрацією та сортуванням.
Третій апдейт, який я хочу виділити окремо, — це оновлення DAX Query View results grid.
Тепер у результатах DAX-запиту можна сортувати й фільтрувати дані прямо в grid, не переписуючи сам DAX-запит.
І якщо ти звик використовувати DAX Query View для дебагу то тепер цей дебаг стане набагато приємнішим.
Інші, менш важливі, але варті уваги оновлення цього місяця:
🚩 Shape Map стала загальнодоступною.
Ще одне оновлення, яке може покращити життя тим, хто працює з геоданими. Тепер можна завантажувати свої кастомні TopoJSON або GeoJSON файли, а ще підключати карти через URL. Враховуючи, що в епоху AI зробити файл із кастомною георозміткою стало набагато легше, ніж колись, виглядає дуже корисно, якщо тобі потрібно візуалізувати геодані.
🚩 Невеликі покращення для точкових, стовпчастих і лінійчастих діаграм.
Для точкових діаграм додали опцію Auto-fit markers, яка автоматично підлаштовує область графіка так, щоб точки або bubbles біля країв не обрізались.
Для bar і column charts теж з’явились дрібні покращення в логіці відображення осей і діапазонів. Це не те оновлення, яке змінює все, але саме такі дрібниці поступово роблять звіти акуратнішими й приємнішими в роботі.
🚩 Ефекти при наведенні курсора на зображення у візуалі картки.
Power BI все більше рухається в сторону того, щоб звіти в ньому виглядали не як “пластиковий звіт”, а як нормальний інтерфейс сучасного SaaS-продукту.
Ще один крок у цьому напрямку — hover states для зображень у card visual.
Тепер можна налаштовувати, як зображення в картці змінюється при наведенні курсора: наприклад, показувати інше зображення або змінювати його вигляд.
🚩 Нові можливості для спливаючих підказок.
Тепер підказки можна робити більш інформативними й зрозумілими для користувача, щоб при наведенні він не просто бачив значення, а краще розумів, що саме перед ним у звіті.
🚩 DAX UDF стали загальнодоступними.
Я сподіваюся, що ти вже давно пішов у налаштування, активував цю фічу в превью й почав її тестувати 🙂 Але якщо ні — тепер вона має бути доступна всім.
UDF дозволяють один раз описати потрібну логіку в DAX і потім перевикористовувати її в різних мірах, calculated columns або visual calculations.
Для складних моделей і командної роботи це дуже корисна історія, бо вона допомагає не дублювати логіку в десятках місць і тримати розрахунки більш структурованими.
🚩 PBIR — майбутнє звітів у Power BI.
Ну і, звісно, команда Power BI не забула нагадати нам у цьому апдейті, що PBIR — це майбутнє формату коду звітів у Power BI.
Якщо ти досі працюєш зі звітами у форматі PBIX, то для тебе особливо нічого не зміниться. Усе відбувається “під капотом”.
Але якщо ти рухаєшся в сторону інтеграції звітів з Git, source control, CI/CD або більш сучасного аналітичного стеку, то для тебе це нагадування: команда Power BI не забула про цей напрямок і продовжує рухати PBIR вперед.
На цьому частина з "базовими" оновленнями в PowerBI все, але є ще частина оновлень, які стосуються AI і нових способів роботи з даними.
🚩 Copilot у веб-моделюванні.
Тепер у Model view в Power BI service можна використовувати Copilot для роботи із семантичною моделлю через natural language: аналізувати структуру моделі, покращувати зв'язки, перейменовувати об’єкти або створювати DAX-міри.
Тобто AI поступово заходить не тільки в роботу зі звітами, а й у сам процес моделювання даних.
Поки що це Preview, але виглядає як ще один крок до того, щоб частину рутинної роботи з моделлю можна було робити швидше.
🚩 Відповіді на основі даних у Fabric Skills, Cowork та чаті M365.
Наступна новина теж, як на мене, добре показує, куди рухається Power BI.
Conversational Analytics вже декілька місяців доступний в BigQuery і ось прийшла черга його аналогу з'явитись і в PowerBI. Не думаю, що команда Power BI прямо орієнтується на BigQuery, тут швидше я б сказав, що більшість тулів які мають бізнес дані зараз рухаються до того, щоб надати можливість фінальним користувачам спілкуватись з ними: багато користувачів не хочуть працювати зі звітами, а хочуть простіший флоу отримання інсайтів і сервіси намагаються його надати.
Тут важливо, що відповіді будуються з урахуванням дозволів користувача і на основі семантичних моделей. Тобто це не просто чат поверх даних, а я б сказав швидше ще один спосіб сприйняття даних, які раніше можна було побачити лише в звітах.
Тепер залишається тільки провести десятки досліджень, щоб зрозуміти коли краще використовувати Conversational Analytics в BigQuery, коли Data answering у Fabric, а коли просто підключити Claude до даних через MCP і працювати в команді з ним. Але багато можливостей це точно краще, ніж їх відсутність. Тому най буде.
🚩 Power BI Desktop Bridge: AI-рішення тепер можуть працювати напряму з Power BI Desktop.
Мені подобається, що команда Power BI не зосереджується тільки на онлайн-можливостях AI, які, звісно, у майбутньому можна буде по-різному монетизувати. Вони паралельно думають і про Power BI Desktop — інструмент, у якому багато хто з нас щодня будує звіти.
Desktop Bridge дозволяє агентам і зовнішнім інструментам підключатися напряму до запущеної сесії Power BI Desktop.
Це відкриває нові сценарії, особливо для AI-рішень. Наприклад, той самий Report Skill може через Desktop Bridge читати, оновлювати й перевіряти звіти в постійному циклі “змінив → перевірив”.
У результаті це може зробити процес створення звітів швидшим і набагато зручнішим.
Ну і остання зі всіх новин PowerBI на сьогодні.
🚩 Додатки Fabric для семантичних моделей: Power BI все ближче до повноцінних data apps.
Якщо коротко, це новий підхід, який дозволяє будувати кастомні web apps поверх semantic models у Microsoft Fabric.
Тобто мова вже не просто про класичні Power BI-звіти, де користувач відкриває дашборд, дивиться на графіки й фільтрує дані. Тут ідея набагато ширша: на базі семантичної моделі можна створювати повноцінні операційні додатки з власною логікою, інтерфейсами й сценаріями роботи.
І це дуже добре показує приклад Reid Havens. Він зібрав Project Delivery Hub — PMO-інструмент у Fabric, де є Gantt, Kanban, Calendar View, і можливість записувати зміни напряму в SQL database у Fabric Workspace.
На мою думку, це ще один із тих апдейтів, який дуже добре показує, куди рухається Power BI і Fabric загалом.
Power BI поступово перестає бути просто інструментом для побудови звітів і все більше рухається в сторону платформи для створення аналітичних продуктів.
Звісно, це ще Preview, але як напрямок розвитку — це дуже цікаво. Особливо для команд, які вже думають не просто про “дашборди”, а про інтерактивні аналітичні інтерфейси, де користувач може не тільки дивитися на дані, а й працювати з ними в більш прикладних бізнес-сценаріях.
👉 Офіційний анонс Fabric Apps for Semantic Models >>>
👉 Приклад Project Delivery Hub від Reid Havens у LinkedIn >>>
👉 Google Ads API розширює product reporting
З 15 червня Google Ads API починає розширювати продуктову звітність.
Якщо коротко, тепер Google Ads API почне повертати cost and conversion metrics для Video, Demand Gen і App campaigns на рівні product reporting.
Якщо ти будуєш автоматизовані звіти, витягуєш дані через API або підтримуєш власні дашборди — це важливий апдейт, оскільки він фактично розділяє репортинг на ДО і ПІСЛЯ. Розширені дані будуть доступні саме з 15 червня. API-запити за дати до цього дня не міститимуть нового покриття, тому частина метрик у продуктовій звітності може почати виглядати інакше.
На цьому новини все - переходимо до корисних матеріалів
🔥 М’яч, який передає дані 500 разів на секунду: що футбол може нагадати нам про аналітику
Як багато хто з вас знає, зараз триває чемпіонат світу з футболу. І навіть якщо ти не дуже цікавишся футболом, є один момент, який точно вартий уваги з точки зору аналітики.
М’яч чемпіонату світу передає дані до 500 разів на секунду.
Але важлива не сама кількість передач, а те, що це в результаті допомагає набагато точніше відслідковувати офсайди та інші проблемні ситуації/порушення на полі.
Питання ж завжди не в тому, скільки даних ти збираєш, а в тому, скільки користі приносить зібрана інформація. Можна збирати тисячі подій, параметрів і метрик — але якщо вони не допомагають приймати рішення, покращувати продукт, оптимізувати рекламу або знаходити проблеми в користувацькому досвіді, то користі від цього не так багато.
Яку реальну бізнес цінність дали останні дані які ти зібрав?
🔥 Як Anthropic будує self-service аналітику з Claude
Ну і який блок корисних матеріалів у сучасному світі може бути без чогось, де є букви AI 🙂
Тому другий матеріал сьогодні — стаття від команди Anthropic про те, як вони будували свій підхід до self-service data analytics з Claude: що в них вийшло, що не вийшло, де були основні проблеми і як вони намагались їх вирішити.
Загалом дуже рекомендую ознайомитися з матеріалом повністю, але окремо хочу підсвітити кілька моментів.
- По-перше, Anthropic прямо пише, що точність в аналітичних задачах — це не стільки проблема генерації коду, скільки проблема контексту, правильних джерел даних і валідації.
Вже тільки заради того, щоб ще раз прочитати цю фразу, варто читати цю статтю. Так, агент може правильно написати SQL-запит, але якщо він вибрав не ту таблицю, не ту метрику або не зрозумів бізнесовий контекст питання — відповідь все одно буде неправильною. - По-друге, мені дуже відгукується їхній підхід зі skills.
Я вже не раз говорив про це на вебінарах: один із найкращих способів зробити так, щоб агент виконував задачу саме так, як тобі потрібно, — це спочатку зробити цю задачу самому, потім попросити агента на основі твого рішення створити skill, а вже далі використовувати цей skill для схожих задач.
Тобто не просто “попросити AI щось зробити”, а спочатку показати йому що ти від нього хочеш на власному прикладі. Так, це працює не лише як базове правило делегування, а й з AI агентами. - І ще один важливий момент. Навіть у команди Anthropic, яка працює з власними просунутими моделями і точно добре розуміє, як ними користуватись, не вийшло досягти 100% точності.
У статті вони пишуть про приблизно 95% accuracy в aggregate.
Тому якщо у твоїх проєктах агент не завжди робить саме те, що ти хочеш, — це нормально. Проблема не завжди в тому, що ти “не так попросив”. Часто проблема в контексті, документації, структурі даних, валідації і тому, наскільки добре агент розуміє бізнесову логіку.
Саме тому такі матеріали дуже корисно читати: вони добре показують, що за красивою ідеєю “self-service analytics через AI” стоїть не магія, а дуже багато роботи з даними, документацією, skills і перевіркою результатів.
🔥 Amplitude через GTM: продуктова аналітика стає ближчою
І останній матеріал у сьогоднішній підбірці — стаття від багатьом відомої Krista Seiden.
Це людина, яка свого часу дуже активно розповідала про Google Analytics 4, оскільки була в команді розробки і, думаю, багато хто з вас можливо навіть навчався на її відео.
Свого часу її перехід в Amplitude був доволі помітною новиною в аналітичному ком’юніті. Для багатьох, в тому числі і для мене, про що я й писав в одному з листів, це виглядало як сигнал, що Amplitude почне активніше рухатись не тільки в сторону продуктової аналітики, а й у сторону більш звичного для маркетологів аналізу трафіку та web-аналітики.
Поки що я б не сказав, що ми побачили якийсь дуже великий зсув у цю сторону. Але нещодавно Krista опублікувала матеріал про те, як налаштувати Amplitude через Google Tag Manager за допомогою офіційного шаблону.
Так, Amplitude не частий інструмент в руках вебаналітика, але коли таке трапиться у тебе під рукою буде готове рішення від одного з членів команди Amplitude.
Будь в курсі актуальних новин зі світу аналітики!
