Всички знаем каква е важността на точните данни и анализ. Въпреки това, продължаваме да виждаме пропуски и грешки от страна на бизнесите.

От тази статия ще научите:

• Какви са типичните пропуски на фирмите при събиране и анализ на WEB данни?
• Какъв е ефектът върху бизнесът им поради тези пропуски? 
• Процес за отстраняване на пропуските

Ще ви разкажем за основните тенденции през последните 3, 4 години и потенциалните казуси. Естествено, фокусът ни ще бъде известният [или печално известният] Google Analytics 4, който почти всички използваме. Ще прочетете някои идеи как да проверявате потенциални казуси и ще ви дадем шаблон за организиране на процес, чрез който да валидирате данните си.

 

Колко е важна точността на данните ви?

Въпросът изглежда тривиален. Всеки ще каже, че е много значима, но защо бизнесите допускат да имат неточни данни и не инвестират достатъчно в този процес?

Ако имат неточни данни, заключенията и решенията, които взимат, са най-вероятно грешни.

Разбира се, според размера на бизнеса, това може да доведе до сериозни отклонения, много големи грешки в оценката на ефективността на рекламните канали и дори в създаването на стратегията.

 

На какво разчитаме за точни данни?

 

Вземане на решения - Неточните данни водят до неправилни решения и отрицателни бизнес последствия.

Оценка на ефективността - Това е много типичен проблем, който обикновено първо се забелязва от клиентите.

Разпределение на ресурсите - Неточните данни ще ни попречат да разпределим бюджетите, когато създаваме маркетинг микса, което може да доведе до неефективност в каналите и стратегията.

Дългосрочна стратегия - Малки разминавания в суровите данни могат да доведат до големи изкривявания в тенденциите

Доверие и комуникация - Може да се създадат проблеми с другите заинтересовани страни, които работят с отчетите, базирани на грешни данни [шефове и партньори].

Историческо сравнение - Неточните сурови данни правят бъдещите сравнение безполезни. Историческите ни сравнения няма да са верни, когато за даден период имаме некоректни данни. 

Това е особено актуално с миграцията от Universal Analytics към GA4. Където, освен всичко друго, данните не са съвсем директно сравними. Има някои разлики, които могат да маскират неточно събиране. Т.е. ние може да сме направили непълна, неуспешна миграция, да събираме грешни данни в GA4.

 

Тенденциите

Напоследък все повече се говори за AI базирани решения. Сега ще видим какви са тенденциите и ще разберем защо тези AI Machine learning базирани решения са още по-чувствителни към точността на данните ни. 

 

Какво се случва в web-измерването през последните години:

• Крос-платформено измерване (WEB & Mobile) - В един интерфейс, какъвто е GA4, едновременно да се измерва поведението на потребителите в сайтове и в мобилни приложения. 
  
  
• Предвиждане на бъдещето - Особено след появата на решения от типа ChatGPT, които по отношение на статистическият анализ на данните не са нещо специално, се очаква интегриране на решения, които “предвиждат бъдещето”. Т.е. анализирайки нашите данни, да определят lifetime value, потенциал за churn, ценност на потребителите, бъдещата ценност на потребителите. 
  
  
• По-точно атрибутиране на конверсиите (Data-driven модели) - Разширява се употребата на data-driven модели за атрибутиране, в които алгоритъм, черна кутия, се опитва да определи в дългото поведение на потребителя всяка интеракция, всеки рекламен, органичен, социален канал, какъв принос има. 
  
  
• Достъп до суровите данни и операции с тях (Big data) -  До някаква степен е решено в GA4. Разбира се, това е и политика на Google, която има за цел по-добра монетизация на инфраструктурата около GA4.  Но все пак бизнесът, усложнявайки изискванията си, все повече има нужда от суровите си данни, за да може да ги извлича, обработва, свързва с данните от други платформи [Universal Analytics не даваше такива възможности].
  
  
• Заобикаляне на ограниченията - GDPR, cookieless browsing, ITP, LPT - Всичко това са предизвикателства пред точното измерване и се изисква прилагане на решение, което да ги преодолее.
  
  
• По-добра интеграция с рекламните платформи - Известно е, че GА4 се интегрира добре с Google Ads, но не толкова добре с Facebook, което води до значителни разминавания между двете платформи. 

 

