Траст-скор профиля: как собрать шкалу готовности к скейлу и перестать принимать решения интуитивно

Материал подготовлен командой TraffCloud при поддержке Octo Browser.

На планёрке кто-то спрашивает: «Этот профиль готов лить?» Байер смотрит в экран пару секунд и отвечает: «Ну, вроде норм, две недели крутится, списания проходят».

Дальше происходит одно из двух. Либо действительно норм – и через месяц никто не вспомнит про этот разговор. Либо через четыре дня после того, как на профиль завели дневной бюджет в несколько раз выше тестового, приходит блокировка. И вот тогда начинается разбор: а что вообще значило «вроде норм»? Какие две недели – календарные или рабочие? Списания – сколько именно и на какие суммы? Была ли отклонёнка по креативам? Кто вообще последний раз заходил в этот профиль и с какого IP?

Ответов нет ни у кого, потому что решение принималось не по данным. Оно принималось по интуиции.

Мы в TraffCloud занимаемся acquisition и аналитикой для iGaming-операторов и партнёрских сетей, и в какой-то момент поймали себя на том, что у нас выстроена приличная аналитика по игрокам – когорты, payback, contribution margin – и полностью отсутствует аналитика по собственным рабочим активам. Профиль в антидетект-браузере – это актив. У него есть себестоимость, есть срок жизни и есть состояние. А управляли мы им на глаз.

Эта статья – про то, как мы перестали.

Почему «на ощущение» – это дорого

Главная ошибка в рассуждениях звучит так: «Ну потеряем аккаунт, купим новый, они недорогие».

Аккаунт действительно недорогой. Дорогое – всё остальное, что к нему прилипло к моменту, когда его теряют.

Посчитайте по строкам: сам аккаунт, прокси под него, часы байера на прогрев (умножьте на ставку), доля профилей, которые не пережили прогрев и не дошли до открутки вообще, платёжный инструмент, доля лицензии антидетекта. А главное – время. Профиль, который дожил до состояния «можно скейлить», стоил вам не денег, а недель календаря. Потерять его в момент, когда на него заведён увеличенный бюджет, – это потерять не аккаунт, а место в очереди.

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

Скор нужен ровно для этого. Не для красоты отчёта, а чтобы момент повышения нагрузки перестал быть выстрелом вслепую.

Откуда мы взяли идею

Ничего оригинального мы не изобрели – просто перенесли механику из двух соседних областей.

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

Вторая – production readiness review из инженерной практики. Прежде чем сервис получает боевую нагрузку, он проходит формальный чек-лист: логи есть, мониторинг есть, алерты настроены, план отката написан. Не прошёл – не выкатываем, независимо от того, насколько все уверены, что «там всё нормально».

Профиль перед скейлом – это ровно такая же ситуация. Мы собираемся повысить нагрузку на систему, про устойчивость которой знаем мало. Логично сначала проверить, что знаем.

Шесть групп сигналов

Скор строится из шести блоков. Все сигналы внутри – проверяемые: их можно посмотреть в интерфейсе рекламного кабинета, в платёжке или в логах браузера. Никаких «выглядит живым».

Платёжная история – 25 баллов. Самый тяжёлый блок, и это не случайно. Платёжка – единственный сигнал, который площадка не может подделать в вашу пользу и который вы не можете нарисовать сами. Что смотрим: количество успешно прошедших списаний, наличие деклайнов и их причины, возраст платёжного инструмента, совпадение биллинг-гео с географией профиля. Отдельно – порог биллинга: по документации Meta он не статичен и меняется по мере того, как платежи проходят успешно. Профиль, у которого порог за месяц не сдвинулся, – это профиль, который площадка не считает своим.

Пройденные проверки – 20 баллов. Всё, что вы прошли и что нельзя пройти задним числом: верификация личности или бизнеса, подтверждение домена, двухфакторка, отраслевая сертификация. Для гемблинга последнее стало особенно весомым: обновление политики Google по азартным играм от 26 августа 2026 года требует действующей локальной лицензии на каждый таргетируемый регион, разводит операторов и партнёров по разным стандартам и прямо запрещает держать в одном аккаунте одновременно сертификацию по онлайн-гемблингу и social casino. Плюс обязанность пересертифицироваться при любом существенном изменении данных – под угрозой приостановки аккаунта. В такой конфигурации «профиль с пройденной сертификацией» и «профиль без неё» – это два разных класса актива, а не два оттенка одного.

Возраст и непрерывность истории – 15 баллов. Не календарный возраст, а именно непрерывность. Профиль, который создан четыре месяца назад и три из них простоял без единой сессии, младше профиля, которому шесть недель, но который использовался ровно и регулярно. Провал в активности – это не пауза, это разрыв в истории.

Поведение за последние 14 дней – 15 баллов. Регулярность сессий, отсутствие рваных скачков активности, стабильность окружения. Заходил ли кто-то, кроме закреплённого владельца. Менялся ли IP резче, чем это объяснимо. Не было ли ночи, когда профиль внезапно открыли из другой страны, потому что человек уехал в отпуск и «на минутку глянул с телефона».

Лимиты и потолок – 15 баллов. Дневной лимит расхода, текущий порог биллинга, поднимались ли они и как быстро. Это прямая обратная связь от площадки о том, насколько она вам доверяет. Игнорировать её и заводить на профиль бюджет, которого он не выдержит, — самый частый способ убить актив в один день.

История предупреждений – 10 баллов. Любые warning, отклонённые креативы, попадания в policy review за последние 90 дней. Один отказ по креативу — шум. Три за месяц – сигнал, что профиль уже под повышенным вниманием, и увеличивать на нём нагрузку не стоит.

Сумма – 100.

Как это выглядит на практике

Профиль FB-BR-14, полтора месяца, работает по бразильскому GEO.

