Как мы провели интеграцию Kommo и Facebook Pixel чтобы отследить пользовательское поведение в воронке продаж

*Признан экстремистской организацией, запрещённой на территории РФ.

Клиент активно использует таргетированную рекламу в *Facebook и Instagram для генерации лидов. Лиды попадают в CRM Kommo, где проходит дальнейшая работа, но до интеграции рекламный кабинет никак не был связан с CRM.

Нужно было:

Мы провели несколько рабочих сессий с отделом продаж клиента и выбрали четыре события, которые наиболее точно отражают воронку:

1. Когда сделка попадает в воронку Initial Consultation — это означает, что пользователь проявил реальный интерес, и менеджер начал с ним работу.

2. Когда сделка доходит до стадии Contract Signed — финальная точка, показывающая конверсию в платящего клиента.

3. Когда контакту в Kommo присваивается тег Interested — это может быть результатом звонка, формы, уточняющего вопроса. Такой контакт ещё не в воронке, но точно тёплый.

4. Когда присваивается тег After Appointment — это значит, что человек прошёл консультацию, пусть и не купил.

Мы настроили систему на базе вебхуков Kommo, промежуточного сервера и API *Facebook. При каждом изменении сделки или контакта срабатывает вебхук, отправляя ID сущности и тип изменения. Затем наша логика проверяет условия (например, входит ли сделка в нужный пайплайн, изменился ли тег), извлекает нужные данные, хэширует чувствительные поля (email, телефон), и формирует запрос в Conversion API.

Пример запроса включает поля:

После формирования запроса данные отправляются в Conversion API *Facebook через безопасное соединение с использованием access token и идентификатора пикселя, которые мы заранее сохранили в переменных окружения. Это обеспечивает безопасность и удобство обновления ключей доступа без необходимости вмешательства в основной код.

Чтобы гарантировать доставку событий даже при временных сбоях на стороне *Facebook, мы внедрили систему повторных отправок. Если API *Facebook возвращает ошибку — например, из-за превышения лимита запросов или сетевой проблемы — событие помещается в очередь и повторно отправляется через заданный интервал. Интервалы наращиваются по экспоненциальной схеме, что позволяет избежать перегрузки и соответствует лучшим практикам для работы с внешними API.

Особое внимание было уделено обработке событий, связанных с тегами, поскольку Kommo не всегда стабильно присылает вебхуки при добавлении тегов вручную. Чтобы покрыть этот сценарий, мы реализовали отдельный фоновый процесс. Он регулярно опрашивает API Kommo, получая актуальные теги всех лидов и сравнивает их с сохранёнными значениями. При обнаружении новых тегов, соответствующих условиям (например, «Interested» или «After Appointment»), система инициирует отправку соответствующего события в *Facebook.

Для контроля и отладки мы встроили полноценную систему логирования. Все входящие вебхуки, ответы от API, а также сами запросы в Conversion API сохраняются в базе с отметками времени. Это позволяет видеть, какие события были отправлены, какие были проигнорированы, и какие — отправлены повторно.

Интеграция Kommo с *Facebook Conversion API позволила наладить точную передачу ключевых событий — таких как переход лида в нужный этап воронки, подписание контракта или появление интереса — напрямую в рекламный кабинет. Благодаря этому рекламные алгоритмы *Facebook  начали получать не поверхностные сигналы вроде заполнения формы, а реальные действия, отражающие бизнес-ценность лида.

Это обеспечило более точную оптимизацию кампаний и снижение стоимости привлечения клиента. *Facebook начал обучаться на чистых, актуальных данных, что повысило рентабельность рекламы.

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