Настройка отслеживания конверсий в Google Ads

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

Из чего состоит отслеживание конверсий

Механизм собран из трех частей, и путаница обычно начинается с того, что их считают одним целым.

Действие-конверсия - запись в аккаунте Google Ads. Она описывает, что вы считаете результатом: отправку формы, покупку, звонок дольше минуты, запись на консультацию. У записи есть настройки: ценность, способ подсчета, окно конверсии, модель атрибуции. Само по себе действие ничего не считает, это описание.

Источник данных - то, чем результат фиксируется. Google tag на сайте, контейнер диспетчера тегов, импорт из GA4, номер для переадресации, файл с офлайн-сделками. Один источник может кормить несколько действий-конверсий, и наоборот.

Идентификатор клика - то, что склеивает первые две части с рекламой. При переходе по объявлению Google добавляет к адресу целевой страницы параметр GCLID, тег сохраняет его в cookie, и при конверсии значение уходит обратно. Без этого параметра система видит событие, но не знает, из какого клика оно выросло.

Отсюда первое, что проверяется в новом аккаунте, - включена ли автоматическая пометка. Она отвечает за добавление GCLID к ссылкам и находится в настройках аккаунта. В новых аккаунтах включена по умолчанию, но в аккаунтах, которые вели несколько подрядчиков, ее регулярно находят выключенной. Без нее не работает ни импорт офлайн-конверсий, ни связка с GA4, ни отчеты по звонкам. Для своих данных пригодится UTM-генератор с макросами Google Ads.

Раздел «Цели» - список действий-конверсий, их статусы и объем данных за период

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

Шесть способов отслеживания и когда какой нужен

Способы отличаются не сложностью, а тем, какое событие они умеют поймать.

• Google tag на сайте. Код вставляется в шаблон страниц, конверсия фиксируется на странице подтверждения или по событию. Базовый вариант для сайта с обычными формами и корзиной.
• Диспетчер тегов (GTM). Тот же тег конверсии, но управляется из контейнера, без правок кода при каждом изменении. Забирает события, у которых нет отдельной страницы: клики по кнопкам, отправку форм на AJAX, скачивание файлов.
• Импорт из GA4. События, размеченные в аналитике как ключевые, переносятся в Google Ads одной настройкой. Быстрый путь, если аналитика уже собрана и работает.
• Отслеживание звонков. Звонок с объявления, звонок с сайта, разговор дольше заданной длительности. Часть механики завязана на номера Google для переадресации, доступные не везде.
• Импорт офлайн-конверсий. Сделка закрылась в CRM через неделю после клика - результат возвращается в кабинет файлом или по API вместе с суммой.
• Конверсии в приложениях. Установки и внутренние события через Firebase или сторонний трекер вроде AppsFlyer.

Комбинация зависит от воронки. Магазину со сквозной оплатой на сайте хватает первого пункта. Сервису с длинным циклом сделки нужны первый и пятый, иначе автостратегия будет оптимизироваться на заявки, половина из которых не доходит до договора. Клинике или автосервису без звонков картина не собирается вообще.

При создании действия-конверсии выбирается источник: сайт, приложение, звонки или импорт

Google tag: установка и проверка

Действие-конверсия создается в разделе «Цели», источник - «Сайт». Дальше система спросит домен и предложит выбрать способ установки.

Сам код существует в двух видах, и их постоянно путают. Google tag - основной код, он ставится один раз на все страницы сайта, в раздел head, как можно выше. Фрагмент события - вторая часть, она отвечает за конкретную конверсию и ставится точечно: на страницу благодарности, либо на кнопку, либо вешается через диспетчер тегов.

Варианты установки:

• Вручную в шаблон. Google tag в общий head, фрагмент события на нужную страницу. Подходит сайтам с доступом к коду.
• Через конструктор. У Tilda, WordPress и других систем есть поле для кода в настройках сайта или отдельной страницы, правки в шаблон не нужны.
• Через диспетчер тегов. Оба фрагмента заменяются тегами в контейнере, о чем ниже.

