Серверное отслеживание Bing: Microsoft Ads через ваш sGTM

Серверное отслеживание конверсий для Bing не требует отдельного проекта. Если у вас уже работает серверный контейнер для Google и Meta, настройка та же: тот же sGTM, тот же хостинг и ещё один тег, который передаёт конверсии в Microsoft Ads через Conversions API. Но два отличия от Google всё же есть, и о них эта статья. Microsoft пока открывает этот API только для отдельных аккаунтов, а без правильной дедупликации каждая конверсия считается дважды.

1. Серверное отслеживание Bing: та же логика, что у Google и Meta

Как вообще работает серверное отслеживание, почему адблокеры и ITP в Safari приводят к потере части данных и при каком бюджете сервер тегов окупается, я подробно разобрал в статье про серверное отслеживание через GTM. Коротко: браузер отправляет события на ваш собственный сервер на вашем поддомене, а второй контейнер GTM, серверный, передаёт данные дальше рекламным платформам.

Для Microsoft Ads в этой схеме ничего не меняется. Новое только то, куда уходят данные. У Meta серверный канал называется Conversions API, и Microsoft назвала свой аналог так же: Conversions API, сокращённо CAPI. Сервер отправляет события конверсий напрямую в Microsoft, и устроены они так же, как события UET-тега в браузере.

UET остаётся, CAPI добавляется

Сразу о частом недоразумении: Conversions API не заменяет UET-тег. В своей документации Microsoft прямо рекомендует по возможности использовать CAPI вместе с UET. UET-тег фиксирует то, что происходит в браузере, а CAPI добавляет события, которые браузер теряет или вообще не видит.

Что это значит для вас:

• Ваша настройка в браузере остаётся как есть. Как собрать UET-тег в GTM, описано в статье про настройку отслеживания конверсий Bing. Эта инструкция по-прежнему основа.
• Серверный тег — это второй канал для тех же конверсий, а не отдельный учёт конверсий.
• Одна и та же конверсия теперь может прийти двумя путями, поэтому нужен общий ID события. Подробнее во втором разделе.

Что Conversions API передаёт в Microsoft

Чтобы Microsoft могла связать серверное событие с кликом по объявлению, в каждом событии должен быть хотя бы один идентификатор. Главные из них:

• msclkid: ID клика, который Microsoft добавляет к адресу посадочной страницы, если включена автоматическая пометка (auto-tagging). Это самый надёжный идентификатор, чтобы связать конверсию с кликом.
• anonymousId: ID посетителя, который UET-тег хранит в cookie.
• Хешированные e-mail и телефон: через SHA-256, никогда открытым текстом.
• И там, где это разрешено, IP-адрес и user agent посетителя.

Если это кажется знакомым, так и есть. У Meta это fbclid и хешированные данные пользователя, у Google gclid и расширенные конверсии. Логика везде одна.

Чего серверное отслеживание Bing не решает

Здесь действует то же правило, что и для любого серверного отслеживания: обойти согласие оно не позволяет. И у Microsoft есть ловушка, о которой стоит знать. По документации Conversions API по умолчанию обрабатывает каждое событие так, будто согласие получено. Только если передать параметр adStorageConsent со значением D, Microsoft не использует событие в рекламных целях. Для сайтов в Германии и в целом в ЕС это значит: серверный тег срабатывает только после согласия на маркетинговые cookie, точно так же, как UET-тег в браузере. Механику триггеров вы знаете из статьи про настройку Consent Mode v2.

2. Настройка: тот же серверный контейнер и ещё один тег Microsoft

Эта часть экономит больше всего времени. Новый сервер, второй контейнер или другой провайдер не нужны. Работает ли ваш sGTM на Stape, на Taggrs или на собственном VPS, значения не имеет. Тег Microsoft берётся из галереи шаблонов серверного контейнера, то есть устанавливается в сам контейнер, а не у хостинг-провайдера.

Шаг 1: проверить, есть ли в аккаунте Conversions API

