CRM-аналитика
Как связать клиента с компанией и подпиской
Время чтения: 5 мин
Уровень материала: Для экспертов
Содержание
Анна управляет подписками двух компаний. У одной заканчивается пробный период, у другой действует годовой тариф. Если записать в профиль Анны единственное поле «тариф», очередное обновление сотрёт предыдущий контекст. Письмо о продлении может прийти с названием не той компании, неверной суммой или чужой ссылкой на оплату.
Customer.io — платформа для автоматизации клиентских коммуникаций. Помимо профилей людей она поддерживает objects: отдельные объекты, например компании и подписки. Relationship обозначает связь человека с объектом. У связи могут быть собственные данные, например роль сотрудника в конкретном аккаунте. Это позволяет описывать отношения точнее, чем набором общих полей человека. [1]
Задача маркетолога — заранее определить получателя и контекст каждого сообщения. Ниже — модель и проверки CRM Lab для продукта, где один человек участвует в нескольких аккаунтах.
Не переносите всю структуру базы данных в профиль
Разделите сущности. Человек — адресат сообщения. Компания — аккаунт, в котором работают люди. Подписка — договорённость о конкретном продукте, сроке и оплате. Роль — отношение человека к аккаунту или подписке: администратор, плательщик, участник.
В текущей документации Customer.io описаны связи объектов с людьми; прямые relationships между двумя объектами не поддерживаются. [1] Поэтому нельзя просто нарисовать цепочку «человек → компания → подписка» и ожидать, что платформа автоматически пройдёт по ней при отправке.
Один рабочий вариант: связать человека отдельно с компанией и с подпиской, а в объекте подписки хранить account_id. Это поле сохраняет принадлежность подписки, но само по себе не создаёт встроенную связь объектов. Нужные для письма сведения о компании придётся подготовить в модели данных или получить предусмотренным интеграцией способом.
| Сущность | Пример данных | Зачем нужна в сообщении |
|---|---|---|
| Человек | person_id, имя, канал | Кому адресована коммуникация |
| Компания | account_id, название | О каком рабочем аккаунте речь |
| Подписка | subscription_id, account_id, срок | Какое обязательство нужно продлить |
| Связь с подпиской | роль, актуальность участия | Имеет ли человек отношение к оплате |
Запускайте сообщение от конкретной причины
Customer.io позволяет использовать изменения объектов и отношений как основание автоматизации и уточнять аудиторию связанных людей. Важен объект, который вызвал запуск: именно он определяет предмет текущего сообщения. [2]
Для напоминания о продлении формулировка «у человека есть заканчивающаяся подписка» недостаточна. Нужно знать, какая именно. Иначе шаблон может взять первую подходящую запись или последнее обновлённое поле, и результат будет зависеть от случайного порядка данных.
Составьте контракт запуска: subscription_id, account_id, причина сообщения, срок, версия условий и получатели с нужной ролью. Затем выберите поддерживаемый способ передать этот контекст в автоматизацию. Название объекта в интерфейсе не заменяет проверку фактических данных, доступных шаблону в вашем типе запуска.
Разделите событие запуска и текущее состояние
Условный пример. Подписка S10 компании A заканчивается 30 сентября. Анна связана с ней как плательщик. Подписка S20 компании B действует до марта. Запуск по S10 должен использовать название A, срок S10 и ссылку на управление S10. Сведения о S20 не участвуют в письме, хотя доступны у того же человека.
Теперь добавим задержку на два дня. За это время подписку S10 могли продлить, а Анну — убрать из плательщиков. Перед отправкой нужно проверить актуальное состояние. Сохранённый контекст объясняет, почему путь начался; текущие данные определяют, имеет ли смысл продолжать.
Для значений, которые должны оставаться историческими, сохраняйте снимок: например, условия предложения на момент входа. Для оплаты, роли и отмены используйте актуальную проверку. Иначе обновление объекта либо перепишет смысл старого предложения, либо устаревшее значение приведёт к ненужному письму.
Проверьте несколько отношений одновременно
Минимального теста с одним человеком и одной компанией недостаточно. Создайте адресата с двумя компаниями, двумя подписками в одной компании и разными ролями. Поочерёдно меняйте только одну подписку и смотрите, кому и о чём сформировалось сообщение.
Отдельно проверьте отсутствие плательщика, удаление связи после входа, смену администратора и одновременное продление двух подписок. Если письмо должно получать несколько ответственных, определите, допустимы ли отдельные сообщения каждому или нужен один основной адресат.
У объектных запусков есть ограничения масштаба: документация Customer.io отдельно описывает предел числа связанных людей для одного запуска. Учитывайте его при проектировании крупных аккаунтов и проверяйте текущий лимит перед реализацией. [2] Разбивать бизнес-объекты искусственно только ради обхода ограничения следует лишь после оценки последствий для данных и сценариев.
Зафиксируйте проверки шаблона и доступа
Проверьте в готовом письме не только имя. Название компании, тариф, сумма, валюта, срок и адрес кнопки должны относиться к одной подписке. Если обязательного поля нет, выберите понятное поведение: остановить отправку и сообщить команде, а не подставлять сведения другой компании.
Ссылка из письма не должна сама давать доступ к чужому аккаунту. Права на просмотр и изменение подписки проверяет продукт при переходе. Корректная персонализация текста не заменяет проверку доступа.
На выходе сохраните схему сущностей, правила обновления связей, контракт запуска и проверенные примеры. Если позже появится новый тип подписки или роль, команда сможет оценить изменение до массовой отправки. Так команда сможет управлять коммуникациями с участниками нескольких аккаунтов без случайной подстановки чужих данных.
Источники
1. Customer.io. Relationships. Customer.io Documentation. Проверено 23.09.2026.
2. Customer.io. Objects and relationships in automations. Customer.io Documentation. Проверено 23.09.2026.