Индустриални предизвикателства

GDPR Consent, Cookieless, ITP, ATT, LPT - Прилагането на GDPR Consent режими, правилната имплементация на ограниченията, свързани с регламента, води до потенциална загуба на много данни. Т.е. ние имаме голям брой посетители, за които няма да имаме запис към Google Analytics 4, Google Ads, Facebook, което може много да изкриви данните ни. Разбира се, това прави още по-важно точното събиране на останалите данни, защото ще работим извадково. Колкото по-точни данни му подадем в извадката, толкова по-добре. 

Специфичност на потребителското поведение - one-size-do-not-fit-all в ecommerce и B2B индустрията - Имаме доста стандартизирано подаване на данните в ecommerce, но за B2B индустрията се налага да се правят custom имплементации, което отваря вратата за потенциални грешки. Те могат да варират от недобро планиране, недобра архитектура на данните до неточно събиране.

WEB + APP = Круши + Ябълки - За щастие повечето от вас нямат нужда [почти никой няма нужда] от съвместно измерване на web и app. Но за нещастие, тази концепция е залегнала в архитектурата на GA4 данните, което създава проблеми при интерпретирането и работата с тях. 

Walled gardens - Най-популярната платформа, която не обменя данни с други е Facebook. И това поражда големи разминавания между GA4 данните и Facebook данните.

Усложняване на инфраструктурата - Чрез натрупване на зависещи едно от друго решения. 

Алчност -  Рекламните платформи съзнателно добавят ограничения и специфики, които ни вкарват в режим на непредвидимост. Появяват се артефакти, които не можем точно да оценим и ни създават проблеми в измерването. 

 

Предизвикателства пред бизнеса

• Бързо усложняване на екосистемата 
  
  
• Липса на квалифицирани специалисти 
  
  
• Неразбиране на значимостта на бизнеса
  
  
• Подценяване на необходимите инвестиции за развитие на дейността
  
  
• Липса на процес и планиране за поддръжка точността на данните
  
  
• Директни загуби и пропуснати ползи

 

GA4 казуси - Общ преглед

Особености на платформата

 

• Сложна и противоречива архитектура на данните 

 

• Усложнено и специфично конфигуриране 

 

• Различна техническа логика за събиране на данните 

 

• Неудобен и недобре направен интерфейс 

 

• Множество очевидни и неочевидни бъгове 

 

• Системно използване на статистическо моделиране

 

• Изпълнено от Black Box, без информация за логиката му

 

• Server-to-server интеграциите са сложни и капризни

Резултатите

• Неразбираеми данни - Възможно е да забележите странни данни, които противоречат и на логиката, и на наблюденията, и на данните от други места. 
  
  
• Липсващи данни - Загуба на данни поради неправилна конфигурация или пропуски в събирането.
  
  
• Грешни данни - Разминавания в данните (напр. брой трансакции).
   
• Атрибутиране - сериозни разминавания в данните, репортувани от различните платформи.
  
  
• Грешни отчети -  GA4 специфики при комбинирането на дименсии и метрики със значителен потенциал за грешки.
  
  
• Усложнен анализ - изисква много повече експертност и вникване в детайла. 

 

GA4 Конфигуриране - профил

Какво да преглеждате в настройките на профила:

• Връзка с UA профила
  
  
• Модифицирани/Нови събития
  
  
• Конверсии
  
  
• Период на запазване на данните
  
  
• Добавени Филтри
  
  
• Определяне на идентичността на потребителите
  
  
• Модел за атрибутиране
  
  
• Връзка с Google Ads и Google Search Console

Как работи gtag.js?

GTAG.js има доста по-различен начин на работа и през него минава цялата комуникация с различните крайни точки на Google екосистемата. Това означава, че Universal Analytics има [ако не сте я деактивирали] връзка с GA4, която представлява конфигурация, която казва как данните и нещата [събития, цели] от Universal Analytics ще се записват в GA4. 

