Двостороння аналітика партнерського iframe-віджета за допомогою Google Tag Manager

Віджети сьогодні є невід’ємною частиною багатьох великих порталів, оскільки дозволяють використовувати складні партнерські розробки уникаючи довгі процедури впровадження. Веб-аналітика віджетів при цьому цікава всім сторонам, але у випадку з iFrame виникають труднощі в плані передачі 100% даних учасникам партнерства. Які це труднощі і як нам вдалося обійти їх, хотілося б розповісти в даній статті. Перш за все, вона буде цікава всім, хто займається розробкою і впровадженням віджетів на iFrame, а також залученими аналітикам.

Для початку трохи підґрунтя. Ми займаємося розробкою як власних рішень для автоматизації у сфері пасажирських перевезень, так і продуктів для використання на партнерських сайтах. Одним з них став проект автоматизованого бронювання VIP та бізнес-залів в аеропортах світу та Росії, спрямований на задоволення потреби бізнес і преміум клієнтів різних авіакомпаній. Єдина база даних тематичних послуг в різних аеропортах цікава в першу чергу компаніям, пов’язаним з пасажирськими авіаперевезеннями, онлайн-тревел агентствам, а також туристичним компаніям з сайтами в інтернеті. Для таких компаній був створений віджет “VIP-зал”, що дозволяє отримати доступ до цієї бази даних користувачеві будь-якого партнерського сайту.

Віджет встановлюється стандартним чином через iFrame, партнеру потрібно лише розмістити код у себе на сайті і налаштувати параметри зовнішнього вигляду відповідно до загальної дизайн-концепції. В результаті на сайті з’являється модуль підбору та бронювання VIP-залів в цікавому аеропорту з доступом до преміум-послуг аеропорту, таким як шатл (індивідуальний трансфер від залу до літака), зустріч в залі з табличкою, супровід співробітника і доступ на парковку для VIP-клієнтів. Процес бронювання здійснюється за кілька простих кроків, всередині яких користувач може варіювати вміст замовлення (рис.1).


Малюнок 1 — Зовнішній вигляд віджету на сайті

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

А. Зі всіх сайтів, на яких встановлений віджет, в веб-аналітику власника (розробника).
Б. З сайту, на якому встановлений конкретний віджет, в веб-аналітику партнера.

У чому тут складність? В основному В тому, що партнер бере єдиний код віджету, який не налаштовується під конкретний партнерський сайт, але при цьому хоче бачити в аналітиці інформацію тільки по своєму віджету. Друга складність полягає в тому, що розробник (власник) віджета повинен отримувати дані відразу з усіх партнерських сайтів в один лічильник, що йде врозріз з бажанням партнера бачити тільки власну інформацію. Зрештою, потрібно просто розмежовувати ті дані, які повинен бачити партнер, і які буде бачити власник. Завдання вдалося вирішити з допомогою Google Tag Manager (далі — GTM).

Цей інструмент широко використовується для веб-аналітики та управління тегами на сайтах, описувати детально принцип його дії не має сенсу, для розуміння досить ознайомитися з концепцією роботи GTM з інших статей. В даному випадку важливо розуміти, що Google Tag Manager (рис.2) дозволяє консолідувати дані з сайту всередині власних контейнерів та роздавати їх різним лічильників веб-аналітики з допомогою заданих правил.

Читайте також  Де мої гроші, чувак: про що мовчить Steam


Рисунок 2 — Вікно “Теги” Google Tag Manager з вже налаштованими тегами для віджету

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

  1. Партнер, як і власник, хоче відстежувати роботу віджета одним з двох способів або відразу двома — з допомогою Яндекс.Метрики або Google Analytics.
  2. Задовольняє рішення має передавати дані в 4 лічильника: Лічильник Метрики власника, лічильник Google Analytics власника, лічильник Метрики партнера і лічильник Google Analytics партнера.
  3. Всередину віджета встановлюється єдиний контейнер Google Tag Manager, який буде збирати дані та розподілити їх таким чином, щоб кожен учасник отримував тільки потрібну йому інформацію.
  4. Ідентифікатори лічильників власника задаються за умовчанням, ідентифікатори партнера повинні бути вказані ним у момент генерації коду віджета в партнерському кабінеті для подальшої установки на сайті.
  5. Оскільки для партнера вже налаштований партнерський кабінет, ідентифікатори можна задати в ньому і прокинути всередину віджета, щоб Tag Manager використав їх.
  6. Всередині GTM відбувається підстановка ідентифікаторів коди спрацьовування цільових подій, а також розподіл передачі даних з лічильників власника і партнера.
  7. При цьому GTM відправляє всі зібрані дані лічильники власника, а дані по сайту партнера — тільки лічильники партнера, т. к. при підстановці ідентифікаторів відстежується тільки заданий партнером сайт.

