Впровадження динамічного ремаркетингу на сайті: фіди, пікселі, GTM

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

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Впровадження динамічного ремаркетингу на сайті: фіди, пікселі, GTM
Середній
~2-3 дні
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1360
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    948

Реалізація динамічного ремаркетингу на сайті

Користувач відкриває картку MacBook Pro, вивчає характеристики, закриває вкладку. За годину в стрічці Instagram він бачить рекламу… холодильників. Знайома ситуація: піксель стоїть, а фід не прив'язаний, події передаються неправильно, ID товарів не збігаються. Динамічний ремаркетинг вирішує це: в оголошенні з'являється саме той MacBook з точною ціною та фото. Ми впроваджуємо цю зв'язку: продуктовий фід + пікселі + Google Tag Manager. Наші рішення працюють з Google Ads, Meta та VK, підвищуючи повернення клієнтів на 30–50%. За статистикою, динамічний ремаркетинг генерує в 3 рази більше конверсій порівняно зі звичайним ретаргетингом, а ROAS (повернення на рекламні інвестиції) збільшується в 2,5 рази. Зниження вартості залучення клієнта (CAC) досягає 25–40% при правильному налаштуванні. Для e-commerce ремаркетингу це особливо критично — навіть один невірний ID може обнулити кампанію.

Типовий сценарій: інтернет-магазин з 10 000 товарів, фід генерується раз на добу, ціни застарівають, реклама показує товари з нульовим залишком. В результаті бюджет витрачається даремно, а користувач розчарований. Наші сертифіковані спеціалісти гарантують актуальність фіду та коректну розмітку подій на всіх сторінках. Досвід впровадження — понад 50 проєктів.

Чому динамічний ремаркетинг потребує технічного налаштування?

На відміну від звичайного, динамічний ремаркетинг спирається на синхронізацію трьох компонентів:

  • продуктовий фід з актуальними цінами та залишками;
  • розмітка подій на сайті (перегляд, кошик, покупка);
  • рекламна платформа (Google, Meta, VK).

Без правильного налаштування реклама показуватиме не ті товари або не показуватиметься взагалі. Ми вирішуємо це завдання під ключ. Наприклад, в одному проєкті знайшли розбіжність ID товарів між фідом та пікселем — це обнулило всю кампанію на 3 тижні. Щоб уникнути таких втрат, ми використовуємо єдину систему генерації ID (артикул) для всіх платформ.

Як динамічний ремаркетинг підвищує повернення інвестицій?

Динамічні оголошення показують користувачеві саме ті товари, які він уже розглядав, що різко підвищує ймовірність покупки. За даними Google, такі кампанії дають на 40% більше повернення інвестицій порівняно зі звичайними ретаргетинговими. CTR динамічних оголошень у 2–3 рази вищий, а конверсія — у 3–5 разів. Це досягається за рахунок релевантності: людина бачить знайомий товар з актуальною ціною, що знижує когнітивний бар'єр.

Як працює динамічний ремаркетинг

  1. Генерація фіду. Система вивантажує товари з цінами, залишками та посиланнями в XML/CSV.
  2. Розмітка подій. На сторінках товарів, кошика та покупки спрацьовують скрипти, що передають ID товарів.
  3. Синхронізація. Платформа (Google Ads, Meta, VK) зіставляє події з фідом і показує релевантні оголошення.
  4. Оптимізація. Автоматичні правила коригують ставки для товарів з високим попитом.

Продуктовий фід: генерація та кешування

Основа динамічного ремаркетингу — фід з даними про товари. Рекламні платформи підтягують з нього інформацію для генерації оголошень. Формат фіду для Google Merchant Center:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:g="http://base.google.com/ns/1.0">
  <channel>
    <title>Каталог товаров</title>
    <link>https://example.com</link>
    <item>
      <g:id>PRODUCT_123</g:id>
      <g:title>MacBook Pro 14 M3 Pro</g:title>
      <g:description>Ноутбук Apple с чипом M3 Pro, 18 ГБ памяти, SSD 512 ГБ</g:description>
      <g:link>https://example.com/catalog/laptops/macbook-pro-14</g:link>
      <g:image_link>https://example.com/images/products/mbp14.jpg</g:image_link>
      <g:price>рассчитывается индивидуально</g:price>
      <g:sale_price>рассчитывается индивидуально</g:sale_price>
      <g:availability>in stock</g:availability>
      <g:condition>new</g:condition>
      <g:brand>Apple</g:brand>
      <g:google_product_category>Electronics > Computers > Laptops</g:google_product_category>
      <g:custom_label_0>bestseller</g:custom_label_0>
    </item>
  </channel>
