Как GTM помог связать формы, звонки и офлайн-доход в одну воронку

В B2B и сложных услугах проблема обычно не в нехватке лидов, а в том, что маркетинг видит только верх воронки. Форма отправлена, звонок был, встреча прошла — а дальше данные расползаются по CRM, коллтрекингу и офлайн-таблицам. В итоге last-click рисует красивую картину, но не отвечает на главный вопрос: какие источники реально приносят выручку.

**Задача**
Компания с длинным циклом сделки хотела понять, какие каналы дают не просто заявки, а доход. Без этого было невозможно нормально перераспределять бюджет между search, контентом и платными кампаниями.

**Решение**
Через Google Tag Manager собрали единую схему событий:
— отправка форм;
— клики по телефонам;
— заявки с разных лендингов;
— передачу событий в аналитику и CRM;
— связку офлайн-конверсий с исходным источником трафика.

Отдельно настроили серверную отправку части событий, чтобы меньше зависеть от блокировок браузеров и потерь cookies. Для 2026 года это уже не «приятно иметь», а базовая гигиена: приватность растёт, а точность клиентского пути без server-side заметно проседает.

**Результат**
В открытом кейсе цифры по росту выручки не раскрывались. Но сам эффект был практический: команда получила сквозную картину от первого касания до сделки и перестала оценивать каналы только по MQL. Это особенно важно в B2B, где классическая лидогенерация всё чаще уступает RevOps-подходу — общей ответственности маркетинга, продаж и customer success за выручку.

**Урок**
Если GTM у вас работает только на форму, вы измеряете не бизнес, а фрагмент воронки. Начните хотя бы с трёх вещей:
— единый набор событий на всех ключевых точках контакта;
— передача идентификаторов в CRM;
— офлайн-конверсии обратно в аналитику.

Тогда маркетинг сможет отвечать не на вопрос «сколько заявок», а на более честный: «какой канал принёс деньги». Именно туда сейчас движется аналитика — от красивых отчётов к модели, где видна реальная выручка.

— @GTMrecipesRuPro

Три триггера, которые “врут” в GTM (и как я их чиню под privacy-first атрибуцию)

В 2026 я всё чаще вижу одну и ту же проблему: в аккаунте GTM трафик и события вроде бы есть, но бизнес-решения принимают на основании данных, которые уже не отражают реальность. Причина редко в “неправильных тегах”. Чаще — в логике триггеров: они срабатывают не там, где вы думаете, или срабатывают так, что атрибуция искажает картину.

Я выделяю три класса “лживых” триггеров — и всегда чиню их по одной методике: сначала доказываю, где именно происходят события, затем калибрую условия с учётом блокировок и неполноты идентификаторов.

1) Триггер “Page View” по DOM-событиям (и почему он даёт двойные загрузки)
Самый распространённый сценарий — SPA или многостраничность, где я видел Page View, который пытались “улучшить” триггером на DOM Ready / History Change / Custom event. В итоге:
— часть переходов получает один Page View, часть — два
— в отчетности это выглядит как рост посещаемости или ухудшение глубины
— а в performance-моделях (и тем более при server-side подходе) это начинает “съедать” инкрементальность

Как я чиню:
— оставляю Page View максимально детерминированным: один источник истины (обычно — изменение URL/route через родной событийный слой сайта, но с жестким антидубликатом)
— добавляю антидубликат на уровне dataLayer (например, хеш текущего route + timestamp/счетчик)
— валидирую не на Preview, а на реальных сессиях: смотрю, совпадают ли связки `page_location` → `event_timestamp` и нет ли повторов в пределах X секунд

Наблюдение из практики: чаще всего двойные Page View появляются не у всех пользователей, а у сегмента с более медленной загрузкой/нестабильным JS. Там Preview “чистый”, а в проде — нет.

2) Триггеры на Form Submit через “CSS selector”
Я понимаю логику: взять кнопку Submit по селектору, и всё. Но в реальности:
— меняются классы фронтенда (A/B или просто рефактор)
— появляется “декоративная” кнопка, которая отправку не инициирует
— а submit ловится раньше, чем формируется финальный payload (например, до валидации)

В результате часть форм:
— отправляется, но событие не логируется
— или логируется с неполными параметрами (и потом вы не можете разложить лиды по типам)
— или вообще ловит “попытку отправки” без факта

