Просто про DataLayer та як він допоможе вашому бізнесу

Веб-сайти, які працюють з бізнес-аналітикою, потребують оперування на рівні даних(DataLayer)! Ось кілька ідей, як отримати від себе максимум користі.

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

Що таке DataLayer?

Кожне будь-коли створене програмне забезпечення має кілька рівнів. Чим більша програма, тим більше в ній шарів. Схоже на бутерброд.

Сендвіч має багато шарів, які підтримують один одного, створюючи чудове поєднання досконалості. Кожен шар сам по собі може принести корисні переваги (певні смаки, текстури, вітаміни тощо), але сендвіч у цілому може бути цілою стравою. Те саме стосується програмного забезпечення, де кожен шар надбудовується один над одним, доки ви не отримаєте корисну програму чи продукт.

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

Так що це? По суті, DataLayer — це певна коробка у вашій програмі, який використовується для звітування та збору даних. Ці дані будуть використані для подальшого аналізу для прийняття бізнес-рішень. Вміст цієї коробки зазвичай стосується кожного користувача та може описувати певні відомості про користувача для різних аналітичних, маркетингових цілей тощо.

Хоча DataLayer можна використовувати майже в кожному програмному забезпеченні, він, безумовно, найпоширеніший в Інтернеті. Якщо ви коли-небудь бачили рекламу на веб-сайті, або аналітику, або кампанії, або ці бульбашки чату, або… список можна продовжувати — тоді ви бачили певну форму відображення DataLayer. Майже кожен сторонній постачальник має певний вид відстеження інформації про користувача, щоб вони знали, як з ним взаємодіяти.

Що може містити DataLayer?

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

• інформація про продукт: id, назва, ціна, розпродажна ціна, категорія, розмір, колір, …
• інформація про замовлення: ідентифікатор, проміжний підсумок, податок, загальна сума, доставка, знижки, …
• інформація про користувача: id, місто, штат, країна, налаштування, ім’я/останнє, …
• інформація на сторінці: час, видимі акції, видимі продукти, категорія, регіон, валюта, …
• пошукова інформація: термін, кількість результатів, запропоновані терміни, …
• інформація про подію: назва події, мітка натиснутої кнопки, …
• багато і багато іншого…

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

Рівень даних міститиме всі дані, необхідні (якщо можливо), щоб надати всім вашим іншим постачальникам. Отже, це може містити всі ваші користувацькі розміри для google analytics, усю інформацію про ваші рекомендації для перевірок ефективності та майже все інше.

Тут також будуть події! Це може бути, якщо користувач натискає певну кнопку, тоді ви можете викликати подію. Або, можливо, вони пройшли через певний потік, ви можете викликати іншу подію. Ідея подій полягає в тому, щоб вказати, що щось сталося, і вам потрібно збільшити лічильник.

Отже, як це виглядає?

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

Google Analytics (GA)

gtag('config', 'GA_MEASUREMENT_ID', { 
  'page_title' : 'домашня сторінка', 
  'page_path': '/home' 
}); 
gtag('event', 'timing_complete', { 
  'name' : 'load', 
  'value' : 3549, 
  'event_category' : 'JS Dependencies', 
  'dimension1': 'foo' 
});

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

Adobe Analytics (AA)

s.pageName = "домашня сторінка"; 
s.prop5 = "домашня сторінка"; 
s.eVar5 = "домашня сторінка"; 
s.events = "подія5,подія5"; 
st(); //або s.tl() для подій

На відміну від GA із переважно іменованими параметрами, Adobe в основному використовує пронумеровані змінні, які називаються props, eVars і events. Є також деякі зарезервовані імена, але більшість з них перераховуються, а потім іменуються в інтерфейсі продукту AA. Перегляди сторінок і події, по суті, налаштовані однаково, але останній виклик відрізняється s.t()для переглядів сторінок і s.tl()викликів подій. Рівень даних AA дуже специфічний лише для їхнього тегу, тому використання їхніх даних в інших постачальників вимагає або окремого рівня даних, або інтеграції. Однак, оскільки всі дані приєднані до глобальної sзмінної, будь-який інший постачальник потенційно може отримати до них доступ, доки sвін не очищений. Для AA від вас вимагається використовувати їх окреслені змінні для відстеження (якщо це не контекстні змінні, але це інша тема).

Tealium

utag_data = { 
  page_name: 'домашня сторінка', 
  page_type: 'домашня сторінка', 
  валюта: 'USD', 
  promo_impressions: ['123', '234'] 
};// для подій 
utag.link({ 
  ...деякі дані, як вище 
});

Менеджер тегів Tealium створено для багатьох постачальників, тому рівень даних не є специфічним для якогось одного постачальника. Вони забезпечують два окремих плоских шари відстеження, один для перегляду сторінки та інший для подій. Будь-який постачальник може отримати доступ до об’єкта utag_data на сторінці, але більшість постачальників буде реалізовано через менеджер тегів, де рівень даних можна доповнити для кожного конкретного постачальника за потреби. Змінні мають непрямий стандарт, але їх можна називати як завгодно, що робить це дуже гнучким.

Менеджер тегів Google (GTM)

dataLayer = [{ 
  pageName: 'homepage', 
  pageType: 'home', 
  currency: 'USD', 
  promoImpressions: ['123','234'] 
}];// для подій 
dataLayer.push({ 
  ...деякі дані, як вище 
});

