Корректировки конверсий в Google Ads 2026: возвраты, отмены и отзыв мусорных лидов

Магазин отчитался о 400 продажах за месяц. Через три недели 70 из них вернули, ещё 20 отменили до отгрузки. В Google Ads по-прежнему висят 400 конверсий и полный оборот, потому что корректировки конверсий никто не загружал — и именно на этих цифрах Smart Bidding продолжает искать «похожих» покупателей. Алгоритм старательно оптимизируется под аудиторию, которая делает возвраты.

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

Механизм, который это чинит, называется корректировки конверсий. В этом материале — какие типы бывают, что нужно для загрузки, какие сроки действуют, как это меняет ставки и какие ошибки чаще всего превращают полезную процедуру в потерю данных.

Что такое корректировки конверсий и чем они не являются

Корректировка — это сообщение системе о том, что уже зафиксированная конверсия изменилась постфактум. Есть два основных типа:

Тип	Что делает	Влияет на количество	Влияет на ценность	Типичный повод
Restate (переоценка)	Меняет ценность конверсии	Нет	Да	Частичный возврат, апсейл, скидка, уточнённая маржа
Retract (отзыв)	Обнуляет конверсию	Да	Да (в 0)	Полный возврат, отмена, мусорный лид, фрод

Отдельно стоит третий механизм — enhancement, дополнение конверсии хешированными данными пользователя. Это уже территория расширенных конверсий, и она решает другую задачу — не «конверсия изменилась», а «конверсию нужно точнее сматчить». Как это устроено, разбирали в материале про расширенные конверсии на first-party данных.

Чем корректировки не являются:

• Это не способ «почистить статистику» задним числом ради красивого отчёта — данные уходят в обучение стратегий, и вранье в обе стороны ударит по ставкам.
• Это не дедупликация. Если одна покупка засчиталась дважды из-за двух тегов, лечится это на уровне тегирования — см. разбор дублей конверсий и переучёта.
• Это не замена импорту офлайн-конверсий. Импорт добавляет новые события; корректировка меняет существующие. Оба механизма нужны вместе — базовый импорт разобран в гайде по импорту офлайн-конверсий в Smart Bidding.

Что нужно, чтобы корректировки вообще работали

Здесь почти вся боль возникает до первой загрузки, а не после. Требования жёсткие:

1. Идентификатор транзакции (order ID) в момент конверсии. Онлайн-конверсию можно корректировать, только если при её фиксации был передан уникальный transaction/order ID. Не передали — корректировать нечего, система не поймёт, о какой из тысячи покупок речь.
2. Либо связка GCLID + время конверсии, если order ID не использовался. Работает, но хрупко: нужно точное время, а по кликам из некоторых сред идентификатор может отсутствовать.
3. Точное название действия-конверсии. Оно должно совпадать символ в символ с тем, что в аккаунте.
4. Действие-конверсия должно быть допустимым. Не все типы конверсий принимают корректировки; проще всего это работает для покупок и лидов с идентификатором заказа.

Практическое правило: если сегодня вы не передаёте order ID в конверсию покупки — начните с этого. Без идентификатора вся дальнейшая механика корректировок недоступна, и никакой обходной путь её не заменит.

Где взять order ID в реальной жизни

• E-commerce: номер заказа из CMS передаётся в параметре transaction_id тега покупки. В большинстве платформ это делается штатно.
• Лидогенерация: генерируйте собственный ID заявки на стороне сайта или CRM (например, UUID) и передавайте его и в тег, и в карточку лида.
• Звонки: ID звонка из колл-трекинга; связку описывали в разборе колл-трекинга и звонковых кампаний.

Сроки: почему «через полгода» уже поздно

Корректировки живут в ограниченном временном окне, и оно устроено с двух сторон:

• Снизу. Загружать корректировку сразу после конверсии не стоит — событию нужно время попасть в систему. Практика: выдерживать несколько часов, безопаснее — сутки.
• Сверху. Слишком старые конверсии корректировать нельзя. Общий ориентир для стандартных действий — порядка двух-трёх месяцев с момента конверсии; для отдельных типов кампаний окна свои и заметно короче.