Установка тега: код для вставки вручную, отправка разработчику или подключение через диспетчер тегов

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

Сумма заказа передается отдельно. Магазину мало факта покупки, нужен чек: она подставляется в фрагмент события переменной вместе с валютой и идентификатором заказа. Идентификатор отвечает за защиту от дублей, когда покупатель обновляет страницу подтверждения или возвращается на нее из истории браузера. Без него один заказ уходит в статистику дважды, и цифры расходятся с бухгалтерией уже на первой неделе. Значения подставляет разработчик на стороне сайта, из шаблона страницы или из объекта заказа.

Быстрая проверка - расширение Tag Assistant. Оно показывает, какие теги нашлись на странице и с какими параметрами сработали. Проходите путь пользователя целиком, до экрана благодарности, и смотрите, ушло ли событие конверсии.

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

Клиентский и серверный сбор

Тег в браузере - клиентский сбор: событие отправляет устройство посетителя. Часть событий до Google не доходит. Блокировщик вырезает скрипт, настройки приватности обрезают cookie, пользователь закрывает вкладку до срабатывания тега. Сторонних cookie в браузерах больше нет, и потери на клиентском сборе растут третий год подряд.

Серверный сбор отправляет событие с вашего сервера или из серверного контейнера, минуя ограничения браузера. Точность выше, идентификаторы хранятся дольше, но нужен отдельный контейнер и оплата хостинга. Порог, за которым переход оправдан, - примерно от тысячи заказов в неделю. До него хватает обычного тега с расширенными конверсиями. Промежуточный вариант - обслуживание тега с вашего домена: снимает часть проблем с блокировщиками без полной серверной сборки.

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

Настройки действия-конверсии, которые меняют цифры

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

Ценность. Одинаковая для всех конверсий, динамическая (сумма передается в коде транзакции) или без ценности. Магазину нужна динамическая: без суммы заказа не работают стратегии по доле рекламных расходов. Для лидов ценность считается через воронку: средняя маржа со сделки умножается на долю заявок, которые доходят до договора. При среднем чеке $600, марже 40% и закрытии 20% ценность заявки выходит около $48. Пока этих цифр нет, поле лучше оставить пустым - выдуманное число уводит стратегии по ценности не туда.

Способ подсчета. «Каждая» считает все конверсии после клика, «Одна» - только первую. Продажам нужна «каждая»: три заказа от одного клиента - три результата. Лидам нужна «одна», иначе клиент, отправивший форму трижды, раздует статистику. Для звонков «одна» тоже обязательна: повторные звонки одного человека иначе умножают цифру на пустом месте.

Окно конверсии. Срок, в течение которого действие после клика еще засчитывается: от одного дня до 90, по умолчанию 30. Короткое окно занижает статистику при длинном цикле сделки. Слишком длинное растягивает картину и мешает быстро оценивать тесты. Ориентир - фактический срок принятия решения в нише плюс запас.

Модель атрибуции. По умолчанию работает модель на основе данных: она распределяет ценность между всеми взаимодействиями в аккаунте по своей статистике. Из-за распределения в отчетах появляются дробные значения вроде 7,5 конверсии, и это не ошибка выгрузки. Модели нужен объем - порядка 200 конверсий и 2000 взаимодействий с рекламой за 30 дней. Аккаунту меньше этого порога точнее работать на последнем клике, пока данные не накопятся.

Тип цели. Основные цели участвуют в оптимизации и попадают в столбец «Конверсии», дополнительные - только в отчеты для наблюдения. Здесь чаще всего ломают статистику: делают основными и заявку, и клик по номеру, и просмотр страницы контактов, после чего автостратегия начинает гнать дешевые микродействия. Пороговые числа конверсий, при которых стратегии вообще запускаются, разобраны в материале про выбор стратегии ставок.