Как я чиню:
— перехватываю событие на уровне факта отправки: success callback, завершение network-запроса (или конечный state в dataLayer, который ставит бек/сервер)
— если это невозможно — делаю связку: “видимость формы + заполнение минимум N полей + клик + подтверждение загрузки/ошибки”
— обязательно прокидываю идентификатор сессии/формы, чтобы не смешивать повторные попытки

Мини-цифра: в одном e-commerce проекте у нас “submit по selector” давал расхождение с backend-логами порядка 8–12% по отправкам. После перехода на подтверждение факта (через конечный state) разрыв ушел почти в ноль — это сразу стабилизировало MQL/SQL-логику и отчётность для RevOps.

3) Триггеры на Consent (CMP) без режима “replay”
Consent Mode и CMP — это не просто галочка “разрешено/запрещено”. В privacy-first мире у пользователя может:
— быть отказ на старте, затем согласие после прокрутки/действия
— очиститься хранилища, смениться домен/вкладка
— поменяться доступность идентификатора (client id/псевдоидентификаторы)

Если триггер на нужные теги завязан только на “consent granted в момент page load”, вы получаете ситуацию: событие в dataLayer может происходить, но трекер уже не может его отправить, и вы теряете конверсию без возможности догнать.

Как я чиню:
— разделяю “сбор события в dataLayer” и “отправку наружу” (только когда consent соответствует)
— делаю replay: храню ключевые события (минимум — конверсионные) до момента разрешения и отправляю один раз при подходящих условиях
— валидирую сценарии: отказ → согласие и согласие → отказ (да, бывает и так)
…

Почему я больше не верю в «идеальную» настройку GTM

Я часто вижу одну и ту же ошибку: маркетолог пытается вылизать контейнер Google Tag Manager до состояния «всё учтено, всё идеально». На практике это почти всегда приводит не к порядку, а к хрупкости.

Моя позиция простая: GTM в 2026 году — не склад пикселей, а **операционная система измерения**. Его задача не в том, чтобы собрать максимум тегов, а в том, чтобы выдержать изменения в продуктах, воронках и требованиях к приватности без постоянных пожаров.

Что я считаю признаком здоровой архитектуры:
— один источник истины для событий;
— минимум дублирующих триггеров и «магии» в интерфейсе;
— чёткое разделение: данные, согласия, отправка;
— серверная часть там, где важна устойчивость к блокировкам и потерям.

Из практики: в одном B2B-проекте после аудита мы сократили число пользовательских событий в веб-контейнере почти вдвое — с 34 до 19. Казалось бы, меньше данных. Но через месяц команда получила не «пустоту», а более чистую картину по пути от первого визита до заявки: меньше конфликтов между источниками, меньше ложных срабатываний, быстрее поиск ошибок.

Почему это особенно важно сейчас? Потому что классический last-click всё хуже объясняет вклад маркетинга, а RevOps и privacy-first-атрибуция требуют не просто «собирать всё», а собирать **надёжно и сопоставимо**. Если события собраны криво, никакая модель — ни server-side, ни MMM, ни сквозная аналитика — не спасёт.

Я бы сформулировал так: хороший GTM — это не тот, где больше тегов. Хороший GTM — это тот, который переживает рост, редизайн, смену агентства и новый инструмент аналитики без переписывания половины логики.

— @GTMrecipesRuPro

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

Всё это выглядит забавно, но давайте не забывать, в какой сфере мы работаем и что реально может произойти с жирным троллем за воровство нейминга. Впрочем, толстому не привыкать отхватывать пиздов за проделки в интернете, поэтому ждем очередную фотку разбитого ебала и длинный пост с извинениями. 😏😏😏

В арбитраже денег нет 💵

Custom HTML в GTM: когда встроенных тегов мало

Когда шаблонного тега нет, а скрипт на сайт поставить нужно — на помощь приходит Custom HTML. Это самый гибкий инструмент в GTM, но и самый опасный: код выполняется прямо в браузере пользователя. Ниже — что делать, чтобы не превратить контейнер в помойку.

— **Сначала проверь, нет ли готового тега.** Прежде чем писать HTML руками, открой галерею шаблонов и поиск по названию сервиса. В 90% случаев официальный шаблон уже закрывает задачу: безопаснее, быстрее, проще отлаживать.

