Как объединить данные магазина и сайта для CRM

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

Объединение онлайн- и офлайн-данных означает, что покупки и другие действия из разных каналов можно отнести к нужному клиенту и учесть в общих правилах общения. Профиль клиента — связанная запись с его контактами и историей. Идентификатор, или ID, — код, по которому система различает клиентов, заказы и другие объекты; у одного человека в разных системах могут быть разные ID.

Сайт хранит заказ, касса — чек, программа лояльности — участника, а ESP, сервис email-рассылок, — контакт получателя. Чтобы сведения работали вместе, нужно описать связи между этими объектами, передавать покупки и их изменения, учитывать ограничения на сообщения.

Разберём минимальный обмен, достаточный для общего сценария, и проверки, которые помогают избежать неверного объединения людей и повторных отправок.

Какие задачи имеет смысл решать первыми

Выберите процесс, в котором разрыв между каналами уже заметен клиенту. Например, человек купил товар в магазине, но продолжает получать напоминание о корзине на сайте. Или программа повторной покупки учитывает только онлайн-заказы и считает постоянного офлайн-покупателя спящим.

Для первого запуска достаточно связать подходящие покупки с клиентом и научить сценарий учитывать их при остановке. Не обязательно сразу переносить все просмотры товаров, обращения в поддержку и историю за десять лет. Каждый дополнительный поток увеличивает объём согласований и проверки.

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

Не используйте совпадение контакта как универсальное доказательство

Телефоном могут пользоваться несколько членов семьи; email может относиться к общему аккаунту. Ошибка объединения опаснее простого дубля, если после неё одному человеку показывают чужую историю или передают чужие предложения.

Разделите внутренний ID клиента, ID участника программы лояльности, аккаунт сайта и контакты. Для связей между ними храните основание: вход в подтверждённый аккаунт, привязка карты в личном кабинете, принятая процедура смены номера. Разные основания могут иметь разную надёжность.

Identity resolution — сопоставление записей, чтобы определить, какие из них относятся к одному клиенту. Salesforce в материалах об этом процессе разделяет правила сопоставления записей и правила выбора значений для объединённого профиля. [1] Практический смысл для проекта прост: сначала нужно решить, относятся ли записи к одному человеку, и только затем выбирать его актуальный адрес или другое поле.

Минимальная модель обмена

В условном ретейле разумно начать с четырёх типов объектов. В модели данных их называют сущностями. Клиент хранит устойчивый внутренний ID и связи с внешними системами. Покупка содержит ID операции, канал, время и статус. Позиции покупки описывают товары и суммы. Изменения передают возврат или отмену со ссылкой на исходную операцию.

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

Условный пример с частичным возвратом

Клиент купил на сайте два товара на 8 000 рублей, затем вернул в магазине один из них за 3 000. Если возврат попадёт в CRM отдельной отрицательной суммой без связи с исходной покупкой, система может сохранить неверный состав заказа и продолжить рекомендацию аксессуаров к возвращённому товару.

Передайте ссылку на исходный заказ и позицию, количество возвращённых единиц и сумму возврата. После обновления чистая сумма операции равна 5 000 рублей, но сценарий должен понимать, какой товар остался у клиента. Одного итогового числа для этого недостаточно.

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

Что делать с неидентифицированными чеками

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

Отдельно считайте долю идентифицированных покупок и причины отсутствия связи. Рост этого показателя должен происходить за счёт корректной процедуры, а не агрессивного объединения похожих записей. Для аналитики также важно не объявлять клиентов с неизвестной историей «новыми» автоматически.

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

Как устроить обмен без лишних копий логики

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

Для надёжной передачи изменения важно не потерять событие между записью покупки и уведомлением интеграции. Один из технических подходов — transactional outbox, или журнал исходящих событий: изменение в исходной базе и запись о необходимости его передать сохраняются как одна согласованная операция. После этого отдельный процесс отправляет запись получателю. Amazon Web Services (AWS) описывает этот способ организации обмена и необходимость учитывать повторы у получателя. [2] Возможность применения зависит от устройства исходной системы.

Маркетологу не нужно выбирать реализацию самостоятельно. Его задача — поставить проверяемое требование: оплаченная покупка не должна исчезать из CRM при кратком сбое интеграции; повторная передача не должна создавать второй заказ или второе письмо.

Как принять первый запуск

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

Сверяйте количество операций, их суммы и состав на уровне ID. Сравнение общих итогов без разбора расхождений может скрыть взаимно компенсирующие ошибки. Период сверки должен учитывать время поступления запоздавших данных и единые границы суток.

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

Источники

[1] Salesforce. Learn to Create and Manage Identity Resolution Rulesets. Trailhead.

[2] Amazon Web Services. Transactional outbox pattern. AWS Prescriptive Guidance.