</rss>

Генерація фіду на Laravel (контролер + маршрут):

// FeedController.php
class FeedController extends Controller
{
    public function googleMerchant(): Response
    {
        $products = Product::where('is_active', true)
            ->where('stock', '>', 0)
            ->with('category', 'images')
            ->get();

        return response()
            ->view('feeds.google-merchant', compact('products'))
            ->header('Content-Type', 'application/xml; charset=UTF-8');
    }
}

// routes/web.php
Route::get('/feeds/google-merchant.xml', [FeedController::class, 'googleMerchant'])
    ->middleware('cache.headers:public;max_age=3600');

Фід оновлюється автоматично — ціни та залишки актуальні. Кешування з TTL 1 година знижує навантаження на базу, не жертвуючи свіжістю.

Як налаштувати розмітку подій для Google Ads, Meta та VK?

Для Google Ads потрібні події view_item_list, view_item, view_cart з передачею item_id:

gtag('event', 'view_item_list', {
  items: products.map(p => ({
    item_id: p.id,
    item_name: p.title,
    item_category: p.category,
    price: p.price,
  })),
});

gtag('event', 'view_item', {
  items: [{
    item_id: 'PRODUCT_123',
    item_name: 'MacBook Pro 14 M3 Pro',
    item_category: 'Ноутбуки',
    price: 89900,
    currency: 'RUB',
  }],
});

gtag('event', 'view_cart', {
  value: 89900,
  currency: 'RUB',
  items: cartItems.map(item => ({
    item_id: item.product_id,
    item_name: item.product_name,
    price: item.price,
    quantity: item.quantity,
  })),
});

Meta вимагає content_ids та content_type: 'product', VK — аналогічний формат:

// Meta — перегляд товару
fbq('track', 'ViewContent', {
  content_ids: ['PRODUCT_123'],
  content_type: 'product',
  value: 89900,
  currency: 'RUB',
});

// Meta — додавання в кошик
fbq('track', 'AddToCart', {
  content_ids: ['PRODUCT_123', 'PRODUCT_456'],
  content_type: 'product',
  value: 94800,
  currency: 'RUB',
  num_items: 2,
});

// VK — перегляд товару
VK.Retargeting.ProductEvent('view_product', {
  id: 'PRODUCT_123',
  price: 89900,
  currency: 'RUB',
});

// VK — додавання в кошик
VK.Retargeting.ProductEvent('add_to_cart', {
  id: 'PRODUCT_123',
  price: 89900,
  currency: 'RUB',
});

Інтеграція через dataLayer + GTM

Щоб не дублювати код для кожної платформи, передавайте події в dataLayer — GTM-теги транслюють їх у потрібний формат:

window.dataLayer.push({
  event: 'product_view',
  product: {
    id: 'PRODUCT_123',
    name: 'MacBook Pro 14 M3 Pro',
    category: 'Ноутбуки',
    price: 89900,
    currency: 'RUB',
    brand: 'Apple',
    stock: 'in_stock',
  },
});

У GTM створюється по одному тегу для Google Ads, Meta та VK. Всі три використовують змінні з dataLayer — змінюєте структуру в одному місці. Це скорочує час налаштування для трьох платформ до 3–4 днів.

Порівняння вимог платформ

Параметр Google Ads Meta VK
Передача ID товару item_id в події view_item content_ids в масиві id в ProductEvent
Формат фіду XML (Google Merchant Center) CSV або XML (через каталог) YML або CSV
Додаткові поля price, currency, category value, currency, content_type price, currency

Типові помилки та їх вирішення

Найпоширеніша проблема — незбіг ID товарів у пікселі та фіді. Якщо в фіді товар має артикул PRODUCT_123, а піксель передає 123456 — реклама не покажеться. Ми використовуємо єдину систему генерації ID на основі артикула, що виключає розбіжності. Друга за частотою помилка — застарілі залишки в фіді. Автоматичне кешування з TTL 1 година та оновлення по тригеру вирішують цю проблему. Третя — відсутність події view_item_list на сторінках категорій. Без неї платформа не розуміє, які товари дивився користувач. Перевіряйте розмітку через Google Tag Assistant та Meta Events Manager. 90% проблем з динамічним ремаркетингом пов'язані з незбігом ідентифікаторів.

