Одна из причин – различие между количеством конверсий и их стоимостью. Data Manager API – интерфейс программной передачи событий в рекламные системы Google. Через него можно скорректировать денежную ценность события. Однако, согласно текущему руководству Google по переходу на этот API, полноценное снятие конверсии с обнулением её количества не поддерживается. Если интеграция отправляет нулевую стоимость, количество остаётся прежним.
Это не означает, что любой отменённый заказ обязательно завышает отчёт. Сначала нужно определить способ загрузки, выбранное действие-конверсию и то, какой бизнес-результат оно обозначает.
Ниже – порядок проверки для маркетолога, владельца магазина и разработчика интеграции. Он касается прежде всего передачи CRM-событий через Data Manager API. Правила файловых загрузок, импорта из GA4 и других коннекторов нельзя автоматически приравнивать к этому маршруту.
Когда стоит проверять отмены и возвраты в Google Ads
Поводом может стать несколько наблюдений. В CRM растёт число отмен, а рекламных конверсий меньше не становится. Менеджер меняет стоимость сделки, но в рекламе сохраняется первоначальная сумма. После обновления коннектора количество событий скачком увеличивается без сопоставимого роста заказов.
По одним итоговым цифрам причину установить трудно. Один и тот же заказ может пройти создание, оплату, изменение состава, частичный возврат и отмену. Для каждого перехода интеграция должна понимать, что произошло – появилась новая продажа или изменился уже переданный результат.
Если расхождения возникают ещё между формой сайта, GA4 и CRM, полезно сначала разобрать проверку отслеживания конверсий между четырьмя системами. Здесь разберём более узкую задачу – жизненный цикл уже переданного заказа.
Сначала определите маршрут передачи конверсии
Попросите разработчика или поставщика коннектора описать путь данных. Формулировки «у нас серверная аналитика» или «CRM подключена к Google» недостаточно.
| Маршрут | Что требуется выяснить |
|---|---|
| CRM отправляет события через Data Manager API | Как задаются получатель, действие-конверсия, идентификатор заказа и корректировки |
| Конверсии поступают через Google Ads API | Какие сервисы загрузки и корректировок использует интеграция и доступна ли соответствующая функция |
| Данные загружаются файлом или по расписанию | Какой шаблон применяется и как обрабатываются изменение стоимости и полное снятие конверсии |
| Покупка фиксируется тегом сайта или импортируется из GA4 | Каким отдельным способом возврат должен попасть именно в Google Ads |
Действие-конверсия – отдельная настройка Google Ads, которая определяет, какой результат учитывается, например покупка или подтверждённая заявка.
Запишите название и ID действия-конверсии, аккаунт-владелец, событие-основание и дату последней проверки. Если подключений несколько, составьте отдельную строку для каждого.
Изменение статуса в CRM само по себе не меняет Google Ads. Для этого должен существовать настроенный и поддерживаемый маршрут корректировки.
Количество конверсий и стоимость конверсий решают разные задачи
Количество отвечает на вопрос, сколько целевых событий система учла. Стоимость – какую денежную ценность этим событиям присвоили. Одна конверсия может стоить 100 евро, после частичного возврата – 75 евро, а после полного – ноль.
При проверке отмен важно отдельно посмотреть оба показателя. Если стоимость изменилась, это ещё не подтверждает снятие события из количества.
Различие имеет значение и для автоматических стратегий. Корректировка денежной ценности меняет данные, используемые при оптимизации по ценности. Она не заменяет уменьшение количества для задач, где результат оценивают по числу конверсий.
Текущее руководство Google разделяет два механизма. Корректировка стоимости меняет ценность существующей конверсии. Полное снятие убирает её из количества и стоимости.
Для Data Manager API руководство прямо указывает отсутствие поддержки полного снятия. Поэтому интеграция должна отдельно показывать, что произошло с отменой – была изменена только сумма или действительно применён другой поддерживаемый способ исключения события.
В справке о файловых корректировках Google описывает тип RETRACT для полного снятия конверсии. Там же есть собственные правила для нулевого значения. Это не основание ожидать такого же поведения от Data Manager API.
Если требуется убрать отменённые заказы именно из количества, нужно проверить поддерживаемую процедуру для конкретного типа конверсии. Иногда для этого рассматривают отдельную загрузку корректировок. Применимость подтверждают на контрольной записи, с её исходным идентификатором и действием-конверсией.
Нельзя считать проблему решённой только потому, что коннектор отправил значение 0.
Как два заказа меняют оценку рекламы
Рассмотрим условный пример. Это иллюстрация расчёта, а не статистика клиентского проекта.
В выбранной группе два заказа полностью отнесены к рекламе. Каждый учитывается отдельной конверсией. Первый стоит 100 евро, второй – 200 евро. Позже по первому возвращают 25 евро, второй полностью отменяют.
Предположим, интеграция через Data Manager API успешно корректирует стоимость, но не снимает конверсии из количества.
| Состояние данных | Количество конверсий | Суммарная стоимость |
|---|---|---|
| Переданы два исходных заказа | 2 | 300 евро |
| По первому заказу учтён возврат 25 евро | 2 | 275 евро |
| Стоимость отменённого второго заказа обнулена | 2 | 75 евро |
Выберите состояние двух заказов. Расходы на рекламу во всех вариантах – 60 евро.
Условный расчёт
Оба заказа сохранены. Денежная ценность и количество пока описывают один и тот же результат.
Стоимость первого заказа уменьшилась на 25 евро. Количество учтённых событий осталось равным двум.
В Data Manager API скорректирована стоимость. Полное снятие из количества в этом маршруте не выполнено.
Это учебная модель из статьи. Она не подключена к рекламному аккаунту и не рассчитывает прибыль. Правила других способов корректировки проверяют отдельно.
После этих изменений в бизнес-учёте остаётся один заказ на 75 евро. В рекламном показателе количества – две конверсии.
При расходах 60 евро стоимость одной учтённой конверсии составит 30 евро. Расход на один сохранившийся заказ в этом примере – 60 евро. Это разные знаменатели.
ROAS после корректировки стоимости равен 75 / 60 = 1,25. Если возвраты вообще не передавались, он выглядел бы как 300 / 60 = 5. Прибыль по этим данным определить нельзя – неизвестны себестоимость и другие расходы.
Более широкий вопрос экономики разобран в материале почему заказы из рекламы не гарантируют окупаемость. При аудите передачи данных сначала проверяют корректность количества и стоимости, затем используют эти значения в финансовом анализе.
Как связать корректировку с исходным заказом
В Data Manager API сопоставление корректировки с существующей конверсией опирается на transactionId в пределах того же действия-конверсии.
Если ID совпал, запрос может обновить существующее событие. Если не совпал, он рассматривается как новая загрузка, которую Google попытается отнести к рекламному взаимодействию. Поэтому неправильный идентификатор способен превратить изменение суммы в новую конверсию.
Для проверяемого процесса нужны устойчивый ID бизнес-события и неизменный получатель. Номер клиента не подходит вместо номера заказа, если один клиент покупает несколько раз. ID карточки CRM тоже может оказаться неудобным, если карточки объединяют или пересоздают.
Согласуйте, какой идентификатор обозначает заказ, и храните соответствие между ним, записью CRM и отправленным transactionId.
Проверьте типичные точки разрыва.
Для Data Manager API принимающий operatingAccount должен соответствовать аккаунту Google Ads, которому принадлежит действие-конверсия. Настройки управляющего аккаунта не заменяют проверку фактического получателя.
Частичный возврат должен менять итоговую стоимость
Если заказ стоил 100 евро и покупателю вернули 25 евро, его новая стоимость – 75 евро. В корректировке передают согласованную итоговую ценность, а не сумму возврата 25 евро.
Сначала бизнес определяет смысл этой ценности. Она может соответствовать выручке по принятому правилу учёта или другому согласованному денежному показателю. Главное – применять одно определение последовательно, включая скидки, доставку и возвраты.
Порядок событий тоже важен. Внутри интеграции стоит хранить время изменения заказа и проверять актуальность состояния перед отправкой. Иначе более старое сообщение может вернуть в обработку сумму, которая уже изменилась. Стабильный transactionId решает задачу связи событий, но не заменяет контроль их содержания.
Не стоит отправлять нулевую стоимость только потому, что менеджер ещё не подтвердил заказ или спорная отмена находится на рассмотрении.
Общая справка Google Ads предупреждает, что после полного снятия или корректировки стоимости до нуля дальнейшие изменения могут игнорироваться без ошибки. Для конкретного маршрута нужно проверить применимые ограничения. Нулевое значение следует передавать как осмысленный результат, а не как техническую заглушку.
Успешный запрос ещё не означает учтённую конверсию
В Data Manager API есть первичная проверка запроса и последующая обработка данных. Эти этапы нельзя свести к одному сообщению «отправлено успешно».
Структурная ошибка или ошибка обязательного поля в одной записи может отклонить весь запрос до обработки. Ошибки необязательных полей могут давать предупреждения. Дополнительные проверки выполняются асинхронно и отражаются в диагностике.
| Этап | Что он подтверждает |
|---|---|
| В CRM изменился статус | Бизнес-событие записано в CRM |
| Интеграция сформировала отправку | Подготовлены данные для передачи |
| API принял запрос | Первичная проверка пройдена, получен requestId |
| Получена итоговая диагностика | Известен результат обработки по получателю |
| Проверены отчёты Google Ads | Оценено фактическое отражение данных с учётом задержки и атрибуции |
Режим validateOnly проверяет базовую корректность без загрузки данных. Он полезен перед отправкой, но не доказывает сопоставление с рекламой или изменение отчёта.
Для принятого рабочего запроса сохраняйте requestId. По нему запрашивают диагностику, в том числе статусы SUCCESS, PARTIAL_SUCCESS и FAILURE. Google рекомендует начинать проверку примерно через 30 минут; обработка отдельных запросов может занимать до 24 часов. Это ориентиры диагностики, а не обещание появления конверсии в отчёте через полчаса.
Таблица проверки отмен и возвратов из CRM
Сценарии ниже предназначены для контролируемой проверки интеграции. Предполагается, что исходная конверсия существует, тип события поддерживается, идентификаторы корректны, а применимые сроки не истекли. Отражение теста в отчёте дополнительно зависит от обработки и атрибуции.
Не отправляйте вымышленные продажи в рабочую цель ради проверки.
| Сценарий | Данные для проверки | Ожидаемое поведение |
|---|---|---|
| Новый подтверждённый заказ | Новый устойчивый ID, согласованная стоимость | Создаётся новое событие; отдельно проверяется его обработка |
| Повтор отправки того же заказа | Тот же ID, получатель и действие | Не появляется вторая самостоятельная продажа |
| Уменьшение суммы | Тот же ID, новая итоговая стоимость | Меняется стоимость существующей конверсии |
| Частичный возврат | Стоимость за вычетом принятого возврата | Возврат не становится новой покупкой |
| Полная отмена через Data Manager API | Проверка нулевой стоимости и количества отдельно | Обнуление суммы не принимается за подтверждение полного снятия |
| Изменение ID при корректировке | Сопоставление исходного и нового ID в журнале | Несовпадение обнаруживается до отправки как риск новой загрузки |
| Ошибка обязательного поля в пакете | Контрольный запрос с нарушением требований | Первичная проверка отклоняет запрос целиком |
| Запрос принят, но есть последующая ошибка | Сохранённый requestId и итоговая диагностика | Ошибка обработки обнаруживается, а не теряется за статусом «отправлено» |
Ошибочные записи и несовпадающие ID безопаснее проверять через валидацию, локальные проверки и согласованную тестовую схему. Рабочие изменения подтверждают на разрешённых реальных событиях с контролем последствий.
Как выбрать событие для оптимизации рекламы
Открытие страницы благодарности, получение заявки, оплата и сохранённая продажа – разные результаты. До настройки нужно согласовать, что именно должна получать рекламная система.
Для интернет-магазина это может быть подтверждённая покупка с дальнейшей корректировкой ценности. Для B2B – отдельный квалифицированный этап, который CRM фиксирует достаточно надёжно. Выбор зависит от процесса, задержек и доступности данных.
Проверьте основные и дополнительные действия-конверсии. Основные действия могут использоваться для назначения ставок, если соответствующая цель включена в оптимизацию кампании. Дополнительные обычно служат наблюдению. Исключение – пользовательские цели, в составе которых дополнительные действия тоже могут использоваться для оптимизации.
Одинаковый transactionId в разных действиях не нужно считать защитой от двойного учёта. Если сайт передаёт покупку в одно действие, а CRM – ту же покупку в другое, необходимо отдельно определить роль каждого сигнала.
Не меняйте цели только ради красивого совпадения итоговых цифр. Сначала подтвердите правильность передачи, затем согласуйте изменения оптимизации и период наблюдения.
Что записывать в журнал интеграции
Журнал нужен, чтобы восстановить путь конкретного события. Удобно хранить в нём следующие сведения.
| Группа данных | Содержание |
|---|---|
| Бизнес-событие | Устойчивый ID заказа, связь с CRM и текущий статус |
| Время | Когда событие произошло, когда изменилось и когда отправлено; часовой пояс |
| Получатель | Маршрут передачи, аккаунт-владелец и действие-конверсия |
| Стоимость | Предыдущая и новая согласованная ценность, валюта |
| Обработка | Причина отправки, повторная попытка, requestId, результат и предупреждения |
Состав полей можно расширять под систему. При этом не нужно переносить в общий журнал открытые контакты покупателей или секреты доступа. Для передачи пользовательских идентификаторов действуют отдельные требования к форматированию, защите и разрешённому использованию данных.
Наличие email или номера телефона в CRM не гарантирует рекламную атрибуцию. Идентификатор заказа связывает бизнес-события, а рекламные идентификаторы помогают сопоставлять их с рекламой – это разные задачи.
Как принять работу разработчика или поставщика коннектора
Результатом должен стать проверяемый процесс корректировок. При приёмке важно получить ответы на несколько вопросов.
Сверять нужно одинаковые группы событий и определения показателей. Общую сумму всех заказов CRM нельзя автоматически сравнивать с конверсиями, отнесёнными только к Google Ads.
Не стоит также обещать полную построчную выгрузку всех transactionId из любого отчёта рекламного кабинета. Связь событий проверяют по собственному журналу, доступной диагностике и контрольным результатам; уровень детализации зависит от источника и инструмента отчётности.
Что делать с уже накопленными расхождениями
Начните с ограниченного периода и сохраните исходное состояние данных. Разделите ошибки на группы – пропущенные корректировки, неверные ID, другой получатель, повторные события и различия методики подсчёта.
После этого исправьте логику новых отправок. Массовое повторение истории до устранения причины способно добавить новые ошибки.
Восстановление старых данных планируют отдельно. Проверяют поддерживаемый тип корректировки, доступные идентификаторы, сроки и влияние на отчёты и автоматические стратегии. Для полного снятия Google отдельно описывает файловые корректировки RETRACT. Возможность применить этот маршрут к вашему действию-конверсии нужно подтвердить.
Не создавайте новые номера заказов только для того, чтобы обойти ошибку сопоставления. Новое событие должно соответствовать согласованной бизнес-логике, а не маскировать проблему старого.
Частые вопросы об отменах заказов в Google Ads
Нет. Поведение зависит от способа корректировки. В руководстве Data Manager API указано, что стоимость можно изменить, а количество остаётся прежним. Правила файловых загрузок отличаются и проверяются отдельно.
Только если для неё настроен соответствующий сценарий. Сам факт изменения CRM-статуса не подтверждает ни отправку, ни успешную обработку корректировки.
Нет. Нужно сохранить связь с исходной конверсией и выполнить требования выбранного маршрута. В Data Manager API корректировка также должна содержать обязательные поля и подходящий идентификатор для обработки события.
Он выполняет базовую проверку запроса без загрузки данных. Сопоставление и отражение рабочего события требуют отдельной проверки.
Нет. В рассматриваемом сценарии это могут быть результаты, поступающие из CRM после рекламного взаимодействия – например, подтверждённая продажа или квалифицированная заявка.
Появятся более корректные исходные данные. Для расчёта прибыли дополнительно нужны себестоимость, расходы и единое правило финансового учёта.
Проверьте путь заказа до рекламного отчёта
Если отмены и возвраты не доходят до рекламной системы, оценка кампаний может опираться на устаревшие результаты. Начните с нескольких заказов и проследите каждый этап – изменение в CRM, отправку, диагностику и отражение стоимости и количества.