Как это выглядит на практике: аккаунт стоматологии, где основными целями стояли клик по кнопке контактов, две минуты на странице и прокрутка на треть. Отчет показывал десятки конверсий в неделю, записей на прием за тот же период - две, при расходе около $3 000. Стратегия честно оптимизировалась на то, что ей назвали результатом, и находила людей, которые скроллят страницу.

Настройки действия-конверсии: ценность, способ подсчета, окно конверсии и модель атрибуции

Диспетчер тегов: когда нужен контейнер и как он собирается

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

Связка собирается из трех частей:

• Тег «Отслеживание конверсий Google Ads». В него подставляются идентификатор конверсии и ярлык конверсии - оба значения берутся в интерфейсе Google Ads, в карточке действия, в блоке установки вручную.
• Тег «Связыватель конверсий». Отвечает за сохранение параметров клика в cookie на всех страницах. Ставится с триггером на все просмотры.
• Триггер. Условие срабатывания тега конверсии: просмотр страницы с определенным адресом, клик по элементу, отправка формы, событие из уровня данных.

Самый устойчивый триггер - просмотр страницы благодарности с уникальным адресом. Он срабатывает только после успешной отправки, его сложно поймать случайно. Если форма отправляется без перезагрузки, надежнее договориться с разработчиком о событии в уровне данных: скрипт формы отправляет событие после ответа сервера, триггер ловит его. Клик по кнопке - последний вариант, к которому прибегают, когда первые два недоступны.

Тег конверсии в контейнере GTM: идентификатор и ярлык из Google Ads плюс триггер срабатывания

Перед публикацией контейнер прогоняется в режиме предварительного просмотра: открываете сайт через режим отладки, проходите форму и смотрите, сработал ли тег конверсии и один ли раз. Частая находка на этом шаге - двойное срабатывание: тег стоит и в коде сайта, и в контейнере. В отчете это выглядит как ровно удвоенное число заявок.

Импорт конверсий из GA4: когда это правильный путь

Импорт устроен просто: аккаунты связываются в администраторе GA4, нужные события помечаются в аналитике как ключевые, дальше в Google Ads создается действие с источником «Импорт» и выбирается ресурс GA4 со списком событий.

Импорт из GA4: список ключевых событий ресурса, из которого выбираются нужные

Путь оправдан, когда аналитика уже собрана и события в ней проверены: не нужно второй раз размечать то же самое, а вместе с событием приезжают параметры электронной торговли. Отдельная выгода - единая логика событий для отчетов и для рекламы.

Отказываться от импорта стоит в трех случаях. Импортированные конверсии приезжают с задержкой: новому событию в аналитике нужно от суток до двух, чтобы стать доступным в рекламном кабинете, и при коротких тестах это заметно. Расширенные конверсии на импортированных событиях настраиваются иначе, чем на собственном теге, - об этом отдельный материал про расширенные конверсии. И главное: событие, размеченное в GA4 неаккуратно, приедет в рекламу ровно таким же неаккуратным.

Для магазина у собственного тега есть измеримое преимущество: он атрибутирует на 10-15% больше покупок, чем то же событие, импортированное из аналитики. Разница в том, что аналитика распределяет конверсию между каналами, а тег фиксирует ее целиком на клик по объявлению. Отсюда практическое правило: основным для e-com держат нативный тег покупки, импорт из GA4 оставляют дополнительным для сверки.

Переключать источник резко не стоит. Новый тег ставится дополнительным, месяц работает параллельно со старым, цифры сверяются - и только потом основным становится он. Мгновенная замена основного действия обнуляет накопленную стратегией статистику.

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

Данные из аналитики и данные Google Ads не совпадают по определению, и это нормально. GA4 распределяет конверсию между каналами по своей модели и относит ее к дате события. Google Ads считает только свои клики и относит конверсию к дате клика. Заявка, пришедшая во вторник после клика в пятницу, в аналитике встанет на вторник, а в рекламном кабинете - на пятницу. Отчеты за одну и ту же неделю разойдутся, хотя обе системы работают верно.

