Yandex Тег Менеджер против Гугл: обзор, настоящий опыт переезда и подводные камешки

В прошлой статье я уже тщательно разъяснял, что такое тег-менеджеры и почему без их современный маркетинг просто не работает. Напомню кратко: тег-менеджер – это единая точка управления кодами отслеживания на веб-сайте. Благодаря ему рекламщики и аналитики могут без помощи разрабов внедрять пиксели, настраивать действия и запускать опыты.

Сейчас я желаю продолжить данную тему и побеседовать о том, что происходит на рынке опосля того, как Гугл Tag Manager практически оказался под запретом в Рф.

Я наиболее 10 лет занимаюсь аналитикой, SEO и управлением командами в digital-маркетинге. А в собственном Телеграм-канале пишу еще более про всякое принципиальное из настоящего маркетинга. Консультирую по аналитике web-проектов и настройке инструментов маркетинга, помогаю проводить технические собеседования профессионалов по разным типам трафика.

Проблематика Гугл Tag Manager в 2025 году

Как я писал ранее, еще в 2024 году РКН признал зарубежные системы веб-аналитики и тег-менеджеров нарушающими закон о индивидуальных данных. GTM, хоть и не постоянно впрямую собирающий ПД, загружает код с серверов Гугл за пределами РФ (Российская Федерация — государство в Восточной Европе и Северной Азии, наша Родина). Проверить, какие данные уходят «под капотом», нереально.

Итог: компании в Рф лишились главного инструмента, через который управлялись не только лишь аналитика, да и вся рекламная инфраструктура – от ремаркетинга и A/B-тестов до чатов и виджетов. И если утрату GA4 почти все пережили, перейдя на Yandex Метрику, то утрата GTM стала еще болезненнее.

На самом деле, в 2025 году бизнес оказался перед выбором: перебегать на локальные решения (к примеру, Yandex Тег Менеджер), пробовать open-source кандидатуры либо ворачиваться к «ручному» внедрению кода на веб-сайт. Любой из этих путей мы уже разглядели с плюсами и минусами, а сейчас разберем подробнее один из основных доступных вариантов – Yandex Тег Менеджер.

Обзор Yandex Тег Менеджера

Интерфейс и логика работы

На 1-ый взор Yandex Тег Менеджер (ЯТМ) очень припоминает Гугл Tag Manager: тут тоже есть контейнеры, снутри которых живут теги, триггеры и переменные. Если ранее вы работали в GTM, акклиматизироваться в ЯТМ будет довольно просто.

Главный экран – перечень контейнеров, где для всякого проекта можно сделать отдельное рабочее место.
Снутри контейнера – вкладки «Теги», «Триггеры», «Переменные» и «Версии».
Есть раздел публикации конфигураций: поначалу правки сохраняются в черновике, а позже публикуются на веб-сайт.

Что именуется, найдите 10 различий

Но функционал, естественно же, не 1 в 1, его и будем разбирать.

Примечание: Тег менеджер Yandex’а уже доступен всем. Компания сделала реально крутое решение, когда интегрировали вызов Тег менеджера в код Yandex Метрики. Но работать он будет лишь опосля включения его в настройках счетчика, а самое основное – включить настройку Пользовательских html тегов.

Способности

Контейнеры

Как и в GTM, на веб-сайт встраивается один код контейнера. Все другое – управление из интерфейса ЯТМ. Это упрощает жизнь маркетологу: код внедряется один раз, а далее конфигурации делаются без роли разрабов.

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

Что любопытно, скрипта от такого же ВК не видно, а означает, настраивать его придется руками через код. В целом, это маленькая неувязка, потому что в эру GTM все эти ребята так и настраивались, ну не считая разве что Flocktory и Вариокуба – у их был собственный пользовательский шаблон.

Вывод: в тегах пока критичного отличия нет, тут мы ничего не утратили, да и пока ничего важного не заполучили.

Триггеры

Они определяют, когда и где должен сработать тег. Ниже привел таблицу сопоставления по триггерам с GTM.

Тип триггера	Yandex Тег Менеджер	Гугл Tag Manager	Комментарий
Загрузка странички	Да, можно избрать: все странички либо отдельные URL	Да, Page View, DOM Ready, Window Loaded	Все взаимозаменяемо
Клик по элементу	Да, по кнопочкам, ссылкам, CSS-селекторам	Да, все клики, в том числе по хоть каким DOM-элементам; есть группы Click Classes, Click ID	Все взаимозаменяемо
Отправка формы	Да, по формам и кнопочкам submit	Да, интегрированный Form Submission Trigger, плюс настройка валидации	В обоих есть, но GTM дозволяет легче фильтровать удачные отправки
Пользовательские действия (Custom Event)	Да, через JS-события либо dataLayer	Да, через dataLayer.push	Все взаимозаменяемо
Скролл странички	Нет встроенного	Да, Scroll Depth Trigger	В ЯТМ необходимо реализовывать через кастомный JS-триггер
Время на страничке / таймер	Нет встроенного	Да, Timer Trigger	В ЯТМ лишь через JS-триггер
Видеособытия (YouTube / HTML5)	Нет встроенного	Да, готовые шаблоны	В ЯТМ необходимо писать без помощи других через JS
Элемент на страничке (Visibility / Element)	Нет встроенного	Да, Element Visibility Trigger	GTM наиболее комфортен для лендингов с динамическим контентом
История браузера / URL change	Нет встроенного	Да, History Change Trigger	В ЯТМ тоже можно через JS, но без интерфейса. И вот эта неувязка для SPA веб-сайтов