Для зручності розуміння наведемо блок-схему процесу (рис.3):


Малюнок 3 — Схема процесу передачі даних

Для початку визначимося, що крім коду Google Tag Manager на сайті також присутні автоматично згенеровані коди лічильників Яндекс.Метрики і Google Analytics. У них при генерації коду для сайту пробрасываются задані партнером ідентифікатори лічильників.

Ці коди в віджеті можна і не ставити, оскільки можливості GTM дозволяють автоматично генерувати їх на сайті як відповідні теги (тип — Користувальницький HTML — рис.4), але в даному випадку жорстке прописування в код віджету було необхідно — деякі події на сайті вимагають, щоб лічильник одразу встановлювався всередину віджета. В основному це події завантаження, появи преролла. Якщо ж у вас немає такого роду подій, то можна генерувати код лічильника через GTM:


Рисунок 4 — Приклад передачі коду Метрики на сайт через GTM

Щоб передавати дані відразу в два лічильника (партнера і власника), потрібно встановлювати не два різних Метрики коду або Analytics, а створювати спеціальний здвоєний код. На момент написання статті правильні коди виглядають так (рис.5):


Малюнок 5 — Вірний варіант використання здвоєних кодів Метрики і GA

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

При ініціалізації віджета створюється iFrame, параметри якого передаються ідентифікатори лічильників партнера (лічильники передаються в iFrame src, після чого парсятся в віджеті з location). iFrame відкриває додаток віджета і в хука created життєвого циклу віджета (SPA) до монтування обробляються вхідні параметри номерів лічильників, а в localStorage зберігаються номери (ідентифікатори).

Для розміщення коду Google Analytics index.html використовується наступна конструкція:

<script>
 window.dataLayer = window.dataLayer || [];

 function gtag() {
dataLayer.push(arguments);
}
 gtag('js', new Date());
 gtag('config', 'UA-15930803-13');
 gtag('config', window[localStorage.getItem('partnerGA')] || 'UA-15930803-14');

 </script>

Скрипти з перемінним src вставляються динамічно при ініціалізації лічильників:

let script = document.createElement('script')
 script.setAttribute('src', `https://www.googletagmanager.com/gtag/js?id=${ga || 'UA-15930803-14'}`)
 document.head.insertBefore(script, document.head.firstChild)

Тут UA-15930803-14 – «підставний» лічильник власника, який використовується в тому випадку, якщо його партнером лічильник не встановлено. Дана ситуація може виникнути, якщо партнер не поставив ідентифікатори лічильників в цілому або задав лише один код – завжди повинен бути змінний код, щоб на сайті не виникало помилок JavaScript, пов’язаних з відсутністю ідентифікатора для правильного спрацьовування коду передачі якого-небудь події. UA-15930803-13 в даному випадку – основний ідентифікатор Власника, який дані приходять у будь-якому випадку і з будь-якого сайту.

Читайте також  Як відключити зарезервоване сховище Windows 10

Аналогічно GA формується код Яндекс.Метрики, в якому використовуються заданий ідентифікатор Метрики власника, підмінний ідентифікатор лічильника власника «за замовчуванням» і конструкція для передачі ідентифікатора партнера. Код формується за схемою, представленої на рис.5 з застосуванням конструкцій з прикладу вище.

Слідом за кодами лічильників потрібно прокинути задані партнером ідентифікатори всередину Google Tag Manager. Всередині контейнера вони вже будуть використовуватися як внутрішні змінні, чиї значення можна поставляти в генеруються події.

Для GTM найчастіше використовується методика змінних рівня даних (dataLayer). Рівень даних — це змінна JavaScript, ініціалізація якій описується всередині контейнера Google Tag Manager автоматично. За допомогою неї можна передавати як відбуваються на сайті події типу event, так і задавати для GTM власні змінні. Робиться це з допомогою конструкції