Т.е. нещо, някакъв компонент ще записва данни в GA4 през Universal Analytics настройките. Това е библиотеката GTAG.js. Ако имате добавена тази библиотека, а ако я нямате, тя ще се сервира през Google Tag Manager, за разлика от преди, вие ще записвате само през интерфейсна конфигурация, без да подавате нищо в кода. 

Да, но обикновено трансформацията на Universal Analytics събития не е оптимална към GA4. Има и друг проблем - Universal Analytics целите се импортират като Google Analytics 4 конверсии.

Tag Manager вече работи също с GTAG.js. Tag Manager ще зареди GTAG.js библиотеката и ще работи с нея. Преди не беше така, Google Tag Manager самостоятелно генерираше съответните заявки към endpoint-a на Universal Analytics или GA4 за запис на данни.

И накрая GTAG.js библиотеката ще подаде данните към Google Ads и към другите платформи, но през GA4 интерфейса вече може да конфигурирате много неща в поведението на GTAG.js, което може да доведе, особено когато имате комбинирана имплементация, до проблеми като двойни записи и др.

Затова самите Google не препоръчват да използват едновременно GTAG.js и Google Tag Manager.

 

Връзка с UA профила

Какво се случва? Първото нещо, ако тази връзка е активирана, Universal Analytics събитията, които сте настроили да идват, ще се подават към GA4 през GTAG.js библиотеката, като се случва тази трансформация:

Event Action [от Universal Analytics събитието] ще бъде мигриран към -> Event Name

Event Category  -> event_category (custom event parameter)

Event Label  -> event_label

Event Value  -> value 

 

Има риск от дублиране на данните по няколко начина:

 

1. Aко има активен Enhanced measurement и в Universal Analytics събирате тези събития, ще постигнете двойни измервания. 
   
   
2. Ако имате активен Google Tag Manager, т.е. вие си правите Custom Event за form submit, имате го обаче в Universal Analytics, имате GTAG.js и Tag Manager на сайта си, ще получите двойно измерване.

Миграция на UA целите

Universal Analytics целите автоматично са мигрирани като конверсии. Отново, ако връзката е активна, няма нужда от допълнително потвърждение. Разбира се, ако използвате импорт на GA4 конверсии в Google Ads, добавените Universal Analytics цели от един момент започват да се импортират като Primary conversions, което води до проблеми, до дублиране. 

 

GA4 КОНФИГУРИРАНЕ - WEB Stream

 

• Автоматични събития (enhanced measurement) - потенциално двойно събиране при свързан UA профил или GTM имплементация

 

• Cross-domain проследяване - има ли нужда, активно ли е, работи ли?
  
  
• Вътрешен трафик - дефиниран ли е правилно?

 

• Нежелани рифъръли - добавени ли са?

 

• Timeout на сесията - стандартна или custom дефиниция?

Събиране на данни - Къде да насочим усилията си?

Типични примери за неподходяща архитектура на данните:

• Висока кардиналност на имената на събитията - Това означава, че идват хиляди стойности, което не може да е добър подход, защото създава затруднения в анализа. Висока кардиналност означава много стойности. 
  
  
• Липса на логика конвенция за имената на custom event parameters - Подават се custom параметри, но те са кръстени без логика.
  
  
• Липсващи важни метаданни при подаване на custom събития - Представете си в един e-commerce, когато подавате purchase event, но нямате items масива, т.е. не подавате данни за отделните продукти, които влизат в тази покупка.
  
  
• Липсваща логика и идея за последващия анализ на данните

 

Процес

Архитектурата на данните се базира основно на професионален measurement plan. Разбира се, ако ще правите тривиален e-commerce, може да не го изготвяте, въпреки че е добра практика да използвате стандартизиран measurement plan, който все пак да къстъмизирате според възможностите и нуждите си.

• Професионален measurement plan:

- Анализ на бизнес очакванията

- Първоначално дефиниране на KPI

- Визия за измерване, имплементация, анализ 

- Детайлно описани custom events, техните параметри, начини на подаване и събиране 

 

• Регулярна проверка на изпълнението е задължителна