— **Вставляй скрипт в ``, а разметку — в ``.** Custom HTML-тег умеет рендерить любой HTML, но инъекцию `` лучше делать через сам тег, а визуальные блоки и пиксели — выносить в `document.body` или через CSS-селектор. Это снижает влияние на CLS и PageSpeed.

— **Используй переменные GTM внутри кода.** Любая встроенная переменная уровня данных (dataLayer) доступна через `{{Название}}`. Так Custom HTML становится параметризованным: один тег закрывает десятки сценариев без копипасты.

— **Добавляй триггер с явным условием.** Custom HTML не должен срабатывать «на всех страницах» — это путь к дублям событий и медленной загрузке. Фильтруй по URL, типу страницы, событию dataLayer или по готовности DOM.

— **Проверяй в режиме предварительного просмотра и Tag Assistant.** Открой Debug-режим, посмотри вкладку Tags, убедись, что тег сработал на нужной странице и только на ней. Загляни в Console — там часто всплывают ошибки парсинга и 404 на скриптах.

— **Галочка поддержки document.write — только осознанно.** Опция ломает асинхронную загрузку и блокирует рендер. Включай её, только если скрипт категорически требует этого (старые пиксели рекламных сетей) и понимаешь последствия для Core Web Vitals.

— **Версионируй и документируй.** Любой Custom HTML — это технический долг. Оставляй в комментарии к тегу ссылку на задачу, автора и дату. Через полгода именно эта строка спасёт, когда придёт запрос «а что это за скрипт на странице 404».

**Когда пригодится:** при подключении скриптов без готового шаблона — внутренних пикселей, кастомных чатов, A/B-провайдеров, систем коллтрекинга и нестандартных пикселей рекламных платформ.

— @GTMrecipesRuPro

Server-side аналитика как фундамент для RevOps в 2026 году

Переход от модели «лид-генерации» к управлению выручкой (RevOps) ставит перед аналитиками новую задачу: как связать данные о первом клике с финальной оплатой, если пользователь прошел через пять касаний в разных каналах, а браузеры заблокировали все сторонние файлы cookie? В эпоху, когда last-click (атрибуция по последнему клику) окончательно потеряла доверие, единственным способом сохранить чистоту данных остается серверная передача событий.

Многие до сих пор используют Google Tag Manager только на клиенте, полагаясь на браузерные API. Но в 2026 году это означает потерю от 30% до 45% данных из-за жестких алгоритмов блокировки трекеров. Когда мы настраиваем серверный контейнер (Server-side GTM), мы переносим контроль над данными на сторону своего сервера. Это не просто технический трюк для обхода блокировщиков, это способ обеспечить прозрачность для CRM-системы, чтобы менеджеры по продажам видели реальный путь клиента, а не «черную дыру» из неассоциированных заявок.

На практике это меняет подход к настройке триггеров. Вместо того чтобы пушить в аналитику каждое мелкое взаимодействие, мы фокусируемся на передаче качественных сигналов:
— серверная валидация уникальных идентификаторов пользователей, которые сохраняются при смене устройства;
— обогащение событий данными из бэкенда (например, реальным статусом сделки из системы учета);
— отправка данных в маркетинговые платформы через API, исключая зависимость от стабильности соединения на стороне пользователя.

В моей практике внедрение серверного контура позволило поднять точность атрибуции для B2B-клиентов на 22% по сравнению с классической схемой. Это критично, когда каждый маркетинговый рубль должен быть обоснован вкладом в LTV (пожизненную ценность клиента), а не просто стоимостью обращения.

Мы перестаем гоняться за объемом трафика и начинаем работать с качеством данных. Если ваша архитектура GTM все еще строится на клиентских тегах, которые «отваливаются» при каждом обновлении браузера, вы не управляете выручкой — вы просто наблюдаете за тем, как значительная часть данных растворяется в пустоте. Перенос логики на сервер — это не роскошь, а обязательный гигиенический минимум для профессиональной команды, которая планирует оставаться на рынке в условиях privacy-first (приоритета приватности) экономики.

— @GTMrecipesRuPro

Про что “реальный” GTM: как мы выстроили серверную доставку событий и сделали 35% трафика пригодным для аналитики

