Интернет-магазины
Сайты
Дизайн
Поддержка
Продвижение
ИнтеграцииКак оценивать работу интернет-магазина: заказы, оплаты, отмены и возвраты
В аналитике может быть 80 покупок, в магазине — 100 заказов, а в отчёте по платежам — другая сумма. Само расхождение ещё не доказывает ошибку: системы могут считать разные события, периоды и деньги. Ниже — заполненный учебный отчёт и пример сверки, которые помогают разобраться до оценки рекламы или работы разработчика.
1. Договоритесь, что означает каждый показатель
Созданный заказ фиксирует намерение и состав покупки. Подтверждённая оплата — отдельный факт из платёжного источника или учётной системы. Отгрузка, отмена и возврат также имеют собственные статусы и даты. При оплате при получении между оформлением и поступлением денег проходит время; при предоплате деньги могут поступить до исполнения заказа.
Событие purchase в веб-аналитике — сообщение, которое отправляет ваша интеграция. Само название не подтверждает банковскую операцию. Зафиксируйте момент отправки и источник данных; не смешивайте в одном показателе нажатие кнопки, сохранённый заказ и подтверждённый платёж. В GA4 события электронной торговли нужно настроить: обычная установка счётчика не создаёт весь набор автоматически.
Сумма оформленных заказов не равна полученным деньгам, а аналитический показатель с названием revenue не становится бухгалтерской выручкой. Для управленческого отчёта явно назовите, что считаете: товарную сумму заказов, подтверждённые платежи или платежи за вычетом возвратов. Бухгалтерские показатели сверяют с учётной системой и ответственным специалистом, а не переименовывают колонку GA4.
- ОформлениеНомер, товары и согласованная сумма
- ОплатаПодтверждённый денежный факт
- ИсполнениеВыдача или доставка заказа
- КорректировкаОтмена, полный или частичный возврат
Это связанные состояния, а не обязательный порядок: при предоплате и оплате при получении последовательность отличается.
Документация: Google Analytics: настройка событий электронной торговли;
2. Выберите период и группу заказов до подсчёта
Есть два полезных, но разных отчёта. Первый берёт заказы, созданные за период, и смотрит их судьбу на определённую дату. Второй считает все денежные операции за период независимо от даты заказа. Не соединяйте первую численность со второй суммой: возврат в августе по июльскому заказу иначе незаметно изменит показатели другой группы.
Далее используется только первый подход. Все цифры вымышлены и служат обучению, это не результаты ActiveLab или клиента. Группа — 100 уникальных заказов, созданных с 1 по 7 августа 2026 года включительно по времени Минска. Состояния проверены на конец 14 августа. Дубли и тестовые заказы исключены. Каждый заказ содержит товары на 100 BYN; доставка бесплатна, налоги отдельной строкой не выделяются. Все денежные суммы ниже относятся только к этой группе.
Для простоты модели нет частичных оплат, обменов товаров и изменений состава. К дате проверки 80 заказов полностью оплачены, 15 отменены без оплаты, 5 ещё ожидают оплаты. Среди 80 оплаченных по четырём позднее оформлен полный возврат 100 BYN, по двум — частичный возврат 50 BYN. Эти шесть не вычитаются из исторического количества оплаченных: факт оплаты был, а возврат показывается отдельно.
3. Прочитайте заполненный отчёт и проверьте арифметику
Источник этого учебного отчёта — реестр заказов и подтверждённые денежные операции, не число событий в браузере. Сначала проверяются взаимосвязи строк; только затем выбираются действия. Возврат товара и возврат денег могут происходить не одновременно: здесь учитываются именно подтверждённые денежные возвраты.
| Показатель | Расчёт | Значение | Как читать |
|---|---|---|---|
| Созданные заказы | Уникальные номера после исключений | 100; товарная сумма 10 000 BYN | Исходная группа, не полученные деньги |
| Когда-либо оплачены к дате среза | 80 заказов × 100 BYN | 80; поступления 8 000 BYN | Включает заказы с последующими возвратами |
| Отменены без оплаты | 15 заказов × 100 BYN | 15; товарная сумма 1 500 BYN | Не вычитать из 8 000 BYN: эти деньги не поступали |
| Ожидают оплаты | 5 заказов × 100 BYN | 5; товарная сумма 500 BYN | Незавершённое состояние, не подтверждённая продажа |
| Денежные возвраты | 4 × 100 + 2 × 50 | 6 заказов; 500 BYN | Четыре полных и два частичных возврата |
| Поступления минус возвраты | 8 000 − 500 | 7 500 BYN | Не прибыль и не бухгалтерская выручка |
| Доля оплаченных заказов | 80 / 100 × 100 | 80% | Показатель этой группы на дату среза |
| Доля заказов с возвратом денег | 6 / 80 × 100 | 7,5% | Любой возврат среди когда-либо оплаченных |
| Доля возвращённой суммы | 500 / 8 000 × 100 | 6,25% | Другой показатель: деньги, а не число заказов |
Если таблица не помещается на экране, прокрутите её по горизонтали.
Контроль группы: 80 + 15 + 5 = 100. Контроль оплаченных: 74 без возврата + 4 с полным + 2 с частичным = 80. Контроль оставшейся суммы: 74 × 100 + 2 × 50 = 7 500 BYN. Два разных расчёта дают один итог. Если равенство нарушено, сначала ищут пропущенные статусы, повторные операции или другой состав суммы.
Пять ожидающих заказов ещё могут оплатить, а по исполненным могут появиться новые возвраты. Поэтому рядом с отчётом сохраняют дату среза. Сравнивая две группы, давайте им одинаковое время на оплату и возврат: свежую неделю нельзя напрямую считать хуже давно завершённой. Расходы на товары, рекламу, доставку, комиссии и обслуживание здесь не вычитались — вывод о прибыльности из 7 500 BYN сделать нельзя.
4. Сверьте один тестовый заказ по полям, а не по красивому графику
Следующий пример отдельный и не входит в группу из 100 заказов. Это учебная запись для проверки в тестовом окружении и отдельном ресурсе аналитики, а не результат проведённого нами теста. Условный заказ TEST-204 содержит две единицы товара DEMO-A по 100 BYN, доставку 10 BYN и итог к оплате 210 BYN. Налог отдельно в примере не выделен; это упрощение данных, не рекомендация по налогообложению.
В учебной настройке purchase отправляется после подтверждённой оплаты. Для магазина с другим способом расчётов правило нужно согласовать отдельно. В параметрах GA4 товарная сумма value не должна подменяться полной суммой платежа вместе с доставкой: для доставки предусмотрен shipping. Сравнивайте поля одной сущности, а не ожидайте равенства любых двух колонок с денежными названиями.
| Что сверяем | Заказ и платёж | Событие аналитики | Критерий |
|---|---|---|---|
| Идентификатор | Заказ TEST-204; платёж связан с ним | transaction_id: TEST-204 | Одна покупка узнаётся во всех источниках |
| Товар и количество | DEMO-A, 2 шт. по 100 BYN | items: DEMO-A; price 100; quantity 2 | Совпадают исполнение, цена и количество |
| Товарная сумма | 200 BYN после скидок | value: 200; currency: BYN | 100 × 2 = 200 |
| Доставка и платёж | Доставка 10 BYN; оплачено 210 BYN | shipping: 10, отдельно от value | 200 + 10 = 210, расхождение объяснено составом |
| Частичный возврат | Возвращена одна единица, деньги 100 BYN; доставка не возвращена | refund: TEST-204; DEMO-A; quantity 1; value 100; BYN | Возврат связан с исходной покупкой и нужным товаром |
| Повтор страницы | Нового заказа и платежа нет | Не создаётся вторая логическая покупка | ID сохраняется; повтор не увеличивает итог покупок |
Если таблица не помещается на экране, прокрутите её по горизонтали.
Откройте тестовую сессию в режиме отладки, совершите предусмотренную провайдером тестовую оплату и посмотрите параметры события в DebugView. Сохраните обезличенный состав заказа, подтверждение тестового платёжного статуса и параметры события. Затем проверьте обработанные данные: появление события в отладке подтверждает получение, но не заменяет сверку итогового отчёта. Фактические результаты, время и доказательства вписываются после выполнения.
Для каждого нового заказа используйте новый непустой transaction_id; обновление страницы не должно создавать новый ID. Google описывает устранение дублей purchase по transaction_id для веб-потоков. Это дополнительная защита аналитики, а не защита от повторного списания денег и не повод намеренно отправлять события многократно.
Документация: Google Analytics: параметры покупок и возвратов; Google Analytics: идентификаторы транзакций и устранение дублей; Google Analytics: проверка событий в DebugView;
5. Разбирайте расхождения по конкретным заказам
Если цифры не сходятся, выгрузите ограниченную выборку с номером заказа, временем, статусом, валютой, товарной суммой, доставкой и возвратами. Сравнение общей суммы без идентификаторов редко показывает причину. Отдельно учитывайте задержку обработки данных и выбранный часовой пояс.
Не пытайтесь получить полное совпадение ценой обхода настроек приватности. Пользовательские ограничения, согласие на аналитику и блокировщики могут влиять на наблюдаемость; отсутствие события не означает отсутствие покупки. Системой учёта самих заказов остаётся магазин, а деньги подтверждаются соответствующим источником.
| Наблюдение | Проверка | Следующее действие |
|---|---|---|
| Есть заказ, нет purchase | ID, правило отправки, согласие, ошибка запроса и задержка | Отделить ожидаемую ненаблюдаемость от подтверждённого сбоя интеграции |
| Сумма аналитики выше платежей | Не отправляется ли purchase при создании неоплаченного заказа | Согласовать событие и название отчёта; проверить отдельный учёт оплат |
| Платёж выше value на 10 BYN | Доставка TEST-204 передана отдельно | Признать объяснённое различие, не увеличивать value вслепую |
| Возврат есть в учёте, нет в аналитике | Настроен ли refund и связан ли он с transaction_id | Проверить передачу и обработку одного учебного возврата |
| Заказы ошибочно объединяются | Пустой или одинаковый transaction_id у разных заказов | Исправить формирование ID и проверить две новые тестовые покупки |
Если таблица не помещается на экране, прокрутите её по горизонтали.
Не передавайте в обычные события GA4 телефон, email или имя покупателя; проверяйте также URL, названия страниц и параметры кампаний. Для сверки достаточно технического номера заказа без персональных данных. Сырые выгрузки с данными покупателей не публикуют в общих таблицах и не добавляют к публичному отчёту.
Документация: Google Analytics: идентификаторы транзакций и устранение дублей; Google Analytics: проверка событий в DebugView; Google Analytics: как избежать передачи персональных данных;
6. Заканчивайте отчёт действиями и ответственными
В учебной группе повод для расследования — 15 отмен без оплаты, 5 ожидающих и 6 заказов с возвратами. Цифры не объясняют причины. Отмена могла произойти из-за отсутствия товара, сроков доставки или изменения решения покупателя; возврат — по разным причинам. Не объявляйте рекламу плохой до проверки качества заказов и их обработки.
| Задача | Ответственный | Результат проверки |
|---|---|---|
| Разобрать 15 отмен | Руководитель продаж | У каждого заказа записана подтверждённая причина либо «не выяснена» |
| Проверить 5 ожидающих | Менеджер заказов | Понятен актуальный статус; платежи сверены перед повторным запросом оплаты |
| Разобрать 6 возвратов | Менеджер качества | Раздельно отмечены товарная причина, сумма и подтверждение возврата денег |
| Выполнить TEST-204 | Специалист аналитики и разработчик | Приложены фактические значения, ID и вывод по каждому полю |
| Подготовить следующий срез | Ответственный за отчёт | Тот же периметр, формулы и дата проверки; изменения объяснены |
Если таблица не помещается на экране, прокрутите её по горизонтали.
После исправления измерения сравнивайте сопоставимые группы по источнику трафика, устройству и ассортименту. Небольшую выборку не выдавайте за устойчивую закономерность. Для оценки эффективности рекламы добавьте расходы и подтверждённые результаты, а для прибыли — затраты бизнеса. Сам по себе рост числа purchase ещё не доказывает, что магазин заработал больше.
Частые вопросы
Почему нельзя считать выручкой сумму всех заказов?
Часть заказов не оплачена, отменена или возвращена. Сначала уточните смысл показателя и источник: сумма оформленных товаров, поступления денег и бухгалтерская выручка не взаимозаменяемы.
Должны ли аналитика и магазин совпадать до заказа?
Не всегда: отличаются правила событий, периоды, обработка данных и наблюдаемость. Но каждое существенное расхождение нужно объяснить, а не списывать всё на допустимую погрешность. Начните со сверки ID и состава суммы.
Как учитывать частичный возврат?
Сохранять связь с исходным заказом, возвращённый товар, количество и подтверждённую сумму. В примере TEST-204 возврат одной единицы равен 100 BYN; это один заказ с частичным возвратом, а не отмена всей покупки на 210 BYN.
Можно ли проверить аналитику только в DebugView?
Нет. Это полезная проверка получения события и его параметров. Дополнительно сверяют заказ, тестовый платёж, обработанные показатели и повторные действия. Тестовые операции отделяют от рабочих отчётов.
Источники и документация
Материал подготовлен для владельцев бизнеса на основе официальной документации. Примеры и планы работ в тексте — учебные: состав решений зависит от конкретного сайта.
Если нужна помощь с описанной задачей, посмотрите состав услуги Развитие интернет-магазина. Объём работ, сроки и стоимость согласуются после изучения вашего проекта.
