FBCLID не сохраняется в CRM

Введение

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

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

Симптомы

Обычно это замечают уже после того, как редирект-цепочка выглядит здоровой. fbclid виден в итоговом URL, но в CRM, webhook-пейлоаде или экспорте лидов поле все равно пустое.

• Итоговый URL лендинга содержит fbclid, а CRM-запись лида - нет.
• После изменений в форме, CRM или middleware падает качество Meta-атрибуции.
• Скрытые поля передают UTM, но не передают отдельное поле для fbclid.
• Браузерные события выглядят нормально, а серверные Meta-события или экспорт лидов уже не могут связаться с исходным кликом.

Типовые причины

Чаще всего ломается именно слой захвата и хранения, а не сам редирект. Скрипт формы сохраняет только UTM, middleware переименовывает поле по дороге в CRM, или схема CRM просто не принимает значение, потому что поле не было согласовано.

Смотрите на задачу как на аудит hand-off: URL в браузере, скрытое поле, payload запроса, преобразование в middleware, поле в CRM и любой downstream экспорт должны показывать один и тот же идентификатор.

• Скрытое поле есть, но ни один скрипт не копирует fbclid туда до отправки формы.
• SPA-навигация или cleanup URL удаляют параметр раньше, чем форма или пиксель успевают его прочитать.
• Middleware умеет работать только с generic click ID и игнорирует Meta-специфичное поле.
• CRM-валидация, лимиты длины или allowlist режут незнакомые tracking-ключи.
• Lead routing, webhook или постбек-слой перезаписывают идентификатор пустым fallback-значением.

Как проверить

Работайте только с реальной production-ссылкой из Meta. Очищенные тестовые URL часто скрывают именно тот hand-off, который и ломает сохранение идентификатора.

Проверка должна идти по шагам: URL лендинга, хранение на странице, payload формы, CRM-запись и любой серверный export или Meta-event, который зависит от того же поля.

1. Подтвердите, что fbclid доходит до лендинга

   Пропустите боевой URL через Redirect Checker, а затем откройте итоговый адрес в Click ID Extractor, чтобы доказать: fbclid есть на странице в момент загрузки.

2. Проверьте захват до отправки формы

   Посмотрите hidden inputs, cookies, localStorage и кастомные capture-скрипты: страница должна сохранить fbclid до перехода по SPA-роуту, consent callback или submit формы.

3. Сравните network payload и CRM-запись

   Откройте network tab или webhook-логи и сравните имя поля и значение в отправленном запросе с тем, что оказалось в CRM после создания лида.

4. Проверьте downstream Meta hand-off

   Если CRM дальше отправляет лиды в offline uploads или server-side events, убедитесь, что там используется то же значение, а не пустое поле или generic click-ID fallback.

Как исправить

Исправляйте первый доказанный hand-off, а затем повторяйте полный путь. Если формой, middleware и CRM владеют разные команды, соберите redirect-лог, payload и скрин CRM в единый Tracking Audit бриф до эскалации.

Не смешивайте этот сценарий с FBCLID Lost After Redirect: тот гайд нужен, когда параметр не доживает до страницы, а этот - когда страница уже получила его, но CRM все равно не сохранила.

1. Сохраняйте fbclid сразу при загрузке страницы

   Записывайте идентификатор в hidden field, cookie или browser storage до того, как SPA-навигация, consent callback или cleanup URL успеют убрать его из адресной строки.

2. Выберите одно каноническое CRM-поле

   Оставьте одно имя поля для Meta click ID и используйте его одинаково в форме, webhook payload, middleware-трансформации и схеме CRM.

3. Почините middleware и lead routing

   Обновите Zapier-шаги, serverless-обработчики, form processors или CRM middleware так, чтобы они передавали сохраненное значение, а не удаляли неизвестные ключи или подставляли default.

4. Синхронизируйте downstream Meta и отчетные потоки

   Если конверсии уходят через постбеки или Conversions API, сравните CRM-поле с payload в Postback Tester и с серверными Meta-событиями, которые строятся на том же идентификаторе.

5. Перепроверьте и заархивируйте чистый путь

   Повторите тот же боевой клик, убедитесь, что CRM теперь хранит fbclid, и сохраните redirect-лог, скрин payload и подтверждение из CRM в заметках Tracking Audit.

Какие инструменты использовать

Практический процесс простой: доказать, что идентификатор доходит до страницы, проверить сохранение, протестировать downstream callback и собрать повторно используемый audit-пакет для следующих запусков.

Выводы

Фикс можно считать завершенным только тогда, когда один и тот же fbclid виден на лендинге, в отправленном payload, в CRM-записи и в downstream Meta- или отчетных потоках. После этого сохраните доказательства в Tracking Audit, чтобы следующий запуск начинался с проверенного эталона.

Похожие проблемы

• FBCLID Lost After Redirect
• Click ID не сохраняется в CRM
• Facebook CAPI не срабатывает

Материалы базы знаний

• fbclid пропадает после редиректа
• How to check if fbclid reaches the landing page
• Click ID не попадает в CRM