Как связать действия ИИ-агента с заказом и платежом, сверить GA4 и CRM, найти дубли и правильно учесть отмены и возвраты.
от события к подтверждённой оплате
Учёт заказов ИИ-агентов начинается с сопоставления конкретного заказа, событий аналитики и платежа. Событие purchase в GA4, успешная сделка в CRM и подтверждённая оплата могут отражать разные состояния. Чтобы посчитать результат, нужно связать записи по идентификаторам и проверить, что означает каждый статус.
Отдельно устанавливают участие агента: какие действия ему можно приписать и где управление могло перейти человеку. Это позволяет сохранить в отчёте настоящие заказы и не принять промежуточные действия за оплаченные покупки.
Разберём, как сверить GA4, систему магазина, CRM и платежи, найти дубли и пропуски, учесть отмены и возвраты. Проверка каталога, товарных данных и интерфейса разобрана в статье о готовности интернет-магазина к ИИ-агентам.
С чего начать сверку заказов ИИ-агентов
Выберите небольшой набор заказов с расхождениями и зафиксируйте время проверки. Для каждого найдите номер в системе магазина, связанную запись CRM, платёжную операцию и доступные события аналитики. Если какой-то записи нет, сначала выясните, должна ли она существовать по правилам вашей интеграции.
Заранее определите, какая система отвечает за каждое состояние. CMS и CRM могут обмениваться данными в обе стороны, поэтому первичную запись заказа выбирают по фактической архитектуре магазина. Платёж проверяют в системе, которая его обслуживает.
На узком экране таблицу можно прокрутить по горизонтали.
| Источник данных | Что проверяем | Что уточнить при расхождении |
|---|---|---|
| Система заказов магазина | Номер, состав, сумма и состояние заказа | Какая запись первичная, не создан ли заказ повторно |
| CRM | Связанный заказ, этап обработки и история изменений | Что означает успешный этап и откуда поступил статус оплаты |
| Платёжная система | Операция, её состояние, сумма и валюта | Связана ли она с нужным заказом, завершена ли оплата, были ли возвраты |
| GA4 | Полученные события электронной торговли | При каком условии отправляется purchase, какой передан transaction_id |
| Clarity или другое средство наблюдения | Записанные действия и признаки участия агента | Что именно классифицировано и есть ли связь с проверяемым заказом |
Сравнивайте одинаковую группу заказов на один момент времени. Число событий за день, число созданных заказов и число поступивших в этот день оплат могут отличаться: покупку могли оформить раньше, оплатить позже или отправить событие повторно. Само расхождение итогов ещё не объясняет причину.
Как установить участие агента в конкретном заказе
Источник перехода и исполнитель действия — разные признаки. Переход из ИИ-сервиса может совершить человек, а запрос робота к карточке товара не подтверждает последующую покупку. Классификация посещения как сеанса с агентом также не доказывает, что агент самостоятельно выполнил все действия.
Один User-Agent недостаточен: это значение сообщает клиент и его можно подменить. Когда доступна проверка идентичности сервиса, используйте предусмотренный механизм — например, подпись запроса или проверку IP-адресов. Сохраняйте способ проверки и область вывода: отдельный запрос, посещение или операция. Подтверждённая идентичность клиента сама по себе не доказывает полномочия на покупку или её оплату.
Для отчёта нужны три состояния: «участие агента подтверждено доступным способом», «есть косвенные признаки», «не установлено». Если средство выдаёт только собственную классификацию сеанса, называйте сегмент именно так. Отсутствие обнаруженных признаков не доказывает, что агент не участвовал.
29 октября 2026 года Microsoft Clarity опубликовал исследование более 5,2 млн сеансов с участием ИИ-агентов на 230 511 проектах. Данные собраны с 13 августа по 9 сентября 2026 года; среди наблюдаемых действий были оформления заказов, отправки форм и бронирования.
В исследовании сеанс мог включать передачу управления человеку, а собранные на разных сайтах события не образуют шаги одной покупательской воронки. Поэтому его результаты нельзя использовать как готовую конверсию автономных покупок. Магазину нужна собственная связь между наблюдаемыми действиями и подтверждёнными заказами.
Какие состояния заказа считать отдельно: оформление, оплата и возврат
События интерфейса полезны для анализа пути покупателя. Для подтверждения заказа нужны записи системы, которая этот заказ обслуживает.
На узком экране таблицу можно прокрутить по горизонтали.
| Этап | Что проверять | Какой вывод допустим |
|---|---|---|
| Открыта корзина или форма оформления | Событие, адрес страницы, условия срабатывания | Посещение дошло до соответствующего интерфейса |
| Запрос на оформление отправлен | Результат обработки запроса приложением | Сервер получил и обработал попытку; её результат нужно уточнить |
| Заказ создан | Уникальный номер и запись в системе магазина | Заказ существует, но может ожидать оплаты или подтверждения |
| Платёж авторизован | Статус операции у платёжного провайдера | Средства авторизованы; окончательное списание проверяется отдельно |
| Оплата подтверждена | Платёж связан с заказом, проверены сумма, валюта и успешный статус | По выбранному правилу учёта подтверждена оплата |
| Заказ исполнен, отменён или возвращён | Последующие статусы заказа и финансовых операций | Можно оценивать итог покупки с учётом отмен и возвратов |
Необходимое уточнение для магазина с оплатой при получении: созданный и подтверждённый заказ является результатом оформления, хотя деньги ещё не получены. В отчёте должны сохраняться оба показателя — оформленные заказы и фактические оплаты. Называть первый вторым нельзя.
То же относится к событию purchase. До сверки выясните, какое бизнес-состояние оно обозначает в вашей реализации: создание заказа, подтверждение оплаты или другое согласованное действие. Само название события не устанавливает состояние платежа.
Для услуг действует аналогичная последовательность: форма принята → обращение записано → передано ответственному → квалифицировано → получен коммерческий результат. Если обращение пропадает между этими этапами, пригодится отдельный разбор потери заявок после отправки формы.
Что проверить в Clarity и GA4 до подсчёта продаж
Определение события важнее его названия
В Clarity Smart Events могут объединять клики, посещения страниц, автоматические определения действий и события, переданные через API. Поэтому откройте условия события, которое в отчёте выглядит как покупка или отправка формы.
Если оно срабатывает по нажатию кнопки, это ещё не подтверждение обработки запроса. Если по посещению страницы благодарности — нужно проверить, можно ли открыть эту страницу повторно и связан ли показ с действительным заказом. Даже вручную настроенное событие отражает только ту логику, которую в него заложили.
В GA4 действия электронной торговли также разделены: добавление в корзину, начало оформления, покупка и возврат. Проверьте, что обработчик начала оформления не отправляет событие покупки, а сумма и валюта относятся к конкретному заказу.
Страница успешного возврата из оплаты не заменяет проверку платежа
Покупатель может успешно оплатить заказ и закрыть окно до возвращения в магазин. Возможна и обратная проблема: интерфейс сообщил об успешном действии, а окончательный результат оплаты ещё ожидается.
Подтверждение должно поступать из платёжной системы по предусмотренному ею механизму: проверяемому серверному уведомлению и, при необходимости, запросу актуального состояния операции. Например, Stripe отдельно указывает, что нельзя строить обработку оплаченных заказов только на посещении страницы возврата. Способы оплаты с отложенным результатом требуют обработки последующего изменения статуса.
Уведомление нужно проверить и связать с правильным заказом. Успешный ответ вашего сервера на доставку уведомления подтверждает приём запроса, но сам по себе не показывает, что статус заказа уже корректно изменён.
Как связать сеанс, заказ и оплату
Главная опора сверки — устойчивые идентификаторы. Они позволяют пройти от действия к записи заказа и платёжной операции без догадок по похожему времени.
Ниже — состав внутреннего журнала проверки. Это поля вашей системы сопоставления, а не готовый набор параметров, который нужно целиком отправить в GA4 или Clarity.
На узком экране таблицу можно прокрутить по горизонтали.
| Группа данных | Что сохранить | Для чего |
|---|---|---|
| Время | Время действия, поступления события и изменения статуса; часовой пояс | Отделить задержку доставки от последовательности действий |
| Посещение | Доступный идентификатор сеанса и источник перехода | Связать наблюдаемую активность с контекстом посещения |
| Участие агента | Статус, основание, средство классификации и его версия, если доступна | Понимать, почему запись отнесена к выбранному сегменту |
| Корзина и заказ | Внутренний идентификатор корзины, уникальный номер заказа | Сохранить связь при переходе от интерфейса к записи магазина |
| Связь с CRM | Идентификатор сделки, связанные номера заказов и время синхронизации | Проверить передачу заказа и обновление его состояния |
| Оплата | Идентификатор платёжной операции, статус, сумма, валюта | Проверить финансовый результат конкретного заказа |
| Доставка события | Источник события, его идентификатор, результат обработки | Найти повторные отправки и пропущенные уведомления |
| Передача управления | Известный переход к человеку и основание связи между этапами | Не приписать агенту действия, происхождение которых не установлено |
| Последующий результат | Отмена, полный или частичный возврат, исполнение | Сохранить итог покупки после первоначального оформления |
| Условия измерения | Тестовый или рабочий режим, доступность аналитики и состояние согласия | Объяснить, почему запись видна не во всех системах |
Идентификатор HTTP-запроса, номер заказа и номер платёжной операции решают разные задачи. Не пытайтесь заменить их одним случайным значением, которое меняется при каждом повторе.
Если агент передал покупку человеку в другой браузер, связь может сохраниться через предусмотренный магазином механизм продолжения корзины или заказа. Это должно быть безопасное сопоставление на стороне приложения. Совпадения IP-адреса, товара и минуты посещения недостаточно.
Когда надёжная связь потеряна, оставьте заказ в общей коммерческой статистике, а участие агента укажите как неустановленное. Пропуск в атрибуции не отменяет существование оплаты.
В аналитические параметры не передавайте email, телефон, адрес доставки, платёжные реквизиты и тексты личной переписки. Для сопоставления нужны технические идентификаторы и ограниченный набор категорий. Серверная отправка событий должна учитывать настройки согласия; она не служит способом обойти выбор пользователя.
Как проверить передачу заказа и статусов в CRM
Номер сделки в CRM может отличаться от номера заказа в CMS. В интеграции должно сохраняться их соответствие. Если одна сделка объединяет несколько заказов, храните связь с каждым из них: количество сделок нельзя автоматически считать количеством покупок.
Проверьте, какое действие меняет каждый статус. Сделку могли отметить успешной после подтверждения менеджером, хотя деньги ещё ожидаются. Статус «оплачено» должен иметь понятное основание: полученные данные платёжной системы или другой предусмотренный магазином способ подтверждения расчёта. Ручное изменение статуса также должно оставлять проверяемую запись.
Сопоставьте время изменения в исходной системе, передачи и обработки в CRM. Если оплата подтверждена, а CRM ещё показывает ожидание, проверьте очередь синхронизации и обработку сообщения. Не создавайте новую сделку только ради выравнивания счётчиков: сначала восстановите связь с существующей записью.
Для отмены и частичного возврата проверьте обновление того же заказа и суммы. Иначе аналитика может уже учитывать возврат, а CRM продолжит показывать первоначальный результат.
Как найти дубли заказов и повторные purchase
Проверять нужно два вида дублей: повторное событие аналитики и повторное создание бизнес-операции. Исправление одного не устраняет другой.
Агент может повторить действие после задержки ответа. Человек тоже может нажать кнопку ещё раз или обновить страницу. Поэтому защита от повторов должна работать независимо от того, кто инициировал запрос.
Для создания заказа предусмотрите повторную обработку одной и той же операции без появления второго заказа. Обычно для этого используют идентификатор операции, сохраняемый при её повторной отправке. Это свойство называют идемпотентностью. Новый HTTP-запрос при повторе может иметь новый технический номер, но смысл бизнес-операции остаётся прежним.
Для платежей отдельно обрабатывайте повторно доставленные уведомления. Повтор одного события не должен второй раз начислять выручку, создавать отгрузку или отправлять тот же заказ в CRM. Время последней доставки при этом сохраняется для диагностики.
В GA4 для веб-потоков предусмотрено устранение повторных purchase по transaction_id. Номер должен быть уникальным для заказа, стабильным при повторной отправке и не содержать персональные данные. Пустое значение или одинаковый номер у разных заказов может привести к потере корректных событий. Этот механизм не заменяет защиту от дублей в CMS, CRM и платёжной интеграции.
Что делать, если заказ есть, а аналитика его не показывает
Отсутствие события браузера не доказывает отсутствие заказа. Возможны ограничения загрузки скриптов, настройки согласия, прерванный переход, ошибка тега или другой маршрут оформления. Сначала найдите запись заказа, затем выясняйте, на каком участке потерялось измерение.
Серверные события помогают передать известный результат, но также требуют проверки. Google описывает Measurement Protocol как дополнение к обычному сбору данных. При использовании только серверной передачи часть отчётности может быть ограничена.
Есть и техническая ловушка: ответ 2xx от Measurement Protocol означает получение HTTP-запроса. Он не гарантирует, что неверно сформированное событие будет обработано и появится в отчёте. Поэтому проверяют данные запроса, правила валидации и фактическое появление события.
Не создавайте вымышленные идентификаторы посещений, чтобы любой ценой присоединить оплату к агенту. Если аналитическая связь недоступна, результат остаётся в системе заказов с соответствующим ограничением атрибуции. Практику сопоставления сайта, GA4 и CRM мы показываем в кейсе аудита отслеживания конверсий.
Как расследовать расхождение по конкретному заказу
Начинайте с небольшого набора расхождений, для которых можно восстановить цепочку. Не требуется сразу перестраивать всю аналитику магазина.
В аналитике есть покупка, в системе магазина заказа нет. Проверьте условие события, тестовый режим, повторное посещение страницы и результат запроса оформления. Пока запись заказа не найдена, не включайте такое событие в число подтверждённых заказов.
Заказ создан, но оплаты нет. Посмотрите способ оплаты и текущий статус. Ожидание перевода, оплата при получении и отказ банка требуют разных выводов. Отдельно проверьте доставку и обработку платёжных уведомлений.
Заказ и оплата есть, CRM показывает другой результат. Проверьте соответствие номеров, правила перехода между статусами и время синхронизации. Найдите конкретное сообщение об изменении состояния и результат его обработки.
Оплата есть, а событие покупки отсутствует. Сопоставьте номер заказа, платёж и отправку аналитического события. Проверьте, не зависит ли измерение только от возвращения покупателя на сайт, нет ли неверного transaction_id и ограничений сбора данных.
Одна операция отражена несколько раз. Установите, задвоились ли события, записи заказа или реальные списания. Проверьте параллельные отправки из браузера и сервера, повторные уведомления и правила обработки повторов.
Агент начал оформление, человек завершил его позже. Восстанавливайте связь по сохранённой корзине или заказу. При наличии доказательства учитывайте участие обоих. При отсутствии связи сохраняйте неопределённость, а не назначайте исполнителя по последнему событию.
Для каждого расхождения зафиксируйте наблюдение, найденную причину, изменение и результат повторного теста. Формулировка «после правки цифры стали ближе» слабее, чем подтверждение конкретного исправленного механизма.
Если запрос оформления не дошёл до приложения, проверьте ответы сервера и журнал защиты по методике диагностики ложных блокировок сайта.
Сопоставим события сайта, записи магазина, CRM и подтверждённые операции. Установим, на каком этапе данные расходятся.
Как считать заказы, оплаты и полноту сопоставления
Отчёт должен показывать одновременно коммерческий результат и полноту его сопоставления с действиями на сайте. Удобно начать с пяти показателей.
На узком экране таблицу можно прокрутить по горизонтали.
| Показатель | Как считать | Как интерпретировать |
|---|---|---|
| Уникальные созданные заказы | Число разных номеров заказов в выбранной группе | Отражает оформление; состояние оплаты показывается отдельно |
| Доля заказов с установленной связью | Заказы, связанные с наблюдаемым посещением, / все заказы проверяемой группы × 100% | Показывает полноту сопоставления, а не качество продаж |
| Доля оплаченных заказов | Оплаченные заказы / созданные заказы одной группы с одинаковым сроком наблюдения × 100% | Позволяет сравнивать завершение оплаты в сопоставимых условиях |
| Частота повторных purchase | Повторные записи purchase сверх первой по каждому номеру / все исходящие записи purchase × 100% | Считается по журналу отправки до возможного удаления дублей аналитикой |
| Оплаты за вычетом возвратов | Сумма подтверждённых оплат минус подтверждённые возвраты по тем же заказам | Показывает денежный результат на дату среза; расходы магазина учитываются отдельно |
Заранее определите, что означает «оплаченный заказ»: например, заказ с полностью полученной суммой. Заказы с предоплатой или частичной оплатой выделяйте отдельно, если они не соответствуют выбранному правилу. Полученные деньги, полная оплата и исполнение заказа — разные показатели.
Разделите заказы с подтверждённым участием агента, с косвенными признаками и с неустановленным участием. Не называйте последнюю группу «покупки только людей»: в ней могут оставаться нераспознанные агенты.
Все суммы приводите к согласованной валюте и одинаковым правилам учёта доставки, налогов и частичных возвратов. Несколько платежей по одному заказу не превращают его в несколько заказов.
Для сравнения используйте группы заказов, созданных в одинаковых условиях и наблюдаемых одинаковое время. Заказ, оформленный сегодня и ожидающий оплаты, нельзя оценивать наравне с заказом, у которого уже завершился обычный для магазина цикл оплаты. Возвраты также требуют достаточного срока наблюдения.
При небольшом объёме показывайте абсолютные количества рядом с процентами. Если знаменатель равен нулю, показатель не рассчитан. Отсутствие доступных данных также нельзя обозначать нулём продаж.
Если нужна конверсия именно посещений, в числителе считайте посещения хотя бы с одним связанным результатом. Деление количества заказов на количество посещений даёт другой показатель: за одно посещение могут появиться несколько заказов.
Почему высокая конверсия ещё не доказывает пользу агента
Агента могут включать ближе к завершению выбора: товар уже определён, цена подходит, осталось проверить условия или оформить покупку. Обычная посещаемость магазина включает и людей, которые только знакомятся с ассортиментом.
Поэтому разница между группами может объясняться стадией выбора, устройством, категорией товара, способом оплаты или доступностью измерения. Даже подтверждённая связь «агент участвовал — заказ оплачен» не доказывает, что без агента этой продажи не произошло бы.
В наблюдательном отчёте указывайте результат связанных заказов. Для вывода о дополнительном влиянии внедрённого вами консультанта или другого изменения требуется отдельно спланированное сравнение с контрольными условиями. Результаты собственного консультанта нельзя автоматически переносить на внешних агентов покупателей.
Сверка заказов нужна и перед передачей результата в рекламную систему. Если реклама получает отменённые, повторные или неверно оценённые покупки, ошибка продолжает влиять на последующую оптимизацию. Подробнее об этой части — в материале о проверке CRM-конверсий и отмен заказов.
Десять проверок учёта заказов перед использованием отчёта
Проведите контролируемые проверки в тестовой среде и тестовом режиме оплаты. Их результаты должны быть отделены от рабочих заказов и рекламных конверсий. Если проверяется агент, сохраняйте известные условия его запуска и передачи управления человеку.
На узком экране таблицу можно прокрутить по горизонтали.
| Проверка | Ожидаемый результат |
|---|---|
| Оформление прекращено до создания заказа | Зафиксированы промежуточные действия, подтверждённого заказа и оплаты нет |
| Заказ создан, платёж отклонён | Заказ существует, неуспешная оплата не увеличивает оплаченный результат |
| Успешная оплата без возвращения на страницу магазина | Результат платежа отражён серверной интеграцией независимо от страницы возврата |
| Повторное открытие страницы благодарности | Не появляется новый заказ и не увеличивается оплаченная сумма |
| Повтор одной операции оформления | Повтор обработан без создания второго заказа |
| Повторная доставка платёжного уведомления | Не создаётся повторное коммерческое действие |
| Отложенное подтверждение платежа | Ожидание сменяется окончательным результатом; связанная запись CRM обновляется по правилам интеграции |
| Передача управления от агента человеку | Связь сохранена предусмотренным способом либо явно отмечена как неустановленная |
| Отмена или частичный возврат | Обновлено состояние того же заказа и корректно изменён денежный результат |
| Аналитика ограничена настройками согласия | Заказ обслуживается по правилам магазина, ограничение измерения не обходится |
После исправлений повторите затронутые сценарии и проверьте обычное оформление человеком. Рабочий результат — воспроизводимая связь между заказом, оплатой и доступными наблюдениями, с объяснёнными ограничениями.
Частые вопросы
Можно ли определить всех ИИ-агентов по журналам сервера?
Нет. Журналы показывают запросы и доступные признаки клиента. Часть автоматизированного трафика можно идентифицировать, но универсального доказательства участия агента во всех посещениях они не дают. Сохраняйте неустановленные случаи отдельно.
Нужно ли исключать из коммерческого отчёта все заказы с участием ботов?
Не автоматически. Агент может выполнять поручение покупателя, и заказ может быть действительным. Проверяйте результат и происхождение по отдельности. Тестовые операции, накрутка и реальные покупки требуют разных правил.
Можно ли использовать только событие purchase?
Для сверки оплаты этого недостаточно. Нужно знать условие его отправки, связанный номер заказа и подтверждённое состояние платежа. Полезно сохранять раздельный учёт создания заказа и оплаты, особенно при отложенных способах расчёта.
А если у магазина пока нет CRM?
Начните с системы заказов CMS и данных платёжного провайдера. Для первичной проверки нужны уникальные номера, состояния, суммы, валюта и время изменений. CRM полезна для дальнейшей обработки обращений, но её отсутствие не мешает проверить существование заказа и оплаты.
Может ли магазин начать с обычной таблицы?
Да. Для небольшой выборки достаточно выгрузок заказов, платежей и доступных событий, сопоставленных по идентификаторам. Неизвестные связи оставляйте неизвестными. Автоматизацию имеет смысл строить после того, как понятны правила сверки и причины расхождений.
Нужна сверка GA4, CRM и оплат?
Если GA4 показывает покупки, CRM — другой результат, а оплаты не сходятся с обоими отчётами, начинать стоит со сверки конкретных операций. В VozniNet можно заказать проверку событий сайта, записей заказов, передачи данных в CRM и связи с оплатами, включая заказы с установленным участием ИИ-агентов.
По результатам определим, где расходятся данные, какие события повторяются или теряются и что изменить в настройках либо интеграции. Для обсуждения достаточно адреса сайта, названия CMS, используемой аналитики и описания расхождения.