Год назад я начал заниматься задачей, которая в маркетинговой индустрии формулируется так: «у вас на сайт пришло 1000 человек, заявку оставили 30 — что делать с оставшимися 970?». Чисто маркетинговый ответ — улучшать сайт, прогревать ремаркетингом, гнать в подписку. Технически — есть другой класс решений: идентифицировать часть тех 970 анонимов и инициировать контакт по телефону.
В рунете эта область с 2022–2023 годов разрослась до десятков сервисов с разной степенью легальности и разной технической архитектурой. Я работаю с одним из них (платформа INTER), но цель этой статьи — не реклама, а разбор того, как такие системы вообще устроены, где они законны, а где нет, и какие технические компромиссы за этим стоят.
Статья рассчитана на инженеров, продакт-менеджеров, юристов в IT и всех, кому интересно, как технически работает рынок «возврата ушедшего трафика».
Часть 1. Откуда берётся «соответствие»
Базовая задача: пользователь зашёл на сайт example.ru, посмотрел страницу, ушёл. С точки зрения сайта он анонимен — у него есть IP, User-Agent, набор куки, fingerprint браузера, возможно, идентификаторы рекламных систем (Яндекс Crypta, Google Click ID и так далее).
Чтобы сопоставить этот набор сигналов с телефонным номером, нужна где-то стоящая база, в которой такое соответствие уже есть. Источники этих баз — главный вопрос всей индустрии, и от ответа на него зависит легальность сервиса.
Условно источники делятся на три категории:
1. Согласие первой стороны (легально). Пользователь однажды оставил телефон на каком-то сайте-партнёре, при этом согласившись с обработкой ПД и передачей данных третьим лицам — это написано в политике обработки. Сайт-партнёр или DMP-агрегатор, с которым у партнёра есть договор, складывает: «вот fingerprint браузера X — вот телефон Y». Когда тот же fingerprint X появляется на сайте example.ru, происходит matching. Это самый чистый путь с точки зрения 152-ФЗ — пользователь сам дал согласие на обработку и передачу.
2. Чёрные/серые базы (нелегально). Утечки баз банков, ритейла, госуслуг. Сервисы, торгующие такими базами, формально незаконны, но в реальности существуют. Опознать их легко по двум признакам: подозрительно низкая цена за контакт (10–50 рублей), отсутствие договора с раскрытием источника. Уголовно наказуемо по 137 УК.
3. Гибрид (юридически серое). Базы, собранные через цепочки косвенных согласий, fingerprinting-агрегацию, парсинг открытых источников, обогащение через telco-данные. В каждом конкретном случае нужна юридическая экспертиза договоров.
Если вы внедряете подобный сервис у себя в компании, первое, что нужно запросить у поставщика — цепочку договоров от конечного пользователя до вас. Если в этой цепочке есть звено без согласия — это потенциальное уголовное дело.
Часть 2. Что говорит 152-ФЗ о телефонном номере
Распространённое заблуждение: «телефон — это персональные данные, всё, что с ним делается без согласия — нарушение закона». Это упрощение.
152-ФЗ в статье 3 определяет персональные данные как «любую информацию, относящуюся к определённому или определяемому физическому лицу». Ключевое слово — определяемый. Сам по себе одиннадцатизначный номер не определяет конкретного человека — у телефона нет «прошитой» привязки к ФИО. Чтобы номер стал ПД, его нужно сопоставить хотя бы с одним идентификатором личности.
В практике Роскомнадзора и судебной практике сложилась такая позиция:
— Телефон с ФИО → персональные данные. Нужно согласие на обработку.
— Телефон с email и/или адресом → персональные данные (определяется через цепочку).
— Чистый телефон без сопутствующих идентификаторов → не персональные данные. Может обрабатываться без согласия конкретного субъекта при наличии законного основания (например, факта первичного согласия на сайте-источнике).
Это не лазейка, а буква закона. На этом стоит легальная часть индустрии возврата трафика — передаваемый клиенту контакт идёт только в виде номера, без ФИО, без email, без других идентификаторов. Дальше клиент-обработчик звонит, представляется, и если человек подтверждает интерес — начинается обычный лидогенерационный цикл с уже зафиксированным согласием на разговор.
Серая зона начинается там, где номер передаётся с обогащением — с ФИО, возрастом, городом, историей покупок. Это уже ПД, и без явного согласия каждого субъекта — нарушение.
Часть 3. Архитектура реал-тайм процесса
Технически процесс выглядит так. На сайте клиента стоит JS-тег (как Яндекс.Метрика). Он собирает сигналы посетителя:
— набор HTTP-заголовков
— canvas/WebGL fingerprint
— результаты navigator.userAgent, navigator.platform, navigator.languages
— разрешение экрана, цветовая глубина
— список установленных шрифтов
— информацию о подключении (Network Information API)
— временную зону, локаль
— идентификаторы рекламных систем (если есть)
Этот «отпечаток» отправляется на бэкенд платформы. Там происходит сравнение со внутренним индексом — методами от точного matching по уникальной комбинации сигналов до fuzzy-matching с порогом схожести (например, через locality-sensitive hashing).
Если совпадение найдено и порог уверенности достаточен (обычно 70–90% в зависимости от настроек) — платформа возвращает связанный с этим отпечатком номер.
Дальше есть две схемы:
— Push в CRM клиента — номер прилетает в CRM как новый лид, дальше внутренний процесс клиента.
— Реал-тайм-обзвон — платформа сама звонит (или передаёт в подключённый колл-центр / AI-оператор) в течение 1–5 минут после того, как посетитель закрыл вкладку.
Скорость в этой схеме критична. Эмпирически: через час после ухода с сайта вероятность конверсии при холодном звонке падает на ~80%. Через сутки — ещё в 3–5 раз. Активное окно — первые 10–30 минут.
Часть 4. Что обычно ломается
Из чисто инженерных проблем в индустрии:
Качество matching. Fingerprint браузера — нестабилен. Обновление ОС, смена браузера, режим инкогнито, защита от трекинга (Safari ITP, Firefox ETP, Brave) — всё это либо ломает отпечаток, либо рандомизирует его. Реальный hit-rate (доля посетителей, для которых удаётся найти контакт) в индустрии — 5–20%, не 50–70%, как иногда рекламируют.
Качество входящей базы. Если в источнике сидят старые телефоны 2–3-летней давности — часть номеров уже неактивна, часть — у других людей. Feedback-loop от клиента по фактическому качеству обзвона критичен: без него поставщик не может отбраковать плохие источники.
Дубль-контакты между конкурентами. Технически возможна ситуация, когда один и тот же контакт продаётся нескольким клиентам в одной нише. Это убивает экономику обзвона. В договорах нормальных поставщиков прописывается эксклюзив по контакту: один номер — в одни руки.
Defensive-меры со стороны браузеров. В 2024–2026 годах Safari и Firefox активно режут возможности fingerprinting. Chrome движется в ту же сторону через Privacy Sandbox. Через 3–5 лет вся индустрия будет вынуждена перейти на server-side matching через cookieless-идентификаторы (UID 2.0, FedID, аналоги).
Часть 5. Что я думаю про этот рынок в целом
Открытый вопрос, который мне самому не до конца ясен: где проходит этическая граница, отдельно от юридической?
Юридически — если все звенья цепочки чисты, технология легальна. Этически — пользователь, оставивший телефон на одном сайте в обмен на скидку, обычно не до конца понимает, что номер может всплыть в звонке от компании, которой он его не давал. Согласие формально получено, но «информированность» этого согласия — спорная.
Индустрия движется к более прозрачным механизмам — login-walls, явное согласие на конкретный сценарий, opt-out на уровне браузера. Через 5 лет, думаю, останутся только сервисы первой категории (явное first-party согласие) и server-side cookieless-matching через стандартизованные идентификаторы. Серые и чёрные практики либо вытеснятся регуляторно, либо станут технически невозможными из-за защиты браузеров.
Что мне самому интересно обсудить:
— какой у вас реальный hit-rate matching после ITP/ETP/Brave-shields и что вы делаете для его восстановления;
— как вы валидируете цепочку договоров «согласие → агрегатор → конечный обработчик» — есть ли практика реальных проверок RKN, или это до сих пор живёт на честном слове;
— какие источники сигналов вы используете кроме классического browser fingerprint — IP-репутация, telco-сигналы, server-side identity graphs;
— как у вас устроен feedback-loop по качеству контактов от клиента — на каком уровне детализации, и как часто перестраивается ранкинг источников.
Пишите в комментариях или мне лично в Telegram — @web_enter. Готов делиться нашими наблюдениями в ответ и при необходимости разобрать конкретный кейс — без рекламы и продаж, просто инженерный обмен опытом.
ссылка на оригинал статьи https://habr.com/ru/articles/1042298/