Как передать данные B2B-мероприятия в CRM

Схема передачи данных B2B-мероприятия в CRM: сущности, ID, статусы, поля, согласия, дубли и проверка принятой записи.

Данные мероприятий для бизнеса (B2B, business-to-business) часто теряют смысл между площадкой и CRM - системой управления отношениями с клиентами. В форме есть имя и email, на бейдже появляется номер, сканер фиксирует действие, а в целевой системе остаётся новый контакт без понятного мероприятия, сессии, встречи или источника приглашения.

Мы в «Авентуре» начинаем с другой стороны: описываем факты, которые должны дойти до системы заказчика, и договариваемся, как CRM подтвердит их приём. Такой контракт нужен до открытия регистрации. Позже менять идентификаторы (ID), статусы и назначение полей заметно сложнее: данные уже идут из нескольких точек одновременно.

Если вы готовите деловое мероприятие и хотите заранее связать регистрацию, отметку о прибытии (check-in) и активности на площадке с системой заказчика, запросите рабочее обсуждение проекта. Мы поможем описать схему данных мероприятия и требования к совместному тесту. Настройка и администрирование CRM остаются у профильной команды заказчика.

Какие данные должны попасть в CRM?

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

Источников у B2B-мероприятия несколько. Приглашение даёт кампанию и канал перехода. Регистрация сообщает, кто заявил участие.

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

Минимальный вопрос к каждому источнику выглядит так:

Метки UTM (Urchin Tracking Module) помогают различить источник, канал и кампанию перехода. Они относятся к контексту регистрации и не заменяют идентификатор человека или заявки. Номер бейджа тоже не должен становиться универсальным ключом: его задача ограничена конкретным проектом и способом доступа.

Отдельная статья о регистрации и требованиях 152-ФЗ разбирает юридическую и организационную сторону формы. Здесь мы держим более узкую границу: какие сущности и поля проходят путь до принятой записи в CRM.

Пять сущностей вместо одного перегруженного контакта

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

Человек (Person) - мастер-запись участника. В мастер-записи находятся устойчивые контактные сведения и принятые идентификаторы. Человек может участвовать в нескольких событиях, несколько раз регистрироваться и совершать разные действия.

Компания (Company) - организация. Компания не равна домену email во всех случаях, поэтому правило связи нужно утвердить. Корпоративный домен может быть сильным признаком. Публичная почта, дочернее общество или консультант требуют другого решения и иногда ручной проверки.

Регистрация (Registration) - заявка человека на конкретное мероприятие. У неё есть собственный ID, event ID, источник, время создания и статус. Повторное участие того же человека в другом событии создаёт новую регистрацию, а не нового человека.

Посещение (Attendance) - факт присутствия. Регистрация не доказывает визит. Microsoft Customer Insights также разделяет event registration и check-in, причём check-in может относиться ко всему событию или отдельной сессии. Поэтому поля «зарегистрирован» и «присутствовал» нельзя считать синонимами.

Активность (Activity) - отдельное действие: посещение сессии, встреча, сканирование материала, визит на стенд или другой согласованный факт. Активность хранит свой ID, тип, время и контекст. HubSpot Meetings API следует той же логике: встреча существует как отдельная CRM-активность и связывается с контактами и компаниями.

Эта модель не требует одинаковой структуры во всех CRM. В одной системе регистрация станет отдельным объектом, в другой - участием в кампании, а активность - записью в ленте действий. Смысл должен сохраниться при любом техническом представлении.

Система идентификаторов для всего пути

У каждого объекта и факта должен быть отдельный стабильный ID. Источник выпускает идентификатор один раз, а следующие системы передают его без пересоздания. Тогда повторная доставка распознаётся как повтор, а команда может найти одну и ту же запись в форме, журнале обмена и CRM.

Рабочий набор может включать:

1. event_id - конкретное мероприятие.
2. person_id - мастер-запись человека в согласованном контуре.
3. company_id - организация в системе заказчика или справочнике обмена.
4. registration_id - заявка человека на это событие.
5. attendance_id - отдельный факт check-in.
6. activity_id - сессия, встреча, стенд или другое действие.
7. source_system - система, которая создала факт.
8. schema_version - версия контракта данных.

Стандарт RFC описывает UUID - универсально уникальный 128-битный идентификатор, который можно выпускать без центральной регистрации. Это удобно, когда форму, мобильное приложение и оборудование на площадке обслуживают разные системы. UUIDv7 дополнительно поддерживает временной порядок, но конкретная версия вторична. Критично другое: одна команда назначает правила выпуска, а все участники сохраняют значение.