Помилка Вирішення
Незбіг ID товарів Єдина система генерації ID (артикул)
Застарілі залишки Кешування з TTL 1 год + оновлення по тригеру
Відсутність події на сторінці Перевірка через Tag Assistant та Events Manager
Некоректний формат фіду Валідація перед завантаженням

Що входить в роботу

В рамках проєкту ми надаємо:

  • Генерація продуктового фіду з автоматичним оновленням
  • Розмітка подій для обраних платформ (Google, Meta, VK)
  • Інтеграція через GTM або напряму
  • Тестування та верифікація збігу ID
  • Документація по підтримці
  • Навчання співробітників (налаштування в рекламних кабінетах)
  • Доступи до систем моніторингу помилок

Процес роботи, терміни та вартість

  • Аудит поточної розмітки та фіду
  • Генерація продуктового фіду з автоматичним оновленням
  • Налаштування подій для Google Ads, Meta та VK
  • Інтеграція через GTM або напряму
  • Тестування та перевірка збігу ID
  • Документація по підтримці

Етапи: аналітика → проєктування → реалізація → тест → деплой. Терміни: одна платформа (фід + пікселі) — 1–2 дні, три платформи через GTM — 3–4 дні, з серверними подіями — 5–6 днів. Вартість розраховується індивідуально після безкоштовного аудиту вашого сайту. Зверніться до нас — ми проведемо аудит вашого ремаркетингу, знайдемо невідповідності та запропонуємо оптимальне рішення. Замовте впровадження та гарантовано збільште конверсію до 3 разів порівняно зі звичайним ретаргетингом.

Як налаштувати веб-аналітику: GA4, GTM, Яндекс.Метрика та Amplitude

Ми часто бачимо: конверсія 1.2 %, трафік зростає, а конверсія стоїть. Маркетолог дивиться в Google Analytics і каже: «користувачі йдуть з кроку 2 оформлення замовлення». Розробник відкриває той самий крок — помилок немає, в Sentry тиша. Значить, справа не в JS-базі, а в UX або в кривих даних, які показує аналітика. Аналітика ламається непомітно: подія перестала трекатися після редеплою — ніхто не помітив; GTM-тег стріляє двічі — дані задвоїлися; фільтр GA4 виключає бота, який насправді — реальний трафік з корпоративного проксі. Замовте аудит поточних тегів — ми знайдемо причину за тиждень. Ми маємо понад 5 років досвіду в налаштуванні веб-аналітики для 100+ проєктів — гарантуємо прозорість та достовірність даних.

Після правильного налаштування економія рекламного бюджету може досягати значної суми щомісяця — це реальний кейс інтернет-магазину з 50 000 сесій на день, де дедуплікація purchase повернула 20 % невірно приписаних конверсій.

Чому події GA4 дублюються і як це виправити?

Universal Analytics закрито, його місце зайняла подієва модель GA4. У ній немає фіксованих хітів сторінок і транзакцій — лише події з параметрами. Це гнучкіше, але вимагає правильного дизайну подій.

Автоматичні події GA4 збирає сам: page_view, scroll, click, session_start. Рекомендовані події потрібно реалізувати самостійно: purchase, add_to_cart, begin_checkout, view_item. Google очікує конкретну схему параметрів — якщо передати product_id замість item_id, дані потрапляють в GA4, але не в стандартні звіти e-commerce. Кастомні події для специфіки проєкту: filter_applied, video_progress, form_step_completed. Кастомні параметри необхідно зареєструвати в GA4 Admin → Custom definitions, інакше вони не будуть доступні у звітах.

Часта помилка — подія purchase з дублями. Причина: тег спрацьовує на сторінці /thank-you, користувач оновлює сторінку — другий purchase іде в GA4. Рішення: на бекенді генеруємо унікальний transaction_id і передаємо в подію. GA4 de-duplicates по ньому — перевіряйте через DebugView. Правильна атрибуція економить до 20 % рекламного бюджету, який раніше йшов на невірно приписані конверсії.

Як налаштувати data layer, щоб не втратити дані?

