Как определять и блокировать скликивание рекламы в Яндекс?

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

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

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

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

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

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

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

Задачи, которые необходимо было решить для достижения цели защиты:

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

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

Из известных на данный момент решений для защиты является сервис CloudFlare. CloudFlare – американская компания, предоставляющая услуги CDN, защиту от DDoS-атак, безопасный доступ к ресурсам и серверы DNS. Сервис представляет собой облако, промежуточное звено между пользователем и сайтом, в случае обнаружения атаки система блокирует доступ к сайту для конкретного пользователя, защищая инфраструктуру веб-ресурса от падения. Принцип работы системы представлен на рисунке ниже. Защита от ботов и недобросовестного сбора информации не является главными инструментами этого сервиса, так что он не может гарантировать высокой эффективности против парсинга.

Ещё один популярный американский сервис – это Distil Networks, он нацелен на блокировку ботов, и защиту от автоматизированного сбора информации. Данная система уже нацелена на более эффективную защиту от ботов, предлагает системы защиты не только сайта, но API. Использует в своём арсенале капчу и блокировку трафика, после анализа активности.

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

Бот-программы (или просто, «боты») всё искуснее имитируют поведение клиента на сайте: могут набрать URL, прийти с самого авторитетного ресурса и отправить товар в корзину, позвонить, заполнить анкету, добавить сайт в бот-сеть, украсть контент, опередив индексацию от Google.

Рассмотрим наиболее типичные ситуации бот-атак в сети:

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

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

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

Приём 4. Снижение оригинальности ресурса. Бот-парсер «тихо» посещает сайт, сканирует и публикует контент на сторонних ресурсах ещё до официальной индексации, при этом не эмулируя действий посетителей. Вследствие чего сайт не поднимается в поисковой выдаче.

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

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

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

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

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

Для начала обратимся к данным собранным вебвизором. На рисунке 3 видно, что Яндекс определил, чётко пять посещений (по одному на браузер), каждый из которых прошёлся примерно по пятидесяти страницам. Здесь сразу можно отметить одну из особенностей свойственных роботам или другим автоматизированным системам – это слишком короткое время нахождения на одной странице. Примерно семьдесят секунд на пятьдесят посещений – это меньше двух секунд на страницу, что крайне несвойственно человеку.

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

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

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

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

Далее воспользовавшись инструментом отчёты можно посмотреть более подробную статистику по всем параметрам из метрики. Для примера выведем график по просмотрам (рисунок 7). На графике видно что при парсинге с одного ip график очень сильно выделяется на фоне остального трафика, а при использовании прокси, он как бы размывается и становится менее заметным.

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

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

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

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

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

Если сайт ограничивает доступ к работе без js, и другие системы детектирования, то чтобы обойти эту защиту против сайта может быть использован WebDriver. Чтобы обнаружить его использование можно получить данные с navigator.webdriver() и если он будет равен true, это будет означать, что пользователь использует автоматизированное ПО, что также говорит о высокой вероятности того, что это вовсе не человек.

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

Также можно блокировать все нетипичные UserAgent, которые принадлежат другим специальным сервисам (например, Postman UserAgent).

Рассмотренные методы детектирования автоматизированного трафика можно классифицировать по следующим параметрам.

По степени однозначности детектирования:

По времени необходимому на детектирование:

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

Рассмотренные методы блокировки трафика можно классифицировать по следующим параметрам.

По однозначности блокировки бота:

По эффективности действия против ботов:

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

На основе предложенной классификации методов защиты нами была реализована следующая модель системы обнаружения автоматизированного трафика (рисунок 9) и защиты от скликивания как следствия. Модель состоит из пяти подсистем-процессов:

1. Сбор и накопление данных

2. Система мгновенных блокировок

3. Система отложенной блокировки

4. Построение поведенческих карт

5. Система блокировки.

На основе модели построена UML диаграмма последовательности (рисунок 10), которая позволит лучше понять процессы работы системы защиты от скликивания:

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

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

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

Берет из базы данных информацию о недавних действиях пользователя (в диапазоне 30 минут) и основываясь на данных поведенческих карт делает выводы о блокировке данного пользователя.

Мониторит базу параметров блокировок и в соответствии с ним, применят против каждого бота свой способ блокировки.

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

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

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

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

Чтобы понять, как защищать, нужно понять от чего защищаться. Система Яндекс Директа умеет защищаться от простых способов скликивания рекламы. Просто так с одно IP подряд скликать ничего не получится, Яндекс не засчитает эти клики, вернёт деньги и перестанет временно показывать рекламу. Однако важно понимать, что после возврата денег Яндекс больше не идентифицирует этого клиента как плохого, поэтому он может снова вернуться через некоторое время с кликами. Чтобы избежать детектирования со стороны Яндекса злоумышленники придумывают сложные схемы. В том числе перед кликом имитирую поведенческий трафик на сайте, переходя по ссылкам. Задачей разрабатываемой нами системы защиты от кликфрода должно служить не только детектирование подозрительного трафика с рекламных площадок, но и возможность сохранить блокировку показа рекламы этому клиенту на долгое время. Чтобы решить это проблему необходимо все подозрительные сессии отметить в Яндекс.Директе, на основе этих пометок построить сегмент и выставить этому сегменту коэффициент в Яндекс Директе минус сто процентов.