Спецификация CloudEvents задаёт полезную модель передачи событий. Пара source + id определяет отдельное событие, а повторно отправленный факт может сохранить тот же ID. Получатель тогда распознаёт дубль без догадок по имени, email и времени.

Важно. Идентификатор передаваемого факта не равен идентификатору человека или event_id мероприятия. Модель событий Adobe XDM ExperienceEvent прямо разделяет _id записи события и identity человека. Один участник может породить много активностей, и каждая получает собственный идентификатор.

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

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

Как договориться о статусах?

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

Начните с отдельных словарей. Статусы регистрации не должны смешиваться со статусами присутствия и исходами встречи.

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

Для каждого статуса запишите четыре правила:

1. Какой наблюдаемый факт его устанавливает.
2. Кто имеет право изменить значение.
3. Можно ли вернуться к предыдущему состоянию.
4. Что происходит при позднем или повторном событии.

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

Не меняйте значение существующего кода во время кампании. Добавьте новую версию схемы и договоритесь о переходе. Иначе одинаковый status=confirmed до и после изменения будет означать разные вещи.

Как составить карту полей и контекста?

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

HubSpot Properties API хорошо показывает разницу между типом данных и интерфейсом поля. Строка, дата, число и enumeration хранятся по-разному. Для справочника статусов подходит ограниченный набор значений, а не текстовое поле. Собственный внешний ID можно вынести в поле с требованием уникальности, если целевая CRM поддерживает такой режим.

Минимальная карта полей выглядит так:

Контекст особенно важен для стенда. Передача одного badge_number=1842 ничего не сообщает получателю. Нужны event ID, activity ID, тип действия, время, источник сканирования и person или registration ID. Если участник запросил конкретный материал, код материала передаётся отдельным полем только при наличии согласованного действия у получателя.

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

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

Минимизация данных и согласия

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

Мы используем простой фильтр полей:

1. Какую задачу решает поле на мероприятии или в CRM?
2. Кто владелец значения?
3. Какое действие последует после получения?
4. Нужна ли точность уже при регистрации?
5. Можно ли получить значение позже из мастер-системы?
6. Что произойдёт, если участник не заполнит поле?

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

Согласие и иное основание обработки проектируются по целям. Европейский совет по защите данных (EDPB) в руководстве по Общему регламенту защиты данных (GDPR) требует конкретного, информированного и однозначного согласия, а также возможности доказать, как и когда оно получено. Этот документ не заменяет российскую юридическую проверку, но даёт полезный принцип: участие в событии и последующие маркетинговые коммуникации не следует прятать в одно неразличимое поле.

Если обработка опирается на согласие, в контракте данных могут понадобиться:

• цель;
• версия текста;
• время;
• источник интерфейса;
• результат выбора;
• способ изменения или отзыва в системе заказчика.

Сервис Google Customer Match показывает ещё одну границу. Рекламная платформа работает с собственными online и offline данными компании, а для партнёрских загрузок данных пользователей из Европейской экономической зоны требует сигналов согласия. Операционная передача регистрации в CRM сама по себе не означает разрешение на любую рекламную активацию. Эту цель, состав полей и основание заказчик согласует отдельно.

Как не создать дубли?

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

Salesforce разделяет правила поиска совпадений (matching rules) и правила обработки дублей (duplicate rules). Первые находят кандидатов, вторые определяют действие: предупредить, разрешить или заблокировать создание. Эта логика полезна вне конкретной платформы.

Рабочий порядок:

1. Найти запись по external_person_id, если он уже известен.
2. Проверить точный нормализованный email, если политика заказчика допускает его как ключ поиска.
3. Проверить другие подтверждённые идентификаторы.
4. Сформировать кандидатов по сочетанию более слабых признаков.
5. Не сливать автоматически при неоднозначном результате.
6. Создать новую мастер-запись только после прохождения правил.
7. Связать с ней новую регистрацию или активность, не перезаписывая историю.

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

Отдельная задача - идемпотентность, то есть безопасная повторная отправка. Если сеть оборвалась после записи, отправитель может не знать итог и повторить запрос. Один и тот же registration_id, attendance_id или activity_id должен обновить или подтвердить существующий объект, а не создать второй.

Проверьте минимум четыре случая:

