Починаємо працювати з Google Analytics: App + Web

by Степан Лютий · 10 Серпня, 2019

Google недавно випустила в публічний доступ нову версію Google Analytics під назвою App + Web. Сімо Ахава вже написав відмінну покрокову інструкцію про те, як почати працювати з інструментом, тому я вирішив перекласти її на українську мову. Від себе додам, що продукт тільки-тільки з’явився в беті і судячи з усього ще буде істотно допилюватися. Ми вже почали тестувати нову структуру даних і можливості вбудованої функції експорту даних в Google BigQuery і сподіваємося незабаром розповісти докладніше про переваги та недоліки. В цілому аналітики сьогодні оцінюють нововведення позитивно. Наприклад, Влад Флакс з OWOX BI вважає, що цим оновленням Google спростив процес збору даних і їх доставку з Google Analytics BigQuery для тих проектів, які готові змінити структуру своїх даних. До того ж, це підвищує цінність Google BigQuery як DWH для маркетинг-даних.

Нижче – переклад статті Симо з його оцінками і враженнями від використання.

Незважаючи на незграбне назви, це дійсно відмінний інструмент для всіх цілей і завдань Google Analytics V2 або Firebase Analytics for Web. Тут ми не говоримо про чарівному способі створення зведених звітів між Google Analytics для Firebase і Універсальний Analytics, або про вдосконалення Універсальний Analytics.

Ні, ми говоримо про нової моделі вимірювання веб-трафіку, вдало сумісної з Google Analytics для Firebase.

Це все ще трохи не відполірований продукт, і документація все ще трохи відсутній, тому я подумав, що я дам вам перевагу і покажу як налаштувати збір даних за допомогою Google Tag Manager. Я маю намір випустити повну, належне, всебічне керівництво, як тільки функція вийде з бета-тестування. Тим не менш, ця стаття повинна допомогти тим з вас, кому вже не терпиться випробувати всі його нові властивості та цікавинки прямо зараз.

Назва Google Analytics: App + Web кілька незручне. Мені здається, що це просто питання часу, коли ми назвемо його Firebase для Web або щось у цьому дусі, адже це те, чим він є по суті. У цій статті я буду називати його GAv2 в тих місцях, де мені буде просто хочеться друкувати назву повністю (так, я ледачий).

Перш ніж почати, відкрийте чудовий блог Крісти Сейден в новій вкладці і зверніть особливу увагу на три статті, які вона опублікувала про можливості звітності Google Analytics: App + Web.

Нові властивості App + Web Analytics
Pathing in Google Analytics
Streamview в Google Analytics.

UPDATE: Відразу після того, як я опублікував цю статтю, Кріста випустила ще одне чудове керівництво, і саме чудове те, що воно доповнює це, оскільки в ньому набагато більш докладно розглядаються етапи створення проекту Firebase. Загалом, зацініть це: Покрокова налагодження App + Web.

Я почну з пари вступних слів, тому, якщо хочете, просто пропустіть їх і переходите відразу до кроків по впровадженню.

Застереження

Насамперед, Google Analytics: App + Web знаходиться в бета-тестуванні. Це означає, що воно ще не готове повністю. Серйозно, воно ще не готове. Багато з тих речей, над якими я зараз ламаю голову, безсумнівно в якийсь момент потраплять на платформу, як і відповіді на багато питань, які у вас виникнуть, напевно будуть подані в наступних релізах.

Ось деякі моменти, які я знайшов у UI звітів і в налаштуваннях Google Tag Manager:

Немає спеціалізованих звітів, наприклад «Звіт про пошук по сайту» або «Ecommerce»
Немає способу розрізняти автоматично зібрані, рекомендовані і настроювані події в користувальницькому UI звітів.
Ви можете налаштувати ресурс користувача, див. нижче як це зробити.
Неможливо відправити items масив (або будь-який інший багатовимірний об’єкт) у якості параметра події в Google Analytics при використанні GTM.
Задати постійні значення в тезі конфігурації в GTM, схоже, неможливо.
Ви можете оновити існуючі ресурси Firebase Analytics згідно з цим документом підтримки. Коли ви відкриєте ресурс Google Analytics (за умови, що ви прив’язали це ресурс Google Analytics), ви побачите синій банер у верхній частині екрана, що пропонує виконати оновлення.

Обов’язково стежте за офіційним блогом, а також за блогом Крісти, адже вони стануть вашими паличками-выручалочками для отримання додаткової інформації, включаючи випуски, присвячені проблемам, переліченим у цій главі.