Главные выводы

ЯТМ покрывает базисные действия: загрузка странички, клики, отправка форм, кастомные действия.
GTM еще гибче: готовые триггеры для скролла, таймеров, видео, видимости частей и конфигурации истории браузера.
Для ЯТМ все «неординарные» триггеры необходимо реализовывать через кастомный JS-код. Это означает – больше ручной работы, но при грамотной настройке все работает размеренно. Благо с возникновением не так давно JS-переменных можно отправлять пользовательские действия из ЯТМ в dataLayer при пришествии чего-то, здесь же триггериться на эти действия и отправлять теги. В общем, выходит некоторый Уроборос, но работает =)

Условия срабатывания триггеров

Нередко этот фактор упускается в обзорах (по последней мере тех, что мне попадались) а это принципиально. И вот здесь я увидел некоторое различие. Специально привел весь перечень вероятных критерий:

Замечаете, чего же не хватает? Начинается с… И здесь мне показалось, что «да как так, да вы что»! Спустя час я сообразил, что не сумел придумать ни 1-го адекватного сценария, где это условие не перекрывалось бы условием содержит. Респект парням из Yandex’а за логическую оптимизацию! Если я не прав, приведите в комментах условия, когда непременно необходимо «начинается с».

Переменные

Тут ЯТМ незначительно скромнее, чем GTM. Есть базисные переменные, но расширенных может не хватать. И это было настоящей неувязкой до середины сентября, пока не было JS-переменных, на данный момент все ок. Привожу полную таблицу сопоставления типов переменных:

Тип переменной	ЯТМ	GTM	Комментарий
URL странички	Да, доступен полный URL, путь, характеристики	Да, Page URL, Page Path, Hostname, Query	В GTM больше гибкости, можно применять отдельные части URL прямо в триггере
Реферер	Да	Да
Кликнутый элемент	Да, элемент полностью	Да, Element, Classes, ID, Attributes, Text	В GTM наиболее продвинутые характеристики клика
ID элемента	Да	Да
Класс элемента	Да	Да
Текст элемента	Нет	Да	В ЯТМ необходимо действовать через JS-переменную
Действия (Custom Event / JS)	Да	Да
Характеристики URL / Query String	Да	Да
Referrer и Origin	Да	Да
JavaScript-переменные на страничке	Да	Да	В ЯТМ, к слову, поддерживается наиболее свежайшая версия JS
Cookies / LocalStorage / SessionStorage	Да, через JS	Да, через интегрированные типы переменных и JS	GTM имеет готовые типы «1 к 1» для куки, ЯТМ – через JS
Data Layer / Custom JS Object	Да	Да
Переменные окружения (Referrer, Hostname, Path)	Да	Да
Интегрированные переменные для кликов и форм	Ограниченный набор: Click ID, Click Classes, Click Text (отчасти через JS)	Полный набор: Click ID, Classes, Target, Text, Form ID, Form Classes, Form Text	GTM покрывает все типовые действия кликов и форм, ЯТМ – базисный минимум
История / Scroll / Visibility / Timer	Нет	Да, интегрированные	В ЯТМ необходимо JS-выражения для реализации

Вывод: ЯТМ покрывает 95% сценариев своими переменными, необходимыми для обыкновенной аналитики. А большего нам и не нужно =)

Версионирование

Все конфигурации можно публиковать по версиям как в ЯТМ, так и в GTM. Это комфортно для отката в случае ошибок. При этом на мой вкус в ЯТМ даже удобнее реализовано:

Рабочие области

В Yandex Тег Менеджере рабочая область представлена одной главный средой, в какой ведутся все конфигурации. Это значит, что вся команда работает на самом деле «в одном потоке»: новейшие теги, триггеры и переменные добавляются и редактируются в одном месте.

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

Ветки либо отдельные филиалы для тестов и тестирования в ЯТМ отсутствуют, потому параллельная работа и поэтапное тестирование реализуются труднее. Проще сказать через чат в ТГ, когда один аналитик всем пишет: «Ребят, а занят ЯТМ для работ, не лезьте, плиз, как закончу отпишусь».

