Proje vitrini hazırlanıyorPreparing project showcaseПодготавливаем витрину проекта

Управление лидами

Фильтр дублей в формах: когда один человек заполняет её дважды

Один человек, две заявки, две карточки в CRM. Как выбрать ключ сопоставления, что предпочесть — объединение или обновление, и какие поля защитить от перезаписи.

Rocketly · 2026-09-05

Вторник, 09:40. Маркетинг запустил анонс вебинара, за ночь форма регистрации собрала 214 заявок. Менеджер открывает список, проходит первые тридцать звонков и на третьем слышит один и тот же голос второй раз: «Мы же с вами утром уже говорили». Человек заполнил форму дважды — сначала с личной почты, потом с рабочей, потому что письмо с подтверждением так и не пришло. В списке две строки, два ответственных, две отдельные истории звонков. Ошибки не допустил никто: форма отработала ровно так, как её собрали, просто одного человека она приняла за двух.

Ниже разберём ситуацию по порядку: почему приходит повторная заявка, по какому правилу запись вообще считается дублем, как выбрать ключ сопоставления, что делать при повторе — объединять, обновлять или игнорировать, какие поля можно перезаписывать, а какие защищать, почему фильтр дублей не заменяет антиспам, что меняется в ответственности и отчётности, что происходит с персональными данными и в каком порядке настраивать форму перед публикацией.

Почему один и тот же человек заполняет форму дважды?

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

Второй источник — смена «личности». В одной заявке имя и фамилия, в другой только имя. Здесь мобильный, там номер приёмной. Сначала личная почта, потом корпоративная. Один человек — три разных ключа. В сценариях с записью это заметнее: если посетитель и форму заполнил, и воспользовался ссылкой для онлайн-записи, которая пишет прямо в CRM, один и тот же человек входит через две разные двери.

Третий источник — время. Тот же контакт полгода назад скачал прайс, а сегодня оставил заявку на демо. Обе заявки настоящие и обе важны, но это не два человека, а два касания одного. Именно на этот вопрос правило дедупликации должно ответить первым: вы обезличиваете повторы по человеку или по запросу?

  • Технический повтор: страница подвисла, посетитель нажал «Отправить» дважды. Одинаковое содержимое с разницей в секунды.
  • Канальный повтор: одну кампанию увидели в двух размещениях и заполнили обе формы.
  • Повтор по личности: тот же человек пришёл с другой почтой или другим номером.
  • Повтор во времени: два интереса с разницей в месяцы, человек один.

Когда заявка на самом деле считается дублем?

Дублирование — это не техническое равенство, а решающее правило. «Одна и та же строка записана дважды» и «один и тот же человек написал дважды» — разные задачи с разными решениями. Первая обычно выглядит как серия одинаковых заявок с разницей в секунды, и её закрывает короткое временное окно. Вторая относится к модели данных: какое поле определяет человека?

На практике задают три порога сразу. Первый — совпадение ключа: какие поля при равенстве означают одного человека. Второй — временное окно: сколько это совпадение остаётся действительным. Третий — действие: что происходит при совпадении. Фильтр, собранный без всех трёх, либо слишком агрессивен и съедает настоящие обращения, либо слишком мягок и не останавливает ничего.

В Form Builder эту логику воплощает фильтр дублей: повторные заявки с той же почтой или тем же телефоном сводятся к одному контакту, вторая запись в CRM не создаётся. Заявка сохраняется, человек не удваивается. Разбор того, что уже накопилось в базе, — отдельная работа: как находить и объединять дублирующиеся лиды, мы разобрали в отдельном материале. Фильтр на стороне формы нужен как раз для того, чтобы такую уборку не пришлось повторять.

Что брать ключом сопоставления: почту или телефон?

Почта пишется стабильнее, но легко множится: у одного человека может быть три адреса. Телефон — более уникальный идентификатор, но записывается небрежно: с восьмёркой и с плюс семёркой, с пробелами и дефисами. Если ключом будет телефон, сначала нужно описать правило нормализации: код страны всегда приводим к одному виду, пробелы и дефисы убираем, ведущий ноль отбрасываем. Без этого правила каждый формат создаёт нового человека.

Второй вопрос — вы дедуплицируете человека или компанию. В B2B форму могут заполнить три сотрудника одной организации, и это действительно три разных контакта, но привязать их надо к одной сделке. Чтобы различать это, нужно понимать, как записи расходятся по уровням; правило дублей, собранное без ясной модели данных CRM с контактами, компаниями и сделками, спокойно затрёт второго законного сотрудника первым.

Самая устойчивая схема — не один ключ, а приоритет: сначала проверяем совпадение по почте, затем по нормализованному телефону, и только если совпадений нет, создаём новый контакт. Здесь всё решает сопоставление полей с CRM: сравнение идёт по тому полю CRM, к которому привязано поле формы. Если поле почты привязано к текстовому примечанию, фильтр не найдёт ничего — там, куда он смотрит, данных просто нет.

Объединить, обновить или игнорировать — что выбрать?

При совпадении есть три варианта, и все три законны. Ошибка — не знать, какой из них у вас включён.

Объединить. Новая заявка записывается как ещё одно касание под существующим контактом, вторая карточка не создаётся. История собирается в одном месте: менеджер видит рядом и скачанный прайс, и более поздний запрос на демо. Для большинства сценариев это разумное значение по умолчанию.

Обновить. Поля новой заявки перезаписывают существующие. Телефон меняется, должность меняется. Данные освежаются, но при небрежной настройке пустое поле затирает заполненное.

Игнорировать. Заявка фиксируется, но в CRM ничего не меняется. Это оправдано только для технических повторов — полностью одинаковых отправок с разницей в секунды. Применённое к длинным повторам, это означает тихо выбросить настоящее обращение.

Если фильтр включают поздно и список уже перемешан, не стоит править записи по одной. Применить то же правило один раз ко всей истории через массовое редактирование и групповые действия, а дальше держать форму настроенной правильно — заметно быстрее.

Какие поля перезаписываются, а какие остаются нетронутыми?

Именно здесь начинаются настоящие споры об объединении. Утверждение «новые данные всегда точнее» ложно: во второй заявке человек мог второпях указать только имя и почту, а поле бюджета оставить пустым. Если эта пустота сотрёт бюджет из первой заявки, качество данных не вырастет, а упадёт. Таблица ниже даёт практическое значение по умолчанию для каждого типа поля.

Тип поляПримерПоведение по умолчаниюОбоснование
Ключ идентификацииПочта, телефонСохранить, новый добавить как запаснойСмена ключа ломает прошлые совпадения
Изменяемый профильДолжность, компания, городОбновлять, если заполнено; пропускать, если пустоСвежие данные профиля обычно актуальнее
Коммерческий интересБюджет, потребность, объёмНе перезаписывать, добавлять новым касаниемДва запроса должны читаться раздельно
АтрибуцияUTM-источник, кампанияПервый сохранить, последний записать рядомПервое и последнее касание отвечают на разные вопросы
Свободный текстСообщение, заметкаНе затирать, дописывать нижеПерезапись текста — прямая потеря информации

Один раз записанная таблица закрывает большую часть будущих споров. Та же логика работает и между системами: если форма питает CRM, а CRM питает что-то ещё, заранее решите, какая сторона владеет каким полем. Когда вы настраиваете интеграцию ERP и CRM, тот же вопрос задаётся снова — уже не на уровне записи, а на уровне системы.

Заменяет ли фильтр дублей защиту от спама?

Нет. Они решают разные задачи и не подменяют друг друга. Антиспам спрашивает, пришла ли заявка от живого человека. Фильтр дублей спрашивает, есть ли этот живой человек уже в базе. Останавливать ботов дедупликацией бессмысленно: боты каждый раз генерируют новый адрес, и совпадений просто не будет.

В Form Builder эти слои разведены. Ловушка для ботов и лимит частоты отсекает автоматический трафик на входе: невидимое поле-ловушка плюс ограничение числа отправок с одного IP. Защита от спама отправляет в корзину спама заявки, у которых оценка reCAPTCHA v3 ниже порога, и лид из них не создаётся. Фильтр дублей включается только на том, что прошло оба слоя и признано настоящим. Порядок важен: сначала подлинность, потом уникальность.

Есть и способ уменьшить повторы без фильтра — сократить форму и подстроить её под человека. Посетитель, увидевший двадцать полей сразу, чаще бросает и начинает заново. Условная логика, меняющая вопрос в зависимости от ответа, просто не показывает лишние поля и снимает часть повторов, вызванных брошенной формой.

Как объединение меняет ответственность и работу с заявкой?

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

Следить надо за маршрутизацией. Правила маршрутизации направляют каждую заявку нужному менеджеру или команде по услуге, региону или бюджету. Если во второй раз человек выбрал другую услугу, правило укажет на другого менеджера. Объединение не должно этот сигнал проглатывать: новый запрос стоит отправить нужной команде уведомлением, не переназначая карточку молча. Передача ответственности — это решение, а не автоматический побочный эффект.

Записанное решение закрывает и один из самых частых споров маркетинга с продажами — серую зону между «этот лид до нас не дошёл» и «он и так был старый». Когда вы выравниваете обе команды через SLA, определение дубля тоже стоит внести в этот документ: цифры зависят именно от него.

О чём говорит доля дублей?

Фильтр дублей — не только инструмент уборки, но и измерительный прибор. Число пойманных повторов говорит о самой форме. Если доля резко выросла, список причин короткий: не показывается экран благодарности, форма стала медленной, одна кампания дошла до одной аудитории по двум каналам или рассылку отправили дважды.

Отслеживание заявок показывает просмотры, отправки и конверсию на одной панели, а разрез по источнику и устройству делит это по UTM-источнику, кампании, сайту-реферреру и типу устройства. Если повторы концентрируются на мобильных, причина обычно в длине формы или в обратной связи после отправки. Если изменение придётся откатить, история версий хранит каждую сохранённую конфигурацию формы: посмотрели разницу и вернулись к прежней версии в один клик.

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

Что меняется с персональными данными при объединении?

Объединение — это сведение персональных данных из двух записей под одну личность, а значит меняется характер обработки. Согласие, данное в первой заявке, может не покрывать объём второй. Практическое правило: согласия не смешивать, применять самое узкое и хранить оба отдельно при своих заявках. Тогда на вопрос «почему мы написали этому человеку?» вы отвечаете по конкретной заявке, а не по контакту в целом.

Сроки хранения — часть той же картины. Хранение и обезличивание позволяет задать срок жизни данных заявки: когда он истекает, персональные поля обезличиваются автоматически, а числовая статистика остаётся. В объединённой записи должно быть ясно, от какой заявки идёт отсчёт — обычно каждая заявка считается от своей даты, и объединение срок не перезапускает.

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

В каком порядке настраивать форму перед публикацией?

Порядок важен, потому что каждый шаг делает возможным следующий. Сначала сопоставьте поля с полями CRM — без сопоставления фильтру дублей просто некуда смотреть. Затем опишите приоритет ключей и правило нормализации телефона. Дальше выберите действие при совпадении и политику перезаписи по типам полей. Ловушку для ботов, лимит частоты и порог reCAPTCHA поставьте перед всем этим.

Потом проведите настоящую проверку: отправьте заявку дважды со своей почты, дважды с разными форматами телефона и один раз с полностью новой личностью. Если результат отличается от ожидаемого, дело почти никогда не в фильтре — обычно виновато сопоставление полей. Если ждёте трафик кампании, прогоните нагрузочное тестирование формы до публикации: инструмент создаёт одновременные отправки, и вы увидите измерением, а не догадкой, как растёт доля повторов, когда время ответа тянется и экран благодарности запаздывает. Для организаций с пиками набора это критично: в учебном центре, который ведёт приём через CRM, один и тот же родитель может отправить форму трижды за день.

После настройки в списке проверок остаётся одно — корзина спама. Первую неделю просматривайте её на ложные срабатывания между фильтром и антиспамом, затем переводите в рутину. Если хотите увидеть весь путь на своей форме, заведите аккаунт Rocketly и отправьте две тестовые заявки, чтобы посмотреть, как они сходятся в один контакт в тот же день.

Частые вопросы

Удаляет ли фильтр дублей вторую заявку?

Нет. Она остаётся как запись заявки, не создаётся только второй контакт в CRM. Содержимое видно под тем же человеком, поэтому ни кампания-источник, ни текст сообщения не теряются.

Что если форму заполнят двое сотрудников одной компании?

При ключе по почте или телефону они создадутся как разные контакты, и это правильно. Если их нужно связать, связь строится на уровне компании, а не на уровне контакта.

Каким должно быть окно сопоставления?

Для технических повторов достаточно нескольких минут. Для повторов по личности окно обычно не нужно вовсе: та же почта и через полгода принадлежит тому же человеку. Если нужен подсчёт в рамках кампании, ставьте окно в отчёт, а не в объединение.

Если включить фильтр позже, объединятся ли старые записи?

Нет. Фильтр на стороне формы работает для заявок, пришедших после включения. Накопленный беспорядок разбирается отдельно и разово — групповыми действиями.