Компания/бренд: B2B SaaS (платформа аналитики для отделов продаж и Customer Success)
Задача: после роста количества интеграций и появления новых сценариев в продукте данные стали “рваными”: часть событий приходила с задержками, часть — без корректных идентификаторов пользователя/сессии, а часть вообще не доходила до систем измерения. Маркетинг пытался оптимизировать кампании по last-click (в 2026 это почти всегда ловушка из-за privacy-first), но отчёты не сходились с тем, что показывали продуктовые команды. Нужно было:
— привести схему событий к единому стандарту (каталог событий + обязательные параметры)
— вынести отправку на сервер (server-side), чтобы убрать зависимость от блокировщиков и лагов браузера
— наладить QA измерений до релиза, иначе любая “мелочь” ломает атрибуцию и воронку

Решение (как сделали по GTM):
1) Сформировали “контракт” событий: для каждой ключевой активности (просмотр демо-страницы, клик по CTA, начало заполнения формы, submit, активация в продукте) определили обязательные параметры: user_id (или его рабочий эквивалент), session_id, page_type, campaign_source (если доступно) и версию схемы. Это не “для красоты”: без контрактов в analytics всегда будет сезон “несовпадений”.
2) Разделили сбор и маршрутизацию: в Web Container GTM оставили минимальный слой (сбор триггеров и обогащение контекста), а отправку в измерительные системы перевели в Server Container. На сервере делали нормализацию параметров и единый формат payload.
3) Добавили контролируемые проверки:
— Rule-валидация: если обязательный параметр отсутствует — событие не отправляем, а пишем в лог (для внутренних проверок)
— дедупликация: защитились от дублей при редиректах/SPA-переходах по ключам (event_name + timestamp_window + user/session)
— тайминг: измеряли latency “от события в браузере до фиксации на сервере” и отслеживали выбросы

Конкретный результат:
— Доля событий, пригодных для воронки (со всеми обязательными параметрами), выросла с **~62% до ~84%**. То есть дополнительно стало доступно **порядка 35%** больше точек поведения, которые раньше “портило” отсутствие идентификаторов/параметров.
— Существенно снизились расхождения между маркетинговыми отчётами и продуктовой аналитикой: разница по конверсиям на ключевых шагах формы уменьшилась с **двухзначных процентов до погрешности в рамках 1–3%** (в основном за счёт исправленной дедупликации и корректной сериализации параметров).

Урок для читателя:
В 2026 “оптимизация кампаний по кликам” часто проигрывает процессной задаче: **сначала обеспечьте качество измерений**. GTM-сценарии — не разовая настройка, а продуктовый артефакт:
— делайте контракт событий (обязательные поля + версия схемы)
— переносите отправку на сервер, когда страдает устойчивость данных
— добавляйте QA-валидации и логи до того, как данные попадут в отчёты
Если этого нет, любые улучшения в таргетинге/креативах будут упираться в “сломанные провода” — а маркетинг будет принимать решения по статистике, которой доверять нельзя.

— @GTMrecipesRuPro

3 инструмента для связки коллтрекинга и AI-операций в маркетинге

Если у вас B2B или усложнённая performance-воронка, выбор инструмента сейчас упирается не в «есть ли автоматизация», а в то, **насколько она помогает доказать вклад маркетинга в выручку**. Ниже — три решения одного класса, но с разным акцентом: на звонки, на стандартизацию бренд-голоса и на повседневные автоматизации команды.

Ringostat — для агентств и in-house-команд, которым нужно связать звонки с рекламными источниками — сильная сторона: коллтрекинг и сквозная аналитика помогают не спорить о «бесплатной Google Analytics», а показывать, какие каналы приводят обращения — слабая сторона: ценность раскрывается только при аккуратной настройке и дисциплине в передаче данных.

Writer — для контент-команд и брендов, которые масштабируют выпуск материалов без потери единого тона — сильная сторона: система бренд-голоса, словари терминов, стиль-гайды и общие рабочие пространства уменьшают расхождения между авторами и отделами — слабая сторона: это не «быстрый генератор текста», а скорее инфраструктура; без ясных правил легко получить формально единый, но пустой по смыслу контент.

AI-агенты для маркетинговых задач — для команд, у которых много повторяющихся операций: брифы, согласования, напоминания, сбор статусов — сильная сторона: снимают рутину и экономят часы каждую неделю, особенно в RevOps-связке маркетинга, продаж и customer success — слабая сторона: требуют жёсткого контроля прав доступа и сценариев, иначе автоматизация начинает путать приоритеты вместо того, чтобы ускорять работу.

