Привіт 🙌
Сьогодні, як завжди, на тебе чекає нова порція аналітичних новин і корисних матеріалів. Перших правда не так і багато, тому будемо компенсувати останніми.
🔍 Сьогодні в розсилці:
Наші новини:
🌟 Нова стаття: Як швидко орієнтуватися в даних GA4 і помічати важливі зміни.
🌟 Нова стаття: Server-Side GTM у Cloud Run: покрокове налаштування, вартість і підключення піддомену.
Новини Google BigQuery:
🔹 BigQuery дозволив працювати з даними з різних локацій в одному запиті (Preview).
🔹 Нові кроки BigQuery назустріч AI у роботі з даними. (5 оновлень)
🔹 Оновлення YouTube Data Transfer.
🔹 Data policies на рівні колонок (Загальнодоступно).
Корисні матеріали
🔸 Як отримувати сповіщення про аномалії на основі BigQuery ML.
🔸 Як зручно показати товари в транзакціях у звітах Power BI.
🔸 Правила побудови зрозумілих і ефективних репортів.
🔸 Сервіс, який економить час на побудові схем.
Починаємо як завжди з наших новин.
Ми вже запустили нові потоки PRO-курсів, і навчання активно триває.
Якщо цього разу ти не встиг приєднатися — плануй своє навчання на червень.
Ну і звісно, ми, як завжди, ділимося експертизою не тільки на курсах, а й у відкритому доступі. Цього разу на наших блогах з’явилося одразу два нових матеріали.
Нагадаю, що загалом ми публікуємося на трьох майданчиках:
- Блог PROANALYTICS.ACADEMY — тут виходять більш загальні матеріали початкового та середнього рівня.
- Блог аналітичної команди ProAnalytics.Team — тут уже глибокі, технічні та комплексні розбори від середнього рівня і вище.
- Мій особистий блог Analytics Tips — тут мої думки, тести й ідеї.
І тепер — до нових матеріалів👇
📰 Server-Side GTM у Cloud Run: покрокове налаштування, вартість і підключення піддомену
На блозі ProAnalytics.Team вийшов великий технічний матеріал про розгортання Server-Side GTM у Google Cloud Platform.
Якщо ти читав наш блог команди, то знаєш: ми зазвичай пишемо обширні, глибокі матеріали, які намагаються закрити тему повністю — з поясненням логіки, інфраструктури й усіх нюансів. І цей матеріал саме такий.
Там не просто “натисни сюди”, а повноцінний розбір: як розгорнути сервер, як порахувати вартість, на що звернути увагу при підключенні піддомену.
🚀 Якщо після прочитання налаштування серверного GTM здалося тобі складним, але ти бачиш у цьому цінність і хочеш розібратися глибше — рекомендую придивитися до курсу по Server-Side GTM.
💭 А якщо ти поки що не розумієш, чи варто взагалі занурюватися в ці технічні налаштування — почни з мого давнього, але досі актуального матеріалу про переваги та недоліки Server-Side GTM. Він допоможе скласти цілісну картину й зрозуміти, чи це твій напрям.
Приємного читання!
На цьому наші новини все. Перейдімо до новин сервісів, які ми всі щодня використовуємо 🔥
Сьогодні з новин у нас небагато. Фактично цього разу нас порадувала тільки команда BigQuery.
👉 Google BigQuery
🚩 BigQuery дозволяє працювати з даними з різних локацій в одному запиті (Preview).
Почнемо з однієї з останніх новин BigQuery (останньої точно не по важливості), але точно знайомої багатьом.
Якщо ти працював із BigQuery, особливо на початку свого шляху, то майже гарантовано стикався з помилкою: SQL-запит не може виконатися, бо дані зберігаються в різних локаціях.
Це класичний нюанс BigQuery. Якщо ми хочемо об’єднати дані в межах одного запиту, вони мають знаходитися в одній локації. Інакше — помилка.
З останнім апдейтом це правило частково змінюється. Поки що функціональність у попередній версії, але тепер можна виконувати глобальні запити, які дозволяють звертатися до даних із кількох регіонів в одному SQL.
Важливо розуміти: архітектурно це складніший процес, ніж робота в межах однієї локації. Відповідно, такі запити будуть коштувати дорожче. Тому моя краще за можливості зберігати дані в одній потрібній локації та уникати крос-регіональних запитів.
Але для тих кейсів, де це дійсно необхідно, тепер з’явилася можливість робити це без додаткових зусиль зі сторони того, хто пише SQL.
Детальніше про глобальні запити в документації >>
І загалом мені здається, що ця зміна з глобальними запитами, які більше не так жорстко прив’язані до регіону, — це крок назустріч ще більшому використанню AI.
Моя суб’єктивна думка: одна з причин, чому це стало суперактуально саме зараз, у тому, що змінюється сам профіль користувача BigQuery.
Одна справа, коли людина працює з BigQuery, отримує помилку про різні локації й іде розбиратися та виправляти її. І зовсім інша — коли людина не до кінця розуміє, як влаштовані процеси в BigQuery, але намагається працювати з даними через AI.
Це вже більше бізнесовий представник, який не хоче занурюватися в написання SQL, а взаємодіє з даними через умовний агент або MCP-сервер. І коли він отримує помилку, він не завжди розуміє, що саме відбулося.
Тому мені здається, що це ще один крок назустріч AI у роботі з даними. І це не єдина зміна за останні два тижні, яка рухається в цьому напрямку.
Якщо коротко, всі останні апдейти можна звести до однієї тези:
🚩 BigQuery робить крок назустріч AI у роботі з даними.
- Контроль використання BigQuery MCP тепер змінюється: замість організаційних політик використовується IAM deny. А після активації BigQuery MCP сервер автоматично вмикається. Детальніше тут >>>
- Dataset insights тепер дозволяють зрозуміти зв'язки між таблицями в датасеті, автоматично визначати relationships і пропонувати аналітичні питання. Детальніше тут >>> (Preview)
- У функціях AI.GENERATE та AI.GENERATE_TABLE тепер можна додавати описи полів у кастомній схемі результату. Детальніше тут >>> (Загальнодоступно)
- Функція AI.CLASSIFY тепер підтримує класифікацію за кількома категоріями. Детальніше тут >>> (Preview)
- Сканування документації даних можна гнучко налаштовувати: генерувати лише SQL, лише описи таблиць і колонок або повний набір інсайтів, а також запускати одноразові скани з автоматичним видаленням через TTL. Детальніше тут >>>
Звісно, для людини, яка давно працює з даними, частина цих апдейтів може виглядати трохи дивно. Наприклад, класно, що система може спробувати зрозуміти зв’язки між таблицями, але по-хорошому аналітик сам має розуміти, як ці таблиці пов’язані, а не покладатися лише на AI.
Але ми всі розуміємо, куди це рухається.
І як я завжди кажу: поки що аналітикам не варто боятися, що AI забере у них роботу. AI може забрати роботу лише в тих аналітиків, які самі не роблять кроків назустріч цій технології.
І далі давай розберемо ще дві новини, які вже більш практично важливі.
🚩 Нові показники в YouTube Data Transfer.
Перш за все — як ти вже, напевно, звик (і я теж), не проходить і двох тижнів без апдейтів у Google Data Transfer. Google дуже активно розвиває цей напрям у межах Google Cloud Platform.
Цього разу оновлення стосується YouTube Data Transfer. Тепер у трансферах із YouTube Channel та YouTube Content Owner з’явилася підтримка reach-звітів.
🚩 Data policies тепер можна застосовувати прямо до колонок (Загальнодоступно).
Це означає, що контроль доступу, маскування та правила трансформації можна застосовувати безпосередньо на рівні стовпця.
Якщо простіше — твої дані стають ще більш захищеними, і ти можеш керувати тим, що саме бачить користувач у конкретній колонці під час виконання запиту. Наприклад:
- Якщо у тебе є таблиця з ПІБ, телефоном і адресою клієнта, маркетологам не обов’язково бачити phone_number. Ти накладаєш маскування — і вони бачать зірочки або NULL, але можуть спокійно працювати з іншими полями й робити аналітику.
- Якщо потрібно аналізувати user journey, можна застосувати хешування (наприклад, SHA256) до user_id. Аналітики не знають, хто саме цей користувач, але оскільки хеш стабільний, вони можуть коректно робити JOIN’и й рахувати унікальні сесії.
По суті, це ще один крок до більш гнучкого й контрольованого управління доступом до даних у BigQuery.
Детальніше за посиланням >>>
Новини, які стосувалися AI, я прописав вище окремими тезами. Але якщо чесно, для мене ця новина теж частково має ухил у сторону AI.
Так, звісно, формально це про відповідність політикам, контроль доступу та підвищення безпеки даних. І це однозначно великий крок у цю сторону — особливо якщо ти працюєш у фінансовій сфері або з чутливими даними.
Але є й інша сторона. Багато компаній не хочуть передавати в AI персональні дані — особливо контактну інформацію. І можливість закрити або обмежити доступ на рівні конкретної колонки для певних користувачів, які далі можуть передавати ці дані в AI-інструменти, виглядає як дуже логічне й сильне рішення.
Тому, на мою думку, це не тільки про безпеку, а й про підготовку інфраструктури до більш активної роботи з AI.
На цьому новини все - переходимо до корисних матеріалів 🔥
Сьогодні корисних матеріалів буде небагато, але це якраз той випадок, коли кількість компенсується якістю.
🔥 Як отримувати сповіщення про аномалії на основі BigQuery ML.
Сьогоднішню підбірку корисних матеріалів розпочнемо з продовження теми аномалій і сповіщень про них.
На початку розсилки я згадував статтю про GA4 Insights. А Paolo Bietolini поділився більш просунутим підходом.
Так, сповіщення в GA4 — це класно. Але не завжди нам потрібно отримувати сповіщення тільки на дані з GA4 — часто це можуть бути дані й з інших систем.
І тут на допомогу приходить BigQuery з його функціоналом BigQuery Email.
Детальніше про те, як це налаштувати, з реальними прикладами SQL-коду можна знайти у статті за посиланням >>>
🔥 Як зручно показати товари в транзакціях у звітах Power BI.
Автоматичні сповіщення про аномалії — це добре. Але загалом нам потрібен і якісний репортинг.
І одна з частих, але не найпростіших задач — як подати інформацію про товари в транзакціях у зручному вигляді. Особливо коли дані складні, вкладені або розбиті на кілька рівнів.
Команда SQLBI підготувала цікаву статтю на цю тему — з практичним підходом і прикладами. Рекомендую до ознайомлення.
🔥 Правила побудови зрозумілих і ефективних репортів.
У продовження теми звітів. Зробити репорт візуально красивим — це лише мінімальна частина справи. Основна складність у тому, щоб створити звіт, який легко доносить інформацію до кінцевого користувача.
Це вічна тема, про яку написано багато матеріалів. Але головна думка проста: ми робимо репорти не для того, щоб вони просто красиво виглядали, а для того, щоб із ними можна було працювати — щоб на їх основі приймалися рішення і щоб ситуацію можна було швидко зрозуміти.
Одне з таких правил — це 3-30-300 rule. Його суть дуже проста: хороший репорт має давати різний рівень глибини залежно від того, скільки часу людина готова витратити.
- За перші 3 секунди ти маєш зрозуміти загальну ситуацію — наприклад, ми перевиконуємо план чи ні.
- За 30 секунд — побачити основні причини: динаміку, волатильність, ключові сегменти або регіони.
- І вже за 300 секунд — мати можливість зануритися глибше: провалитися в конкретні акаунти, продукти або аномальні точки.
Детальніше про це правило та інші принципи побудови ефективних репортів — читай у статті за посиланням нижче.
І важливо розуміти ще одну річ. Незалежно від того, де ти будуєш звіти (в Power BI, Tableau чи в будь-якій іншій системі) — ці принципи залишаються актуальними.
🔥 Сервіс, який економить час на побудові діаграм.
І наостанок — не стільки матеріал, скільки корисний тул.
Дуже часто при побудові документації потрібно створювати різного роду схеми: зв’язки між таблицями, опис процесів, архітектуру потоків даних тощо.
Раніше я користувався сервісами, де такі схеми потрібно було будувати вручну.
Але зараз з’явилася ціла група інструментів, які дозволяють описати те, що ти хочеш побудувати, текстом — і вони автоматично генерують схему у вигляді картинки. Цього тижня моя колега поділилася одним із таких сервісів — Mermaid Live Editor.
На перший погляд може здатися, що текстом це складніше. Але в епоху AI, коли він чудово працює з текстом, ти можеш навіть просто надиктувати голосове повідомлення, AI сформує структуру тексту, а ти вставиш її в сервіс — і отримаєш готову схему. Дуже просто і дуже швидко.
На всяк випадок нагадую, що існує англомовна версія розсилки на LinkedIn, на яку ти теж можеш підписатися та поділитися з англомовними колегами.
Твій сенсей, Макс Гапчук 🔥
Будь в курсі актуальних новин зі світу аналітики!