Как мы защищаем от скликивания рекламы «Яндекс.Директа», используя машинное обучение

Меня зовут Максим Кульгин, моя компания Clickfraud занимается защитой от скликивания контекстной рекламы в «Яндекс.Директе» и Google Ads. Расскажем довольно подробно нашу методику обнаружения кликающих ботов и подход к реализации защиты, которую вы можете реализовать и на своем сайте полностью или частично.

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

В наши дни все больше товаров и услуг продаются через интернет. Зеркальным ответом стало появление рекламы в интернете. Это один из самых быстрых способов донесения коммерческого контента до потребительской аудитории. Реклама устроена таким образом, что оплата рассчитывается в зависимости от количества кликов по рекламным объявлениям, а не за количество или длительность показов, как это бывает с классической рекламой по телевидению, радио или на билбордах. Ежедневно бюджет рекламной кампании ограничен внесенной суммой, при окончании бюджета показ рекламы прекращается.

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

Скликивание, кликфрод (англ. click fraud – мошенничество с кликами) — это процесс намеренного (автоматизированного) увеличения количества нецелевых переходов по рекламной кампании (таким образом, бюджет скликивается). Защита от скликивания – комплекс мер по предотвращению появления нецелевых кликов и минимизации ущерба от атак. Защита чаще всего строится на блокировке пользователей или групп пользователей в рекламных системах по ip, id на основе cookie или иным способом.

Подходы к защите от скликивания у наиболее популярных в России рекламных площадок, таких, как Яндекс.Директ и GoogeAds, эффективны не против всех видов атак. Чаще всего они признают автоматизированными только заходы с применением Selenium webdriver. Современные боты помимо маскировки использования Selenium webdriver (или применения других средств автоматизации управления браузером) также могут имитировать действия реальных пользователей, делая себя почти не отличимыми от обычных посетителей сайта с точки зрения систем обнаружения, встроенных в рекламные объявления.

Классические подходы к защите от скликивания, основанные на условном анализе формальных параметров сессий, становятся все менее эффективными в силу нескольких причин. Во-первых, все чаще корпорации, имеющие значительное влияние на тенденции развития веб-технологий (компании, создающие и поддерживающие браузеры, популярные библиотеки и фреймворки, языки программирования, поисковые и рекламные системы и т.д.), продвигают идеи анонимизации пользователей. Они затрудняют или и вовсе делают невозможным сбор некоторой информации о личности пользователя или технических характеристиках его компьютера. Такие данные могут быть использованы не только для идентификации пользователя без необходимости его регистрации и входа в систему или для показа определенного контента на основе определенных ранее предпочтений, но и в мошеннических целях. Чтобы усложнить задачу мошенникам, пользователя обезличивают и представляют его как некий набор характерных черт или как принадлежность к одному классу из некоторого разбиения.

Во-вторых, разработчики ботов создают все новые методы обхода защит. Появляются боты, которые «блуждают» в интернете. Посещая случайные страницы, они имитируют действия пользователя: передвигают указатель мыши, нажимают на кнопки, переходят по ссылкам, имитируют прокрутку колёсика мыши. Некоторые боты могут повторять человеческие сценарии поведения, составляя корзину, оставляя заявки на обратный звонок, переходя по ссылкам со схожей тематикой, при заходе на сайт дав согласие на сбор всех cookie файлов и разрешив получение уведомлений от сайта. Своими действиями боты создают себе историю и набор cookie файлов, характерных для обычного человека. Они буквально очищают себя почти ото всех формальных параметров (в т.ч. и некоторых алгоритмически вычисляемых), отличающих их от человека.

Предложенный алгоритм комплексно анализирует открытые параметры пользователей при помощи методов машинного обучения. Данный поход позволяет обойти проблему отсутствия формальных отличительных параметров у ботов и использовать анонимизацию в борьбе против мошенников при защите от скликивания.

В связи с наступлением пандемии коронавируса нового типа в 2020-м году и сопутствующим введением карантинного режима многие предприниматели, работающие в сфере B2C, были вынуждены ограничить работу своих точек продаж и предоставления услуг или и вовсе закрыть их. Не каждый бизнес оказался готов к таким значительным неожиданным изменениям условий рынка. Чтобы не допустить критического снижения доходов и банкротства своего бизнеса, некоторые бизнесмены частично или полностью перевели работу в онлайн. В том числе, начали выставлять рекламу в интернете.

Помимо увеличения количества рекламы в интернете некоторые недобросовестные предприниматели в своём стремлении обойти конкурентов стимулировали и развитие бот-сетей, покупая их услуги. Владельцы бизнесов прибегают к мошенничеству с целью влияния на алгоритмы рекламных систем, ранжирующих объявления в выдаче. Этот подход в действительности не имеет прямого влияния на ранжирование объявлений мошенников, они лишь опускают (или и вовсе удаляют из выдачи) скликиваемые объявления конкурентов.

В купе с этим повысился и спрос на защиту от скликивания, при том, требования к ней сильно возросли. Имеется в виду не только очевидное требование к способности обнаружения продвинутых ботов. Например, современный конкурентоспособный сервис защиты от скликивания должен уметь блокировать и другие источники нецелевых кликов помимо ботов, совершающих атаку на рекламу сайта. Нежелательными можно назвать любые клики, не приводящие к увеличению конверсии сайта, такие как:

Также защита от скликивания необходима и сайтам, предоставляющим место для размещения рекламы (рекламным площадкам), чтобы боты не могли скликивать ее, тем самым понижая рейтинг площадки в глазах рекламной системы и рекламирующихся брендов. Это может привести к отказам от размещения рекламы на данном сайте и снижению доходов его владельца.

Таким образом, ущерб от скликивания рекламы в действительности весьма велик и затрагивает не только скликиваемые рекламные кампании, но и рекламные площадки. В теории возможность скликивания объявлений рекламной системы должна влиять и на популярность самой системы, но в сложившейся неконкурентной монополистической обстановке это маловероятно. Большинство рекламных мест поделено между крупными корпорациями и у них нет рисков их потерять. Это реклама на интернет-страницах и порталах с большим ежедневным потоком пользователей. Среди «гарантированных» рекламных мест можно перечислить:

Единственной сферой, в которой рекламные системы могут конкурировать – независимые площадки. К независимым площадкам относятся:

Также существует интегрированная реклама, но скликивание на ней не имеет смысла, так как она почти не относится к рекламным площадкам.

На данный момент на рынке представлено несколько решений для защиты от скликивания. В таблице ниже приведены некоторые сервисы (включая и наш), работающие и в России, и за рубежом.

Как хорошо видно из таблицы, отечественный рынок не содержит большой спектр решений для удобного интеллектуального мониторинга скликивания для всех популярных в России рекламных систем, несмотря на явное наличие проблемы.

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

δ=m + n / k(1)

Здесь δ – погрешность, m и n – количество ложно заблокированных пользователей и количество незаблокированных ботов соответственно, а k – общее количество блокировок.

В процессе проектирования и реализации необходимо учитывать, что создается не полностью автономный самодостаточный сервис, а компонент системы, выполняющий конкретную задачу. Существующая система имеет свою архитектуру и построена на основе определенного стека технологий, так что надо выбирать технологии и стандарты (связи, формата данных) для обеспечения совместимости разрабатываемого сервиса с ней. Также требуется обеспечить сохранение совместимости сервиса с системой после возможного обновления стека технологий системы в будущем.

Анализ должен производиться в режиме реального времени с достаточной скоростью, чтобы не вызывать задержек в работе системы. При увеличении количества анализируемых сессий в n раз суммарный срок их обработки должен увеличиваться менее, чем в n раз. Не допускается и чрезмерное использование памяти. Сервис не должен хранить в ОЗУ длительное время данные, если нет необходимости в частом обращении к ним (как минимум раз в несколько сессий анализа).

Анализ не должен быть основан на условном сравнении параметров и должен возвращать некоторую вероятность того, что заход выполнен ботом (т. н. уровень подозрительности сессии). Система должна носить детерминированный характер. При необходимости при подготовительных к анализу работах допускается использование сторонних открытых источников данных (в том числе базы данных, датасеты и API). Обращаться к ним можно только в двух случаях:

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

Сервис должен либо иметь возможность настройки чувствительности анализа, либо предоставлять окончательный выбор, блокировать сессию или нет, тому, кто обращается к сервису. В первом случае сервис должен ожидать на вход некий параметр, линейно влияющий на результат его работы. Такой параметр может задаваться вручную или являться результатом некоторого анализа конверсии на сайте. При втором же варианте построения интерфейса взаимодействия с сервисом от него ожидается некая рекомендация, на основании которой может быть вынесено окончательное решение. Такой функционал необходим, так как реклама каждого отдельного сайта скликивается в разной степени и их владельцы могут ожидать разной работы от системы защиты от скликивания.

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

Сервис будет состоять из нескольких частей, обеспечивающих разные этапы (или отдельные процессы) в его работе. Архитектура, как и более подробное описание технических средств, будут описаны ниже, в таблице ниже лишь перечислены конкретные способы реализации отдельных модулей с кратким описанием.

Резюмируя, сформулируем постановку задачи. Необходимо создать отдельный независимый сервис вынесения решений о качестве интернет-сессий пользователей на основе отнесения их к одной из групп. Также требуется реализовать автоматизированный сбор всех необходимых данных, а разделение посетителей на группы осуществить при помощи методов машинного обучения. Полученный сервис должен иметь возможность работы в реальном времени.

Для реализации проекта необходимо собирать открытые данные пользователей во время их визитов на защищаемый от скликивания сайт. Данное утверждение основывается на предположении, что существует возможность отличить бота от реального человека, опираясь на открытые параметры его сессии (в т.ч. с нахождением и учётом скрытых связей). Сбор должен осуществляться при помощи установки скрипта (или набора скриптов) на клиенте, который бы запускался во время открытия страницы в браузере, считывал различную информацию о пользователе, сессии и устройстве и отправлял ее на хранение на удаленный ресурс.

Для таких целей используются интернет-сервисы веб-аналитики, рассмотрим некоторые из них.

Для наших целей более всего подходит Matomo, так как все данные будут храниться на нашем сервере. Например, Google Analytics открыто заявляет, что будет использовать полученные данные в «собственных целях», что недопустимо при работе с реальными клиентами. Также Matomo предоставляет наиболее простое, но при том полное API. Программный интерфейс других перечисленных сервисов стандартизирован, и от того более сложен. Быстрота и простота настройки – немаловажные факторы при создании приложения. Еще одно преимущество Matomo – высокая степень гибкости. Для кластерного анализа потребуются некоторые данные, которые не собирают сервисы веб-аналитики «из коробки». Выбранный сервис поддерживает широкий спектр расширений, позволяющих собирать необходимые данные. Google Аналитика и Яндекс.Метрика больше нацелены на анализ рекламных кампаний, который не требуется в нашем случае.

Как было указано в предыдущем параграфе, необходимый сбор данных осуществляется установкой скрипта на клиенте. Однако помимо самого сценария веб-аналитики в нашей работе могут понадобиться и некоторые другие, такие как:

Интеграция перечисленных скриптов в систему Matomo не предусмотрена изначально, однако гибкость данного сервиса позволяет отправлять пользовательские переменные как дополнительные параметры сессий в веб-аналитику. Результаты работы скриптов и будут отправляться как пользовательские переменные. Для Google recaptcha v3 это вынесенная оценка, для счётчика Яндекс.Метрики – yaClId, для FingerprintJS – сам фингерпринт, а для скрипта определения Selenium Webdriver – буль, определяющий наличие средств автоматизации тестирования.

Таким образом, необходимо разработать сценарии-обёртки над перечисленными скриптами, инициализирующие и вызывающие их и передающие выходные значения в Matomo. Для обеспечения бесперебойной работы при обнаружении багов в самописных скрипах и при необходимости их обновления (например, в случае обновления условий использования браузеров или версии языка JavaScript) используются так называемые менеджеры тегов. Менеджер тегов – сервис, позволяющий удаленно добавлять и изменять добавленные теги в HTML разметку сайта (или разметку мобильного приложения). Такой подход дает возможност править фрагменты кода (теги) без необходимости непосредственного редактирования HTML файлов.

Google Tag Manager (GTM) – менеджер тегов от компании Google. Его код устанавливается на страницу и при ее рендеринге добавляет заранее определенные теги в разметку. Данный сервис предоставляет удобную систему управления версиями тегов и возможность создания нескольких рабочих областей, что может быть полезно для одновременной работы по доработке функционала несколькими членами команды. Еще в GTM есть возможность управления очередностью запуска тегов или определения триггеров для их активации. Также реализован функционал создания глобальных переменных и их инициализации.

Серверная часть разрабатываемого сервиса создавалась с учетом особенностей существующей системы распознавания и блокировки ботов по формальным параметрам. Существующая часть нашей написана на языке C# версии 6 под платформу .NET Framework 4.7.2. Однако помимо совместимости важным параметром является современность технологий (для обеспечения безопасности и бесперебойности работы) и возможность предоставления длительной поддержки. Также в будущем планируется контейнеризация [6] всей системы, и для того, чтобы не зависеть от ранее выбранной ОС (Windows 10), более правильным подходом будет выбор кроссплатформенного фреймворка для разработки сервиса.

Наиболее современный фреймворк кроссплатформенной разработки из экосистемы .NET – .NET 5, ставший наследником двух ранее развиваемых раздельно фреймворков – кроссплатформенного .NET Core и .NET Framework под ОС Windows. Он позволяет также использовать существующий код, написанный под более старую платформу. Тем не менее, кроссплатформенность и поддержка старого кода – не единственные причины выбора данного фреймворка. Существуют фундаментальные различия между перечисленными платформами, обратимся к рекомендациям Microsoft (компания, выпускающая .NET) по выбору фреймворка. Среди случаев рекомендованного использования .NET Framework – если приложение уже разработано под .NET Framework (именно само приложение или проект, для которого выбирается платформа, а не другие сервисы в системе или проекты в решении) или если приложение использует некоторые технологии, платформы или библиотеки, не поддерживаемые .NET Core/5+ (имеются в виду .NET Core и .NET версии 5 и более поздних версий). .NET Core/5+ же рекомендуется использовать в случаях, когда требуется кроссплатформенность, создается приложение, ориентированное на микросервисную архитектуру, планируется контейнеризировать приложение при помощи Docker (докеризировать) или требуется возможность сохранения высокой производительности при масштабировании системы. Также поводом для применения .NET 5 может стать необходимость поддержки кода под разные версии .NET.

Как видно, для наших целей наиболее подходящей платформой является .NET 5, так как выполняются все условия, при которых Microsoft рекомендует её использование.

При выборе версии языка C# было решено использовать версию 8, так как в ней были добавлены некоторые особенности синтаксиса, которые помогают улучшить внятность кода и ускорить процесс разработки приложения. Также данная версия языка по умолчанию поставляется с компилятором .NET 5, что облегчает её использование.

Разрабатываемый сервис с машинным обучением будет использоваться как вычислитель параметра, определяющего необходимость блокировки показа рекламы конкретному пользователю. Похожие вычислители уже используются в существующей системе, но они имеют ряд особенностей, отличающих их от нового сервиса. Во-первых, они просто анализируют формальные параметры, производя ряд несложных вычислений лишь по необходимости. Во-вторых, при их создании не требовалось длительной настройки, сложного анализа, создания и проведения более одного теста (пусть и с несколькими кейсами). В-третьих, для их работы нет необходимости в заблаговременной подготовке некоторых данных.

Существующие вычислители (критерии подозрительности сессии) оформлены как классы, чьи методы вызываются прямо в пайплайне[8] анализа и блокировки. Такой же подход к использованию разрабатываемого функционала допустим, но не оптимален. Новый сервис будет в разы более ресурсоёмким, будет оперировать набором сущностей и требовать предварительного обучения с сохранением полученных в результате него файлов на жёстком диске. Также, чтобы не блокировать работу основного пайплайна, он должен вызываться в отдельном потоке. Вдобавок понадобится составление тестов и создание некоторого функционала, который будет использоваться только при разработке сервиса.

Перечисленные особенности можно реализовать в рамках одного класса, однако логичнее разместить их за пределами основного пайплайна в отдельном микросервисе.

Остальные микросервисы существующей системы, состоящие в основном пайплайне, используют базу данных как способ передачи данных друг между другом. Разрабатываемый сервис отличается от существующих тем, что он должен выполнять некоторые действия по запросу от других микросервисов и возвращать ответ, а не циклично проводить некоторые действия, опираясь на полученные ранее данные. Таким образом, требуется некоторая система удаленного вызова методов через протокол HTTP, на основе которой можно будет создать службу; рассмотрим некоторые из существующих решений. Приведены не взаимозаменяемые технологии, выполняющие одинаковые функции, а лишь возможные подходы к решению поставленной задачи.

Также WCF предоставляет широкий функционал для обеспечения безопасности обмена сообщениями, их бесперебойности, расширяемости разрабатываемых сервисов, интеграции с другими инструментами Microsoft (в т.ч. использование классов C# как основы для автоматического построения формата обмена данными) и многое другое.

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

Документация платформы .NET 5, используемой для создания нового сервиса, предоставляет свободно распространяемый шаблон для проектов ASP.NET Core, работающих на основе технологии gRPC. Microsoft позиционирует эту платформу как кроссплатформенного потомка WCF, расширяющую её возможности. Данный подход довольно прост, он работает на основе технологии .NET Core Workers, регистрируя специальный класс работы, обрабатывающий сообщения. При том полезной будет функция добавления таймаутов ожидания ответов. Благодаря ним можно синхронизировать запросы и обрабатывать их порциями, по нескольку за один такт. Это необходимо для бесперебойной работы сервиса. Также метаданные в сообщениях будут служить для передачи кодов ошибок.

Для машинного обучения может не всегда быть достаточно имеющихся данных. Некоторая информация нуждается в уточнении или интерпретации. Целью данного этапа является извлечение значащих данных из собранной информации более высокого уровня абстракции и формирование датасета машинного обучения. Однако функционал, разработанный для подготовки первоначального датасета также будет использоваться при штатной работе сервиса, так как и данные новых сессий пользователей необходимо будет приводить к одному виду. Например, название страны надо будет преобразовать в её код в соответствие с какой-либо системой; более полное перечисление применений будет описано ниже. Как легко видеть, такие данные не всегда можно преобразовать, ограничиваясь внутренними вычислениями, требуются какие-то дополнительные ресурсы. Среди широко распространенных открытых источников такой информации можно перечислить:

Все перечисленные информационные ресурсы и способы получения данных были так или иначе использованы в разработке системы. Например, использовался NuGet пакет IsDayOff, предоставляющий удобный доступ к API одноименного сервиса и позволяющий определять, являлся ли указанный день выходным по производственному календарю.

После обработки исходной информации и составления датасета его необходимо сохранить в файловую систему (или на удаленный ресурс). Это требуется для того, чтобы при возникновении необходимости повторного обучения алгоритмов не приходилось снова преобразовывать все данные. Существует довольно много форматов хранения структурированных данных на диске. Рассмотрим некоторые наиболее популярные из них:

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

Для целей машинного обучения в данном проекте был выбран фреймворк ML.NET, который является современным инструментом, разработанным под .NET Core/5+, предоставляющим широкий спектр функций, полезных на разных этапах машинного обучения: загрузку данных из датасета, их фильтрацию, нормализацию, различные методы машинного обучения. Также полученную в результате машинного обучения модель можно сохранить в файловую систему в формате. zip и загрузить обратно, а также создать на ее основе объект, отвечающий за работу метода машинного обучения и возвращающего результат его работы (predictor, англ. предсказатель). Также очень ценной для нашей работы особенностью этого фреймворка является широкий ассортимент функций сериализации (приведения к унифицированному, закодированному виду – числовому значению) и нормализации (распределения множества значений в определенном числовом промежутке).

Вдобавок платформа ML.NET предоставляет широкий ассортимент методов машинного обучения, выбор из нескольких алгоритмов для каждого метода и возможность интеграции новых алгоритмов, в том числе из таких популярных библиотек машинного обучения как TensorFlow и ONNX. Среди методов машинного обучения, доступных по умолчанию при установке ML.NET можно перечислить следующие методы:

Для наших целей был выбран алгоритм k-средних (k-means) метода кластеризации (clustering) машинного обучения. Он содержится в пакете ML.NET по умолчанию, также большинство необходимых нам средств сериализации и нормализации интегрированы в нее (остальные средства подготовки данных были применены в предыдущем пункте). Также данная платформа поддерживает необходимый функционал потоковых предсказаний на основе одного объекта, выносящего решения.

Также в проекте было использовано несколько других технологий, не так сильно повлиявших на ход реализации или являющихся классическими, рекомендованным в своих областях. Например, в качестве поставщика данных был использован пакет Microsoft.EntityFrameworkCore, для тестирования использовался фреймворк Microsoft.VisualStudio.TestTools.UnitTesting, а для создания визуального распределения сессий по кластерам использовалась классическая библиотека System.Drawing. Перечисленные пакеты были добавлены в проект через менеджер пакетов NuGet.

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

Для целей определения ботов необходимо анализировать параметры сессий и на основе них выносить решение о характере сессии. То есть, надо, получая на вход набор характеристик, классифицировать их как наиболее характерные для одного из выходных классов. Данная задача может быть решена при помощи машинного обучения. Рассмотрим основные методы машинного обучения:

Легко видеть, наиболее походящим для поставленной задачи методом машинного обучения является кластеризация. Форма обучения хорошо встраивается в систему, так как параметры анализируемых сессий легко могут быть представлены как вектор характеристик. Также логично использовать этот метод как наиболее популярный в задачах разбиения пользователей [12].

Существует множество алгоритмов кластеризации, все они принимают n-мерный вектор числовых характеристик на вход и на их основе определяют ближайшие объекты. При том, все характеристики расположены в одном числовом промежутке (чаще всего [0, 1] или [-1, 1]). Существует множество алгоритмов кластеризации, чаще всего их разделяют на иерархические и плоские или на чёткие и нечёткие.

Для поставленной задачи кластеризации пользователей не требуется с какой-либо вероятностью относить сессии ко всем кластерам, достаточно отнесения к одному из кластеров, определяющему конкретную вероятность недоброкачественности сессии. Также не требуется иерархичности разбиения, а делать выбор в сторону иерархических алгоритмов только для достижения детерминированности среды неразумно, так как это влечет серьезные накладные расходы. Существуют и иные способы достичь этого. Таким образом, будем выбирать алгоритм среди чётких алгоритмов плоского разбиения.

Для данной работы был выбран алгоритм k-средних (k-means). Он относится к алгоритмам квадратичной ошибки (плоский, чёткий), подразумевает минимизацию среднеквадратичной ошибки по формуле:

Здесь cj — «центр масс» кластера j, x – расстояние от экземпляра данных xi до cj. Этот алгоритм строит заданное число кластеров, расположенных как можно дальше друг от друга, итеративно подбирая их центры. В качестве критерия остановки работы алгоритма может выступать критерий минимизации ошибки. В алгоритме k-средних алгоритм не переходит на n+1-ю итерацию и возвращает полученное распределение, если распределения, полученные в n-ной и n-1-й итерации неотличны. Недостатком данного алгоритма является необходимость изначального задания количества кластеров.

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

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

Архитектура разрабатываемого сервиса подразумевает наличие клиентской и серверной частей, обменивающихся запросами без непосредственного участия пользователя.

На рисунке выше схематически изображена архитектура всей системы. Справа помещена клиентская часть. На ней располагается сценарий, считывающий поведение пользователя и остальную информацию о его сессии. Данный сценарий активируется при заходе на страницу, анализирует необходимую информацию и отсылает ее на сервер с внешним сервисом Matomo, который описан посередине рисунка. В левой части рисунка расположены сервисы серверной части. Здесь под «сервером с логикой» подразумевается набор сервисов, включенных в основной пайплайн анализа и блокировки. Этот сервер с логикой тоже построен на основан на архитектуре .NET Core Workers, хоть и написан под .NET Framework. Он циклично раз в некоторый промежуток времени посылает запросы на сервер с внешним сервисом, хранящий данные недавних сессий пользователей.

Ответы возвращают на сервер с логикой сырые данные, требующие многоступенчатой доработки и анализа для использования в рабочих целях. Там они обрабатываются, параллельно записываются в базу данных и используются в пайплайне анализа-блокировки по прямому назначению. Под хранилищем здесь подразумевается не только база данных, но и файловая система, директория сборки, в которой можно хранить некоторые дополнительные файлы, не подходящие для хранения в базе данных. Под сервером машинного обучения подразумевается некая программа с необходимым функционалом, поддерживающая gRPC запросы. Для процесса первоначального обучения модели сервер с машинным обучением запрашивает данные сессий из хранилища и обрабатывает их в соответствие со внутренней логикой.

Файл, содержащий обученную модель, сохраняется в файловую систему как часть хранилища. Для штатной работы сервис запрашивает обученную модель из хранилища. В процессе штатной работы сервер с логикой из основного пайплайна запрашивает решение по поводу некоторой сессии, сервер с машинным обучением вычисляет ответ и возвращает его в запрашивающую точку. Некоторые из описанных частей системы уже реализованы, в основном разрабатываемый функционал затрагивает сервер с машинным обучением.

Рассмотрим архитектуру сервера с машинным обучением. Она схематически представлена на рисунке ниже.

Весь сервис условно можно разделить на две независимые части, используемые на разных этапах разработки:

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

Сбор данных сессий пользователей производится в несколько этапов. После инициализации DOM вызываются скрипты, вычисляющие дополнительные параметры сессии пользователя и основной скрипт веб-аналитики. После этого вызывающие скрипты собирают данные при помощи API Matomo, и они отправляются на сервер. Вызов всех сторонних сценариев производится при помощи вызывающих скриптов, расположенных на сайте в форме тегов GTM.

Как видно на рисунке выше, в нашем случае Google Tag Manager размещает на сайте 4 тега – Fingerprint, вычисляющий отпечаток пальца браузера, Matomo – скрипт веб-аналитики, Google ReCaptcha v3, дающий оценку пользователя по многим параметрам его поведения в интернете и Webdriver – скрипт, определяющий наличие средств автоматизации тестирования при заходе на сайт.

Определение пользовательских переменных, благодаря которым дополнительные данные передаются в Matomo вместе с остальными параметрами сессии, производится при помощи добавления специальных записей в глобальный стек document._paq. Эти записи считываются скриптом Matomo и интерпретируются в зависимости от содержания. В записи содержится следующая информация:

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

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

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

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

Здесь важно найти параметры исходных данных, не имеющие объективного смысла для алгоритма машинного обучения. Чаще всего это могут быть строковые представления чего-либо. Например, в исходных данных содержалась информация о стране и городе (локаль), откуда был совершен заход на страницу. Просто название страны и города в форме набора символов не дает почти нисколько информации алгоритму машинного обучения, так как его текущее представление не отражает сути.

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

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

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

На данном этапе вместо каждой строки исходного датасета стоит числовой вектор, далее все данные анализируются и изменяются в числовом виде. Не все поля исходного набора данных получили свое отражение в поясненном датасете. Не перенесенные поля либо не имеют видимого независимого влияния на результат, либо не удалось придумать подходящее преобразование для них. Например, в поле с датой-временем начала сессии нет необходимости, потому что присутствуют поля, отражающие дату-время конца сессии и ее длину. А поле с названием провайдера, возможно, имеет смысл, но соответствующего преобразования для него придумать не получилось.

Данные два этапа – первые, выполняемые при помощи фреймворка ML.NET и контекста машинного обучения. Объект типа MlContext содержит в себе так называемые каталоги – наборы функций и моделей, служащих разным целям машинного обучения. Например, в каталоге Data есть функции для загрузки датасетов, их сохранения, а также некоторых операций с обученной моделью. Также каталог Data содержит функции для фильтрации данных на основе полей с числовыми значениями. Единственная использованная здесь функция – FilterRowsByColumn, позволяющая отсеивать те строки, в которых значения числовых полей с плавающей точкой не входят в заданные рамки. Этот метод подходит для большинства наших полей, так как для них заранее известны допустимые рамки. Например, для поля с номером секунды в сутках нижней границей будет являться 0, а верхней (исключающей) – 86400 по количеству секунд в сутках. Аналогично 4294967296 будет верхней границей для IP и ASN как 232, а 32 – для SubnetMaskBits.

Замена пропущенных значений в основном проводится на предыдущем этапе пояснения данных, однако каталог Transform объекта типа MlContext предоставляет функции замены некоторых граничных (пропущенных или удовлетворяющих заданному условию) значений. Например, можно заменять пропущенные значения минимумом, максимумом или средним из всех значений данного поля.

На данном этапе анализируется уже полученный числовой вектор. Требуется унифицировать его, масштабировать все значения таким образом, чтобы они в одинаковой мере влияли на результат. Это обязательный этап подготовки данных для анализа при помощи машинного обучения. Чаще всего он заключается в пропорциональном масштабировании значений поля в разных записях таким образом, чтобы максимальное значение стало 1, минимальное – 0, а все остальные поместились бы в промежуток от 0 до 1. Также иногда используют систему, при которой значения распределяются в пределах от -1 до 1. Для разных целей могут применяться разные типы масштабирования.

В данной работе помимо пропорционального масштабирования на основе минимального и максимального значений используется также логарифмическое масштабирование на основе среднего значения. Оно используется, например, в таких полях, как длительность визита, количество действий за визит, количество посещений и номер посещения за день. Здесь значения могут разниться очень сильно, при том, не имеет особой разницы, например, 1000 секунд длился визит или 10000, однако разница между 10 и 100 секундами существенна. Таким образом, логарифмическое масштабирование с большей чувствительностью относится к одинаковым изменениям в малом диапазоне значений, нежели в больших значениях.

Дискретные значения, полученные в результате преобразований перечислений и булевых переменных нормализуются пропорционально, при том булевы переменные, изначально имевшие значение False, примут значение 0, а True преобразуются в 1. Все функции, необходимые для нормализации значений датасета, присутствуют в каталоге Transforms объекта MlContext.

Большая часть работы, относящейся к машинному обучению в проекте, написанном под фреймворк ML.NET, производится при помощи специального объекта контекста машинного обучения MlContext. Он создается в начале работы программы и передается внутри нее в течение всей ее работы.

Класс MlContext имеет один публичный конструктор, содержащий опциональный параметр – целочисленное значение. Этот параметр называется seed (от англ. зерно), он используется для создания детерминированного характера среды. Дело в том, что в процессе машинного обучения много применений нашли генераторы случайных чисел, использующиеся для самых разных целей. Они требуют на вход некоторое зерно, seed, при присутствии которого всегда после каждого перезапуска программы они будут выдавать одинаковую последовательность случайных чисел. Если этого не сделать, от запуска к запуску результаты работы могут отличаться, даже при одинаковых входных данных. Для того, чтобы гарантировать одинаковую работу при каждом запуске, укажем некоторое значение при создании объекта MlContext.

Объект контекста машинного обучения позволяет проводить множество операций над наборами данных, моделями и даже другими операциями. Среди ключевых принципов, на которых строится вся работа с ML.NET есть работа с трансформерами (ITransformer). Они преобразуют некоторые входные данные и возвращают «трансформированные» данные. Частым подходом является составление цепочек трансформеров (TransformerChain), являющих собой пайплайны подготовки данных и/или обучения модели. Внутри одного приложения пайплайн подготовки данных и пайплайн обучения модели можно объединить в одну TransformerChain, что облегчит в последствие создание ядра предсказаний (PredictionEngine) на её основе.

Однако в одну цепочку трансформеров можно добавить только функции из каталога Transforms контекста машинного обучения. Так что функции фильтрации, расположенные в каталоге Data, необходимо сохранять отдельно и использовать перед применением получившегося пайплайна.

После получения пайплайна подготовки данных необходимо в конец него добавить алгоритм машинного обучения и обучить модель при помощи заготовленных преобразованных и отфильтрованных данных в формате IDataView. Обученная таким образом модель будет содержать в себе предварительные функции нормализации, помимо самой кластеризации. Таким образом, их не надо будет применять дополнительно. Полученная модель может быть сохранена в. zip архивный файл в файловую систему или на удаленный ресурс. После загрузки модель сразу же может использоваться без необходимости повторного обучения.

В разработанном сервисе реализован класс ClusteringResultsPlottingWorker, наследованный от BaseService, определяющего фоновую задачу, так называемую работу (work). Логика его работы такова: из базы данных берутся сессии для анализа и сразу преобразовываются для машинного обучения, обученная модель загружается из файловой системы и делается распределение сессий из БД по кластерам. Далее из обученной модели извлекаются центроиды (показания средних значений по всем входным параметрам для сессий в одном кластере), по предсказаниям определяются «координаты» точке на карте кластерного распределения.

На основе полученных данных строится псевдо-проекция распределения сессий по кластерам. Проекция не настоящая, так как исходное пространство имеет 27 измерений, и любая проекция была бы слишком запутанной. При том она не отражала бы реальную ситуацию распределения лучше, чем это делает псевдо-проекция.

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

Данная метрика полезна для визуальной оценки качества распределения. На первый взгляд может создаться впечатление, что кластеры не разделены и точки перемешаны. Однако не стоит забывать, что это лишь псевдо-проекция и расположение точек весьма условно. С другой стороны стоит обратить внимание на то, что точки внутри кластеров расположены кучно, распыление не очень большое. Это может свидетельствовать о низком среднеквадратичном внутрикластерном расстоянии (расстоянии от центроида кластера до конкретной точки), что является хорошим признаком качественного кластерного распределения.

Данный этап заключается в корректировки модели машинного обучения на основе полученных результатов. Важно отметить, корректировка модели проводится хронологически не после предыдущего этапа, а итеративно сменяя его.

При корректировке модели машинного обучения может изменяться не только модель входных данных, но и пайплайн нормализации. Также при применении метода кластеризации отдельному анализу и корректировкам подлежит параметр количества кластеров

Первоначальный пайплайн подготовки данных не включал логарифмическую нормализацию, однако после нескольких сеансов обучения было обнаружено, что строки данных, имеющие значительные логические отличия, не теряли их, находясь в форме выходного вектора целочисленных значений. Был проведен анализ и выявлено неожиданное поведение алгоритмов нормализации. Слишком большие значения таких параметров как длина сессии, количество действий во время сессии (и других параметров, теперь анализируемых логарифмически) не отбрасывались на этапе фильтрации, так как теоретически были допустимыми. Несмотря на допустимость высоких значений, не имело особого значения, какое именно число было в параметре, если оно было выше определенной точки, однако различия в низких значениях играли большую роль даже при разнице в 1.

В каталоге Transforms объекта MlContext содержится несколько заготовленных функций нормализации, среди которых есть функция NormalizeLogMeanVariance, предоставляющая необходимый функционал. Она производит нормализацию данных на основе вычисленного среднего значения и дисперсии логарифма данных.

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

Существуют специальные алгоритмы, основанные на среднеквадратичных внутрикластерном и межкластерном расстояниях. Платформа ML.NET предоставляет удобный инструмент для построения метрик кластеризации. Объект MlContext в каталоге Clustering содержит метод Evaluate, который создает эту метрику. Она содержит два числовых поля с плавающей точкой – среднеквадратичное внутрикластерное расстояние и среднеквадратичное межкластерное расстояние. Для построения таких метрик и применения их в алгоритмах подбора количества кластеров был создан отдельный Worker – ElbowMethodWorker.

На графике отмечен перегиб на точке с пятью кластерами, можно считать, что метод локтя определил 5 кластеров как оптимальное количество для данного распределения. Однако на графике перегиб показан не очень ярко выраженно, возможно, верное количество кластеров – 8. На этот вопрос алгоритм локтя не может дать однозначного ответа, придется прибегнуть к другому методу.

Здесь S – мера кластерной группировки по методу силуэта, I – среднеквадратичное внутрикластерное расстояние, а O – среднеквадратичное межкластерное расстояние. Метод предписывает искать пик на графике, составленном аналогично методу локтя. Такой график с исходными данными и отмеченным пиком показан здесь:

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

Анализ результатов заключается прежде всего в оценке изменений по количеству обвинительных вердиктов при анализе и блокировке сессий. Для этого недостаточно двух подготовленных датасетов, и необходимо наладить доступ к хранилищу. В существующей части системы есть проект, представляющий слой доступа к данным (Data Access Layer, DAL), но его использование не представляется возможным в силу особенностей совместимости платформ .NET Framework, на котором написан слой с данными и .NET 5, на котором написан новый проект.

В виду сложившейся необходимости реализуем новый слой с данными для проектов на новых версиях .NET Core/5+. В качестве основного фреймворка-поставщика данных будем использовать Entity Framework Core (EFCore). Чтобы использовать существующую базу данных и в будущем не задумываться о сложных миграциях, для реализации слоя данных был выбран подход ручного переноса необходимых сущностей из базы данных в код. В общем EFCore похож на своего предшественника Entity Framework 6 (EF6), но он также имеет и ряд особенностей, которые необходимо учитывать. Перечислим некоторые из них:

Сложно судить о преимуществах и недостатках новой версии платформы из-за не очень большого опыта ее использования, однако новый подход позволяет более однозначно оценивать процессы, происходящие при подключении к БД и во время взаимодействия с ней. Также регистрация типов позволяет явно указать типы, гарантировано возвращаемые из БД.

Как было написано выше, для оценки качества кластеров необходимо получить из базы данных новый набор сессий, чтобы на их основе оценить качество сессий, попавших в разные кластеры.

Для этих целей была создана хранимая процедура БД, по набору Id сессий возвращающая некоторую комплексную оценку или метрику качества этих сессий. В эту метрику входит статус блокировки сессии, коэффициенты подозрительности и некоторые другие формальные параметры, позволяющие судить о качестве сессий.

Из базы данных было выбрано 1000 сессий, для них было построено распределение между кластерами по обученной модели. После этого для всех обработанных сессий была создана метрика качества (из ХП БД), все метрики с указанием номера кластера были сгруппированы и записаны в файл. csv для дальнейшего ручного анализа при помощи Microsoft Excel. Сводная информация была построена при помощи применения встроенных функций суммеслимн, суммесли, срзначесли для фильтрации полного набора данных. Целью построения данной таблицы является определение средних или суммарных значений ключевых параметров для каждого из кластеров. Полученная метрика изображена ниже:

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

По суммарным показателям метрик лучшие результаты показали сессии из кластеров номер 3 и номер 5. Сессии, попавшие в эти кластеры, можно считать человеческими. Сессии из кластеров номер 1 и номер 2 имеют худшие результаты и скорее всего являются автоматизированными. А сессии, попавшие в 4-й кластер, не имеют однозначного вердикта и оставляют возможность для настройки чувствительности сервиса. Таким образом, анализ результатов доказал работоспособность созданного алгоритма и его пригодность для решения поставленной задачи по защите от скликивания.