Как выбирать: если задача в доказательстве ценности каналов — берите связку вокруг коллтрекинга; если проблема в единообразии коммуникации — смотрите на бренд-системы; если узкое место в операционке — полезнее всего будут AI-агенты, но только с понятными правилами и метриками качества.

— @GTMrecipesRuPro

Как настроить opt-out от Google Analytics в GTM без ручной возни

Если в контейнере много тегов, отключать трекинг по одному через customTask быстро становится тяжело. Практичнее собрать централизованную схему, где отказ пользователя от аналитики управляется одним правилом, а не десятком исключений.

— Определите источник отказа.
Задайте понятный флаг: cookie, localStorage или переменная уровня dataLayer.
Важно, чтобы состояние согласия читалось одинаково во всех тегах, а не хранилось отдельно в каждом.

— Пропишите единый шаблон проверки.
Сделайте условие, которое блокирует отправку хитов Google Analytics, если opt-out активен.
Так вы не будете править customTask в каждой настройке и снизите риск расхождений между тегами.

— Привяжите проверку к триггерам.
Ограничьте срабатывание тегов на уровне запуска, а не только на уровне параметров отправки.
Это особенно полезно в больших контейнерах, где теги размножаются быстрее, чем документация.

— Закройте редиректы DoubleClick.
Если у вас есть переходы через рекламные ссылки, проверьте, что отказ от аналитики не ломает логику перехода, но не запускает лишние запросы.
Иначе пользователь формально «отказался», а часть событий всё равно утекает.

— Проверьте сценарий после обновлений.
После каждого изменения контейнера прогоняйте тест: отказ включён, хиты не уходят, согласие снято — теги снова работают.
В GTM такие вещи удобно валидировать через Preview и сетевые запросы.

— Документируйте правило в одном месте.
Опишите, где хранится статус отказа и какие теги его читают.
Это экономит время аналитике, разработке и маркетингу, когда контейнер растёт.

Когда это пригодится: если вы строите privacy-first аналитику и хотите централизованно отключать Google Analytics без ручной правки каждого тега.

— @GTMrecipesRuPro

Переход на Server-side отслеживание для B2B-сервиса: как спасти данные в эпоху Privacy-first

Компания: SaaS-платформа (программное обеспечение как услуга) для автоматизации документооборота.

Задача: В условиях 2026 года, когда браузеры массово блокируют файлы cookie (куки) сторонних ресурсов и ограничивают время жизни локального хранилища, компания столкнулась с потерей до 40% данных о пути клиента. Маркетинговые отчеты перестали биться с выручкой в CRM (системе управления отношениями с клиентами), что сделало невозможным расчет окупаемости инвестиций в рекламу.

Решение: Перенос трекинга на серверную сторону с использованием Google Tag Manager Server-side. Вместо прямой отправки данных из браузера пользователя в рекламные системы, поток информации перенаправили через собственный облачный сервер. Это позволило:
— Настроить проксирование запросов, превращая сторонние файлы куки в собственные (первичные), что обходит жесткие ограничения Safari и Firefox.
— Обогатить данные на сервере: объединить события с сайта с данными из CRM до отправки в аналитику.
— Снизить нагрузку на клиентскую часть сайта, удалив тяжелые SDK (комплекты средств разработки) рекламных площадок.

Результат:
— Достоверность атрибуции (приписывания ценности конверсии конкретному каналу) выросла на 28%.
— Средняя точность передачи данных о транзакциях (SQL — квалифицированных продажами лидах) достигла 95%.
— Удалось восстановить цепочку касаний для 15% пользователей, которые ранее были «невидимы» из-за настроек приватности.

Урок для специалиста: В эпоху, когда Last-click (атрибуция по последнему клику) окончательно теряет смысл, серверный сбор данных становится базовой гигиеной. Если вы работаете в B2B или E-com, переход на Server-side — это не вопрос «модности» стека, а вопрос выживания вашей маркетинговой аналитики.