І наостанок очевидний момент. Це не Універсальний Analytics. Багатьох речей, які ви звикли бачити в Universal Analytics, в Firebase немає. Особисто я сподіваюся, що паритет функціональності не за горами, адже тепер у Google є шанс створити щось нове й краще. Але, природно, ми б усі хотіли, щоб ця платформа в якийсь момент замінила Універсальний Analytics, тому, вона повинна бути корисною, принаймні, тих же випадках використання.

Ось, на мій погляд, основні відмінності Універсальний Analytics від нової платформи.

Універсальний Analytics:
Сесії на передньому плані.
Кастомні визначення hit-, session-, і user-scoped.
Поверхневі звіти в реальному часі.
Сегменти.
Немає семантичного структурування.
Досить сприятливі квоти і ліміти (крім вибірки).

Google Analytics V2:
Користувачі та події на передньому плані.
Настроювані властивості кастомні параметри подій
StreamView і DebugView забезпечують всебічну деталізацію.
Аудиторія.
Автоматично збираються і рекомендовані події.
Суворі квоти та обмеження (без вибірки).

Обмеження особливо болючі, якщо порівнювати їх з тим, що було в Universal Analytics.

У будь-якому випадку, я впевнений, що ці проблеми будуть вирішені до того, як Google Analytics: App + Web вийде з бета-тестування, але одне можна сказати напевно: це не Універсальний Analytics. Спробуйте поглянути на нову модель вимірювань, як на можливість вийти за рамки того, що коли-небудь могло запропонувати Універсальну аналітику, а не просто як на спосіб заповнити давню модель даних GA.

У зв’язку з цими застереженнями я настійно не рекомендую припиняти збір даних Універсальний Analytics і збирати дані, виключно в Google Analytics: App + Web. У всякому разі, цю нову модель вимірювання краще запускати паралельно з будь налаштуванням, яка вже була на сайті, щоб можна було порівняти паритет між двома наборами даних.

Створюємо нові налаштування Google Analytics: App + Web

Щоб створити новий ресурс Google Analytics: App + Web, вам необхідно виконати наступні дії.

Зверніть увагу! Грунтуючись на опублікованій документації, ймовірно, що в майбутньому ці кроки будуть значно спрощені.

Крок 1. Створіть новий проект Firebase

Перейдіть до консолі Firebase і створіть новий проект. Це буде базовий проект Firebase для вашої нової установки.

Назвіть проектом ім’я і ID (ID повинен бути унікальним, він буде згенерований виходячи з імені проекту).

Прочитайте та прийміть умови Firebase, потім натисніть Сontinue.

На наступному кроці переконайтеся, що встановлено прапорець «Set up Google Analytics for my project», і натисніть Continue.

В залежності від того, чи є у вас вже облікові записи Google, тепер ви можете вибрати, в якій облікового запису створити ресурс або створити новий обліковий запис в цілому. Якщо у вас немає облікових записів Google Analytics, пов’язаних з вашим логіном, вам буде необхідно прийняти умови обслуговування GA, після чого для вас буде створено новий аккаунт і ресурс.

Після того, як ви натиснете Create project і обробка завершиться, ви можете перейти в Google Analytics і знайти нове властивість App + Web вибраної вами облікового запису.

Крок 2. Створіть новий веб-потік

Нова модель вимірювання обертається навколо потоків, які можуть надходити з ваших додатків (iOS і Android) або з інтернету. Сподіваюся, що в майбутньому ми побачимо нові потоки, такі як «Measurement Protocol», які буде приймати HTTP-запити від будь-якого пристрою, підключеного до інтернету.

У будь-якому разі, виберіть Data Streams у стовпці властивостей і виберіть Web.

Щоб налаштувати потік, введіть адресу свого сайту і дайте потоку описове ім’я. Потім натисніть на маленьку шестірню, щоб налаштувати додаткові параметри вимірювання (the Enhanced Measurement).

Enhanced Measurement в основному додає деякі можливості автоматичного відстеження на сайт, які активуються при створенні тега базовій конфігурації.

Список речей, які можна автоматично відстежити, досить зрозумілий і добре пояснений в конфігурації Enhanced Measurement (див. скріншот вище).

Як тільки ви будете готові, створіть потік даних, і ви побачите на екрані купу інструкцій з тегированию та інші моменти. Найважливіша річ, яку потрібно відзначити — це Measurement ID. Тримайте цю вкладку відкритою, щоб при необхідності ви могли скопіювати ID вимірювання в теги Google Tag Manager.

Готово? Добре, тепер давайте перейдемо до Google Tag Manager.

Створюємо тег базової конфігурації

У Google Tag Manager при створенні нового тега ви побачите два нових шаблону тегів в селекторі.

Google Analytics: App + Web Configuration аналогічна команді config, використовуваної в реалізації gtag.js. Ви використовуєте його для налаштування трекера, відправлення початкового переглянути сторінки та налаштування постійних значень для всіх ваших подій.

Коли ви відкриваєте шаблон, вас точно не вітає безліч варіантів. По суті, у вас є поле для визначення Measurement ID, перемикач для вибору, відправляти початковий перегляд сторінки або ні, і конфігурації поля, які ви можете встановити в тегу.

Щоб налаштувати базовий тег, вкажіть його в полі Measurement ID веб-потоку, створеного в попередній частині. Ви можете встановити в поле user_id якесь значення, яке пов’язане з ID аутентифікації користувача, у разі, якщо хочете прокласти шлях для вимірювання між пристроями і програмами.

Згідно документації, ви повинні мати можливість визначати параметри події в полях для установки (set Fields to тега конфігурації, якщо ви хочете, щоб ці параметри події відправлялися при кожному наступному зверненні, в якому використовується той же ID вимірювання. На жаль, на момент написання не схоже що це працює.

Встановлюємо користувальницькі властивості

Щоб встановити властивості користувача, спочатку необхідно створити їх UI створення звітів.

Далі перейдіть у вашій конфігурації в Fields to Set і додайте нове поле. Ім’я поля повинно бути user_properties.

В якості значення поля необхідно використати власну змінну JavaScript (чи шаблон користувача змінної), яка повертає об’єкт, де кожен ключ об’єкта відповідає імені User Property, яке ви створили в UI створення звітів, а значення того, що ви хочете відправити як властивості в питанні.

Наприклад, щоб встановити властивість user_type (див. скріншот вище), я можу створити змінну Custom JavaScript, яка виглядає наступним чином:

"function() {
 return {
 user_type: 'Premium user'
};
}"

Потім вам потрібно додати цю змінну в якості значення поля user_properties в тезі конфігурації.

Альтернативний метод полягає у використанні шаблону змінної (див. моє керівництво, якщо ви не пам’ятаєте, що таке шаблони). Ось шаблон, який я створив для повернення об’єкта властивостей користувача. Ви можете використовувати його для створення змінної, в якій ви встановлюєте окремі ключі і значення властивостей користувача, а потім ставите цю змінну, значення ключа user_properties в тезі конфігурації.

Після того, як ви створили тег конфігурації, увімкніть його перемикачем All pages, увійдіть в режим попереднього перегляду. Давайте подивимося, як ця нова модель вимірювання працює на веб-сайті!

Тестуємо!

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

Файл cookie _ga майже такий же, як і в Universal Analytics, з одним невеликим відзнакою. _ga cookie кодує кількість частин домену в значенні cookie число після GA1. Наприклад, якщо cookie записується на simoahava.com домен складається з двох частин, а префікс значення cookie буде GA1.2.

Однак, з GAv2, це не схоже на використання значення cookie_domain за замовчуванням (автоматична настройка).
Я думаю, що це може бути недогляд, як якщо б ви вручну встановили домен, наприклад, www.simoahava.com, cookie має звичайний GA1.3. префікс.

Інший файл cookie, _ga_MEASUREMENT-ID **, схоже, підтримує стан сеансу. Перше довге число — це тимчасова мітка (у секундах), коли був створений файл cookie, а друге довге число — це тимчасова мітка, коли в останній раз хіт був відправлений у GA.

Іншими словами, схоже, що GAv2 як мінімум веде облік того, є чи сеанс активним у даний момент. Ще невідомо, чи буде він в більшій мірі використовувати сталість на стороні клієнта для інформації про сеанс і чи може цей файл cookie використовуватися для визначення стану сеансу в веб-браузері.

Для файлів cookie використовується JavaScript, тому на них впливають заходи по зниженню ефективності файлів cookie на стороні клієнта, такі як інтелектуальне відстеження Safari (Safair’s Intelligent Tracking Prevention).

Потім прослідкуйте за запитами мережі, відправленими браузером, або скористайтеся розширенням відладчика Google Analytics, щоб дізнатися, як бібліотека відправляє хіти в Google Analytics.

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

Тип запиту POST, а кінцева точка раніше є пікселем зображення. Іншими словами, схоже, що хіт за замовчуванням використовує API-інтерфейс Beacon, що є відмінним поліпшенням для Універсальний Analytics, де вам доводилося вручну включати цю функцію.