Отслеживание звонков: что осталось в 2026 году

Звонки собираются из трех разных источников, и настраиваются они по-разному.

Звонок по объекту звонка в объявлении. Номер отображается прямо в выдаче, пользователь нажимает и звонит. Конверсия фиксируется на стороне Google, если звонок идет через номер для переадресации. Здесь же важное изменение: с февраля 2026 года создать новое объявление только с номером телефона нельзя, а с февраля 2027 существующие перестанут получать показы. Номера переносятся в объекты звонков внутри адаптивных поисковых объявлений.

Звонок с сайта по номеру Google для переадресации. На страницы ставится специальный фрагмент, он подменяет ваш номер на подменный, и разговор попадает в отчеты вместе с длительностью и статусом. Ограничение серьезное: подменные номера Google работают в ограниченном списке стран. В Казахстане, Узбекистане и большинстве стран СНГ такой опции нет, поэтому здесь используют сторонний коллтрекинг, а результаты возвращают в кабинет как Импорт офлайн-конверсий.

Клик по номеру телефона на мобильном сайте. Ловится триггером на ссылку tel: в диспетчере тегов. Считается кликом, а не разговором: человек мог нажать и передумать. Делать такое событие основной целью не стоит - как минимум потому, что автостратегия начнет закупать нажатия, а не звонки.

Отдельная настройка - минимальная длительность разговора, после которой звонок засчитывается конверсией. Рабочий диапазон - от 30 до 60 секунд: разговор короче 30 секунд редко означает обращение, чаще это ошибочный набор или вопрос про часы работы. Там, где вопрос решается за полминуты, длинный порог срежет обращения, а в сложных услугах короткий зачтет мусор.

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

Практическое наблюдение: коллтрекинг регулярно расходится с CRM. Часть звонков теряется на переадресации, часть менеджеры не заводят в систему, обратный звонок дублируется как два обращения. Сверять эти два источника раз в месяц дешевле, чем однажды обнаружить, что стратегия полгода училась на завышенных цифрах.

Обращения в мессенджерах: где трекинг слепнет

В Казахстане и Кыргызстане поток обращений идет в WhatsApp, в Узбекистане - в Telegram. Форма на сайте при этом собирает меньшую часть заявок, а стандартный тег видит только ее.

Клик по кнопке мессенджера ловится триггером на ссылку, и на этом точность заканчивается. Переход засчитан, диалог - нет: человек открыл приложение, посмотрел и закрыл. Кабинет в такой схеме показывает завышенную цифру, и держать этот клик основной целью означает учить автостратегию закупать нажатия.

Что с этим делают:

• Первые недели сверяют вручную: переходы в кабинете против диалогов у менеджеров за ту же неделю. Полученный коэффициент показывает, во сколько раз кабинет завышает, и дальше на него делают поправку.
• Клик по кнопке переводят в дополнительные действия, а основным делают состоявшийся диалог, выгруженный из CRM.
• Разделяют обращения на два действия-конверсии: с ответом клиента и без ответа. Первое кормит стратегию, второе остается для наблюдения и показывает долю пустых переходов.

Есть и прямой конфликт: динамические номера коллтрекинга и WhatsApp плохо уживаются. Клиент звонит на подменный номер, менеджер перезванивает с рабочего, и человек не узнает входящий. Там, где основной канал общения - мессенджер, подмену номеров обычно отключают.

Офлайн-конверсии: как довести сделку до кабинета

Заявка и деньги - разные события. Пока в кабинет уходят только заявки, автостратегия оптимизируется на количество форм и честно приносит их дешевле. Качество при этом падает, потому что за качество ее никто не просил.

Порядок передачи офлайн-результата:

• В аккаунте включена автоматическая пометка, ссылки получают параметр GCLID.
• На сайте скрипт забирает GCLID из адреса и кладет в скрытое поле формы.
• Значение уходит в CRM вместе с заявкой и хранится в карточке сделки.
• Когда сделка меняет статус, из CRM формируется выгрузка: идентификатор клика, название конверсии, дата и время, сумма, валюта.
• Файл загружается в Google Ads в действие с источником «Импорт» и подтипом для данных из CRM.