Прежде чем что-то создавать в GTM, проверьте в Microsoft Ads, доступен ли этот API для вашего аккаунта. По документации Microsoft токен получают так:

1. Откройте в аккаунте раздел UET и отредактируйте существующий UET-тег через значок карандаша.
2. В разделе «Edit UET tag» нажмите Save and next.
3. В разделе «Set up tagging» выберите Use Conversions API.
4. В разделе «Conversions API» нажмите Copy Token и сохраните токен в надёжном месте.

И вот честная оговорка к словам «настройка та же»: во многих аккаунтах этой опции нет. В сентябре 2026 года ppc.land писал, что Microsoft ведёт Conversions API как пилотную программу и подключает её для каждого аккаунта отдельно. Включить её самостоятельно нельзя: нужно попросить вашего менеджера в Microsoft или поддержку Microsoft Ads открыть доступ к Conversions API для вашего аккаунта (укажите ID клиента). Сделайте это первым шагом, а не последним. Иначе контейнер будет настроен, но отправлять данные в Microsoft ему ещё не разрешено.

Шаг 2: добавить тег Microsoft в серверный контейнер

Дальше в серверном контейнере всё идёт так же, как с Meta Conversions API:

1. Теги → Создать → Конфигурация тега → найдите в галерее шаблонов Microsoft Ads UET Conversion API by Stape и добавьте его в рабочую область.
2. Создайте новый тег на основе этого шаблона.
3. Укажите UET Tag ID. Это тот же ID, что уже стоит в вашем браузерном теге.
4. Вставьте токен из первого шага. Он привязан именно к этому UET-тегу, токен от другого тега не подойдёт.
5. Передайте хотя бы один параметр с данными пользователя, например хешированный e-mail из события отправки формы.
6. Триггер: то же событие, которое в серверном контейнере уже запускает тег Google Ads или Meta.

ID клика и ID посетителя шаблон берёт из cookie, которые UET-тег и так ставит (_uetmsclkid и _uetvid), или прямо из параметра msclkid в адресе страницы. Проверьте в Microsoft Ads, что автоматическая пометка включена. Без неё msclkid не появляется, и связать конверсию с кликом гораздо сложнее.

Шаг 3: настроить дедупликацию

Именно на этом шаге чаще всего ошибаются. UET-тег в браузере сообщает о конверсии, а серверный тег сообщает о ней ещё раз. Если их не сопоставить, Microsoft посчитает обе, и Smart Bidding будет учиться на вдвое большем числе конверсий, чем было на самом деле.

Решение: общий ID события.

• В веб-контейнере UET-тег события получает параметр event_id с уникальным ID для каждой конверсии.
• Тот же ID уходит вместе с событием в серверный контейнер, а серверный тег передаёт его в Microsoft как eventId.
• ID тега и название события должны совпадать в обоих каналах. По данным Microsoft, именно по этой комбинации распознаются дубли.

Если вы уже настраивали дедупликацию для Meta Conversions API, схема вам знакома. Как это устроено у Meta, описано в статье про настройку пикселя Meta. У Microsoft принцип тот же, отличаются только названия полей.

Шаг 4: проверить

Три проверки, в таком порядке:

1. Предпросмотр в серверном контейнере: срабатывает ли тег Microsoft на нужном событии и отвечает ли Microsoft статусом 200? Ответ 401 почти всегда означает неверный токен или неверный ID тега, ответ 400 означает ошибку в одном из полей события.
2. Посмотрите ту же тестовую конверсию в веб-контейнере: есть ли у события UET тот же event_id, что и у серверного события?
3. Через некоторое время откройте цель конверсии в Microsoft Ads. Если после одного теста счётчик вырос на две конверсии, а не на одну, дедупликация не работает.

3. Когда серверное отслеживание Bing окупается

Логика бюджета из общей статьи действует и здесь, но с одним отличием. С Microsoft вопрос обычно не «нужен ли сервер», а «работает ли он уже».

Если sGTM у вас уже есть

