# Передача чеков в CDP: почему Mindbox видит не все транзакции и как это проверить > Интеграция с кассой настроена, а чеки до CDP доходят не все. Разбираем, где теряются транзакции, почему из-за них врёт LTV и как сверить поток с кассой за один день. **Рубрика:** Статьи **Автор:** Василина Бреусенко, CRM-маркетолог, ClientCore **Дата:** 2026-09-25 «Интеграция с кассой настроена» — в проекте внедрения напротив этого пункта стоит галочка. Отчеты в Mindbox строятся, цифры двигаются, все выглядит рабочим. А потом маркетолог замечает странности: в сегмент «не покупали 90 дней» попал постоянный клиент розницы, LTV офлайн-покупателей вдвое ниже реального, а выручка в CRM-отчете не сходится с кассой на треть. Причина почти всегда в потоке чеков: он есть, но неполный. Транзакции теряются, дублируются и приходят без привязки к человеку. Василина Бреусенко, CRM-маркетолог ClientCore, аудировала десятки таких интеграций и знает, где данные застревают чаще всего. > **Читайте также:** [Ecommerce-события для рассылок: полный чек-лист для триггерных сценариев](https://clientcore.ru/blog/articles/ecommerce-sobytiya-dlya-rassylok-polnyy-chek-list-dlya-triggernyh-scenariev) ## Что происходит с чеком между кассой и CDP Путь выглядит простым: покупка в магазине → фискальный регистратор → кассовое ПО → промежуточная система (ERP, процессинг лояльности или самописный коннектор) → API Mindbox. Четыре-пять звеньев, и на каждом данные можно потерять или исказить. Когда в акте внедрения написано «интеграция Mindbox с кассой завершена», это значит одно: тестовый чек прошел по цепочке и появился в CDP. Один чек, в контролируемых условиях. Никто не проверял, что происходит ночью, когда касса уходит в офлайн-режим, что будет с возвратом на следующий день и что прилетит при обрыве связи на двадцатой транзакции из очереди. Отдельный слой — состав чека. Для аналитики мало знать, что клиент потратил 3400 рублей. Нужны артикулы, категории, магазин, способ оплаты: без этого не построить рекомендации и кросс-сейл. Если маппинг полей настраивали в спешке, чек в CDP есть, а толку от него — как из пустого конверта. Первый шаг к порядку — сменить вопрос. Не «есть ли интеграция», а «какая доля чеков доходит целиком, вовремя и с привязкой к клиенту». Это уже измеримая вещь. > Аудит всегда открываю одной цифрой: число транзакций в CDP за вчерашний день против Z-отчета кассы. Разбег в 5% — уже повод копать. В одном проекте расхождение было 23%: полгода отчеты строились на трех четвертях реальных продаж, и никто не замечал». > > — Василина Бреусенко, CRM-маркетолог, ClientCore ## Где чеки теряются: четыре разрыва в цепочке Картина из аудита в аудит повторяется. Вот места, которые проверяем первыми. **Офлайн-режим кассы.** Касса потеряла связь, пробила чеки локально, выгрузила их пачкой через шесть часов. Если коннектор не умеет обрабатывать пакетную выгрузку, часть чеков упадет с ошибкой — и никто этого не заметит. **Битый webhook и тихие ошибки API.** Событие отправлено, в ответ пришел отказ: таймаут, 500-я ошибка, протухший токен. Ретраев нет. В логах коннектора — ошибка, в интерфейсе Mindbox — тишина. Так теряются проценты выручки месяцами. **Возвраты и нестандартные операции.** Частичный возврат, отложенный чек, продажа в кредит, корректировка — у каждой кассовой системы свой формат. Если маппинг настраивали только под стандартную продажу, возвраты либо не приходят, либо записываются как обычные продажи. Второй вариант хуже первого: выручка в CDP завышена, и все выводы смещены. **Разрозненные источники.** Сайт шлет заказы через одно API, приложение — через другое, розница — через кассовый модуль. Разные форматы ID заказа — и один заказ приходит дважды, а часть каналов не приходит вовсе. > Один мертвый webhook после обновления кассового ПО — и розница молчит в CDP две недели. Маркетинг в это время режет „неактивных" по RFM и запускает win-back. Клиент, который был в магазине вчера, получает письмо „мы по вам скучаем". Поток мы чиним, а вот осадок у базы остается». > > — Василина Бреусенко, CRM-маркетолог, ClientCore ## Дубли и склейка: когда один клиент — это три профиля Единый профиль клиента — что это на практике: запись в CDP, к которой привязаны все идентификаторы человека (телефон, email, карта лояльности, device ID) и все его транзакции из всех каналов. Именно из этой записи считаются LTV, RFM и сегменты. Реальность без правил склейки выглядит иначе. Человек на кассе назвал телефон жены, на сайте залогинился через email, в приложении оставил только device ID. В CDP живут три профиля с тремя кусками истории. LTV каждого занижен, RFM-сетка ставит их не в те ячейки, персонализация стреляет мимо. Обратная болезнь — дубли самих чеков. Коннектор отправил событие, не дождался подтверждения, повторил отправку. Если у события нет уникального ключа (номер заказа плюс ID кассы плюс дата), CDP честно запишет две транзакции. Клиент купил один раз, в отчете — два чека. Умножьте на тысячу чеков в день: когортный анализ превращается в фантастику. **Норма** - у каждой транзакции есть уникальный внешний ID, повторная отправка не создает дубль - правила склейки профилей задокументированы: по каким идентификаторам и в каком приоритете - доля профилей-дублей измеряется и снижается **Red flag** - «склейка работает сама, Mindbox разберется» - транзакций в CDP стабильно больше, чем чеков по кассе - в карточке клиента видны только онлайн-заказы, хотя он год покупает в рознице ## Неидентифицированные чеки: слепая зона офлайна Даже чек, дошедший без потерь, оставляет вопрос: чей он. Покупка без карты лояльности и телефона — транзакция без владельца. В клиентской аналитике ее как будто нет. Как объединить офлайн и онлайн данные, если кассир не спросил телефон? Механики известны: QR-код на чеке с бонусом за регистрацию покупки, розыгрыш среди зарегистрировавших чек, баллы за фото чека в приложении. Работает все это при двух условиях: у клиента есть мотив, а у кассира — причина предлагать карту каждому. Мы проверяли это на практике. В проекте для ресторана «Урюк» механика розыгрыша сертификатов привлекла 2435 новых участников программы лояльности — то есть больше двух тысяч человек, чьи офлайн-покупки раньше были анонимными, получили профили в базе ([кейс](https://clientcore.ru/blog/articles/keis-uryk-rozygrysh-sertifikatov)). Доля неидентифицированных чеков — самостоятельная метрика, за ней стоит следить ежемесячно. Если анонимных транзакций больше половины, программа лояльности не выполняет главную функцию — идентификацию покупателя. И никакая передача чеков в CDP эту дыру не закроет: передавать-то нечего. ## Как проверить качество потока: сверка за один день Месяц аудита для первого диагноза не нужен. Базовая сверка занимает день: 1. **Сравните с кассой.** Возьмите Z-отчет или выгрузку из учетной системы за 3–5 дней и сопоставьте с транзакциями в CDP за те же даты. Считайте раздельно: продажи, возвраты, суммы. 2. **Замерьте лаг.** Время от пробития чека до появления транзакции в CDP. Лаг больше 15–30 минут — и триггер «спасибо за покупку» приходит, когда клиент уже дома. 3. **Посчитайте долю идентифицированных чеков по каналам.** Сайт, приложение, розница — отдельно, иначе средняя цифра скроет провал в одном канале. 4. **Поищите дубли.** Выгрузите транзакции за день и проверьте совпадения по клиенту, сумме и времени в пределах секунд. 5. **Сверьте возвраты.** Дошли ли они в CDP и записались ли со знаком минус. **Норма** - расхождение с кассой в пределах 1–2%, и у каждого случая есть объяснение - лаг передачи до 15 минут, возвраты приходят с корректным знаком - метрики потока (полнота, лаг, идентификация) выведены на дашборд, и кто-то на них смотрит **Red flag** - сверка с кассой не делалась ни разу с момента внедрения - об ошибках передачи узнают из жалоб маркетинга, а не из мониторинга - «исторические данные загрузим как-нибудь потом» — сказано год назад ## Что дает чистый поток Когда чеки доходят целиком, с привязкой и без дублей, открывается то, ради чего CDP и покупали. RFM-сетка строится на всех покупках клиента, и офлайн-покупатель перестает попадать в win-back по ошибке. LTV считается честно: видно, кормит ли розница базу так же хорошо, как онлайн, или нет — и это тоже знание, с которым можно работать. Когорты по первому каналу покупки показывают, куда реально приводит реклама. Сегменты становятся рабочим инструментом. В проекте MINIDINO рассылки уходили всей базе без разбора — мы пересобрали логику с упором на точность вместо охвата, и эффективность email выросла на 110% за квартал ([кейс](https://clientcore.ru/blog/articles/keis-minidino-rost-effektivnosti-email)). Такая точность невозможна, когда сегмент считается по половине транзакций: сначала чистый поток чеков, потом сегментация и персонализация. В обратном порядке получается красивый отчет о несуществующем бизнесе. > **Читайте также:** [Идентификация клиента на сайте: как склеить анонимов с базой и вернуть выручку](https://clientcore.ru/blog/articles/identifikaciya-klienta-na-sayte-kak-skleit-anonimov-s-bazoy-i-vernut-vyruchku) --- [Открыть статью на сайте](https://clientcore.ru/blog/articles/peredacha-chekov-v-cdp-pochemu-mindbox-vidit-ne-vse-tranzakcii-i-kak-eto-proverit)