Помните, что *Server-side GTM* — это не просто перенос кода на сервер. Это фундамент для внедрения MMM (маркетингового моделирования на основе микса каналов) и оценки инкрементальности (прироста эффективности от каждого канала), без которых невозможно планировать бюджеты в текущих реалиях RevOps (общей ответственности за выручку). Начинайте с малого: переведите на сервер хотя бы базовые события отправки форм, чтобы увидеть разницу в данных своими глазами.

— @GTMrecipesRuPro

Интеграция e-commerce от “покупки” до “дохода”: как настроили цепочку событий в GTM и сократили расхождения в отчётах

Компания: сеть онлайн-магазинов с подпиской на сервис доставки (e-com + контент для удержания)
Задача: перестали сходиться цифры между веб-аналитикой и бэк-офисом. В отчётах было много “успешных оплат”, но выручка и состав заказов расходились. Из-за этого маркетинг недооценивал связки “контент → заказ”, а performance-отчётность приходилось сводить вручную. Нужно было привести события к единой модели: от просмотра товара и клика по CTA до транзакции и post-purchase шагов, плюс унифицировать параметры для атрибуции в privacy-first мире (без опоры на last-click).

Решение (как делали в GTM по шагам, без магии):
1) Сформировали единый “контракт параметров” для всех событий
— product_id, sku, category, price, currency
— order_id, affiliation (источник/канал), value, tax, shipping
— coupon (если есть), item_count
Важно: одинаковые ключи и формат данных во всех тегах, чтобы потом не “лечить” расхождения костылями.

2) Развели события по фазам в воронке
— ViewItem / AddToCart (верх воронки)
— BeginCheckout (старт оформления)
— Purchase (факт оплаты)
— Refund/Cancel (post-purchase), если бизнес это учитывает
Так мы отсекли ситуацию, когда данные “похожих” событий (например, из UI) заливали отчёт как покупку.

3) Перенесли логику формирования dataLayer на страницу “гарантированной” истины
В GTM часто ломается не сам триггер, а источник данных (DOM меняется, порядок отрисовки скачет). Поэтому для Purchase использовали данные, которые бизнес-система подтверждает на сервере/в ответе API, и прокидывали их в dataLayer одним событием в момент консистентности.

4) Согласовали триггеры и условия отправки
— Purchase отправляется только при наличии order_id и валидного value
— AddToCart не считается “успешным” повторно, если пользователь открыл модалку и закрыл
— чекбоксы/формы без подтверждения не отправляют “BeginCheckout” пока не выполнены условия заполнения

5) Проверка: “контрольные точки” в режиме Preview + ре-вычисление на фронте
Сделали чек-лист тестов:
— 3 сценария покупки (обычная, с купоном, с доставкой)
— повторный refresh после оплаты
— отмена/возврат
И смотрели не только факт срабатывания, но и соответствие параметров (что именно улетело в value, currency, item_count).

Конкретный результат (что изменилось после внедрения):
— Расхождения по заказам между веб-аналитикой и бэк-офисом сократились с “существенных” (ручные сверки занимали время) до погрешности, которую можно объяснить разницей статусов и таймингом (например, отмены/возвраты).
— Маркетинг смог строить отчётность по связкам “контент/сервисная страница → checkout → purchase” без ручных таблиц.
— Снизилось количество “ложных” Purchase из-за условий отправки: события перестали дублироваться при перезагрузке и навигации.

Урок для читателя:
Если “покупка” в системе — единственное событие, на которое вы смотрите, то любая ошибка в цепочке данных превращается в неверную выручку и неверный вывод по эффективности. В 2026-реальности важнее не просто включить больше тегов, а обеспечить:
— единый контракт параметров во всех событиях
— отправку Purchase только из источника, которому доверяет бизнес
— валидацию ключевых полей (order_id, value, currency)
— проверку пост-purchase сценариев (отмена/возврат), чтобы отчёты не “светились” лишними покупками

Если хотите — опишите вашу текущую карту событий (какие есть: ViewItem/AddToCart/BeginCheckout/Purchase и есть ли Refund) и где именно расхождение (заказы, выручка, состав). Подскажу, какие триггеры и правила в GTM дадут максимальный эффект в первую очередь.

— @GTMrecipesRuPro

В роликах Youtube теперь можно рекламировать товары Amazone

➡️ Читайте на сайте: https://aff.top/blog/v-rolikakh-youtube-teper-mozhno-reklamirovat-tovary-amazone

🧠 Ещё больше инсайтов → в канале AFF.top