Якщо ви читаєте мою розсилку (Email або LinkedIn) - то чули про моє захоплення MCP вже давно.

І от я зібрався і написав статтю на блог про це: трохи думок, трохи практики, трохи порівняння з рідними чатами сервісів.

Звісно, всі приклади більше під аналітичні задачі, але буде корисно і для загального розвитку.

Для тих хто нічого не знає про MCP - це ваш ключ до більш ефективної роботи з LLM. Детальніше читайте в матеріалі.

Для тих хто вже трохи чув - в статті я показую на практиці роботу з Google Analytics MCP та MCP Toolbox for Databases.

Приємного читання ;)

https://analytics-tips.com/uk/model-context-protocol-what-it-is-and-why-it-s-the-future-of-analytics

Ну і для розуміння загальної картини: ви вже використовуєте MCP? Які? Для яких задач? Чи бачите в цьому цінність?

P.S. хотілось написати більше, але якось всі думки не лягли в один матеріал, тому можливо буде продовження

Цікавим прецедентом по GDPR & GTM поділились в чаті курсу PRO ANALYTICS:

"Ганноверський адміністративний суд (VG) надіслав чіткий сигнал щодо захисту даних під час відстеження веб-сайтів. Використання Google Tag Manager (GTM) дозволено лише за попередньою, усвідомленою та добровільною згодою відповідно до § 25 (1) Закону Німеччини про телемедіа (TTDSG) у поєднанні зі статтею 6 (1) (a) GDPR. Суд уточнив, що GTM не є нейтральним щодо захисту даних, а активно отримує доступ до кінцевих пристроїв та передає персональні дані до Google у США." (Цитата українською надана через автопереклад Google)

Ось тут по лінках детальніше:
- тут більше як вижимка
- тут повний матеріал

Цікаво слідкувати за тим, що буде далі. Бо зараз багато рішень по налаштуванню згоди грунтується саме на налаштуванні через GTM.

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

Але моя думка тут нічого не змінює. Бо суд вирішив своє, а саме він має можливість накладати штрафи.

Поки не знаю, чи варто вже прямо зараз бігти змінювати налаштування і блокувати завантаження GTM, до надання фактичної згоди, чи все ж це поодинокий випадок. Але слідкувати за цим точно варто, якщо ваш бізнес працює на користувачів з ЄЕЗ.

P.S. Можливо на рішення суду вплинуло й те, що на самому банері не було кнопки "Не надавати згоду". Але факт є фактом. Тому будьте обережні. І обов'язково при налаштуванні згоди консультуйтесь з юристами.

P.P.S. Налаштування згоди з самого початку було важливим не просто для запуску реклами від Google, це глобальні процеси на рівні компанії. Не забувайте про це.

Всі ви вже, напевно, звикли і полюбляєте п'ятничний мем на цьому каналі.

Ну це я так собі думаю, що звикли і полюбляєте, бо бачу кількість шерів, яка до речі часто перевищує кількість лайків.

Ну і взагалі було таке, що мемчики тиждень не виходили, то мені навіть пара людей в особисті питала, чи все ок зі мною.

Так от, оскільки перша, так би мовити, постійна рубрика, вам зайшла - хочу спробувати запустити ще одну - квізи по аналітиці.

Формат буде такий: раз на тиждень, в п'ятницю, під кінець дня, я роблю пост з одним питанням і варіантами відповіді. Десь приблизно через годину публікую розбір питання. І ще через пару хвилин після цього з'являються меми.

Сьогодні, і в наступну п'ятницю я зроблю тестовий запуск, тому буде не один квіз, а більше. І з різними напрямками питань (десь більш практичне, десь теорія, і т.д.), щоб зрозуміти, які з них вам більше подобаються, і чи подобаються взагалі.

Якщо вам сподобалась ідея - поставте вогник 🔥 конкретному квізу або його розбору. Якщо сподобалось декілька квізів - поставте пліз 🔥 кожному з тих що сподобались. Якщо не бачите користі з таких квізів - ставте 👎.

В залежності від ваших реакцій через два тижні я вирішу чи варто робити цю рубрику постійною і які саме питання готувати.

Перші квізи будуть вже через декілька хвилин.

💡 Пояснення до квізу 1:

A: Правильно, за замовчуванням Google Analytics 4 зберігає детальні дані події лише протягом 2 місяців. Це обмеження стосується звітів у блоці Explore. Без змін у налаштуваннях, ці інструменти відображатимуть дані лише за останні ~60 днів.
Детальніше тут

B: 14 місяців – це максимальний період збереження подій у безкоштовній версії GA4. Якщо ви перейдете в Admin → Data Retention, то можете збільшити 2 місяці до 14. 14 місяців — це не стандартне значення, а максимальний період, який можна встановити вручну (у GA4 360 доступні й довші терміни).

C: 26 місяців — одне з розширених значень збереження, доступних лише у платній версії GA4 360 (Enterprise). У безкоштовній версії обрати 26 місяців неможливо.

D: Ні, за замовчуванням дані GA4 не зберігаються вічно. За замовчуванням ці дані зберігаються 2 місяці, або 14 місяців за умови змін у налаштуваннях. Після завершення цього періоду вони автоматично видаляються. Нескінченне зберігання можливе лише через експорт у BigQuery.

💡 Пояснення до квізу 2:

A: Ні, Active Users – це підмножина всіх користувачів. Загальні (Total) користувачі – будь-який унікальний відвідувач за період, а активні – ті з них, хто мав хоч якусь мінімальну взаємодію. Наприклад, користувач, що відкрив сторінку і одразу пішов, увійде до Total Users, але не до Active Users.

B: У GA4 є показник Total users (загальна кількість юзерів), який доступний у звітах. Отже, твердження, що залишилися лише активні – неправильне.

C: Active Users не обмежується тільки новими відвідувачами. Метрика “New Users” окремо рахує тих, хто прийшов вперше, а “Active Users” може включати і тих, хто повернувся – головне, щоб їхні сесії були зі взаємодією.

D: Правильно, у GA4 Active Users — це користувачі, які взаємодіяли із сайтом або додатком у межах вибраного періоду. А саме ті, хто або перший раз відвідали сайт/додаток (події first_visit та first_open), або у подіях яких є параметр engagement_time_msec, що свідчить про взаємодію. Значення цього показника зазвичай нижче, ніж Total Users, оскільки виключає тих, хто не виявив активної взаємодії.

Детальніше тут

💡 Пояснення до квізу 3:

A: 50 конверсій – ні, це завищена кількість. Наразі такий ліміт має GA4 360. Для безкоштовної версії встановлено ліміт у 30.

B: 20 – це було лімітом кількості цілей (Goals) на подання в Universal Analytics (і 20 додаткових для 360). Але у GA4 ліміт інший – 30 на всю властивість. Отже, 20 – неправильна відповідь (в GA4 це занизька оцінка).

C: Правильно, у безкоштовній версії GA4 ви можете позначити до 30 різних подій як конверсії. Тобто, у властивості GA4 можна виділити максимум 30 подій, які ви вважаєте ключовими (Key Events), і відстежувати їх як конверсії.

D: Обмеження є. Якщо спробувати позначити як конверсію більше 30 різних подій, GA4 не дозволить цього зробити (потрібно спершу зняти позначку з якихось інших). Таким чином, варіант про необмежену кількість – неправильний.

💡 Пояснення до квізу 4:

A: Правильно. GA4 має вбудовану можливість відстежувати “віртуальні” перегляди сторінок у SPA. Коли увімкнено Enhanced Measurement, подія page_view спрацьовує не лише при завантаженні сторінки, а й при зміні стану історії браузера – тобто при викликах history.pushState, replaceState або popstate у вашому додатку.
Це означає, що якщо ваш SPA-додаток змінює URL при навігації, GA4 зафіксує ці зміни як окремі перегляди сторінок. Примітка: переконайтесь, що увімкнена опція “Page changes based on browser history events” у налаштуваннях потоку даних, яка увімкнена за замовчуванням

B: Немає окремої опції з назвою “SPA Mode”. Все відбувається автоматично через описаний вище механізм Enhanced Measurement. Достатньо мати встановлений тег GA4 (або GTM з GA4 Config) і увімкнену опцію “Page changes based on browser history events” у налаштуваннях потоку даних, яка увімкнена за замовчуванням – GA4 сам буде слухати події історії.

C: На відміну від Universal Analytics, де для SPA часто доводилося вручну викликати gtag('config', 'UA-...') чи ga('send','pageview') при зміні екранів, GA4 суттєво спростив цей момент – багато SPA сценаріїв покриваються без коду. Однак, якщо ваш додаток не змінює URL при навігації, можливо, доведеться вручну викликати подію page_view.

D: GA4 не обмежується тільки першим переглядом. Якщо SPA змінює URL, GA4 спрацює повторно і зареєструє новий page_view. Тобто наступні “внутрішні” переходи не ігноруються, а теж фіксуються – за умови коректної реалізації SPA, що оновлює стан історії

💡 Пояснення до квізу 5:

A: Правильно. Позначка (other) з’являється у випадках, коли вибрана у звіті розмірність (параметр) має дуже високу кардинальність – тобто тисячі чи мільйони унікальних значень. GA4 встановлює певні ліміти на кількість рядків у звіті.
Якщо, наприклад, ви дивитеся розмірність “Page Title”, а на вашому сайті 100 000 різних сторінок, GA4 не буде виводити всі 100к рядків. Натомість він виведе, скажімо так, топ-значення, а всі менш значущі згрупує під “(other)”. Це означає “інші значення, які не вмістилися явно в звіт через обмеження на кількість рядків”. Other – поширене явище при високій унікальності значень, і це нормальна поведінка системи при захисті від занадто “широких” звітів.

Детальніше тут

B: Ні, (direct)/(none) – це про джерело трафіку (source/medium). У звітах GA4 воно так і відображається (“direct / none”). (other) – це зовсім інше: він може з’являтися для будь-якої розмірності (сторінки, події, кампанії і т.д.), якщо тих значень надміру багато. Отже, варіант B не стосується суті (other).

C: (other) не має відношення до семплювання. Семплювання – це, якщо дуже простими словами, коли береться 50% даних і екстраполюється на 100%. (other) – це коли дані є, але дуже роздроблені за значеннями, і система їх згрупувала.

D: (other) – це не про конфіденційність, а про технічне обмеження на кількість рядків у звіті. Дані під (other) не обов’язково конфіденційні – це можуть бути просто рідкісні сторінки або події. Тому D – неправильна відповідь.