
Комментарии 5
Очень интересная тема. Но, как будто бы, если я правильно понял статью, то подход довольно примитивный, и должен генерировать невообразимое количество ложных сигналов.
Навскидку:
1) загибается весь каз, а не один провайдер -> шторм из сигналов (соответственно, просится использование относительных величин)
2) контент менеджер перетасовал слоты -> шторм из сигналов, но меньший (соответственно, просится нормирование по какой-то из веб метрик, как, например, показ или клик на слот/игру)
3) один лудоман ушёл в полный тильт, открыв автовращение в 20 экземплярах браузера на непопулярном провайдере, разогнав бейзлайн. Когда его баланс опустеет - прилетит алерт. Соответственно, просится учёт уников вместо кол-ва ставок.
Ну и да, в этом бизнесе ж есть более интересный вызов - определять моменты целенаправленного выноса неисправных слотов. К примеру, бот-ресечер нашёл последовательность действий, вызывающую RTP>1. После чего начинается эксплуатация со многих акков. Интересно, как такое ловите)
корректно обнаруживает около 93% падений активности провайдеров, включая плавные и растянутые во времени деградации, которые ранее оставались незамеченными.
Ну и да. Такое утверждение имеет смысл только, если есть ground truth по реальным проблемам. Вангую, что всем, начиная от линейного персонала (ибо зачем терять премию) и до основателей (ибо зачем терять репутацию) со стороны провайдера, выгоднее тихо починить и никому ничего не сказать
Справедливое замечание.В iGaming действительно редко бывает идеальный ground truth - многие проблемы со стороны провайдеров чинятся тихо и без формального инцидента, если они не успевают заметно повлиять на данные
Поэтому 93% это не абсолютная истина, а сравнительная метрика. Мы сравнивали работу алгоритма с предыдущим мониторингом и смотрели, какие падения активности:
фиксировались внутренней поддержкой,
отражались в отчетах операторов,
и подтверждались дальнейшей динамикой данных.
В этом смысле цифра показывает, какую долю реально проявившихся падений активности система смогла обнаружить заранее
Спасибо за комментарий, кейсы справедливые)
Попробую ответить по пунктам
Здесь важно уточнить контекст: компания - не казино в чистом виде, а платформа, агрегирующая провайдеров для разных операторов. Поэтому сценарий «падает весь каз» не основной кейс этого алгоритма - такие инциденты покрываются отдельным мониторингом. Относительные метрики пробовала, но для раннего обнаружения именно плавных деградаций отдельных провайдеров они работают хуже
Перетасовка слотов действительно может дать шум. Поэтому алерт не срабатывает по одному проседанию, я смотрю на устойчивый нисходящий тренд на нескольких окнах подряд. Короткие эффекты от контентных изменений чаще всего отсекаются
Хорошее замечание, такие кейсы действительно бывают. Чаще всего это выглядит как кратковременный всплеск активности с последующим возвратом к норме, а не как стабильная деградация. Но учет уникальных пользователей тоже можно попробовать внедрить как дополнительную проверку. Спасибо за идею!
Антифрод и ловля RTP-эксплойтов - это вообще другая задача и другой класс алгоритмов :) Этот мониторинг не про это, он именно про раннее обнаружение деградации активности, включая плавные и растянутые падения, которые раньше просто терялись в шуме
Не рассмотрено отслеживание movingAverage.
Как я построила систему раннего обнаружения падений активности игровых провайдеров