Отсюда организационный вывод: цикл возвратов должен помещаться в окно корректировок. Если магазин принимает возвраты 90 дней, а корректировки принимаются 55, часть возвратов вы физически не сможете отразить. В такой ситуации честнее не тянуть до конца срока возврата, а корректировать по факту оформления возврата в CRM, ежедневно.

Необратимость

Retract — операция в одну сторону. Отозванную конверсию нельзя «вернуть» новой корректировкой; единственный путь — загрузить её как новое событие с другим уникальным идентификатором. Поэтому автоматический отзыв по сырому признаку («лид без ответа за 24 часа») — плохая идея: половина таких лидов перезванивает на третий день.

Как загружать: три пути

Способ	Как выглядит	Кому подходит
Ручная загрузка файла	Google Ads → Цели → Загрузки → шаблон корректировок, CSV/Google Sheets	До нескольких сотен строк в неделю, старт
Расписание из Google Sheets / URL	Тот же шаблон, но с автообновлением по расписанию	Средний объём, есть кто ведёт таблицу выгрузкой из CRM
Google Ads API / Data Manager	uploadConversionAdjustments или коннектор данных	Постоянный поток, интеграция с CRM/ERP

Начинать почти всегда стоит с шаблона: он показывает, какие колонки система реально ждёт (идентификатор, название действия, время конверсии, время корректировки, тип, новая ценность и валюта). После того как ручная загрузка стабильно проходит без ошибок, тот же формат переносится в автоматизацию. Инфраструктурная часть — как заводить источники данных без трёх параллельных пайплайнов — разобрана в материале про Data Manager и данные первой стороны.

Мини-схема потока для e-commerce

1. Заказ оформлен → тег покупки отправляет конверсию с transaction_id и ценностью по марже или обороту.
2. Заказ отменён до отгрузки → на следующий день выгрузка формирует строку retract с этим же ID.
3. Частичный возврат → строка restate с новой ценностью (оставшаяся сумма).
4. Файл уходит в аккаунт по расписанию; отчёт о загрузке проверяется на ошибки.
5. Раз в неделю сверяется: количество корректировок против количества возвратов в CRM.

Что происходит со ставками

Корректировки — не косметика в отчётах, они меняют то, чему учится алгоритм:

• Retract влияет и на tCPA, и на tROAS. Конверсия исчезает из истории, а значит меняется и оценка вероятности конверсии по сегментам, где были отзывы.
• Restate влияет только на стратегии по ценности — tROAS и максимизацию ценности. Для tCPA переоценка ценности нейтральна.
• Данные пересобираются задним числом. Отчёты за прошлые дни изменятся: вчерашний ROAS перестанет совпадать с тем, что вы видели вчера. Это нормально и связано с тем же эффектом, что описан в материале про окно конверсии и лаг конверсий.
• Массовый разовый отзыв — это шок для стратегии. Если вы за один день отзовёте три месяца мусорных лидов, алгоритм получит резкую переоценку истории. Лучше загрузить исторический массив частями за несколько дней и после этого не трогать таргеты неделю.

Корректировки против других способов передать качество

Корректировки — не единственный инструмент, и часто не первый. Сравнение:

Инструмент	Когда лучше	Ограничение
Корректировки (retract/restate)	Событие уже засчитано и изменилось: возврат, отмена, фрод	Нужен order ID и попадание в окно
Отдельные действия-конверсии по стадиям	Есть чёткие этапы: лид → квалификация → сделка	Требует дисциплины в CRM и настройке первичных/вторичных целей
Правила ценности конверсии	Ценность заранее предсказуема по гео/устройству/аудитории	Не отражает фактический исход конкретной сделки
Импорт офлайн-конверсий	Реальная продажа происходит позже и вне сайта	Нужен сохранённый GCLID и работающая связка с CRM

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

Семь ошибок, которые убивают эффект

1. Нет order ID. Самая частая: корректировки задумали, а идентификатор в теге так и не появился.
2. Время конверсии в неверном часовом поясе. Строка не сматчится, и загрузка отдаст ошибку «конверсия не найдена».
3. Название действия с опечаткой или из другого аккаунта. Проверяется копипастом из интерфейса, а не по памяти.
4. Загрузка через минуты после конверсии. Событие ещё не доехало — корректировка отвалится.
5. Автоотзыв по слабому признаку. «Не дозвонились с первого раза» ≠ мусорный лид. Отзывать стоит только то, что подтверждено.
6. Разные ID в теге и в CRM. Классика: в теге ID заказа магазина, в выгрузке — внутренний ID сделки. Совпадать должно точь-в-точь.
7. Никто не читает отчёт о загрузке. Файл ушёл, половина строк отклонена, все считают, что данные в системе.

