Same-origin трекінг у Shopify: обмеження чекауту та як подолати

Метод same-origin спрямовує запити серверного трекінгу через домен вашого вебсайту, а не через окремий субдомен для трекінгу.

Він визначає, коли дві URL-адреси належать до одного вебпоходження (origin). Origin складається з трьох компонентів: схема (https:// або http://), ім'я хоста (наприклад, shop.example.com) і порт (наприклад, 443 для HTTPS).

Шлях URL-адреси – це окремий компонент URL, і він не визначає її origin. Наприклад, ці URL-адреси мають однаковий origin, хоча друга містить шлях:

• https://shop.example.com/
• https://shop.example.com/metrics

Проте спільний origin на рівні URL не гарантує, що кожне браузерне середовище чи платформа дозволить запит до цього ендпоінта. Приклад – чекаут Shopify, який ми детально розглядаємо в цьому гайді.

Трекінг чекауту Shopify працює в більш обмеженому середовищі, ніж вітрина. Залежно від реалізації чекауту скрипти можуть виконуватися з обмеженнями щодо мережевих запитів, API браузера та взаємодії з іншими origin.

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

Серед найпоширеніших обмежень, які може помітити будь-який фахівець із трекінгу, – те, що за замовчуванням ви не бачите подій чекауту в GTM Preview під час тестування налаштування. Так відбувається тому, що сніпет контейнера GTM завантажується в пісочницю чекауту, і GTM Preview просто не знає, де шукати контейнер. Щоб увімкнути налагодження GTM у чекауті, код трекінгу потрібно завантажити на батьківську сторінку для вашої власної сесії браузера. Розширення Chrome Stape GTM Helper дає змогу зробити це в кілька кліків.

Обмеження GTM Preview – лише один приклад того, чим середовище чекауту Shopify відрізняється від сторінок вітрини. Під капотом обмеження пісочниці також впливають на те, як браузери обробляють взаємодію між доменами, що позначається на трекінгу через same-origin домени.

Same-origin ендпоінт – корисний підхід для трекінгу на вітрині, але під час чекауту Shopify він має обмеження.

Коли піксель чекауту Shopify намагається надіслати запит на same-origin ендпоінт (наприклад, подію GA4 у форматі https://shop.stapedesk.com/metrics/g/collect), консоль браузера може показати помилку, подібну до тієї, що на скріншоті нижче:

У нашому тесті запит завершився помилкою RestrictedUrlError. Це означає, що піксель чекауту спробував виконати запит XHR/fetch до того самого домену, на якому працює вітрина, але середовище виконання пікселів Shopify відхилило запит ще до того, як браузер його надіслав.

Що каже документація Shopify?

Про таку помилку повідомляли в Shopify Community, але наразі документація Shopify не описує безпосередньо точне правило, яке блокує same-origin запити в чекауті.

Проте Shopify надає інформацію про базову архітектуру, яка може пояснити, чому так відбувається. Згідно зі сторінкою Shopify про вебпікселі, Shopify завантажує Web Pixels в ізольованому середовищі (пісочниці) у браузері відвідувача, як уже згадувалося.

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

Тому запити, які надсилає Web Pixel, оцінюються за правилами пісочниці, у якій працює піксель, а не лише за цільовою URL-адресою (URL, що отримує запит).

Головне – «той самий (same-origin) домен» не завжди означає «той самий контекст виконання». URL, що є same-origin з погляду вітрини продавця, усе одно може бути обмежений під час звернення з пісочниці Web Pixel у Shopify.

Наведений нижче тест показує, що пісочниця Web Pixel у Shopify не просто блокує всі запити до домену вітрини. Обмеження стосується саме програмних HTTP-запитів, таких як fetch() і XMLHttpRequest.

Під час тесту події чекауту запускалися у двох налаштуваннях магазину Shopify – same-origin ендпоінт і субдомен для трекінгу. Порівняння типів запитів показує таку поведінку:

Це може пояснити, чому підходи до трекінгу на основі пікселів-зображень (ваші page_views, які здебільшого є GET-запитами) можуть працювати, тоді як реалізації серверного трекінгу, що використовують fetch() до same-origin ендпоінта, можуть не спрацьовувати.

Схоже, запити GET і beacon просто не проходять через власну обгортку Shopify для XHR і fetch, а отже, їх можуть непомітно обмежити будь-коли в майбутньому, якщо припустити, що це недогляд. Звісно, це лише припущення.

Service worker – це JavaScript-файл, який працює окремо від основної сторінки браузера. Його зазвичай використовують для таких функцій, як офлайн-режим, кешування та перехоплення мережевих запитів.

У контексті трекінгу чекауту Shopify він може перехоплювати мережеві запити та допомагати обробляти їх навіть тоді, коли робота сторінки переривається. Саме таке рішення використовує Google Analytics 4, щоб зменшити втрату запитів трекінгу.

Проте оскільки ви явно не контролюєте, яка подія буде надіслана через worker, і GA4 запровадив їх не для цього сценарію, покладатися на них для трекінгу подій чекауту Shopify не варто. Звісно, ви можете зафіксувати кілька подій чекауту/купівлі, і може здатися, що все працює, але це чиста випадковість – протестуйте ще.

Навіть якби same-origin запити не блокувалися в пісочниці кастомних подій Shopify, їхня практична користь була б обмеженою через пісочницю Shopify (так, знову).

Підхід same-origin корисний насамперед тим, що дає змогу встановлювати cookie з передбаченим терміном дії в ITP та подібних середовищах. Але в пісочниці чекауту cookie не передаються у ваших запитах трекінгу; так само не вийде встановити їх і через відповіді. Саме тому наш Data Tag має опцію Send Common Cookies, яка додає cookie до payload запиту.

Оскільки iframe пісочниці налаштовано без allow-same-origin, браузер призначає йому непрозорий origin, тож він завжди відображається як null. Так відбувається навіть тоді, коли iframe завантажується з власного домену магазину, і незалежно від того, чи явно задано в запиті ‘credentials: include’ або ‘mode: cors’. У результаті браузер під час обробки cookie вважає ці запити cross-site. Простими словами, браузер обробляє пов'язані cookie як сторонні (third-party).

Simo Ahava детально описав цю проблему з cookie в чекауті Shopify ще у 2024 році.

Для магазинів Shopify з налаштованим серверним трекінгом рекомендовано гібридний підхід:

• підхід same-origin на вітрині;
• стандартна маршрутизація через субдомен для чекауту.

На вітрині same-origin трекінг дає очікувані переваги (краща маршрутизація first-party запитів, обробка cookie та стійкість трекінгу), оскільки запити трекінгу надсилаються з того самого доменного контексту, що й вебсайт.

Проте чекаут Shopify має обмеження, через які підхід same-origin не може працювати так само, як на вітрині. Тож стандартна маршрутизація через субдомен тут доречніша. Спрямування запитів трекінгу через окремий субдомен для трекінгу дає змогу обійти саме це обмеження, щоб запити досягали ендпоінта трекінгу.

Same-origin налаштування для вітрини Shopify можна виконати за допомогою різних DNS- та інфраструктурних провайдерів. Точна конфігурація залежить від провайдера, яким ви користуєтеся.

Наприклад, Cloudflare пропонує інтеграцію Orange-to-Orange (O2O), яка дає змогу маршрутизувати трафік як через зону Cloudflare продавця, так і через інфраструктуру Cloudflare від Shopify. Це забезпечує додатковий контроль над обробкою трафіку й водночас зберігає ваш домен як точку входу.

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

Для чекауту Shopify використовуйте стандартну конфігурацію субдомену.

На відміну від same-origin налаштування, конфігурація субдомену потребує додавання DNS-записів, щоб підключити субдомен до вашого провайдера серверного трекінгу.

Після налаштування доменів трекінгу для вітрини й чекауту потрібно налаштувати GTM, щоб надсилати дані подій до вашого серверного контейнера.

У вашому вебконтейнері GTM додайте та налаштуйте темплейт Data Tag. Цей тег надсилає дані подій разом із налаштованими параметрами до вашого серверного контейнера GTM.

У серверному контейнері GTM встановіть і налаштуйте Data Client. Data Client отримує та обробляє запити від Data Tag. Так вхідні дані подій стають доступними для тегів серверного GTM.

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

Увімкніть цю опцію для кожного Data Tag, який має спрацьовувати на сторінці чекауту.

Логіка вибору домену реалізується у вебконтейнері GTM, оскільки це рішення потрібно ухвалити до надсилання запиту. Потім серверний контейнер отримує запити з вибраного ендпоінта й обробляє їх далі за допомогою налаштованих clients і тегів.

Щоб задати логіку, використайте змінну RegEx Table.

3.1 Щоб налаштувати її, перейдіть до розділу Variables у веб-GTM → натисніть New → виберіть RegEx Table як конфігурацію змінної.

3.2 Виберіть Input Variable для змінної.

Конкретна умова залежатиме від сценарію вашого сайту на Shopify. У нашому випадку сторінки чекауту та подяки (thank-you page) розміщено на тому самому домені, але Page Path відрізняється.

Якщо вам потрібно більше деталей про те, як знайти Input Variable для вашого сайту на Shopify, натисніть на розгортний елемент нижче:

Вкажіть Input Variable (у нашому випадку – Page Path).

3.3 Введіть шаблон і потрібний результат.

Введіть Pattern за допомогою регулярних виразів (regex).

Для нашого сценарію підходить такий регулярний вираз:

Відповідає будь-якому рядку, що починається з /checkouts, незалежно від того, що йде далі.

Як Output вкажіть субдомен, який має використовуватися для трекінгу в пісочниці.

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

Позначте прапорець Set Default Value і додайте змінну з вашим same-origin доменом як Default Value.

Ось приклад налаштування змінної:

Збережіть зміни.

Замініть у ваших тегах усі жорстко прописані (hardcoded) значення same-origin URL або змінні, що містять same-origin URL, на змінну RegEx Table.

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

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

Перевірте, чи налаштування трекінгу правильно працює як на вітрині, так і в чекауті.

Щоб переглянути деталі дебагінгу, розгорніть елемент нижче:

Трекінг чекауту Shopify – непросте завдання, особливо в контексті серверного трекінгу. Підхід same-origin дає всі переваги на сторінках вітрини, але середовище чекауту має обмеження пісочниці, через які той самий підхід не працює належним чином.

Найкраще рішення на сьогодні – адаптувати архітектуру трекінгу до середовища Shopify: зберегти same-origin налаштування там, де воно приносить користь, і використовувати стандартний підхід із субдоменом для подій чекауту. Завдяки правильній конфігурації GTM і процесу тестування ви зможете зберегти точний трекінг на всьому шляху користувача.

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