Напишем простой алгоритм, по которому может работать система на начальном уровне:

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

Так определим первое условие блокировки: посетитель пришёл с рекламы, находился на сайте менее 20 секунд, посетил только одну страницу, а его ip-адрес находится в одном из списков подозрительных адресов. Данное условие будет проверяться только на завершённых сессиях, с последнего действия в которых прошло более 30 мин. Надо понимать, что бот мог почистить cookie и снова зайти на сайт, поэтому следующим шагом ищем подобных в связке ip-адрес плюс отпечаток браузера (fingerprint), такая связка даст гарантию, что это именно тот же посетитель. Для системы мгновенной блокировки добавляем параметр webdriver, так как он нам говорит, что сессия точно автоматизированная и можно не ждать конца, по этому параметру также сверяем связку ip-отпечаток.

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

Для следующих версий системы планируется добавить такие вещи как:

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

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

Разрабатываемая система должна включать в себя:

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

Проектируемая система будет представлять собой набор совместно взаимодействующих систем:

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

Разработанная архитектура системы позволяет быстро настроить работающее решение, а также в будущем масштабировать решение путем добавления новых обрабатывающих серверов, сервисов и баз данных. А выбранные средства разработки позволяют контролировать все этапы сбора информации, анализа и блокировки.

Решение задачи производилось на мощностях нашей компании, поэтому некоторые решения обусловлены доступностью инфраструктуры:

Google Tag Manager – диспетчер тегов. Сервис позволяет из одного интерфейса управлять всеми тегами различных сервисов. На сайт интегрируется только один код, а остальные коды маркетолог самостоятельно добавляет в Диспетчер без участия IT-специалиста. В нашем случае данное решение помогает минимизировать контакты с клиентами при необходимости обновления кода скрипта и расширения его возможностей.

Matomo – это бесплатная система веб-аналитики с открытым исходным кодом. Система устанавливается на сервер владельца. Основное преимущество данной платформы перед такими онлайн сервисами как Яндекс Метрика является возможность полного контроля над хранящимися данными, удобный доступ ко всем данным через api, а также возможность отслеживания ip адресов и собственных параметров, в то время как решения от Яндекса не предоставляют информацию об ip адресах, а собственные параметры обрабатываются больше дня.

Microsoft SQL Server – система управления реляционными базами данных, разработанная корпорацией Microsoft. СУБД масштабируется, поэтому работать с ней можно на портативных ПК или мощной мультипроцессорной технике. Размер страниц – до 8 кб, поэтому данные извлекаются быстро, подробную и сложную информацию хранить удобнее. Система позволяет обрабатывать транзакции в интерактивном режиме. Реализован поиск по фразам, тексту, словам, можно создавать ключевые индексы – что является особым преимуществом для нашей задачи.

Система аналитики Matomo позволяет предавать для каждого визита или действия дополнительные пользовательские параметры, внедрив специальный js код на сайт. Данный инструмент позволит нам расширить базовые возможности сервиса и использовать параметры повышения точности детектирования пользователей за счёт таких средств как вычисление fingerprint браузера, вычисление использования средств автоматизации (таких как selenium web driver). Также для повышения точности, если сайт параллельно использует систему аналитики Яндекс Метрика, то мы можем в Matomo передать уникальный идентификатор, вычисленный самой метрикой.

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

В менеджер тэгов было добавлено три скрипта: «Fingerprint», «Matomo+Ycid», «WebdriverDetect».

«Matomo+Ycid» – это основной скрипт инициализации, он запускает сбор действий на клиенте и отправляет в matomo. В дополнение к этому скрипт id Яндекс Метрики и также отправить его в matomo.

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

Скрипт «WebdriverDetect» написан с целью быстрого выявления браузеров, использующих средства автоматизации. Многие системы автоматизации браузеров (такие как Selenium Webdriver) внедряют для правильной работы служебные переменные, которые можно отследить с помощью js кода. Код был написан на основе сбора и компоновки воедино разных приёмов детектирования автоматизации.

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

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

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

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

Для тестирования системы был подключен веб-ресурс с ежедневной посещаемостью примерно триста тысяч посещений в день. На сайте был установлен наш GTM скрипт, который начал передавать данные в реальном времени.

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

Чтобы убедиться, что блокируются именно автоматизированные сессии мы можем вывести список заблокированных сессий с параметрами и отсортировать их по ip-адресу (рисунок 17). На рисунке видно, что хоть мы и не используем пока алгоритмов по блокировке подсети, но заблокированные сессии находятся в одной подсети, все они кликают по рекламе и сразу же уходят. Можно обратить внимание, что есть сессии с одинаковыми отпечатками браузера в разные даты, что говорит о том, что бот использует одни и те же машины на протяжении нескольких дней.

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

Для того чтобы убедиться в эффективности работы системы выгрузим дневную статистику по сайтам (рисунок 19). Выделим среди сайтов три типовых: крупный – site_id равное 7, средний site_id 3 и маленький site_id 15.

Дневная посещаемость у этих сайтов 281 101 посетитель, 28 617 и 1 580 соответственно. В последней колонке приведено общее количество заблокированных сессий за выделенный день. А в колонке visits_adv_count содержится информация о общем количестве переходов с рекламы. Посчитаем для этих сайтов относительное процентное соотношение заблокированных сессий к числу визитов с рекламы.

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

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

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

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