Подібно до Tealium, змінні можна називати як завгодно, а перегляд сторінки та налаштування подій відрізняються. Однак, подібно до GA, рівень даних GTM базується на подіях, тому вам не потрібно мати код перегляду сторінки, і ви можете реалізувати все за допомогою dataLayer.push(). Для певних постачальників (наприклад, GA) цей рівень даних матиме конкретні назви змінних і кілька рівнів вкладеності, на відміну від повністю плоского та відкритого рівня даних, який використовує Tealium.

W3C

digitalData = { 
pageInstanceID: "MyHomePage-Production", 
page:{ 
   pageInfo: { 
     pageID: "Домашня сторінка", 
     destinationURL: "http://mysite.com/index.html" 
   }, 
   category:{ 
     primaryCategory: "Сторінки поширених запитань" , 
     subCategory1: "ProductInfo", 
     pageType: "FAQ" 
   }, 
   attributes:{ 
     country: "US", 
     language: "en-US" 
   } 
} 
};

Подібно до Tealium і GTM, рівень даних W3C може використовувати всі ваші власні назви змінних і зазвичай не залежить від постачальника. Однак цей стандарт набагато чіткіше визначений, і кожен розділ рівня даних певним чином згрупований за своїм типом. Це призводить до досить вкладеного об’єкта з конкретними іменами змінних. Назва та використання для перегляду сторінки/події не є такими конкретними, як структура даних.

Так багато варіантів!

https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fgiphy.com%2Fembed%2FAANqYGD9LVsw8%2Ftwitter%2Fiframe&url=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2FAANqYGD9LVsw8%2Fsource.gif&image=https%3A%2F%2Fi.giphy.com%2Fmedia%2FAANqYGD9LVsw8%2F200.gif&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=giphyМозок…болить!

Я навів лише 5 прикладів. Уявіть собі, що буквально тисячі постачальників мають власні формати на рівнях даних! Ось чому так важливо спланувати свій рівень даних, а не просто прив’язуватися до частинок, які надходять. Ось чому поширеність менеджерів тегів стала набагато більш актуальною за останнє десятиліття.

Отже, як мені це спланувати?

Я знаю людей, які мають цілі консультаційні компанії, засновані на цьому питанні. Я також витратив на це близько 5 років! Загалом, ось процес:

1. Визначте своїх постачальників. Це буде ваша аналітика, маркетинг, підтримка тощо. Я вважаю, що корисно скласти велику електронну таблицю кожного постачальника, якого ви плануєте використовувати, і включити їхні фрагменти коду та вимоги відстеження для кожного з них.
2. Для складних постачальників (наприклад, аналітики) визначте свої потреби відстеження. Це включає в себе визначення запитань, на які потрібно отримати відповідь, а потім зіставлення цих відповідей із відповідними змінними. Розмістіть ці змінні на іншому аркуші для кожного складного постачальника.
3. Почніть створювати список змінних, нейтральних до постачальника. Взявши інший чистий аркуш, почніть складати список усіх змінних, які з’являються для кожного постачальника, і помістіть їх у нейтральну змінну постачальника. Наприклад, можливо, у мене є змінна типу сторінки в AA як prop1, GA як pageType, і в якогось іншого постачальника як page. Це всі сторінки одного типу, тому, можливо, моя змінна, нейтральна від постачальника, стане page_type. Ви також захочете повторити цей крок для подій (виписка, надсилання інформаційного бюлетеня тощо).
4. Отримавши ці списки, ви зможете вирішити, як їх упорядкувати. Особисто мені подобається плоский підхід Tealium до свого об’єкта utag_data. Як розробнику, на нього найпростіше посилатися порівняно з вкладеними рівнями даних. Як би ви не вирішили організувати його, переконайтеся, що він читабельний, має сенс і гнучкий.
5. Реалізуйте це! Закодуйте його на сторінках, щоб почати ним користуватися.

Що ще я повинен знати?

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

Також потрібно бути послідовним. Виберіть схему іменування змінних і дотримуйтеся її. Це також стосується значень у змінних. Це, безумовно, те, звідки виникає більшість помилок у реалізаціях, які я бачив, іноді аж до повного розриву сторінок, оскільки розробники не отримали достатньо інструкцій. Якщо вам потрібні підказки щодо цього, перегляньте приклади Tealium, GTM або W3C, оскільки вони дуже широко використовуються та мають визначені стандарти.

Нарешті, подумайте розумно про те, що ви розміщуєте на рівні даних. Я бачив кілька дивовижних запитів на відстеження, які в кінцевому підсумку так і не були використані в будь-якій якості, але розробникам на їх реалізацію знадобилося багато годин. Ваш рівень даних має 1) реалізовувати те, що потрібно для ваших постачальників, 2) реалізовувати те, що необхідно для відповідей на ваші запитання. Більше цього не потрібно, але обидва вони абсолютно потребують попереднього планування. Якщо ви не сплануєте заздалегідь, пізніше це буде коштувати набагато більше, щоб додати та підтримувати те, чого можна було легко уникнути під час початкового впровадження.

Заключні думки

Сподіваюся, ця стаття дає деяке уявлення про те, що таке рівень даних і як ним користуватися. Це не повинно бути важко, хоча на початку це може бути непосильним. Просто не забувайте планувати заздалегідь і зробити це корисним для себе!

• Стюарт Роскеллі Що таке рівень даних? Поради та найкращі практики