О чем материал
Разбираемся, почему ориентация на метрики в продуктовой разработке может привести к возникновению рисков безопасности и превратить пользователей в потенциальный источник угроз
Метрики стали универсальным языком принятия решений для CPO, продуктовых команд, PMM, инвесторов и руководителей. Показатели роста, вовлеченности, удержания и конверсии позволяют упростить сложные процессы и перевести поведение миллионов пользователей в измеримые значения, на которых строится развитие цифрового продукта.
Однако в последние годы стало очевидно: метрики выполняют не только измерительную функцию. Они формируют нормативную рамку, которая определяет облик успешного результата, приоритет внедрения изменений, допустимые риски и «правильные» решения. В результате целями эволюции продукта становятся не долгосрочная устойчивость и безопасность, а оптимизация измеряемых показателей. По сути, они формируют систему стимулов и становятся финальным аргументом при принятии решений. Эффективность ради эффективности...
Получается, метрико-ориентированное управление может непреднамеренно создавать риски безопасности? Причем речь не об уязвимостях в коде и ошибках архитектуры. Эти риски возникают не потому, что разработчик написал плохой код, а AppSec’и его не проверили. И не потому, что DevOps’ы принесли в пайплайн зловред. Причина — комбо из ошибок бизнес-логики и возможностей продукта (иногда очень неожиданных). В такой среде пользователь может трансформироваться из бенефициара продукта в источник угроз, оставаясь при этом легитимным участником экосистемы.
Слепота метрик
Итак, метрики часто рассматриваются в продуктовой практике как объективное отражение реальности. Однако они неизбежно упрощают сложные явления и фиксируют лишь ограниченный набор наблюдаемых действий. Как только такие показатели превращаются в KPI, они начинают влиять на решения сильнее, чем исходная цель развития продукта.
Этот эффект проявляется в перераспределении внимания: команды оптимизируют все, что можно измерить, и начинают игнорировать то, что не попадает в отчеты. Безопасность, устойчивость и другие долгосрочные показатели редко имеют простое количественное выражение, поэтому оказываются вторичными — например, по отношению к росту активности пользователей. Как результат, простые количественные метрики начинают восприниматься как доказательство ценности продукта. В свою очередь, негативные эффекты, возникающие из-за выбора неправильного вектора развития, в этой логике трактуются как исключения или неизбежные издержки масштабирования.
Возникает феномен, который можно назвать слепотой метрик: система управления перестает различать качественную природу активности. Любой рост показателей воспринимается положительно — независимо от того, связан он с полезными сценариями или злоупотреблением функциональностью. Нельзя забывать, что метрики фиксируют поведение, а не намерение. Они показывают, что пользователь активен, но не отвечают на вопрос, зачем он использует продукт.
Конечно, классическая парадигма предполагает добросовестного пользователя. Безопасность продукта в этом случае направлена на защиту человека от ошибок и внешних рисков. Зачастую эта модель вообще не учитывает сценарии, в которых сам пользователь становится угрозой для приложения. В этом случае он является двойственным актором: легитимным участником экосистемы и потенциальным источником угроз. Для наглядности рассмотрим несколько распространенных метрик и связанных с ними злоупотреблений.
Сценарии злоупотребления и как от них защищаться
Представьте, что вы PO огромного продукта. Давайте рассмотрим несколько типовых кейсов злоупотребления функциональностью продукта и разберемся, как можно избежать подобных ситуаций.
Отмечу, что во всех этих кейсах наблюдается одна и та же цепочка: метрика → оптимизация → снижение ограничений → рост возможностей эксплуатации → злоупотребление → ложный сигнал успеха.
- Acquisition и реферальные бонусы
Метрики:
- количество регистраций;
- CPA (стоимость привлечения клиента, совершившего целевое действие);
- число приглашенных пользователей;
- коэффициент виральности (сколько новых пользователей приглашают текущие).
Для роста acquisition команды упрощают регистрацию пользователей, снижают требования к верификации, вводят бонусы за приглашения и разрешают быстрые повторные регистрации.
Технические последствия:
- слабая привязка аккаунта к личности;
- отсутствие цифровых отпечатков устройств;
- отсутствие ограничения количества запросов от пользователей;
- излишнее доверие к клиентской стороне.
Типичные злоупотребления:
- referral farming — автоматизированное создание аккаунтов с использованием disposable email, эмуляторов, прокси и headless-браузеров;
- multi-account exploitation — перевод бонусов между собственными аккаунтами с целью формирования искусственной экономики.
В этом случае метрики демонстрируют рост регистраций и активаций, но без учета природы трафика (органический vs синтетический).
Как защищаться?
Основная задача — научиться различать реальный пользовательский рост и синтетический трафик, который гонят злоумышленники. Для этого можно использовать следующие технические механизмы.
Привязка аккаунта к устройству и среде
Вместо простой email-регистрации можно применять:
- device fingerprinting (отпечаток устройства);
- анализ браузера;
- поведенческие характеристики устройства.
Это поможет выявлять множественные аккаунты, которые создаются с одного устройства или из одной среды. Помните 2007-й? «Да я тебя по айпи вычислю!» :)
Ограничение скорости регистрации
Rate limiting должен применяться не только к API, но и к бизнес-сценариям:
- регистрация аккаунтов;
- активация бонусов;
- использование реферальных кодов.
Например:
- ограничение числа регистраций с одного IP;
- ограничение регистраций с одного device fingerprint;
- контроль частоты использования реферального кода.
Отложенная выдача бонусов
Классическая ошибка реферальных программ — мгновенная выдача бонуса. Вот более безопасная модель:
- бонус активируется только после действия пользователя (например, покупки);
- вводится период «созревания» аккаунта;
- бонусы ограничиваются поведенческим score.
Антифрод-модели
Отслеживайте базовые антифрод-сигналы:
- скорость регистрации;
- повторяющиеся устройства;
- одинаковые паттерны поведения;
- сетевые корреляции между аккаунтами.
- Engagement и эксплуатация функциональности
Метрики:
- DAU/MAU (количество уникальных пользователей, за сутки/месяц);
- действия за сессию;
- длительность пребывания пользователя в сервисе;
- количество запросов.
Для роста engagement разработчики снимают ограничения на частоту действий, уменьшают friction интерфейса и ускоряют API-операции.
Технические последствия:
- большое число запросов от пользователей;
- отсутствие поведенческого анализа;
- одинаковые права у всех пользователей.
Типичные злоупотребления:
- API abuse — массовая автоматизация действий через публичные эндпоинты;
- LLM misuse — генерация фишинговых писем, спама и мошеннического контента в AI-системах.
Как защищаться?
Когда продукт оптимизирует вовлеченность, важно не допустить превращения API и функциональности в инфраструктуру злоупотреблений.
Rate limiting и квотирование
Каждый API-метод должен иметь ограничения:
- количество запросов в секунду;
- лимиты на пользователя;
- лимиты на IP;
- лимиты на токен.
Причем лимиты должны быть динамическими, а не статическими. Например:
- новые аккаунты имеют меньший лимит, потому что доверия к ним меньше;
- доверенные аккаунты получают расширенные возможности.
Поведенческий анализ
Большинство злоупотреблений отличаются от нормального поведения пользователя. Типичные сигналы:
- сверхвысокая частота действий;
- отсутствие пауз между операциями;
- повторяющиеся паттерны запросов;
- аномальная активность ночью или из разных регионов (например, если зарегистрированный в РФ аккаунт начинает спамить действиями из Австралии, Швеции и Венгрии в течение часа).
Разделение прав пользователей
Не все пользователи должны иметь одинаковый доступ к функциональности.
Можно использовать модель progressive trust:
- новые пользователи имеют ограниченный доступ;
- доступ расширяется по мере накопления доверия.
Примеры:
- ограничение числа API-запросов;
- ограничение массовых операций;
- ограничение генерации контента.
- Retention и закрепление злоумышленников
Метрики:
- D7/D30 retention (% пользователей, вернувшихся в сервис через 7/30 дней после первого использования);
- частота возвращений;
- LTV (пожизненная ценность клиента).
Для удержания пользователей разработчики уменьшают количество блокировок, вводят накопительные бонусы и снижают чувствительность антифрод-механизмов.
Типичные злоупотребления:
Возникают long-term abuse accounts — аккаунты, которые длительное время имитируют нормальное поведение, накапливают доверие и затем используются для мошенничества. Парадоксально, но чаще всего они демонстрируют лучший retention.
Как защищаться?
Retention может маскировать злоумышленников, которые долго прогревают аккаунты.
Trust scoring
Каждый аккаунт может иметь динамический уровень доверия, который рассчитывается на основе следующих параметров:
- возраст аккаунта;
- история поведения;
- успешные транзакции;
- жалобы пользователей;
- корреляции с другими аккаунтами.
Доступная пользователю функциональность продукта может зависеть от итогового trust score.
Мониторинг аномального retention
Важно анализировать не только сам retention, но и его структуру. Например:
- аккаунты с аномально высокой активностью;
- аккаунты с повторяющимися действиями;
- связанные между собой аккаунты.
Иногда именно «лучшие» пользователи оказываются злоумышленниками.
- Growth experiments и эксплуатация A/B-тестов
A/B-системы редко учитывают adversarial behavior (враждебно настроенное поведение пользователя). Если злоумышленники находят экспериментальную ветку функциональности с более мягкими ограничениями, то концентрируются именно на ней. Эксперимент показывает рост, функция масштабируется, а вместе с ней — и уязвимость.
Предположим, команда продукта решила упростить процесс регистрации в приложении, чтобы повысить конверсию. В экспериментальной ветке отключается дополнительная проверка номера телефона или уменьшается количество антифрод-проверок. Система распределяет пользователей между контрольной и экспериментальной группами, однако злоумышленники довольно быстро обнаруживают различия в поведении API или интерфейса. Например, по измененным ответам сервера, отсутствию rate limiting или просто за счет иной логики регистрации. После этого атакующие начинают целенаправленно ломиться в экспериментальную ветку — например, с помощью массового создания аккаунтов, перебора параметров запроса или повторной регистрации (до тех пор, пока система не отправит пользователя в нужную группу).
Что мы видим в результате? Парадокс! В экспериментальной группе растет конверсия регистрации, увеличивается количество активных пользователей и улучшаются показатели вовлеченности. С точки зрения продуктовой аналитики и неподготовленного продакт-оунера (PO), эксперимент выглядит успешным, и команда принимает решение масштабировать новую механику на всю аудиторию приложения. На практике же рост показателей будет вызван не улучшением пользовательского опыта, а активностью злоумышленников, которые используют в своих целях менее защищенную конфигурацию. После глобальной раскатки уязвимость начинает масштабироваться вместе с продуктом…
Как защищаться?
A/B-эксперименты должны учитывать сценарии adversarial behavior (например, как в описанном выше гипотетическом сценарии).
Изоляция экспериментов
Экспериментальная ветка должна иметь те же ограничения безопасности, антифрод-механизмы и rate limits, что и основная. Нельзя ослаблять защиту ради роста метрик — даже если вас очень просят и «очень надо». Прекрасное решение — провести анализ эксперимента с привлечением ИБ до раскатки на весь продукт.
Мониторинг аномалий в экспериментальных группах
Здесь важно отслеживать:
- необычно высокую активность;
- подозрительные источники трафика;
- корреляции между аккаунтами.
Если экспериментальная группа демонстрирует слишком резкий рост, это повод искать злоупотребления.
Рандомизация
Иногда злоумышленники специально пытаются попасть в нужную ветку эксперимента. Поэтому важно:
- использовать серверную рандомизацию;
- не раскрывать параметры эксперимента;
- избегать детерминированных алгоритмов распределения.
- Монетизация и экономические атаки
Метрики:
- конверсия в оплату (% пользователей, которые принесли деньги);
- ограниченный доступ к материалам;
- активация бонусов.
С точки зрения разработчиков, классическими архитектурными решениями будут free trial без строгой проверки личности, отложенная оплата или бонусные кредиты.
Типичные злоупотребления:
- trial cycling — бесконечное создание новых аккаунтов;
- reward exploitation — автоматизация получения внутренней валюты.
Как защищаться?
Для отражения экономических атак необходимо контролировать не только транзакции, но и жизненный цикл аккаунта.
Ограничение free trial
Типичные меры:
- привязка к платежному инструменту (банковская карта, счет в электронном кошельке и т. д.);
- ограничение числа trial-периодов на устройство;
- проверка повторных регистраций.
Контроль бонусных систем
Бонусы должны иметь следующие ограничения:
- лимиты на использование;
- связь с поведением пользователя;
- антифрод-проверки перед активацией.
- Когда приложение ломают, а продукт радуется
Особенно опасны ситуации, когда пользователь/злоумышленник фактически проводит стресс-тест продукта. Например, находит эндпоинт без ограничения частоты запросов и начинает генерировать тысячи операций с помощью бота. В результате заметно растут задержка и общая нагрузка на сервис. При этом продуктовые метрики показывают рост активности, увеличение DAU и высокий feature adoption. В течение недель разработчики могут воспринимать происходящее как успешный запуск новой функции.
Как защищаться?
Системы мониторинга должны отслеживать не только технические метрики, но и аномалии пользовательского поведения. Например:
- резкий рост запросов к одному эндпоинту;
- всплеск активности новых аккаунтов;
- необычные паттерны использования функций.
Такие сигналы должны автоматически передаваться в систему мониторинга, антифрод-команде и продуктовым аналитикам.
Общий принцип защиты
Безопасность должна быть встроена в сами продуктовые метрики. Они должны отвечать не только на вопрос «Насколько активно используется продукт?», но и на вопрос «Насколько это использование легитимно?». Поэтому в зрелых продуктах к классическим показателям добавляются:
- fraud rate;
- abuse rate;
- suspicious activity score;
- trust score пользователей.
***
Описанные выше проблемы редко становятся результатом сознательного игнорирования безопасности. Скорее они возникают как свойство социотехнической системы:
метрики создают стимулы → стимулы формируют продуктовые возможности → пользователи адаптируются → появляются новые практики → часть из них превращаются в злоупотребления.
Однако метрики остаются необходимым инструментом управления, поэтому отказываться от них нельзя. Но важно использовать их осознанно: метрики должны проектироваться с учетом adversarial behavior — сценариев, в которых пользователь пытается абьюзить систему в своих интересах.
В конце концов, только сочетание продуктовых метрик и метрик безопасности позволит вам увидеть реальную картину роста. А теперь ответьте честно: вы вместе с PO все это учли? ;)
