Нативная интеграция выглядит привлекательно: кнопка “Подключить” в обоих интерфейсах, пара кликов - и системы “связаны”. Маркетолог ставит галочку, закрывает задачу. Через три месяца оказывается, что данные в двух системах расходятся, attribution сломан, а RevOps не может объяснить инвестору почему CAC по LinkedIn кажется нулевым.
Нативные интеграции не плохи сами по себе - они плохи для конкретных задач, для которых не предназначены.
Что нативная интеграция делает хорошо
Синхронизация справочных данных: названия компаний, контактная информация, статические поля. HubSpot + Salesforce нативная интеграция хорошо синхронизирует Company records. Mailchimp + HubSpot нативная интеграция нормально синхронизирует списки контактов для email.
Это работает потому что данные медленно меняются, структуры совпадают, и потеря одной записи некритична.
Где нативная интеграция ломает данные
Временные метки. Нативная интеграция часто передаёт “время синхронизации”, а не “время события”. HubSpot + Salesforce: если сделка закрылась в понедельник, а синхронизация запустилась в среду - в Salesforce она появится с датой среды. Когортный анализ по дате закрытия становится бесполезным.
Attribution source. HubSpot + Klaviyo нативная интеграция создаёт контакты в Klaviyo - но без UTM-параметров из HubSpot. Email subscriber в Klaviyo потерял источник (откуда пришёл на сайт). Аналитика по каналам в Klaviyo бесполезна.
Engagement history. HubSpot + Zoom нативная интеграция создаёт Meeting record в HubSpot при проведении Zoom-звонка. Но если звонок отменён и проведён повторно - в HubSpot два Meeting, без пометки что первый не состоялся. Менеджер видит “2 встречи” вместо “1 встреча”.
Duplicate prevention. CRM + email marketing нативная интеграция часто создаёт дубли: контакт существует в HubSpot с email A, создаётся в Mailchimp с email B (та же persona, другой адрес) - нативная интеграция создаёт второй HubSpot contact вместо merge.
Конкретный пример: HubSpot + Slack нативная интеграция
Нативная интеграция: уведомления о сделках в Slack-канал при смене стадии. Выглядит полезно. Проблемы:
- Уведомления дублируются при нескольких изменениях в день
- Нет логики “не уведомлять о тестовых сделках”
- Нельзя настроить разные каналы для разных pipeline
- Данные из Slack-треда не попадают обратно в HubSpot Deal
В итоге Slack засорён нотификациями, которые никто не читает, и команда отключает интеграцию через месяц.
Когда нужна кастомная интеграция
Признаки что нативная интеграция не справляется:
- Данные в двух системах расходятся больше чем на 5%
- Приходится вручную корректировать записи после синхронизации
- Attribution-отчёты не сходятся с реальными источниками лидов
- Нативная интеграция не поддерживает нужное событие или поле
Кастомная интеграция - не разработка с нуля. Это webhook-обработчик + API-логика на 100-300 строк кода, который делает ровно то что нужно и не делает ничего лишнего. Время разработки: 1-3 дня для типовых сценариев.
Примеры того что решается кастомно: передача Loom video views в HubSpot Deal, учёт Harvest времени в Deal Timeline, синхронизация статусов Shortcut Stories с Kommo сделками. Каждый из этих сценариев невозможен нативно - и каждый занимает конкретный день разработки.
Практический чеклист
Перед тем как нажать “Подключить”:
- Что конкретно синхронизируется? Запросите документацию, не верьте маркетингу
- В какую сторону? Однонаправленная синхронизация часто создаёт конфликты
- Что происходит при конфликте? “Выигрывает” какая сторона?
- Передаёт ли интеграция временные метки события или синхронизации?
- Есть ли дедупликация? По какому полю?
Если на любой из этих вопросов нет чёткого ответа в документации - нативная интеграция создаст проблемы при масштабировании.
Если нужна оценка конкретной интеграции в вашем стеке - команда exceltic.dev разбирает такие задачи как часть технического аудита.