Загрузка офлайн-конверсий: файл с идентификаторами кликов, датами и суммами сделок

Загружать можно вручную файлом, через таблицу по расписанию, по SFTP или через API - последний вариант закрывают готовые коннекторы к популярным CRM. Расписание удобнее ручной загрузки: выгрузка раз в сутки убирает человеческий фактор. Отдельный путь - подключение CRM через центр данных в самом кабинете: связка настраивается без кода, дальше сделки уезжают автоматически.

Полезно передавать не один статус, а цепочку: заявка, квалифицированный лид, закрытая сделка. Каждый статус заводится отдельным действием-конверсией, и система видит, как выглядит путь от формы до денег. Ценность при этом считается как вероятность закрытия, умноженная на сумму сделки: заявка с шансом 10% и чеком $5 000 приезжает с ценностью $500.

Важное правило про загрузку через таблицы, которого нет в справке: на каждое действие-конверсию нужна своя отдельная таблица. Если сложить в один файл строки для двух разных действий, все конверсии припишутся первому, и счетчики станут одинаковыми. Ловится это поздно, потому что загрузка проходит без ошибок.

Ограничения, о которые спотыкаются:

• Конверсия загружается не раньше чем через несколько часов после клика - слишком свежие идентификаторы система отклонит.
• Идентификатор клика старше 90 дней не принимается, при длинном цикле сделки часть данных теряется.
• Окно конверсии в настройках действия должно перекрывать цикл сделки, иначе загрузка пройдет, а конверсия не зачтется.
• Даты в файле нужны с указанием часового пояса, иначе строки отклоняются пачками.

Передача рвется обычно не в Google Ads, а до него: GCLID теряется на редиректе, форма стоит в стороннем сервисе на отдельном домене, поле в CRM обрезает длинную строку, менеджер заводит сделку руками и поле остается пустым. Проверять стоит с конца - от карточки сделки в CRM, а не от отчета в кабинете.

Когда GCLID собрать невозможно, остается вариант с передачей хешированных контактных данных: конверсия сопоставляется по адресу почты или телефону. Механика разобрана в статье про расширенные конверсии.

Порядок внедрения для нового аккаунта

Последовательность, которая экономит время на переделках.

• Проверить автоматическую пометку. Один переключатель в настройках аккаунта, без него остальное бессмысленно.
• Составить список событий. Заявка, заказ, звонок, запись, оплата - и сразу отметить, что станет основной целью, а что уйдет в наблюдение.
• Выбрать способ фиксации под каждое событие. Страница благодарности, событие уровня данных, импорт из аналитики, коллтрекинг, выгрузка из CRM.
• Поставить тег или контейнер и убедиться, что он отдается на всех страницах, включая экраны подтверждения.
• Создать действия-конверсии и заполнить настройки. Ценность, способ подсчета, окно, тип цели. Пустые поля всплывут позже, в отчетах.
• Сделать тестовую конверсию по каждому событию. Ровно столько тестов, сколько событий: выборочная проверка ничего не подтверждает.
• Сверить объемы через неделю - конверсии в кабинете против обращений в CRM.
• Подключить офлайн-конверсии, когда наберется история закрытых сделок. Раньше передавать в кабинет нечего.

Для агентства с управляющим аккаунтом порядок чуть другой: действие-конверсия создается на уровне управляющего аккаунта и расшаривается на клиентские. Так одинаковые события считаются по одной логике во всех аккаунтах, а не собираются заново каждым специалистом по-своему.

С аккаунтами, которые достались по наследству, есть еще один шаг. До правок выгрузите текущие настройки действий-конверсий и запишите цифры, которые кабинет показывал раньше. После чистки дублей статистика упадет, иногда вдвое, и без этой записи объяснить падение клиенту будет нечем.