GTM — інструмент для керування тегами без деплою коду. Але «без коду» не означає «без архітектури». Data Layer — основа всього. Передаємо дані з застосунку в GTM через dataLayer.push(). Структура: event + контекстні дані. Для e-commerce: перед відкриттям сторінки продукту — push з даними товару. GTM-тег читає з dataLayer, не з DOM.

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'view_item',
  ecommerce: {
    items: [{
      item_id: 'SKU-12345',
      item_name: 'Назва товару',
      price: null,
      currency: null
    }]
  }
});

Погана практика: GTM-тег парсить DOM — шукає ціну в span.price, назву в h1. Це ламається при будь-якій зміні верстки. Хороша практика: завжди dataLayer. Використовуємо Preview Mode для налагодження та GTM Server-Side для чутливих даних — відправка з сервера, не з браузера, обходить блокувальники реклами, не втрачає дані. Server-side підхід у 2-3 рази надійніший за client-side за показником втрати подій через розширення браузера.

Як Яндекс.Метрика доповнює веб-аналітику?

Для російської аудиторії Метрика обов'язкова — особливо Вебвізор. Запис сесії користувача, який кинув кошик, часто дає відповідь швидше, ніж тиждень аналізу воронки. Цілі в Метриці: подієві (через ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) або автоматичні (клік по кнопці, відвідування сторінки). Зв'язка з CRM через Метрика Плюс — передача офлайн-конверсій. Наш досвід: у 8 з 10 проєктів після налаштування Метрики знаходили приховані баги в UX, які не показували інші системи.

Що дає product analytics в Amplitude?

Amplitude — продуктовий інструмент, на відміну від маркетингових GA4 та Метрики. Він заточений під аналіз поведінки користувачів всередині продукту: воронки, ретеншн, user paths. Amplitude підходить для SaaS-продуктів, мобільних застосунків та будь-яких сервісів із зареєстрованими користувачами, де важливо зрозуміти, як проходять онбординг, на якому кроці йдуть, які фічі використовують частіше. Ключові концепції: identify (пов'язати анонімного користувача з userId після авторизації), group (акаунт у B2B SaaS), когорти для утримання. Amplitude Chart — воронка кроків за останні 30 днів з розбивкою за джерелом.

Моніторинг якості даних

Аналітика без моніторингу — чорна скринька. Налаштовуємо:

  • GA4 Realtime — перевіряємо після кожного деплою, що ключові події приходять
  • Alerting в GA4 — аномалія в кількості подій purchase (різке падіння = щось зламалося)
  • GTM Preview в staging-оточенні перед продакшеном
  • Ручні тести воронок раз на тиждень — просто пройти шлях покупця і перевірити, що все трекається

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

Що перевіряємо після кожного деплою

  • Чи всі рекомендовані події присутні в DebugView
  • Чи немає задвоєнь (рахуємо кількість purchase на 100 сесій)
  • Чи не змінилася структура dataLayer після оновлення фронтенду

Що входить в роботу

Компонент Опис
Аудит поточних тегів Перевірка існуючих GTM-тегів, dataLayer, дублів та помилок
Дизайн подієвої схеми Документація: список подій, параметри, тригери
Налаштування GA4 + GTM Створення конфігурації, тегів, Custom definitions
Яндекс.Метрика Встановлення лічильника, створення цілей, налаштування Вебвізора
Amplitude (опціонально) Налаштування клієнтського та серверного SDK, когорти
QA та моніторинг Тестування в Preview Mode, Alerting
Навчання та передача Доступи, інструкція з додавання нових подій, консоль

Процес та терміни

  1. Аудит поточних тегів та даних (2 дні)
  2. Дизайн подієвої схеми (2 дні)
  3. Розробка Data Layer та налаштування тегів (3–5 днів)
  4. QA в Preview Mode та на staging (2 дні)
  5. Деплой та налаштування дашбордів (1 день)
Сценарій Термін
Базове налаштування GA4 + GTM 1 тиждень
Повний e-commerce tracking + Метрика 2–3 тижні
Server-side GTM + Amplitude 3–5 тижнів

Вартість розраховується індивідуально. Отримайте консультацію з налаштування веб-аналітики для вашого проєкту — ми оцінимо обсяг робіт за один день. Зв'яжіться з нами, щоб почати. Для точного розрахунку вартості залиште заявку — ми проаналізуємо ваш стек за 1 день.