- Коментари, промени, оптимизации

- Минимум веднъж на 6 месеца

- Препоръчително веднъж на 3 месеца

 

• Валидиране на събираните данни спрямо заложените в плана

 

Грешно поадаване на данните

Некоректни данни в datalayer / gtag.js - Не идва това, което трябва. Но ако имате measurement plan, валидацията ще е по-лесна. Може да го дебъгваме в Google Tag Manager, ако има datalayer, може да го дебъгваме в DebugView-то на GA4. Т.е. може да виждаме какво идва към конкретните събития. Това е най-типичният случай. 

Грешно конфигуриране на GTM / gtag,js - Може би не сме направили както трябва тригери, изпълняваме двойно-тройно ивенти или пък не изпълняваме нещо вътре. 

Грешно форматиране на продуктови данни (ecommerce)

• Различни transaction_id
• Неправилно калкулиране на discount, tax, shipping
• Грешно quantity
• Грешни item параметри  

Грешно таргетиране на събитията - Кликове на бутон вместо изпращане на формата

Грешни / Липсващи custom параметри

 

Процес

• Регулярен преглед на данните в GA4. Сравнение със заложените в measurement plan 

-Сравнение на данните с други платформи за целите на валидацията - ERP, рекламни платформи, GSC, инструменти за имейл маркетинг

- Добре е да се прави ежемесечно, при бизнеси със значителен обем - по-често!

- Използване на автоматизирани инструменти (API export и логика за валидация)

- Като минимум - Explorations и ръчно сравнение

 

• Намиране на причините

-Преглед на front-end

- Наблюдения на GA4 front-end заявките и GA4 Debug mode

- Преглед на GTM конфигурацията

Типични неприятни грешки

 

• Различни Transaction ID в GA4 и ERP
  
  
• Липсващи UTM-параметри - Добавяйки UTM параметри на платения ви трафик. [Забележка] Bitly не предлага по подразбиране пренасяне на вашите UTM параметри, т.е. това, че ще сложите на Facebook поста Bitly link и ще сложите в настройките на кампанията UTM параметри, не означава, че те ще стигнат до вас. Bitly ще ги отреже.
  
  
• Неконсистентни UTM параметри

- Липса на консистентна логика при генериране и употреба 

- Ръчно тагване вместо автоматично (Facebook, GAds) 

- Презаписване на gclid с ръчни utm параметри

 

• Грешни UTM параметри - промяна на имената на кампанията 
  
  
• Неконсистентни user properties, особено User ID (user_id) - избягвайте да подавате User ID, преди да сте сигурни, че може да го генерирате консистентно. 
  
  
• Модификации на някои параметрите на Еnhanced events (page_location) 
  
  
• Необмислено добавяне на user properties, различни от user_id 
  
  
• Интерфейсна модификация на Events 
  
  
• Останала по подразбиране стойност на Data Retention - ще имаме данни само за 2 месеца 
  
  

Как да го внедрим в нашата фирма/клиент?

Планиране

• Дефиниране на цели и процес - Ключово е да се дефинират вътрешно или с клиента.
  
  
• Бюджетиране -  Поради подценяването на ролята на точните данни, това се превръща в проблем на много фирми. Планирайте процент от бюджета, който харчите за реклама, да отделяте за валидиране и работа с данни.
  
  
• Списък със задачи и срокове - Ако не може да се справите, използвайте външна помощ. 
  
  
• Изграждане на инфраструктура за проверка - Ако не ви е позната темата, това може да ви звучи като rocket science, но не е. Има шаблони, инструменти, автоматизация, които може да използвате [включително безплатни инструменти, които извличат данни от GA4 през API].
  
  
• Определяне на колега/и, натоварени с изпълнението им - Всяка фирма, която иска да има сериозно отношение, трябва да определи кой ще бъде отговорен по темата.
  
  
• График за проверки - Изградете график за регулярна проверка и не го пренебрегвайте.

 

Тази статия обобщава ключовите точки и добрите практики от лекцията за F5 Conf Google Ads на Благовест Йорданов, основател и управител на ID Consult.