dataLayer.push('ім'я_змінної': 'значение_переменной');

Спрацьовує після оголошення коду GTM на сайті. Однак у нашому випадку змінна рівня даних не спрацювала, можливо справа в складнощах роботи саме з iframe. Якщо ставити конструкцію push() автоматично, то контейнер не отримує змінних, а в даному випадку хотілося саме такої реалізації завдання. Якщо ж пробувати задавати змінну рівня даних вручну (наприклад, по кожному натисканні на сайті), то кидок змінної проходить нормально.

Щоб не витрачати час на розбір процесу, ми використовували альтернативне рішення — створення глобальних змінних JavaScript через localStorage.

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

localStorage.setItem('partnerMetrika1', 'УУУУУУУУ');
localStorage.setItem('partnerMetrika2', 'yaCounterУУУУУУУУ');
localStorage.setItem('partnerGA', 'UA-УУУУУУУ-УУ');

Тут перша конструкція передає сам номер партнерської Метрики, друга конструкція передає збірне значення yaCounter для зручності створення тега “Подія” в Google Tag Manager (про це далі), а третя — ідентифікатор Google Analytics.

На цьому передача даних завершена і в справу вступає налаштування самого GTM.

По-перше, визначимося з принципом роботи Google Tag Manager. У ньому представлено 3 рівня взаємодії:

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

Тег спрацьовує, якщо на сайті виконується деяка умова.

Тригер. Це власне умова, виконання якого викликає за собою спрацювання тега. Це може бути подія (event) на сайті, зміна значення змінних або стандартне дію — наприклад клік або перегляд сторінки.

Читайте також  SEO в 2019 році не працює?

Змінна. Містить у собі деякі значення, які можна передавати різними способами, і використовується як постачальник даних тегів або маркер умови.

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

Ми створили три основних змінних типу “Власний код JavaScript” (рис.6):


Рисунок 6 — Приклад змінної, що бере партнерський ідентифікатор Метрики

Тут значення змінної = те значення, яке ми взяли з localStorage.

Тепер якщо GTM звернеться до змінної, то отримає її значення — ідентифікатор партнерської Метрики. Точно також ми створили змінні під номер партнерської Метрики і ідентифікатор партнерського Google Analytics.

Для чого використовуються такі змінні? Вони вирішують завдання відправки даних про спрацювання подій на сайті в партнерські лічильники. У Google Tag Manager є стандартна процедура передачі цілей в Google Analytics, де в якості ідентифікатора лічильника можна використовувати значення змінної. А для Метрики використовується тег у вигляді користувацького HTML-коду, що містить стандартний JavaScript Метрики:

yaCounterXXXXXX.reachGoal('TARGET_NAME');

Тут TARGET_NAME — це внутрішнє найменування цільового події для Метрики (такі цілі створюються у налаштуваннях лічильника через тип “JavaScript-подія”), а ХХХХХХ — номер лічильника.

Таким чином, ми створюємо для різного виду лічильників відповідні теги.

Для Google Analytics:

Тип тега — “Універсальний Analytics”, ідентифікатор відстеження — з нашої змінної.


Рисунок 7 — Приклад налаштування тега, який передає дані в Google Analytics.

Тут Категорія і Дія — ті значення, які повинен зловити Google Analytics в якості параметрів спрацювання мети. Ідентифікатор відстеження — задана раніше змінна, яка взяла партнерський ідентифікатор localStorage.

Для Яндекс.Метрики:

Тип тега — Інтерфейс HTML” із застосуванням конструкцій JavaScript.


Рисунок 8 — Приклад налаштування тега, який передає дані в Яндекс.Метрику

Тут {{PartnerMetrikaCounter}} — внутрішнє оголошення змінної, що бере ідентифікатор партнерської Метрики з localStorage. З допомогою об’єкта window ми підставляємо значення змінної в виконуваний код, і на виході отримуємо yaCounterXXXXXXХХ.reachGoal(‘widget_loading’);, де widget_loading — значення, яке ловить Метрика в якості параметра спрацьовування мети.

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

  • Події успішного завантаження віджета;
  • Події успішного чи неуспішного проходження кроку на віджеті;
  • Заповнення деяких полів;
  • Вибір умов А або Б всередині віджета;
  • Взаємодія з формами, кнопками і посиланнями.

Далі у налаштуваннях лічильників Метрики і Google Analytics залишається лише створити відповідні цілі:


Рисунок 9 — Приклад налаштування мети в Яндекс.Метриці


Малюнок 10 — Приклад налаштування цілі Google Analytics

Задача вирішена. Здвоєні коди лічильників підставляють у ідентифікатори Метрики і Analytics партнера задані їм значення, а значення ідентифікаторів власника залишаються незмінними. У той же час Google Tag Manager прокидає спрацьовування відповідних цілей у лічильники партнера тільки в тому випадку, якщо отримує змінних саме ті ідентифікатори, які поставив конкретне партнер на своєму сайті. Паралельно з цим GTM надсилає власнику всі цільові події з усіх сайтів.

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

Степан Лютий

Обожнюю технології в сучасному світі. Хоча частенько і замислююся над тим, як далеко вони нас заведуть. Не те, щоб я прям і знаюся на ядрах, пікселях, коллайдерах і інших парсеках. Просто приходжу в захват від того, що може в творчому пориві вигадати людський розум.

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *