Данные из формы захвата: 4 точки до CRM, где их могут перехватить

Когда пользователь нажимает «Отправить заявку», большинство владельцев бизнеса думают одно: данные ушли в CRM. Зафиксировано, защищено, в работе у менеджера.

Между кнопкой «Отправить» и появлением лида в вашей CRM данные проходят минимум 4 промежуточных этапа. На каждом открыты разные каналы, через которые информация о клиенте может уйти не туда.

Архитектура современного веба устроена именно так - вне зависимости от того, знаете вы об этом или нет. Разберём каждый этап.

Если вы уже теряли заявки или замечали, что конкуренты звонят вашим клиентам первыми - начните с проверки периметра. Детали на stopparsing.ru.

Все думают, что форма напрямую связана с CRM. Это не так

Коротко: между формой и CRM всегда есть промежуточные слои. Их количество зависит от архитектуры сайта - от одного до четырёх и более.

Промежуточные слои - это нормальная часть архитектуры, не баг. Форма - это HTML-элемент на странице. CRM - это отдельная система на другом сервере, часто в другой компании. Между ними должна быть цепочка обработки.

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

Этап 1: что происходит в браузере до нажатия «Отправить»?

Коротко: на большинстве коммерческих сайтов работает несколько сторонних скриптов одновременно. Часть из них технически имеет доступ к полям формы.

Пока пользователь заполняет форму, на странице активны скрипты:

  • счётчики веб-аналитики (Яндекс.Метрика, Google Analytics)
  • пиксели рекламных платформ (ВКонтакте, myTarget)
  • виджеты онлайн-чатов и обратных звонков
  • скрипты A/B-тестирования
  • инструменты записи сессий

Каждый из этих скриптов загружен в браузер пользователя и работает в том же JavaScript-окружении, что и сама форма. Это не значит, что все они считывают данные из полей - большинство этого не делают по умолчанию. Но технически такая возможность существует, и конфигурация конкретного скрипта определяет, что именно он собирает.

Некоторые трекинговые системы намеренно собирают содержимое заполненных полей как часть поведенческой аналитики. Задача таких систем - знать, что пользователь вводил на сайте конкурента.

Вы оплатили рекламу, пользователь пришёл на ваш сайт и начал заполнять форму. В этот момент, ещё до нажатия «Отправить», его данные могут уже быть собраны.

Этап 2: как данные идут от браузера к серверу?

Коротко: при HTTPS-соединении данные в transit зашифрованы. Но факт самой передачи и её метаданные видны аналитическим системам.

При нажатии «Отправить» браузер отправляет данные формы на сервер через HTTP-запрос. Если сайт работает по HTTPS - а сегодня большинство коммерческих сайтов так и работает - содержимое этого запроса зашифровано. Это значит, что «прочитать» данные на уровне сетевого трафика значительно сложнее.

Но метаданные передачи остаются видимыми. Какой домен, когда, как часто, с какого устройства. Для систем, которые агрегируют данные о поведении пользователей, этого иногда достаточно - не содержимое формы, но сам факт «этот пользователь отправил заявку на этом сайте».

Сам запрос формы также может обрабатываться несколькими системами по пути - если сайт использует CDN или реверс-прокси с функцией логирования запросов.

О том, как автоматические системы проверяют формы без ведома владельца, подробно написано в этом разборе.

Этап 3: кто обрабатывает форму на стороне сервера?

Коротко: если форма реализована через сторонний сервис - ваши данные проходят через сервер этого стороннего сервиса. Это третья сторона с доступом к информации о ваших клиентах.

Вот где начинается то, о чём многие не думают.

Формы на современных сайтах редко обрабатываются напрямую собственным сервером. Чаще используется один из вариантов:

Конструктор сайта со встроенными формами (Tilda, Битрикс24.Сайты, Wix). В этом случае данные идут на серверы платформы-конструктора - прежде чем попасть к вам.

Специализированный сервис форм (Typeform, JotForm, Marquiz и аналоги). Данные идут на серверы этого сервиса. Вы получаете их уже оттуда - через API или уведомления.

Собственный backend - данные обрабатывает ваш сервер напрямую. Это вариант с наибольшим контролем.

Разница принципиальная. В первых двух случаях сторонний сервис является посредником, у которого есть копия ваших данных. Условия использования этих данных определяет сервис, не вы.

Если вы не уверены, через какие системы проходят ваши заявки прямо сейчас - с этого и начинается аудит периметра. Что именно закрывает StopParsing и как считается стоимость защиты - на сайте.

Этап 4: что происходит между обработчиком формы и вашей CRM?

Коротко: данные редко идут напрямую из формы в CRM. Между ними обычно стоит интеграционный слой - ещё одна точка прохождения.

Предположим, форма обрабатывается вашим сервером или платформой-конструктором. Теперь данным нужно попасть в CRM.

Для этого используется один из механизмов:

Вебхук - сервер автоматически делает POST-запрос на URL вашей CRM или интеграционного сервиса. Данные передаются как структурированный JSON. Любой, кто знает URL вебхука, может отправить туда запрос.

Интеграционный сервис (Albato, Make.com, n8n) - посредник, который принимает данные от формы и передаёт их в CRM. Ещё одна система с копией данных.

Самописный API-коннектор - скрипт, который вы или разработчик написали для передачи данных. Качество защиты здесь зависит от того, как он написан.

Каждый интеграционный инструмент - это отдельная система с доступом к данным ваших клиентов. И каждый из них - потенциальная точка утечки, если:

  • учётные данные к сервису скомпрометированы
  • сам сервис имеет уязвимость
  • URL вебхука стал известен третьим лицам

Где конкретно данные могут уйти на сторону?

Коротко: 4 точки риска - браузер, транзит, сервер обработки, интеграционный слой. Уязвимость каждой зависит от архитектуры.

Этап Что происходит Риск
Браузер Сторонние JS-скрипты на странице Трекинговые системы могут собирать данные из полей
Transit (HTTPS) Передача браузер - сервер При HTTPS - низкий. Метаданные передачи видны
Обработчик формы Сторонний сервис форм или конструктор Данные хранятся у третьей стороны
Интеграция Вебхук, сервис интеграции Дополнительные посредники с доступом к данным

Ни одна из этих точек не является автоматически «дырой». Каждая - это вопрос конкретной конфигурации. Но каждая требует осознанного решения о том, как она защищена.

Рекламный бюджет, который работает на конкурента

Коротко: если данные заявки уходят до попадания в вашу CRM, вы платите за трафик, конверсию которого получает кто-то другой.

Вот как это работает на практике.

Вы настраиваете рекламу. Платите за каждый клик. Пользователь переходит на сайт, видит предложение, начинает заполнять форму захвата. На этом этапе его данные уже могут быть в системе сбора данных - ещё до того, как он нажал «Отправить».

Конкурент, использующий такую систему, получает контакт раньше вас. Он звонит первым. К тому моменту, когда заявка попадает к вашему менеджеру, клиент уже разговаривает с другим продавцом.

В аналитике это выглядит как обычная заявка, которую «не закрыли». В отчёте о рекламе - как конверсия, которая не дошла до сделки. Причина не в менеджере и не в скрипте продаж. Просто конкурент позвонил раньше.

Именно это описывает четвёртый риск, который закрывает StopParsing: «Каждый переход оплачен вами; если контакт попал в перехват раньше заявки - вы платите за чужую продажу».

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

Как закрыть эти каналы?

Коротко: StopParsing закрывает формы захвата как часть периметра - делает сбор данных из них значительно сложнее для систем перехвата.

Технически «закрыть» все риски разом не получится - это часть архитектуры веба. Но значительно осложнить работу систем сбора данных можно.

Формы захвата входят в периметр защиты StopParsing наравне с сайтом и телефонами сотрудников. Конкретные каналы закрытия определяются по результатам аудита - потому что у каждого сайта своя архитектура и свой набор уязвимых точек.

Первый шаг - аудит периметра: вы передаёте список сайтов и номеров сотрудников, специалисты показывают, какие данные доступны системам сбора прямо сейчас. После этого формируется план защиты и считается стоимость - не «пакет вслепую», а цена по реальному объёму.

Честно: гарантий абсолютной защиты нет. Риск снижается ощутимо - но «полностью исключить» невозможно. StopParsing говорит «намного сложнее» и «значительно труднее», а не «100% защита» - потому что это правда.

О том, как парсинг сайтов соотносится с 152-ФЗ и что считается законным, - читать отдельный разбор.

Про то, с чего начинается аудит периметра и что он показывает, - подробнее здесь.

Слоган сервиса точно описывает логику: «Никто не уведёт то, что не смог собрать».

Начать с аудита периметра - бесплатно. Стоимость защиты считается по результатам, не вслепую.

Узнать, что видно о вашем сайте - stopparsing.ru

Источники

  • STOPPARSING-FACTS.md - официальные данные о сервисе StopParsing (периметр защиты, риски, механика работы)
  • Общие принципы архитектуры веб-форм: стандарты HTML Living Standard (WHATWG), MDN Web Docs - обработка форм
  • Принципы работы HTTPS: RFC 8446 (TLS 1.3), описание шифрования транзитных данных
  • Архитектура вебхуков: RFC 7230-7235 (HTTP/1.1), описание POST-запросов и их обработки