Как проверить, что всё работает

• Отчёт о загрузке (Цели → Загрузки) — процент принятых строк должен быть близок к 100%; каждая ошибка в отчёте расшифрована.
• Столбцы «Все конв.» и «Ценность всех конв.» за прошлый период должны меняться после загрузки — если цифры застыли, корректировки не применились.
• Сверка с CRM: количество отзывов за неделю против количества отмен/возвратов. Расхождение больше 5–10% — повод искать ошибку в матчинге.
• Если конверсии в принципе ведут себя странно, начните не с корректировок, а с базовой диагностики — она собрана в материале «Конверсии пропали: диагностика за 30 минут».

Шаблон файла: какие колонки и чем их заполнять

Формат загрузки жёсткий, и большая часть отклонённых строк — это ошибки на уровне колонок, а не логики. Минимальный набор:

Колонка	Что писать	Частая ошибка
Order ID / GCLID	Идентификатор из исходной конверсии	Взят ID сделки из CRM вместо ID заказа из тега
Conversion Name	Точное имя действия-конверсии	Лишний пробел, другое имя из соседнего аккаунта
Conversion Time	Время исходной конверсии с таймзоной	Локальное время без пояса или пояс аккаунта ≠ пояс выгрузки
Adjustment Time	Время формирования корректировки	Стоит раньше времени конверсии — строка отклоняется
Adjustment Type	RESTATEMENT или RETRACTION	Русские значения или произвольный текст
Adjusted Value	Новая ценность (только для restate)	Заполнена у retraction или указана в другой валюте
Currency	Код валюты по ISO	Отличается от валюты аккаунта без указания кода

Совет по процессу: держите выгрузку в одном источнике (SQL-запрос или отчёт CRM), а не собирайте руками. Ручная сборка почти гарантированно даёт расхождение форматов даты и времени между неделями.

Как считать ROAS, когда есть возвраты

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

• Валовый ROAS — то, что показывал интерфейс раньше: оборот по всем засчитанным конверсиям на расход. Завышен ровно на долю возвратов.
• Чистый ROAS — после корректировок: возвраты вычтены, отменённые сделки обнулены.
• Маржинальный ROAS — если вы передаёте в ценность не оборот, а маржу. Самая честная метрика для принятия решений по ставкам.

Пример на цифрах. Расход $10 000, зафиксированный оборот $40 000 — валовый ROAS 4,0. Возвращено 18% оборота: чистый оборот $32 800, чистый ROAS 3,28. Средняя маржа 35%: маржинальная ценность $11 480, маржинальный ROAS 1,15. Три разные картины одного и того же месяца — и решение «масштабировать или резать» в каждой из них своё.

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

Организационная часть: кто, когда и с какой регулярностью

Технически корректировки — это один файл раз в сутки. Ломается процесс всегда на человеческом слое, поэтому имеет смысл зафиксировать три вещи:

1. Владелец. Один человек отвечает за то, что файл ушёл и был принят. Не «отдел маркетинга», а конкретный сотрудник.
2. Регулярность. Ежедневная выгрузка лучше еженедельной: она держит вас далеко от верхней границы окна и делает объём каждой загрузки маленьким.
3. Контроль качества. Раз в неделю — сверка количества строк с числом возвратов и отмен в учётной системе, раз в месяц — проверка, что доля отклонённых строк близка к нулю.

Отдельно проговорите правило отзыва для лидов: что именно считается мусором. Хороший критерий — проверяемый и бинарный: неверный номер после трёх попыток дозвона, дубль существующего клиента, явный отказ, признанный фрод. Всё остальное — не повод обнулять конверсию.

Автоматизация через API: что важно знать до интеграции

Когда объём перерастает таблицы, корректировки переносят в Google Ads API (метод uploadConversionAdjustments) или в коннектор данных. Разработчику стоит заранее объяснить четыре вещи, которые не очевидны из документации:

• Частичный успех — норма. Батч не отклоняется целиком: часть строк применяется, часть возвращает ошибку. Обрабатывать нужно ответ построчно, иначе вы никогда не узнаете, что 12% корректировок не доехали.
• Повторная отправка той же корректировки безопасна не всегда. Retract идемпотентен по смыслу (второй отзыв уже отозванной конверсии просто вернёт ошибку), а вот серия restate с разными значениями перезапишет ценность последним значением — следите за порядком.
• Размер батча. Разумный ориентир — несколько тысяч строк за вызов; гигантские батчи дольше обрабатываются и хуже диагностируются при ошибках.
• Логи обязательны. Храните у себя, что и когда отправлено, с ответом API. Без этого невозможно ответить на вопрос «почему конверсия за 14 марта выглядит вот так».

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

Как объяснить изменение цифр заказчику

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

1. Продажи не изменились — изменилось то, какие из них учитываются. Сверьте цифры с бухгалтерией: чистый оборот совпадёт.
2. Решения станут дешевле. Раньше бюджет уходил на сегменты с высоким процентом возвратов, потому что в отчёте они выглядели лучшими. Теперь это видно.
3. Целевые показатели пересчитываются. Старый tROAS был выставлен по завышенным данным; новый должен быть ниже на долю возвратов, иначе стратегия зажмёт расход.

Кому это даёт больше всего

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

Если реклама у вас идёт через агентские кабинеты и вы хотите одинаково корректно вести данные во всех аккаунтах, разумно сразу закладывать единый формат ID и общий шаблон выгрузки — это часть той же инфраструктурной гигиены, что и аренда трастовых аккаунтов Google Ads с прозрачной структурой доступов. Про финансовую сторону непрерывности — в свежем разборе биллинга и порогов списаний Google Ads, а про то, как показывать вернувшимся пользователям товар, от которого они отказались, — в материале о динамическом ремаркетинге на фидах.

FAQ

Чем retract отличается от restate?

Retract полностью отзывает конверсию: она перестаёт считаться, ценность обнуляется, меняется и количество, и ценность. Restate оставляет конверсию, но меняет её ценность — количество не трогается.

Можно ли корректировать конверсии без order ID?

Только через связку GCLID + точное время конверсии, и это менее надёжно. Для регулярной работы правильный путь — передавать уникальный идентификатор транзакции в момент конверсии.

Через сколько после конверсии можно загружать корректировку?

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

Как долго конверсию ещё можно скорректировать?

Окно ограничено — ориентир для стандартных действий порядка двух-трёх месяцев с момента конверсии, у отдельных типов кампаний оно короче. Проверяйте актуальные лимиты для своего типа конверсии.

Можно ли отменить ошибочный отзыв?

Нет. Отозванную конверсию нельзя восстановить корректировкой. Единственный вариант — загрузить событие заново как новую конверсию с другим уникальным идентификатором.

Влияют ли корректировки на обучение Smart Bidding?

Да. Retract меняет данные для tCPA и tROAS, restate — только для стратегий по ценности. Массовая разовая загрузка исторических корректировок может заметно встряхнуть стратегию.

Почему отчёты за прошлые дни меняются после загрузки?

Корректировки применяются к дате исходной конверсии, а не к дате загрузки. Поэтому исторические строки пересчитываются — это ожидаемое поведение.

Стоит ли отзывать все неквалифицированные лиды подряд?

Нет. Отзывать нужно только подтверждённый мусор: неверные контакты, фрод, дубли, явные отказы. Слабые признаки вроде «не взяли трубку с первого раза» ведут к потере валидных данных.

Что делать, если возвраты приходят позже окна корректировок?

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

Нужны ли корректировки, если я уже импортирую офлайн-конверсии?

Да, это разные механизмы. Импорт добавляет новые события, корректировка меняет уже засчитанные. В связке с возвратами нужны оба.

Как понять, что корректировки реально применились?

Смотрите отчёт о загрузке (процент принятых строк) и динамику исторических столбцов конверсий — они должны пересчитаться. Плюс сверка количества корректировок с числом возвратов в CRM.

Влияют ли корректировки на дубли конверсий?

Нет. Дубли — это проблема тегирования и дедупликации, её нужно решать на стороне тегов, а не задним числом через корректировки.