API-інтерфейс Beacon захищає асинхронні запити, надіслані при вивантаженні сторінки, що дозволяє виконувати їх, навіть якщо браузер закритий. Це дозволяє уникнути неприємностей, пов’язаних з пропуском звернень (наприклад, подіями, пов’язаними з кліком на посилання), оскільки користувач пішов зі сторінки до того, як запит був виконаний.

Якщо подивитися на фактичні параметри, надіслані в GA, то тут є багато знайомих речей, якщо ви пам’ятаєте, як будуються запити протоколу вимірювань.
Параметр v має значення 2, тоді як Універсальний Analytics він дорівнює 1. Це версія протоколу.
Параметр tid встановлений на ваш ID вимірювання.
Параметр gtm хэшируется з ID вашого контейнера GTM.
Параметр cid — це ідентифікатор клієнта, який зберігається у файлі cookie _ga.

Інші параметри, які залишилися практично незмінними, включають в себе такі речі, як uid (ідентифікатор користувача), dl / dr / dt (метадані документа) і sr (дозвіл екрану).

Більше немає вимірювання «Hit Type», замість цього використовується параметр en (event name/ім’я події), щоб відрізняти різні типи хітів один від одного. Це є основною відмінністю від Universal Analytics, оскільки в GAv2 у вас є один єдиний потік подій, де параметри події, які ви відправляєте разом з ім’ям події, визначають, як саме дані відображаються у звітах.

Параметри події мають префікс ep. або epn. для текстових параметрів і числових параметрів відповідно. На скріншоті я створив параметр події з ім’ям country і встановив для нього значення US.

Властивості користувача мають префікс up. або upn. для користувацьких властивостей в текстовому або числовому форматі відповідно. На скріншоті показано одне текстове властивість користувача з ім’ям user_type, для якого встановлено значення Premium user.
Нарешті, параметр sid, схоже, містить позначку часу, коли розпочався поточний сеанс (взятий з cookie _ga_MEASUREMENT-ID).

Досі неясно, що роблять інші параметри.

Одна річ, яку ви могли помітити, це затримка відправки хіта. Коли ви завантажуєте сторінку, ви можете побачити, як браузер почекає кілька секунд, перш ніж відправляти в хіт GA. Це пов’язано з тим, що GAv2 автоматично групує запити, що, знову ж таки, є відмінним оновленням функції.

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

Перед створенням вашого першого тега події, подивіться, як працює Enhanced Measurement. Спочатку прокрутіть вниз до кінця поточної сторінки і погляньте на подію, відправлений в Google Analytics.

Потім клікніть на посилання, яка веде від вашого сайту (CTRL/CMD + клік, щоб відкрити її в новій вкладці). Погляньте на параметри.

Нарешті, якщо на вашому сайті вбудований YouTube з параметром enablejsapi = 1, перевірте автоматичне відстеження відео!

Це все неймовірно круто, але я сподіваюся, що ми ще отримаємо деякі елементи управління для налаштування роботи Enhanced Measurement.

Тепер, давайте створимо наш власний тег події!

Створюємо тег події

функціонують аналогічно використанню подій gtag.js і Firebase.

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

При створенні нових подій спочатку переконайтеся, що подія ще не зібрано автоматично.

Потім перевірте, чи є рекомендована структура подій, яку ви можете використовувати замість інтерфейсу події. Якщо ви знайдете відповідне рекомендована подія, переконайтеся, що ви використовуєте запропоноване ім’я події і параметри при налаштуванні тега події.

Тепер, при бажанні, ви все одно зможете відправити повністю задане ім’я події з абсолютно довільними параметрами події. Просто врахуйте, що при цьому ви втратите деяку гнучкість у інтерфейсі створення звітів, оскільки існують деякі суворі обмеження на кількість загальних властивостей, які ви можете визначити для створення звітів в інтерфейсі.

Давайте почнемо з простого інтерфейсу події.

Створіть новий Google Analytics: App + Web Event teg і заповніть його наступним чином:

Встановіть для параметра Конфігурації Tag значення, створене у попередній частині. Це працює аналогічно змінної налаштувань Google Analytics, так як вам потрібно налаштувати параметри трекера тільки один раз, після чого вони будуть застосовуватися до всіх користувачів, які використовують тег конфігурації.

Дайте події довільне ім’я (тобто не одне з автоматично зібраних або рекомендованих подій). У цьому випадку ми використовуємо data_loaded в якості імені події.

Потім додайте деякі параметри:

all_data – це користувальницький текстовий параметр, для якого встановлено значення true.
debug_mode – це параметр, який при встановленні в тезі відображає хіт в потоці DebugView UI створення звітів (детальніше про це нижче).