В Гугл Tag Manager подход наиболее гибкий и нацелен на многопользовательскую работу. В GTM можно создавать несколько рабочих областей для различных профессионалов, что дозволяет сразу тестировать конфигурации, не мешая друг дружке. Система поддерживает версионирование и ветки, позволяя экспериментировать с новенькими тегами, триггерами и переменными без риска сломать основную инфраструктуру. Это в особенности принципиально для больших проектов и установок, где аналитики, рекламщики и создатели работают параллельно, а контроль версий и публикация конфигураций поэтапно помогают избежать ошибок и обеспечить стабильность работы веб-сайта.

Быстрее всего это ожидаем в будущих релизах.

Режим предпросмотра

А вот тут есть ряд проблем. На текущий момент режим предпросмотра у ЯТМ номинально есть, но по факту работает так для себя. Практически он дает или применять особый тег, который будет писать для вас в консоль, что такой-то тег сработал, или сами обучайтесь в коды тегов писать console.log («Эй пацаны, я тег такой-то я отработал»).

Естественно, есть маленькой лайфхак: можно опосля пуска режима предпросмотра, когда вас перекинет на адресок с параметром /?_ytm_preview=9106430618561807075 (к примеру), дописать к этому параметру &_ym_debug=2, чтоб возникла вот таковая прекрасная панелька. Но при тестировании конфигураций в одной и той же цели вы будете получать двойное срабатывание в тестовом режиме, настоящей цели и испытательной. Тем не наименее, это уже очень упрощает жизнь.

Уверен, что в наиблежайшее время режим предпросмотра все таки покажется настоящий, как в GTM.

Чемодан переезда с GTM на Yandex Тег Менеджер

Нами был перевезен достаточно большой веб-сайт, но именовать, какой непосредственно, пока не могу – не согласовано. Следует все таки сказать, что это большой веб-ресурс с высочайшей посещаемостью, который интенсивно употребляет аналитические инструменты для мониторинга поведения юзеров на страничках веб-сайта.

Оценка ресурсов

Веб-сайт имел посещаемость около 600 000 визитов за месяц. Для удачного переезда потребовались:

Аналитик – 40 часов: инвентаризация целей и переменных, настройка триггеров в ЯТМ, тестирование.
Разраб – 1 час: внедрение кода ЯТМ, перенос кода Метрики из GTM в код веб-сайта, проверка работы посторониих скриптов.

Общий срок проекта занял около 2 недель для первой волны целей, плюс еще 2 недельки для полной передвижения всех целей с мониторингом.

Реестр целей и тегов

В GTM было около 30 целей, все привязаны к Yandex Метрике для работы с Директом, плюс несколько посторониих скриптов для фронтенда.

Часть целей и динамика срабатываний:

Цель	Срабатывания до переезда	Срабатывания опосля переезда	Дельта
Оформление заказа	1 256	1 253	-0.24%
Подписка на рассылку	2 871	2 865	-0.21%
Клик по кнопочке «Заказать звонок»	4 092	4 083	-0.22%
Просмотр главный странички промоакции	12 038	11 987	-0.42%
Отправка формы оборотной связи	1 647	1 641	-0.36%
Клик по баннеру акции	3 519	3 508	-0.31%
Переход на страничку контактов	2 212	2 206	-0.27%
Открытие всплывающего окна подписки	5 028	5 013	-0.30%

Сопоставление проведено за равные периоды в 2 недельки, при всем этом у веб-сайта нет выраженной сезонности. Уверен, что таковым дельтам можно довериться – нигде нет конфигураций больше чем в 1%.

Метод переноса

Код Yandex Метрики перенесен из GTM в код веб-сайта, чтоб ЯТМ начал работать впрямую.
Выбраны 1-ые 10 целей, перенесены копированием в ЯТМ.
Испытана отработка целей в режиме предпросмотра.
Цели отключены в GTM и размещены конфигурации, цели включены в ЯТМ и размещены конфигурации.
В течение 2 недель отслеживалась динамика срабатываний 10 целей.
Опосля доказательства корректной работы по такому же принципу переносились все другие цели в ЯТМ.
Живем еще 2 недельки, тестируем работу всех целей. При всем этом GTM находится в коде, как пустой контейнер с отключенными целями на вариант отката.
Опосля удачного тестового периода GTM удаляется из кода веб-сайта.

Результаты

Замеры спустя месяц проявили, что срабатывания целей фактически не поменялись, дельта не превосходит 1%.
Посторонние скрипты фронтенда работают размеренно.
Реклама в Директе продолжает работать без остановки и переобучения.
Вся аналитическая инфраструктура сейчас стопроцентно завязана на ЯТМ, что соответствует требованиям локального законодательства.

Вывод

Переезд с GTM на ЯТМ вероятен без утраты данных и с малой корректировкой маркетинговой инфраструктуры. При всем этом принципиально соблюдать пошаговый метод переноса, кропотливо тестировать 1-ые цели и лишь опосля доказательства правильности переносить другие.

Оригинал статьи на SEOnews