Как проверить, что данные доходят

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

Тестовая конверсия. Пройдите путь клиента целиком: перейдите на сайт по объявлению, заполните форму, дойдите до экрана благодарности. Смотрите в Tag Assistant, что событие ушло, и проверьте, появилась ли заявка в CRM. Цифры в кабинете при этом появятся не сразу: отображение конверсий идет с задержкой в несколько часов, а импортированные события приезжают еще позже.

Статусы действий-конверсий. В списке у каждой записи есть статус. «Записывает конверсии» - данные идут. «Нет последних конверсий» - тег найден, событий за последнюю неделю не было. «Не проверено» или «Тег неактивен» - система не видит ни тега, ни данных, и это первое, что чинят. Исключение одно: действие, созданное под импорт из CRM, висит неактивным до первой загрузки. Это ожидаемое поведение, чинить нечего.

Диагностика показывает, видит ли Google тег на сайте и доходят ли конверсии

Сверка объемов. Возьмите неделю и сравните число конверсий в кабинете с числом заявок в CRM за тот же период с поправкой на дату клика. Расхождение в пределах десятой части объема - обычная картина. Разница в полтора-два раза означает поломку: либо дубли, либо потерянные события.

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

Есть и грубый тест на здоровье учета: если за десять секунд не получается назвать, сколько клиентов принесла реклама в прошлом месяце, учет не работает независимо от того, что показывает столбец «Конверсии».

Доверять цифрам как основе для решений можно, когда накопился объем. Неделя данных и десяток конверсий - недостаточно для выводов, на таком объеме случайные колебания перекрывают разницу между кампаниями.

Почему кабинет и аналитика показывают разное

Расхождение между системами - норма, вопрос в его размере и причине. Перед сравнением стоит учесть разницу между моделями атрибуции.

• Разные даты. Google Ads относит конверсию к дате клика, аналитика - к дате самого события. На дистанции суммы сходятся, по дням расходятся всегда.
• Разные каналы. Кабинет считает только конверсии после кликов по объявлениям. Аналитика распределяет результат между всеми источниками, включая переходы из поиска и прямые заходы.
• Разная атрибуция. Модель на основе данных дробит ценность между взаимодействиями, из-за чего появляются нецелые значения.
• Разный способ подсчета. «Каждая» против «Одной» дает разные суммы на одном и том же наборе событий.
• Согласие и блокировщики. Часть событий не отправляется вообще: пользователь не дал согласие на сбор данных или включил блокировщик. Для трафика из Европы это регулируется режимом согласия, о котором есть отдельный материал.
• Дубли. Тег в коде плюс тег в контейнере, импорт из аналитики поверх собственного тега - самая частая причина расхождения в большую сторону.

Ошибки, которые чаще всего портят статистику

• Выключена автоматическая пометка - GCLID не добавляется, импорт и звонки не работают.
• Фрагмент события стоит на всех страницах, а не на странице подтверждения.
• Конверсия срабатывает по клику на кнопку, без проверки успешной отправки формы.
• Одно событие настроено дважды - тегом и импортом, обе записи основные.
• Все действия помечены основными, включая просмотр контактов и клик по номеру.
• Для лидов выбран способ подсчета «Каждая», один клиент дает три конверсии.
• Окно конверсии в 30 дней при цикле сделки в два месяца.
• Ценность конверсии не заполнена, стратегии по доле расходов запускать не на чем.
• Тег стоит на сайте, но заявки идут через мессенджер, и переход туда никак не фиксируется.
• Контейнер настроен, но версия не опубликована - в режиме отладки все работает, а на сайте нет.
• Основных действий несколько на одну кампанию: система получает противоречивые сигналы и выбирает то, что дается дешевле.
• Цель по умолчанию на уровне аккаунта стоит на микродействии, и все новые кампании наследуют ее автоматически.
• В магазине основной целью назначено добавление в корзину вместо покупки.