В этой статье хочу рассказать, как мы боремся с фродом в In-App трафике.

Сразу скажу: мы пользуемся сервисом AppMetrica, и на это две причины:

1. С 30 мая 2025 года вступили в силу изменения в КоАП РФ (ст. 13.11, ст. 12, 13, 14 и примечание к статье, п. 4). Там прямо говорится: любые уникальные идентификаторы пользователя (GAID, ID устройства и пр.), которые можно сопоставить в разных системах, признаются персональными данными.
2. Давно действуют требования о локализации персональных данных и ограничениях на их трансграничную передачу, предусмотренные Законом о персональных данных.

Из-за этого выбор ограничен одним сервисом, сервера которого находится в России. 

Проблема борьбы с фродом на примере AppMetrica

Внутри AppMetrica с 2025 года появился специальный платный инструмент, основанный на технологии компании FraudScore. Он отслеживает подозрительные установки приложений и помечает их. Но справиться с высокоуровневыми бот-фермами — та ещё задача. Боты часто хорошо имитируют поведение живого человека, поэтому отследить их очень тяжело.

Почему это проблема? Дело не только в установках. Боты умеют фальсифицировать любые события внутри приложения, за которые мы платим подрядчикам (статья о том, как мы работаем с In-App агентствами), и делают это массово. В AppMetrica нашего приложения «Кошелек ЦУПИС» мы фиксировали случаи отправки тысяч фальшивых событий.

Один случай запомнился особо: одна партнёрка, которую подключило агентство, инициировала более 1 000 событий, соответствующих условиям оплаты по договору с агентством. После требования оплаты и сверки выяснилось, что все эти события являлись фродом. В реальных событиях есть уникальный параметр user code, представляющий зашифрованный номер пользователя, взломать или подделать который невозможно. Мы сказали про это агентству, те сообщили партнёрке, а партнёрка создала ещё более 800 событий с использованием такого параметра, выглядящего правдоподобно. Проверка совпадений с нашей базой данных показала только одно реальное событие — тестовый платёж на 10 рублей. Для остальных событий партнёрка просто скопировала формат user code, полагаясь на визуальное сходство.

Как мы решили проблему с фродом в In-App трафике

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

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

Мы решили отправлять в AppMetrica уникальный идентификатор (user code) при каждом входе пользователя в приложение, записывая его в поле ProfileId. Это позволило обогащать данные AppMetrica информацией о наших пользователях, а затем извлекать полученные данные обратно в нашу систему, чтобы понимать источники установок.

Здесь возникли сложности с бесплатным решением Logs API от Яндекса, которое постоянно сбоило и зависало. Проблему решил платный сервис Data Stream API, тоже от Яндекса: мы стали получать необходимые данные в реальном времени без задержек и сбоев.

Итак, у нас появились полные данные об установках и действиях пользователей. Однако остался вопрос о поведении пользователей до момента входа в аккаунт, потому что у него до входа нет user code. Это не связано с борьбой с фродом, но задача важная — для анализа пользовательских путей. Мы её решили через сопоставление по другим идентификаторам AppMetrica и последующего привязывание к уникальному user code после успешного входа пользователя.

Возвращаемся к фроду. Для обработки полученных данных мы создали дэшборд. Существует немало специализированных сервисов, но наши айтишники выбрали Glarus BI. Нам осталось сделать фильтры:

• Дата установки приложения
• Дата события (заказ, платёж и т.п.)
• Партнёр, на которого сделана трекинговая ссылка
• Трекер: ссылка, с которой происходили инсталлы
• Платформа приложения: Android/iOS
• Reinstallation: является ли установка повторной
• Новый/старый: есть заказы от этого клиента в вашей базе
• Партнёры с расходами

Вы можете создать другие фильтры под ваши задачи и специфику бизнеса.

Что это нам даёт?

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

Вот, например, кампания, по которой в AppMetrica мы видим 205 пользователей:

А Glarus показывает реальность — 123:

То же самое происходит с «перехватами» заказов, поскольку реальные даты заказов в базе другие. Да, если вы не знали, боты умеют перехватывать данные настоящих заказов и передавать их в систему под видом новых. То ли ещё будет.

Внутри системы можно создавать доски для отслеживания фрода по In-App источникам, сопоставляя их результаты с органическим трафиком или чистыми кабинетными кампаниями. Отклонения по ключевым параметрам вроде конверсии, среднего чека, времени в приложении, удержания пользователей будут сигнализировать о возможных проблемах с качеством трафика.

Во-вторых, мы можем анализировать эффективность партнёров. Тут нужно пояснить, что такое «партнёры с расходами». Мы загружаем в систему через Excel-файл данные о затратах каждого партнёра за прошедший месяц. Например, «январь | VK Ads | 1 000 000 ?». Система сама рассчитывает обороты и ROMI с установивших приложение через этот источник, показывая доходность по каждому месяцу. Это позволяет видеть среднее время окупаемости источника, рассчитывать ROMI и определять самые прибыльные источники.

Пример файла (*числа изменены в целях защиты коммерческой тайны):

Система отображает окупаемость по месяцам отдельно для каждого партнёра (источника) в следующем формате:

Расходы достаточно грузить раз в неделю — такого интервала вполне хватает для оперативного анализа эффективности.

И ещё пара советов вдогонку:

1. Для борьбы с клик-спамом и подобными манипуляциями можно пользоваться фильтрами на основе данных из AppMetrica. Посмотрите статью от Алёны Максимовой, COO CTV House.Там есть таблица с параметрами, на которые стоит обращать внимание. Нам сильно помогло.
2. Попросите разработчиков добавить в BI дополнительную вкладку с сырыми данными — специально для сверки событий с партнёрами (агентства и источники трафика). Так ваши контрагенты смогут оперативно получать подтверждение по сомнительным событиям из AppMetrica.