Документация
Панель управления API

Обзор Digital Fraud Protection: возможности, принцип работы, сценарии использования

Digital Fraud Protection (DFP) — это решение для создания устойчивых отпечатков клиентского окружения и анализа дополнительных признаков запроса.

Проще говоря, наш продукт показывает ID уникальной связки «конкретный браузер + конкретное устройство» (DFP для сайта) или уникального устройства (DFP для мобильного приложения), откуда пришёл запрос. Этот ID стабилен — он не меняется, даже если в следующий раз пользователь пытается скрыть информацию о себе: чистит cookies, включает VPN, открывает вкладку инкогнито или меняет настройки компьютера/телефона. Используя эти ID, вы сможете точнее отличать действия одного пользователя от другого.

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

Полученные данные вы используете в своих бизнес-сценариях: например, чтобы узнать пользователя без cookie, выявить мультиаккаунтинг или заметить кражу cookie/токена аутентификации.

Протестировать DFP

Мы встроили виджет DFP прямо на эту страницу. Ниже вы увидите результат проверки своего окружения. Тестируйте смело: открывайте статью с разных браузеров/устройств, включайте и выключайте VPN, переходите в инкогнито — вы увидите, как меняется результат.

Открыть playground DFP

Что вы будете знать о каждом запросе

Полный список полей, которые присылает DFP, описан в статье Что значат поля из ответа DFP. Советы по интерпретации этих данных и использованию в вашей бизнес-логике читайте в Как интерпретировать ответ DFP.

DFP передаёт вам четыре важных типа данных:

  • стабильный идентификатор клиентского окружения, откуда сделан запрос — user_id;

  • оценку вероятности, что запрос отправила автоматизация — bot_score;

  • оценку вероятности, что при отправке запроса использовался VPN или прокси — proxy_score;

  • дополнительные данные о браузере, устройстве, сети и других признаках запроса.

User ID

user_id — стабильный идентификатор клиентского окружения.

Говоря проще, это ID, который описывает уникальную связку «конкретный браузер + конкретное устройство» (DFP для сайта) или уникальное устройство (DFP для мобильного приложения). ID остаётся стабильным, даже когда пользователь меняет разные настройки. Например, если он:

  • включит VPN;

  • обновит ОС;

  • поменяет время на компьютере/телефоне;

  • откроет инкогнито в браузере;

  • обновит версию браузера.

ID будет тем же самым, ведь главный критерий выполняется: устройство и браузер остались те же. А вот если пользователь откроет другой браузер или сделает запрос с нового устройства, вы увидите другой ID.

Bot score

bot_score — это число от 0 до 1, которое показывает, насколько запрос содержит признаки автоматизации, подмены параметров браузера и иных аномалий, характерных для активности ботов.

Ориентироваться можно так:

  • < 0.4 — запрос отправлен человеком;

  • от 0.4 до 0.5 — есть подозрительные признаки, возможно, действовал бот;

  • >= 0.5 — запрос наверняка отправил бот.

Proxy score

proxy_score — это число от 0 до 1, которое показывает, насколько вероятно, что при отправке запроса использовался VPN или прокси. DFP оценивает его, сравнивая параметры браузера с параметрами сетевого соединения.

Ориентироваться можно так:

  • < 0.5 — признаков VPN или прокси нет;

  • >= 0.5 — при отправке запроса использовался VPN или прокси.

Вместе с оценкой DFP передаёт proxy_signs — признаки, на основании которых DFP рассчитал proxy_score: например, часовой пояс браузера не совпадает с часовым поясом IP-адреса.

Дополнительные данные

Помимо user_id, bot_score, proxy_score и proxy_signs, DFP передаёт дополнительные данные о клиентском окружении и запросе. Они помогают понять контекст и точнее настроить бизнес-логику.

Список параметров зависит от способа интеграции: на сайт или в мобильное приложение.

  • DFP для сайта

  • DFP для мобильного приложения

  • engine — какой браузерный движок используется: например, Blink, WebKit, Gecko или другой.

  • hosting — относится ли IP-адрес к хостинговой подсети.

  • bot_hosting — относится ли IP-адрес к хостинговой подсети, откуда мы зафиксировали активность ботов или другую подозрительную активность.

  • isp_active_subnet — относится ли IP к активной подсети интернет-провайдера, которая используется для подключения частных или корпоративных клиентов к интернету.

  • tor — относится ли IP к сети Tor, которая скрывает реальный адрес пользователя.

  • incognito — открыт ли браузер в режиме инкогнито или приватного просмотра.

  • antidetect — используется ли антидетект-браузер, который подменяет параметры браузера и отпечаток, чтобы с одного устройства можно было выдавать себя за разных пользователей.

  • vm — запущен ли браузер в виртуальной машине.

  • rdp — есть ли признаки использования программы для удалённого доступа.

  • webview — открыт ли ваш ресурс внутри другого приложения (WebView), например, по ссылке в мессенджере, а не в обычном браузере.

  • mobile — пришёл ли запрос с мобильного устройства.

  • os — какая операционная система используется: например, Windows, macOS, Linux, iOS или Android.

  • vpn — есть ли признаки использования VPN.

  • new_user — впервые ли ваш ресурс посещают из этого клиентского окружения.

  • confidence_score — степень уверенности в том, что user_id определён корректно.

  • white_bot — от доверенного ли источника пришёл запрос.

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

    Запросы с white_bot: true рекомендуем автоматически пропускать на вашем бэкенде. Для них DFP не вычисляет user_id и возвращает в этом поле пустую строку ("user_id": "").

  • os — операционная система;

  • isp_active_subnet — относится ли IP к активной подсети интернет-провайдера, которая используется для подключения частных или корпоративных клиентов к интернету;

  • vpn — используется ли VPN;

  • hosting — из хостинговой подсети пришёл запрос или из обычной;

  • bot_hosting — пришёл ли запрос из хостинговой подсети, откуда мы зафиксировали активность ботов или другую подозрительную активность;

  • new_user — впервые ли ваш ресурс посещают из этого клиентского окружения;

  • confidence_score — степень уверенности в том, что user_id определён корректно.

Какие задачи поможет решить

DFP пригодится в задачах, где важно понимать клиентское окружение и признаки запроса. Например, с помощью его данных можно:

  • идентифицировать пользователей без cookie;

  • обнаруживать мультиаккаунтинг;

  • выявлять кражу cookie или токена;

  • замечать подозрительные регистрации;

  • защищать промоакции и приветственные бонусы от злоупотреблений;

  • отличать обычный клиентский трафик от автоматизированного;

  • учитывать VPN, прокси, Tor, хостинговые подсети, подозрительную активность из подсети, режим инкогнито, антидетект-браузеры и другие признаки в бизнес-логике;

  • находить повторные действия с одного клиентского окружения: например, повторное прохождение опроса.

Для популярных сценариев мы сделали готовые инструкции, как использовать данные DFP для закрытия бизнес-задач:

Как работает

  1. Вы подключаете DFP:

    • на своём сайте — добавляете JavaScript-библиотеку на нужные страницы;

    • в приложении — встраиваете Servicepipe Mobile SDK.

    Если вам важно разобраться, как работает наша JavaScript-библиотека, напишите в тех. поддержку — всё подробно расскажем.

    Код библиотеки обфусцирован с использованием анти-LLM техник, поэтому ответы ИИ при ревёрс-инжиниринге могут быть ошибочными и вводить в заблуждение. Кроме того, при загрузке библиотеки в ChatGPT, Claude, Grok или другой ИИ-сервис есть риск блокировки аккаунта в этом сервисе.

  2. Пользователь открывает страницу сайта / мобильное приложение и выполняет действие, для которого нужна проверка: например, входит в аккаунт, отправляет форму, регистрируется, подтверждает операцию.

  3. Библиотека/SDK собирает параметры клиентского окружения.

    Интеграцию DFP на сайт рекомендуем настроить так, чтобы сбор данных о клиентском окружении начинался как можно раньше (например, при открытии страницы), а их отправка на API DFP — в момент целевого действия (например, входа в аккаунт, отправки формы или подтверждения операции). Так вы будете получать ответ DFP быстрее и его точность будет выше.

    Как это настроить, читайте в инструкции по интеграции.

  4. Библиотека/SDK отправляет собранные данные на API DFP.

  5. Внутри инфраструктуры Servicepipe анализируются особенности сетевого взаимодействия при выполнении запроса: признаки автоматизации, особенности TLS-хендшейка, данные L3/L4-сетевого уровня и другие.

  6. DFP анализирует все данные и формирует результат: user_id, bot_score, proxy_score, а также признаки хостинговой подсети, подсети с подозрительной активностью, инкогнито, антидетект-браузера и другие.

  7. DFP шифрует результат и возвращает его в браузер/приложение.

  8. Браузер/приложение передаёт зашифрованный ответ на ваш бэкенд.

  9. Ваш бэкенд расшифровывает ответ и применяет вашу бизнес-логику.

Подробнее весь процесс описан в статье Схема работы.

Как подключить

Подключить DFP легко:

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

  2. Передадим вам:

    • CUSTOMER-TOKEN — токен для подключения DFP: на сайте он используется для загрузки JavaScript-библиотеки и вызова API, в мобильном приложении — для вызова API через Servicepipe Mobile SDK;

    • SECRET-KEY — им ваш бэкенд будет расшифровывать payload.

  3. Выберите способ интеграции:

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

Отправить заявку на подключение