Платёжная история: 11 успешных списаний, один деклайн в начале по причине лимита карты, порог биллинга поднимался дважды – 21 из 25. Пройденные проверки: верификация пройдена, домен подтверждён, 2FA включена, отраслевой сертификации нет – 13 из 20. Возраст и непрерывность: 46 дней, был провал на 9 дней в середине – 9 из 15. Поведение за 14 дней: ровное, один заход не с того устройства – 12 из 15. Лимиты: дневной лимит поднимался один раз, текущий потолок вдвое выше тестового бюджета – 11 из 15. Предупреждения: одна отклонёнка по креативу 20 дней назад – 8 из 10.

Итого 74. Скейлим – но с фиксацией того, что тянет вниз: провал в истории и отсутствие сертификации. Первое уже не исправить, второе – задача на ближайшие две недели.

А теперь сравните это с фразой «ну, вроде норм, две недели крутится». Разница не в точности числа. Разница в том, что теперь есть предмет для разговора.

Правило 70 – и что делать с теми, кто не дотянул

Порог мы поставили на 70. Ниже – не скейлим, точка. Не «скейлим осторожно», не «скейлим, но следим», а не скейлим.

Это важнее, чем кажется. Правило работает, только если оно не обсуждается в моменте. Как только появляется формулировка «ну тут 66, но профиль хороший, давайте попробуем» – шкала умирает, потому что превращается в ещё один способ обосновать то, что и так собирались сделать.

При этом «не скейлим» не равно «выбрасываем». Профиль с 40–69 – это профиль в работе. У него есть конкретный дефицит, видимый по разбивке баллов, и есть план: добить платёжную историю, пройти верификацию, выровнять активность, дождаться закрытия окна после предупреждения. Через две недели пересчитали.

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

Где скор живёт: интеграция с Octo Browser

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

Балл хранится в тегах профиля. Не точное число – оно меняется слишком часто, – а бэнд: score-80+, score-70-79, score-40-69, score-low. Плюс тег с датой последнего пересчёта, например checked-w34. Байер, открывая список профилей, видит состояние актива до того, как что-то с ним сделает, а не после.

Фильтрация и массовые действия – по тем же тегам. Задача «показать все профили с баллом выше 70 по бразильскому GEO, которые пересчитывались на этой неделе» решается фильтром, а не выгрузкой в Excel. Массовые операции применяются к отфильтрованной выборке, что убирает главный риск ручной работы – задеть не тот профиль.

Права доступа тоже раздаются по тегам. В Octo можно настраивать разрешения участников команды с привязкой к тегам – и это превращает скор из отчётной метрики в реальный контроль. Профили низкого бэнда просто не попадают в зону видимости байеров, работающих на скейле. Не «нельзя брать», а «не показывается».

Пересчёт автоматизируется через API. У Octo полноценный REST API с поддержкой Selenium, Puppeteer и Playwright. Часть сигналов – активность, окружение, факт использования — вытягивается программно; часть подтягивается из вашей таблицы платежей и из кабинета. Скрипт раз в неделю пересчитывает балл и переставляет теги. Ручная работа остаётся только там, где нужна оценка человека.

Кто и что делал с профилем – видно в логе действий. Когда профиль улетает, первый вопрос всегда один: что с ним происходило перед этим. Лог действий команды закрывает этот вопрос фактами, а не воспоминаниями. Он же, кстати, даёт данные для блока «поведение за 14 дней» – заходы не тем человеком видны без дополнительных инструментов.

Шаблоны профилей задают стартовые условия. Новый профиль создаётся из шаблона с уже проставленным тегом score-low и закреплённым владельцем. Ни один профиль не появляется в пуле в состоянии «непонятно чей и непонятно какой».

Промокод Для читателей материала – 30% скидки на Octo Browser по промокоду CPARUPARTNER30. octobrowser.net

Кто ставит балл

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

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

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

Четыре места, где шкала врёт

Инфостиль обязывает сказать и это.

Веса подобраны под нашу вертикаль и наши площадки. Мы работаем с iGaming, и поэтому платёжка и сертификация у нас весят больше всего. У команды, работающей с нутрой или e-commerce, приоритеты будут другими. Копировать наши цифры бессмысленно – копируйте метод и калибруйте под себя по собственной статистике потерь.

Скор оценивает состояние, а не будущее. Он не предсказывает изменение политики площадки. Когда правила меняются разом для всех – а обновление гемблинг-политики Google от 26 августа 2026-го ровно такой случай, – под удар попадают и профили с баллом 85. Шкала не защищает от системных событий, она защищает от собственной неаккуратности.

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

Первый месяц шкала будет ошибаться. Веса выставляются гипотезой. Настраиваются они одним способом: каждый потерянный профиль поднимаете и смотрите, какой у него был балл перед смертью. Если регулярно улетают профили с 80+ – веса стоят неправильно, и правда в данных, а не в изначальной логике.

Что меняется через квартал

Ощутимее всего – не экономия, а тишина.

Исчезает жанр планёрки, где спорят о том, готов ли профиль. Спор просто нечем вести: есть число и есть разбивка, и обсуждать можно только конкретный дефицит.

Появляется предсказуемость. Вы заранее знаете, сколько профилей выйдет на скейл через две недели, потому что видите, сколько сейчас стоит в бэнде 40–69 и что каждому из них не хватает. Планирование бюджета перестаёт зависеть от того, повезёт ли на этой неделе.

И появляется история. Через квартал у вас накапливается статистика «балл перед потерей» – а это уже данные, на которых считаются кривые выживаемости профилей по когортам поставщиков и методов прогрева. Но это тема отдельной статьи.

TraffCloud — Infrastructure for scalable performance. Материал подготовлен при поддержке Octo Browser.