Перенесення події електронної комерції з браузера на сервер не усуває потреби розуміти подію, її стан згоди або призначення. Надійний запуск відстеження OpenCart починається з фіксації того, що надсилається і навіщо. Додавання іншого маршруту доставки до нечіткого налаштування може призвести до більш суперечливих даних замість кориснішого вимірювання.
Плануйте відстеження в браузері та на сервері разом. Визначте, який компонент відповідає за кожну подію, які ідентифікатори пов’язують маршрути доставки і що відбувається, коли клієнт відмовляється або змінює згоду. Тримайте обсяг достатньо малим для тестування перед увімкненням більшої кількості платформ.
Зробіть інвентаризацію подій перед додаванням інтеграцій
Запишіть джерело переглядів продуктів, дій у кошику, активності оформлення замовлення та покупок. Визначте наявні скрипти теми, маркетингові розширення, робочі простори тег-менеджера та відстеження повернення платежів. Два незалежні компоненти можуть уже надсилати одну й ту саму покупку.
Для кожного призначення запишіть необхідне корисне навантаження та призначення кожного поля. Ідентифікатори продуктів, валюта, значення та посилання на транзакції мають надходити із зрозумілої події магазину. Не додавайте інформацію про клієнта лише тому, що API пропонує для цього поле.
Зробіть рішення про згоду явним
Визначте, як збирається згода і як її стан досягає компонента, що надсилає подію. Запит на сервер не повинен безшумно ставати альтернативним маршрутом навколо вибору, зробленого відвідувачем у браузері.
Документація Google керівництво з реалізації згоди пояснює сигнали згоди Google і послідовність оновлень. Інші призначення мають власні вимоги. Технічне налаштування та вимоги конфіденційності, що застосовуються до бізнесу, потрібно розглядати разом; встановлення розширення відстеження саме по собі не встановлює відповідність.
Обирайте невеликий початковий запуск
Починайте з одного призначення і однієї чітко визначеної події, часто тестової покупки в підтримуваному тестовому середовищі провайдера. Підтвердіть назву події, грошову суму, валюту та ідентичність продукту. Порівняйте вихідне замовлення з корисним навантаженням і діагностикою приймаючої платформи.
Лише потім додавайте більше типів подій або платформ. Це полегшує розрізнення проблеми корисного навантаження від проблеми автентифікації, непідтримуваного поля або невідповідності стану згоди. Довгий список інтеграцій не замінює відтворюваний випадок прийняття.
Проєктуйте дедуплікацію та повторні спроби для призначення
Доставка з браузера і сервера може описувати одну й ту саму реальну дію. Використовуйте ідентифікатори подій або транзакцій, необхідні приймаючою платформою, і переконайтеся, що вони посилаються на одну й ту саму дію через маршрути доставки. Різні призначення використовують різні правила співставлення, тому не припускайте, що одне універсальне поле вирішує всі випадки.
Також визначте, як поводяться повторні спроби. Тайм-аут не завжди означає, що призначення відхилило подію. Стабільні ідентифікатори та корисна діагностика допомагають розслідувати повторну спробу без перетворення одного замовлення на кілька видимих покупок. Наше керівництво з дублювання покупок GA4 охоплює пов’язане розслідування на стороні браузера.
Тримайте логи корисними та пропорційними
Корисний діагностичний запис пов’язує вихідну подію, спробуване призначення, відповідь і результат. Він має підтримувати розслідування без розкриття облікових даних API або публічного доступу до корисного навантаження клієнта. Перегляньте дозволи, зберігання та інформацію, яку справді потрібно логувати.
Перевіряйте також невдалі шляхи: недійсний доступ, відсутні обов’язкові поля, відмову в згоді та відповідь провайдера, що потребує розслідування. Панель, що показує успішний запит, не доводить, що кожна наступна подія правильна, тому підтримуйте практичний пострелізний огляд.
Підбирайте розширення відповідно до плану запуску
Google Marketing Tools для OpenCart надає спільний ecommerce dataLayer, інтеграції браузера, генерацію робочих просторів і робочі процеси продуктового фіду. Його необов’язкові серверні доповнення купуються окремо і використовують спільні дані магазину. Перегляньте поточну сторінку продукту для підтримуваних призначень і вимог пакету.
Підтвердіть версію OpenCart, тему, оформлення замовлення, налаштування згоди та платформи, які плануєте використовувати, перед вибором компонентів. Огляд на стенді має включати ті ж інтеграції, що працюватимуть у продакшені, а не порожній магазин, який не може відтворити реальне оформлення замовлення.
DevmanExtensions може допомогти провести аудит існуючого відстеження, спланувати інтеграцію та перевірити запуск. Зв’яжіться з нашою командою щодо налаштування відстеження OpenCart з платформами, які вам потрібні, і проблемами, які ви намагаєтеся вирішити. Мета — зрозумілий потік подій, а не обіцянка, що серверне відстеження відновить кожну втрату події.