Встановіть мітку для запуску перемикача Window Loaded, поновіть режим попереднього перегляду і завантажте контейнер на веб-сайт. Подивіться на мережні запити to /collect.

Після завантаження сторінки ви повинні побачити один запит з двома хітами, об’єднаними в один (пакетний режим).

Як бачите, в першому ряду є хіт page_view, а в другому ряду користувальницьке подія data_loaded.

Тепер перейдіть в UI звітів Google Analytics і виберіть DebugView в навігаторі звітів.

Не забудьте прочитати чудову статтю Крісти про потокових звітах, щоб зрозуміти, як інтерпретувати наступні дані. Ви також можете ознайомитися з власною документацією Firebase DebugView для отримання додаткової інформації.

У селекторі Debug Device у верхній частині екрану ви зможете побачити, скільки пристроїв (наприклад, примірників браузера) в даний момент відправляють debug-хіти в GA. З допомогою селектора перегляньте перераховані пристрої, поки не знайдете той пристрій, що нещодавно відправило подія data_loaded.

Цей селектор Debug Devices зараз непридатний. Сподіваюся, в найближчому майбутньому буде легше знайти debug-пристрої.

Знайшовши подія data_loaded, ви можете побачити та інші хіти, включені в DebugView. Це пов’язано з тим, що якщо пакет містив інші хіти, відмінні від хіта data_loaded, вони також будуть автоматично перераховані в DebugView.

Ви можете клацнути на параметри подію data_loaded, щоб побачити, який тип інформації надсилається в Google Analytics з хітом.

Перш ніж закінчити, давайте спробуємо відправити рекомендований подія теж. Ми відправимо пошукове подія для імітації пошуку по сайту.

Якщо ви ознайомитеся з інструкціями в списку рекомендованих подій, ви побачите, що ім’ям події пошуку search, і він приймає один параметр: search_term. Отже, давайте створимо новий тег події і заповнимо ці значення! Ось як буде виглядати тег:

Як бачите, я просто жорстко закодував пошукове слово в параметрах події. Я запускаю тег з Custom Event Trigger, встановленим для події ім’ям search.

Після оновлення режиму попереднього перегляду і перезавантаження мого веб-сайту я можу запустити подія з допомогою простого window.dataLayer.push ({event: 'search'}), що виконується в JavaScript-консолі сторінки.

У DebugView я бачу, що подію було зареєстровано:

І… ось і все. Ніщо не відрізняє цю подію від подій. Поки ще немає звітів, які б зіставляли дані пошуку по сайту аналогічно Універсальний Analytics. В якийсь момент я впевнений, що деякі пошукові події будуть записані в їх власний звіт, де пошукові дані об’єднуються з автоматично зібраних подією view_search_results (перегляд сторінки, записаний з параметрами запиту, відповідними пошуку по сайту).

Підсумки

У цій статті я хотів показати вам, як налаштувати нову властивість Google Analytics: App + Web при використанні Google Tag Manager в якості обраного інструменту для впровадження.

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

Призначена ця платформа для заміни Універсальний Analytics? Ще невідомо. Але концептуально було б важко обґрунтувати майбутні випуски обслуговування або функцій Універсальний Analytics, коли є нова блискуча модель вимірювання, з якою доводиться миритися.

Я радий обережно представитьь Firebase в інтернеті. Це те, чого я з нетерпінням чекав з тих пір, як почав працювати з Firebase (і Firebase Analytics) дуже давно. Я думаю, що модель вимірювання користувачів і подій перевершує сильно агреговану і сесійний модель, використовувану Google Analytics.

Тим не менш, ще належить з’ясувати, яку частину перемикання контексту нам потрібно виконати подумки, щоб зрозуміти, як варіанти використання, розглянуті Google Analytics: App + Web, можна порівняти з варіантами використання Універсальний Analytics.

Безумовно, Я виділю більше ресурсів для написання контенту для Firebase, оскільки цей новий спосіб об’єднання аналітики додатків і веб-сайтів надто цікавий, щоб його ігнорувати.

Давайте обговоримо Google Analytics: App + Web в коментарях, але пам’ятайте, що ми говоримо про бета-продукті. Ви можете вільно висловлювати своє розчарування з приводу рішень по розробці і відсутніх функціях, але врахуйте, що надання вашої критики конструктивним чином може привести до змін, спрямованих на усунення цих критичних зауважень в кінцевому продукті, оскільки мета бета-версії полягає в тому, щоб отримати зворотній зв’язок від спільноти.