Ця стаття народилася зі стітті Сімо Ахави написаною ще у 2014 році він важав у той час що “Писати цю статтю небезпечно”. Файно але у 2022 це вже стандарт як я вважаю, тому й перероблю цю статтю додав ремарки та вважаю що це може бути корисно. Я хочу щоб це був вже мій чесний погляд на те, що таке DataLayer з різних точок зору.
А перспектив справді багато. Саму термінологію важко визначити. У цій статті я розглядаю DataLayer , який містить такі визначення:
- Опис бізнес-вимог і цілей, вирівняний у форматі, який можна легко перенести в технічні специфікації
- Концепція дискретного шару семантичної інформації, що зберігається в цифровому контексті
Я також використовуватиму назву змінної dataLayer для позначення структури даних, яка використовується Менеджером тегів Google(GTM) для зберігання, обробки та передачі даних між цифровим контекстом і рішенням для керування тегами. Я також віддаю перевагу терміну цифровий контекст, ніж веб-сайт, наприклад, оскільки рівень даних можна використовувати в різних контекстах, а не лише в загальнодоступному веб-середовищі.
Рівень даних, який найбільше досліджується в цій статті, міцно вкорінений у DMZ між розробниками та маркетологами. Це дуже технічна концепція, оскільки її існування виправдано обмеженнями, які накладають певні веб-технології (наприклад, JavaScript) на те, як браузери взаємодіють із програмами (наприклад, Google Tag Manager). У той же час Рівень даних належить і повинен належати принаймні частково маркетологам, аналітикам, керівникам, дизайнерам і фахівцям з комунікацій, які розробляють бізнес-вимоги та цілі, які задовольняються методами збору даних.
Іншими словами, дуже часто питання про управління рівнем даних гаряче обговорюється між різними зацікавленими сторонами «організації даних» у компанії. Оскільки, як ми дізнаємося, це загальна модель даних, яка може використовуватися всіма програмами, які взаємодіють із вашими цифровими даними, дуже важко розробити модель управління, яка задовольнила б усі сторони. Це теж ми дослідимо в цій публікації.
Наприкінці я поділюся чудовими ресурсами, щоб дізнатися більше про рівень даних, оскільки ця публікація не буде глибоким зануренням (хоча вона багатослівна).
ЩО ТАКЕ РІВЕНЬ ДАНИХ (DataLayer)
Коротко кажучи, рівень даних — це структура даних, яка ідеально містить усі дані, які ви хочете обробити та передати з вашого веб-сайту (або іншого цифрового контексту) до інших програм, з якими ви пов’язали зв’язок.
Причина, чому ми використовуємо рівень даних, полягає в тому, що іноді необхідно відокремити семантичну інформацію від іншої інформації, що зберігається в цифровому контексті. Це, у свою чергу, тому, що якщо ми повторно використовуємо вже наявну інформацію, існує ризик того, що після внесення змін до вихідного джерела цілісність даних буде порушена.
Дуже поширеним прикладом є відстеження веб-аналітики. У вас може бути рівень даних, який передає дані про відвідувача в інструмент аналітики. Часто ці дані недоступні на рівні презентації або взагалі в розмітці. Такими даними можуть бути, наприклад, відомості про відвідувача (статус входу, ідентифікатор користувача, геолокація), метадані сторінки (оптимальна роздільна здатність, авторські права на зображення) або навіть інформація, яка вже міститься в розмітці, але до якої ви хочете отримати доступ більш надійний спосіб.
Це дублювання часто спостерігається в даних електронної комерції. Замість того, щоб «збирати» деталі транзакцій із заголовка чи вмісту сторінки, надійніше використовувати рівень даних для передачі цієї інформації, оскільки лише таким чином дані належним чином відокремлюються від веб-сайту, а це означає, що вони менш схильні до помилок, коли розмітка змінена.
Якщо, наприклад, ви хотіли б використовувати дані, що зберігаються в заголовку H2 розмітки HTML на сторінці подяки, одна зміна розмітки або формату інформації в цьому елементі HTML поставила б під загрозу збір даних із сайту на ваш інструмент відстеження. Проте, якщо дані зберігалися на рівні даних без зв’язку з презентаційним рівнем, існує набагато менший ризик виникнення неочікуваних змін (хоча це точно не неможливо).
Отже, коротко кажучи, рівень даних — це структура даних для зберігання, обробки та передачі інформації про контекст, у якому він існує .
РІВЕНЬ ДАНИХ: НЕТЕХНІЧНИЙ ПОГЛЯД
Для маркетолога, аналітика, керівника, спеціаліста зі зв’язків із громадськістю чи інших осіб, які не є розробниками, рівень даних насправді є переліком бізнес-вимог і цілей для кожної підмножини цифрового контексту.
Для веб-магазину, наприклад, бізнес-вимоги та цілі можуть включати інформацію про транзакції (що було придбано), дані користувача (хто зробив покупку), просторові та часові деталі (де було зроблено покупку та в який час) та інформацію про можливі мікроконверсії (чи підписувався користувач на оновлення продукту).
Для іншої частини того самого веб-сайту бізнес-вимоги та цілі можуть включати просто деталі про те, який канал соціальних мереж привів користувача на веб-сайт або які сторінки користувач переглядав більше одного разу.
Це не технічні специфікації, а чітко визначені списки елементів, які необхідно зібрати, щоб задовольнити бізнес-цілі, встановлені для кожної бізнес-сфери веб-сайту чи іншого цифрового контексту.
В ідеалі рівень даних містить інформацію, яка може використовуватися якомога більшою кількістю різних інструментів/користувачів/зацікавлених сторін, але дуже часто виникають особливості. Ось чому надзвичайно важливо розглядати рівень даних як живу, гнучку модель, а не застійну, монолітну, єдину сутність.
Подібно до будь-якого аспекту цифрової аналітики, рівень даних також слід розглядати як щось, що постійно змінюється. Дані, які він зберігає, необхідно оптимізувати, опрацьовувати, розділяти, об’єднувати, очищати, переробляти та перевіряти так часто, як з’являються нові вимоги до бізнесу або коли попередні цілі не приносять користі для бізнесу.
DATALAYER МЕНЕДЖЕРА ТЕГІВ GOOGLE
Оскільки для моделі даних, розглянутої в цій статті, не існує жодного існуючого стандарту (хоча робота триває ), рівень даних може мати багато технічних іпостасей. Технічна структура, яку я вибрав, — це та, яка розвивалася завдяки Менеджеру тегів Google. Це тому, що я вважаю, і я лише трохи упереджений, що dataLayer це одна з більш елегантних реалізацій моделі структурованих даних у веб-середовищі.
dataLayer це масив JavaScript, який містить дані в парах ключ-значення. Ключ — це ім’я змінної у форматі String, а значення можуть мати будь-який дозволений тип JavaScript. Це приклад dataLayer із різними типами даних:
dataLayer = [{
'products': [{
'name': 'Kala Ukulele',
'tuning': 'High-G',
'price': 449.75
},{
'name': 'Fender Stratocaster',
'tuning': 'Drop-C',
'price': 1699
}],
'stores': ['Los Angeles', 'New York'],
'date': Sat Sep 13 2014 17:05:32 GMT+0200 (CEST),
'employee': {'name': 'Reggie'}
}];
Тут ми маємо такі значення, як масив об’єктів (продукти), числові значення (ціна), масив рядків (магазини), об’єкт дати та вкладений об’єкт (ім’я працівника).
Справа тут у тому, що dataLayer є загальним і не залежить від інструментів. Поки він поводиться як типовий масив JavaScript, він не буде обмежений лише одним інструментом. Інформацію в dataLayer об’єкті вище може використовувати будь-яка програма, яка має доступ до глобального простору імен цієї сторінки.
Таким чином, інструмент обробляє дані в цьому масиві. У Менеджері тегів Google, наприклад, проміжний допоміжний об’єкт використовується для обробки даних у dataLayer, які потім зберігаються у внутрішній абстрактній моделі даних у самому інструменті. Це гарантує, що dataLayer він може залишатися загальним і незалежним від інструментів, але дані всередині обробляються відповідно до ідіосинкратичних функцій Менеджера тегів Google.
Допоміжний об’єкт, який використовується Менеджером тегів Google, має низку цікавих функцій, як-от:
- Слухач, який прослуховує додавання до
dataLayer. Якщо відбувається додавання даних(push), оцінюються змінні в доданому. - Отримайте та встановіть методи, які обробляють/маніпулюють
dataLayerяк чергу (першим увійшов, першим вийшов), і переконайтеся, що спеціальні значення (об’єкти, масиви) у моделі даних можуть бути оновлені та правильно додані. - Можливість доступу до команд і методів об’єктів, що зберігаються в
dataLayer, а також можливість запуску спеціальних функцій у контексті моделі даних.
Усі вони, звичайно, прозорі для користувачів Менеджера тегів Google, але вони пояснюють, наприклад, чому макрос змінної рівня даних може однаково отримувати доступ до назв змінних (gtm.element) і властивостей (gtm.element.id), розділених крапками, а також чому ви можете надсилати кілька значень з тим самим ключем, dataLayer але лише останнє надіслане значення доступне для тегів, які запускаються після надсилання.
Оскільки абстрактна модель даних у Менеджері тегів Google враховує лише останнє значення будь-якої змінної, бізнес підрозділ повинен вирішити, де і коли рівень даних як бізнес-компонент стане dataLayer структурою масиву. Це тема наступного розділу.
ВІД БІЗНЕС-ЦІЛЕЙ ДО ТЕХНІЧНОЇ РЕАЛІЗАЦІЇ
Я вважаю, що найпоширеніший підхід полягає в тому, що бізнес-вимоги та цілі транслюються в набір пар ключ-значення, який має бути відображено/розгорнуто за допомогою коду на стороні сервера, щоб dataLayer він заповнювався всіма необхідними даними перед GTM завантаження фрагментів контейнерів .
Природно, ви можете зробити це за допомогою коду на стороні клієнта, і його не потрібно попередньо заповнювати, але критично важливі для бізнесу дані найкраще захищені, якщо вони відображаються в dataLayer якомога раніше момент завантаження сторінки, щоб уникнути втрати даних мінімізується, якщо користувач вирішить залишити сторінку до dataLayer її відтворення.
Ось приклад. У нас є сторінка з такими бізнес-вимогами, які ми хочемо відстежувати як бізнес-цілі:
- Ідентифікатор користувача , оскільки ми хочемо відстежувати весь шлях користувача , а не лише сеанс за сеансом або пристрій за пристроєм
- Внутрішній користувач – тому що ми хочемо відфільтрувати трафік наших власних співробітників із даних
- Погода під час візиту – тому що ми хочемо побачити, як погода впливає на поведінку відвідувачів
Це простий, хоча й безглуздий, перелік бізнес-вимог, які безпосередньо впливають на те, як ми відстежуємо цілі для цієї частини веб-сайту. До цього списку потрібно додати додаткову інформацію, наприклад, які приклади значень для цих змінних, який їхній обсяг (наприклад, звернення, сеанс, користувач, продукт), чи мають вони зберігатися (залишатися зі сторінки на сторінку) і так далі. Я не буду цього робити зараз, оскільки це дуже залежить від того, як ваша організація керуватиме проектами, які охоплюють різні відділи чи сфери діяльності.
У будь-якому разі приклад dataLayer, відтворений перед контейнерним фрагментом, може виглядати так:
<script>
window.dataLayer = window.dataLayer || [];
dataLayer.push({
'userId' : 'abf5-3245-ffd1-23ed',
'internalUser' : true,
'weather' : 'Cloudy'
});
</script>
<!-- GTM Container Snippet Code Here -->Як бачите, дані відображаються перед фрагментом контейнера GTM, тому всі теги, які запускаються, щойно завантажується GTM, можуть використовувати ці дані.
Зауважте, що ви також можете і будете використовувати dataLayerв межах Менеджера тегів Google, оскільки ваші теги чи інші бібліотеки на сторінці цілком можуть вставити дані в структуру після цієї послідовності попереднього завантаження. Я не думаю, що ці динамічні надсилання чи обмін даними потрібно так ретельно документувати, оскільки вони відбуваються виключно в області інструменту, який виконує надсилання. Таким чином, документація та контроль версій залишаються на розсуд самого інструменту.
Причина, по якій вам потрібно багато думати над попереднім рендерингом, dataLayerполягає в тому, що кожна нова зацікавлена сторона робить питання управління дещо складнішим.
УПРАВЛІННЯ РІВНЕМ ДАНИХ
Придумати хорошу модель управління важко. Придумати таку структуру даних, яка знаходиться на милості кількох різних сторін, усі з різним рівнем знань (і загальним інтересом), ще складніше.
Тим не менш, чітко визначена, структурована та формалізована модель управління — це, ймовірно, єдине, що запобіжить краху вашої аналітичної організації через помилки в роботі з рівнем даних.
У цьому контексті модель управління — це документ (або документація), який якомога чіткіше описує рівень даних, його частини, бізнес-домени, у яких він розгорнутий, його різних власників, його історію версій, його змінні, як здійснюється управління ризиками оброблені тощо
Це дуже мінлива концепція, і це дійсно залежить від організації, як вони хочуть організувати себе навколо цього проекту, але в ідеалі це та модель управління, з якою я був би радий працювати:
Вступ
- Призначення документа
- Для кого цей документ
- Зміст
II Історія версій
- Що було переглянуто
- Коли його переглянули
- Ким переглянуто
III Право власності
- Що означає право власності
- Кому належить процес
- Які права та привілеї має власник
IIIa Зацікавлені сторони
- Хто має частку в Data Layer (інструменти, платформи, відділи, агентства, треті сторони)
- Яка їх роль
- Які у них права та привілеї
IIIb Технічні характеристики
- Кому належить технічний рівень даних (найчастіше ІТ чи дуже освічений маркетолог)
- Яка їх роль
- Які у них права та привілеї
IIIc Управління
- Кому належать бізнес-вимоги (керівник відділу маркетингу чи інша подібна посада в організації-клієнті)
- Яка їх роль
- Які у них права та привілеї
IV Розподіл процесу
- Які сторони використовують рівень даних
- Які у них особливі вимоги
- Як уникнути конфліктів між різними зацікавленими сторонами
V Управління ризиками
- Які є ризики
- Яка їхня тяжкість
- Яка їх вірогідність
- Кому належать ризики (і будь-які дії, вжиті для їх зменшення).
VI Модель управління рівнем даних
- Як планувати оновлення
- Як реалізувати оновлення
- Хто розгортає оновлення
- Хто тестує оновлення
- Кого потрібно повідомити
- Хто оновлює документ
- Як уникнути конфліктів
VII Технічний опис рівня даних
- Що таке базова структура даних
- Як ця структура транслюється у власну модель даних кожного інструменту
- Чи є зарезервовані імена змінних або інші потенційні джерела конфлікту
VIII Змінні рівня даних
- Бізнес-вимоги, перекладені на змінні рівня даних
- Відсортовано за бізнес-доменом
- Приклади значень, область дії, параметри, очікувані типи
- Звідки надходять дані
- Як використовуються дані
- І так далі…
Я знаю, це виглядає жахливо. І, ймовірно, непридатний для багатьох. Однак наявність такого документа, який також постійно оновлюється, не лише забезпечує певну договірну безпеку, але й дозволяє всім бути в курсі найновішої структури та формату рівня даних.
Чи потрібно переглядати/оновлювати цей документ, коли ви створюєте новий фрагмент коду JavaScript, який обчислює кількість зображень на сторінці?
Напевно ні.
Чи потрібно переглядати/оновлювати цей документ, коли ви впроваджуєте піксель конверсії, який також використовує значення транзакції?
Швидше за все.
Чи потрібно переглядати/оновлювати цей документ, коли ви розгортаєте розширену електронну комерцію?
Абсолютно.
Це не повинно бути більшим за життя чи величезною складністю. Просто майте постійний доступ до якогось конкретного опису рівня даних і принаймні домовтеся в письмовій формі про те, як і ким оновлюється рівень даних. Таким чином ви заощадите багато проблем у довгостроковій перспективі, коли незабаром відбудуться невиправдані зміни.
ВИСНОВКИ ТА ПОДАЛЬШЕ ЧИТАННЯ
Я думаю, що рівень даних — це дуже складна концепція для розуміння. Це не лише тому, що для більшості це технічна річ, а й тому, що більшість не усвідомлює, що це також перелік бізнес-вимог.
Перетворення бізнес-цілей на добре сформований, компактний і 100% використаний рівень даних справді складно. Чесно кажучи, я вважаю, що однією з найбільших помилок є дотримання моделі водоспаду, коли величезний список вимог записується на початку проекту, а потім перекладається на рівень даних, який з’являється на кожній сторінці сайту, а потім точка конструкції більше ніколи не торкається.
Це не працює.
Модель водоспаду має недоліки через людські помилки. Ми просто не можемо спроектувати чи передбачити остаточну форму чогось такого величезного, як цілий шар семантичних даних, який може охоплювати майже кожен окремий аспект нашого цифрового контексту. Він має бути спритним. Має бути взаєморозуміння, що форма шару з часом стає чіткішою.
Почніть з малого та збільшуйте масштаб, якщо є час. Якщо ви поспішаєте, зосередьтеся виключно на критично важливих для бізнесу вимогах.
Що б ви не робили, переконайтеся, що існує процес, який дозволяє швидко пропонувати зміни до рівня даних. Це вимагає багато змащення, освіти та передачі знань. Ось чому я вважаю, що найважливіше в будь-якому проекті обробки даних – це почати з навчання всіх сторін щодо того, що інші сторони роблять у проекті. Зробіть маркетологів більш орієнтованими на розвиток, а розробників — більш поважними до ваших маркетингових зусиль.
Таким чином усі виграють, і ви миттєво отримаєте чудовий рівень даних.
Подальше читання:
- Google Tag Manager Dev Guide від Google
- Покращуйте аналітику за допомогою керування тегами та рівня даних Джастіна Катроні
- Розблокуйте рівень даних: Посібник для менеджера тегів Google для нерозробників від Dorcas Alexander / Bounteous
- Структура dataLayer у JavaScript 101 для GTM: Частина 1
PS Якщо хтось знає справді хорошу статтю про керування семантичними даними, я хотів би прочитати її та надати посилання на неї в цій публікації.