Мост CRM
Когда сеанс получает имя, запись становится заметкой к уже существующему человеку в CRM, без создания нового.
1. Одним предложением
При идентификации сеанса мы ищем человека в CRM по переданному ID и добавляем заметку со ссылкой на запись.
Всё. Без новых контактов, сделок и изменений воронки продаж. CRM с дублем на каждый визит к ценам хуже отсутствия интеграции.
Если человек не найден, ничего не происходит. Создать его значило бы записать данные в CRM из браузерного сеанса, а сеанс не является источником истины о клиентах.
2. Ключ сопоставления
Уделите этому десять минут: именно здесь CRM-интеграция обычно незаметно ошибается.
Мы знаем посетителя по сообщению сайта: MousePlayer.setUserId(), ID аналитики или серверному identify. CRM тоже знает его по чему-то. Эти значения должны совпадать.
| Поиск по | Можно изменить | |
|---|---|---|
| HubSpot | почте контакта | нет — эндпоинт поиска построен вокруг неё |
| Pipedrive | людям по term, сначала почта | нет |
| Salesforce | полю, заданному вами, по умолчанию Email | да |
Почему Salesforce спрашивает
Salesforce редко использует почту ключом. У вас это может быть Customer_Number__c или внешний ID платёжной системы. Поиск по почте ничего бы не нашёл и сообщил успех — худший сбой, когда интеграция выглядит живой.
Поэтому форма спрашивает: какое поле Contact содержит переданное значение? Укажите API-имя, включая __c для собственного поля.
Имя строго проверяется до запроса. Только буквы, цифры и подчёркивание; остальное отклоняется, а не экранируется: в экранировании можно незаметно ошибиться, в отказе нет.
3. Когда срабатывает и когда намеренно нет
При идентификации: сайт вызывает MousePlayer.setUserId(), мост читает ID PostHog, Mixpanel или Amplitude либо сервер вызывает identify.
Один раз за сеанс, не за страницу
Вход с последующим просмотром одиннадцати страниц даёт одну заметку. Историю CRM читают люди.
Не без идентификатора
Анонимный сеанс не с чем сопоставить. Мы не угадываем по IP и не прикрепляем запись к случайному владельцу того же адреса.
Не для неизвестного CRM человека
Считается выполненным, а не сбоем: потенциальный клиент вне CRM — обычный случай, повтор завтра не поможет.
4. Вид заметки и хранение токена
Одна заметка в истории контакта: строка о записи сеанса и ссылка. Продавец смотрит реальные действия до обращения.
Учётные данные
Хранятся с шифрованием AES-256-GCM. Не показываются после сохранения: поле со звёздочками, его повторное сохранение не меняет значение. Во внутреннюю очередь задачи не попадают: общее состояние — неверное место для ключа.
Salesforce нужно три значения, остальным два
Salesforce использует Connected App с токеном обновления, поэтому требует consumer key, secret, refresh token и URL экземпляра. HubSpot и Pipedrive — один API-токен. Приложение ваше: MousePlayer не запускает приложение маркетплейса, которому нужно доверять.
5. Zoho CRM и Freshsales
Ещё две CRM на противоположных концах сложности настройки.
| Zoho CRM | Freshsales | |
|---|---|---|
| Вы указываете | дата-центр, ID клиента, секрет клиента, токен обновления | API-ключ и домен Freshworks |
| Поиск по | заданному полю, по умолчанию Email | заданному полю, по умолчанию email |
| Заметка попадает | к контакту как запись Note | к контакту как заметка |
Zoho в одном из шести дата-центров
Аккаунт находится в com, eu, in, com.au, jp или com.cn, а ключ не указывает где. Неверный центр даёт INVALID_TOKEN — выглядит как неверный ключ и ведёт не туда. Поэтому поле — выпадающий список.
Self Client один раз
Создайте Self Client в консоли Zoho API, получите grant token для ZohoCRM.modules.ALL и ZohoSearch.securesearch.READ и обменяйте один раз на refresh token. Он бессрочный; часовые access token получаются из него и не хранятся.
Zoho отвечает 200 при отказе
Обмен токена и запись могут вернуть HTTP 200 с ошибкой или статусом записи в теле. Мы читаем тело: доверие только к коду сообщило бы успех для несуществующей заметки.
Все названные товарные знаки принадлежат владельцам. У MousePlayer нет деловых отношений с поставщиками.