Тогда расчёт простой. Сервер работает, расходы на него всё равно есть, события уже приходят. Для Microsoft вы добавляете один тег, настраиваете дедупликацию и проверяете. Работы немного, а автоматические ставки Microsoft после этого опираются на более полные данные, как уже у Google и Meta. Если вы ведёте Microsoft Ads со стратегией ставок на основе конверсий и ваш аккаунт получил доступ, я бы не откладывал.

Если сервера пока нет

Тогда одной Microsoft, как правило, мало, чтобы ради неё ставить сервер. Если Microsoft у вас небольшой канал рядом с Google и Meta, а во многих аккаунтах так и есть, вопрос о сервере решает не Bing. Решение принимается по общему рекламному бюджету, с ориентиром из статьи про серверное отслеживание: если бюджет меньше примерно 1 000 € в месяц, сначала стоит наладить базовое отслеживание, объявления и лендинг; при большем бюджете сервер окупается. Microsoft тогда просто подключается вместе с остальными.

Заявки из CRM: да, но только за последние семь дней

По данным Microsoft, Conversions API принимает не только события с сайта, но и события из CRM и офлайн-продажи. Для бизнеса, который работает с заявками, это интересно: можно передавать как конверсию целевую заявку или заключённую сделку, а не только отправку формы. Но одна деталь решает многое: время события в поле eventTime должно приходиться на последние семь дней. Сделка, которая появилась в CRM через три недели после клика, этим путём уже не пройдёт. Как правильно передавать в Google данные о сделках с долгим циклом продаж, описано в статье про импорт офлайн-конверсий.

Когда не стоит (пока)

• UET-тег в браузере считает неправильно или цели конверсий ничего не считают. Сначала исправьте основу, иначе сервер будет надёжнее передавать те же неверные данные. Что вообще срабатывает на вашем сайте, покажет моя проверка отслеживания (на английском).
• Microsoft не подключила Conversions API для вашего аккаунта. Тогда UET-тег остаётся единственным путём, и в этом нет ничего страшного, если он считает правильно.
• За дедупликацию никто не отвечает. Серверный тег без общего ID события ухудшает данные, а не улучшает их.

FAQ

Нужен ли для Bing отдельный сервер тегов?

Нет. Тег Microsoft работает в том же серверном контейнере, что и теги Google и Meta, независимо от того, стоит за ним Stape, Taggrs или собственный сервер. Вы добавляете тег, а не сервер.

Заменяет ли Conversions API UET-тег?

Нет. Microsoft рекомендует использовать их вместе. UET-тег остаётся в браузере, а Conversions API дополнительно отправляет данные с сервера. Чтобы ничего не считалось дважды, у обоих один и тот же ID события.

Почему в моём UET-теге нет опции «Use Conversions API»?

Скорее всего, API для вашего аккаунта ещё не подключён. По данным профильных изданий на сентябрь 2026 года, Microsoft подключает Conversions API для каждого аккаунта отдельно. Напишите в поддержку Microsoft Ads или своему менеджеру и укажите ваш ID клиента.

Итог

Серверное отслеживание Bing — это та же настройка, что у вас уже есть для Google и Meta, плюс один тег Microsoft. Разница не в технике, а в доступе к API и в аккуратной дедупликации.

Главное:

• Тот же серверный контейнер и тот же хостинг: Stape, Taggrs или свой VPS, тег Microsoft просто добавляется к остальным.
• Conversions API дополняет UET-тег, а не заменяет его. Настройка в браузере остаётся основой.
• Сначала выясните доступ: если в UET-теге нет «Use Conversions API», попросите Microsoft открыть доступ к Conversions API для вашего аккаунта (укажите ID клиента).
• Общий ID события в веб-теге и серверном теге, иначе каждая конверсия считается дважды.
• Серверный тег срабатывает только после согласия. События без параметра согласия Microsoft считает разрешёнными.
• Если sGTM ещё нет, одна Microsoft редко бывает причиной ставить сервер. Если есть, это небольшой дополнительный шаг.