Одна мастер-запись не означает одну строку на всё. Мастер относится к человеку. Регистрации, посещения и активности остаются отдельной историей вокруг него.

Владельцы отправки, приёма и ошибок

У обмена должны быть два названных владельца: со стороны отправителя и со стороны получателя. Первый отвечает за полноту, формат и повторную доставку. Второй - за схему CRM, правила принятия, связи и контрольное чтение записи. Без этой пары команды не понимают, кто исправляет ошибку и кто подтверждает повторный приём.

Распределение можно зафиксировать так:

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

Мы в «Авентуре» не внедряем CRM заказчика и не назначаем правила внутри неё. Мы можем описать источники данных мероприятия, согласовать формат передачи с профильной командой и проверить, что сценарий площадки даёт ожидаемые факты. За принимающую модель и права доступа отвечает владелец CRM заказчика.

Как проверить путь до открытия регистрации?

Сквозной тест начинается с действия участника и заканчивается контрольным чтением записи из CRM. Между этими точками команда отдельно проверяет источник, передачу и обработку данных. Ответ программного интерфейса или появление файла в папке подтверждает только промежуточный шаг. Запись считается принятой, когда в целевой системе проверены ключевые поля, связи, владелец и статус.

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

1. Нормальная регистрация. Заполните форму, сохраните UTM-контекст и проверьте registration ID.
2. Известный человек. Повторите регистрацию с person ID существующей тестовой мастер-записи.
3. Check-in. Отсканируйте тестовый бейдж и проверьте отдельный attendance ID.
4. Сессия или стенд. Создайте activity_id с event_id, типом действия, временем occurred_at и системой-источником source_system.
5. Встреча. Передайте время, владельца, исход и связи с человеком и компанией.
6. Повторная доставка. Отправьте тот же идентификатор записи ещё раз и убедитесь, что дубль не создан.
7. Ошибка справочника. Передайте неизвестный статус и проверьте, что система отклонила запись по согласованному правилу.
8. Пропущенное обязательное поле. Убедитесь, что причина ошибки понятна отправителю.
9. Контрольное чтение. Прочитайте CRM-запись и сравните значения, связи и владельца с ожиданием.
10. Исправление. Повторите запись после исправления без потери исходного ID и истории.

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

Нагрузочная проверка регистрации и check-in решает соседнюю задачу: выдержит ли контур плановый поток и что произойдёт при сбое. Её сценарии собраны в статье про нагрузочную репетицию регистрации и check-in. Здесь критерий приёмки ограничен смыслом и целостностью одной записи на всём пути.

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

Чек-лист готовности к запуску

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

1. У мероприятия есть стабильный event_id, а у регистрации, посещения и активности - собственные идентификаторы.
2. Человек, компания, регистрация, посещение и активность разведены по смыслу.
3. Статусы имеют коды, определения, владельцев и версию словаря.
4. Карта полей фиксирует типы, обязательность, преобразования, кампанию и ошибки.
5. Правила поиска совпадений, повторной отправки и обработки дублей согласованы отдельно.
6. Названы владельцы отправки, приёма и исправления ошибок.
7. Сквозной тест включает нормальную запись, известного человека, дубль, ошибку и контрольное чтение.
8. Владелец CRM подтвердил связи и версию схемы до открытия регистрации.

Эта готовность не заменяет дальнейшую работу с данными. Общую связь событий с коммерческой системой разбирает материал про event-led growth и воронку. Порядок передачи действий маркетингу и продажам после события вынесен в статью про SLA follow-up. Текущий контур заканчивается в момент, когда CRM приняла проверяемую запись с правильными связями и владельцем.

Мы в «Авентуре» можем собрать точки данных мероприятия в единое техническое задание, пройти путь гостя и провести совместный тест с командой заказчика. Запросите обсуждение проекта и предварительную смету. На встрече определим источники данных мероприятия, границы нашей работы и участников приёмки со стороны CRM.

Источники

• European Data Protection Board - Guidelines 05/2020 on consent
• CloudEvents specification 1.0.2
• HubSpot - CRM Properties API Guide
• HubSpot - Meetings API Guide
• Google Analytics - URL builders and UTM parameters
• IETF - RFC 9562: Universally Unique IDentifiers
• Microsoft Learn - View and manage event attendance
• Salesforce Trailhead - Resolve and Prevent Duplicate Data
• Adobe Experience Platform - XDM ExperienceEvent class
• W3C WAI - Forms Tutorial
• Google Ads - About Customer Match