Разработка системы поддержки принятия решений на основе анализа зависимостей показателей однотипных объектов

Юлия Боганюк

Разработка системы поддержки принятия решений на основе анализа зависимостей показателей однотипных объектов

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

Информатика

Диссертации

Вуз: Тюменский государственный университет (ТюмГУ)

ID: 5f4d4166cd3d3e0001ceafa1

UUID: c00259a0-cde5-0138-27bf-0242ac180006

Язык: Русский

Опубликовано: почти 4 года назад

Просмотры: 17

10.44

Юлия Боганюк

Тюменский государственный университет (ТюмГУ)

Комментировать 0

Рецензировать 0

Скачать - 2,0 МБ

Поделиться работой

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное автономное образовательное учреждение высшего образования «ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ» ИНСТИТУТ МАТЕМАТИКИ И КОМПЬЮТЕРНЫХ НАУК Кафедра программного обеспечения РЕКОМЕНДОВАНО К ЗАЩИТЕ В ГЭК И ПРОВЕРЕНО НА ОБЪЕМ ЗАИМСТВОВАНИЯ Заведующий кафедрой д.п.н., профессор ____________________И.Г. Захарова ______________________2018 г. МАГИСТЕРСКАЯ ДИССЕРТАЦИЯ РАЗРАБОТКА СИСТЕМЫ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ НА ОСНОВЕ АНАЛИЗА ЗАВИСИМОСТЕЙ ПОКАЗАТЕЛЕЙ ОДНОТИПНЫХ ОБЪЕКТОВ 02.04.03. Математическое обеспечение и администрирование информационных систем Магистерская программа «Высокопроизводительные вычислительные системы» Выполнила работу Студентка 2 курса очной формы обучения Боганюк Юлия Викторовна Научный руководитель к.т.н., доцент Воробьева Марина Сергеевна Рецензент к.т.н., доцент

Михаил Викторович Григорьев Тюмень 2018 ОГЛАВЛЕНИЕ ВВЕДЕНИЕ.................................................................................. 3 ГЛАВА 1. ОПРЕДЕЛЕНИЕ ЦЕЛЕЙ И МЕТОДОЛОГИИ ИССЛЕДОВАНИЯ.......................................................................5 § 1.1. Принципы работы аукциона в поисковой системе.......5 § 1.2. Обзор существующих инструментов анализа стратегий ................................................................................................... 6 § 1.3. Применение методологии CRISP-DM в работе.............7 ГЛАВА 2. ПРОЕКТИРОВАНИЕ СИСТЕМЫ «COMPETITOR». .10 § 2.1. Постановка задачи........................................................10 § 2.2. Алгоритмы и подходы, используемые в системе «Competitor»...........................................................................13 2.2.1. Средства регулирования нагрузки на сервер..........13 2.2.2. Автоматизированный сбор данных...........................16 2.2.3. Алгоритм поддержки средств регулирования нагрузки на сервер..............................................................................18 ГЛАВА 3. ПРОГНОЗИРОВАНИЕ СОСТОЯНИЯ АУКЦИОНА. .22 § 3.1. Подготовка данных.......................................................22 § 3.2. Выбор алгоритмов и оценка качества моделей обучения.................................................................................26 ГЛАВА 4. ОПИСАНИЕ ПРОГРАММНОГО ПРОДУКТА...........30 § 4.1. Используемые технологии и архитектура системы....30 § 4.2. Реализация автоматизированного сбора данных........33 § 4.3. Реализация информационного обеспечения...............35 § 4.4. Программная реализация web-приложения «Competitor»...........................................................................38 § 4.5. Программная реализация модуля анализа данных и обучения.................................................................................40 § 4.6. Апробация работы системы..........................................43 2

ЗАКЛЮЧЕНИЕ..........................................................................52 СПИСОК ЛИТЕРАТУРЫ............................................................54 ПРИЛОЖЕНИЕ 1......................................................................58 ПРИЛОЖЕНИЕ 2......................................................................59 ПРИЛОЖЕНИЕ 3......................................................................64 ПРИЛОЖЕНИЕ 4......................................................................66 ВВЕДЕНИЕ В настоящее время все более неотъемлемой частью продвижения в интернете Необходимость детального эффективности продвижения количества активных конкурентов, продвигающих интернете. Одним из является web-аналитика. анализа показателей обусловлена увеличением пользователей свои методов интернета продукты и услуги web-аналитики и в является анализ рекламных кампаний конкурентов. При разработке стратегии продвижения, в частности контекстной рекламы, используется множество инструментов. Одним из инструментов является аналитика стратегий продвижения конкурентов, то есть рекламных кампаний с однотипными параметрами. Аналитика зависимостей кампаний с стратегий и включает периодичности пересекающимися в себя выявление показателей рекламных параметрами. Такая аналитика позволяет разработать стратегию продвижения, которая будет наиболее эффективна при вводе внешних ограничений, таких как бюджет рекламной кампании и количество посетителей сайта, и будет учитывать стратегии продвижения конкурентов. 3

Данная тема является актуальной, так как ежегодно наблюдается рост оборота интернет-рекламы. Например, исследовательской компании глобального «в 2017 году Magna, рынка по оценке объем рынка интернет-рекламы составил 41% мирового рекламного рынка, при оценке объема телевизионной рекламы в 35%. Ожидается, что к 2020 году интернет-реклама составит 50% мирового рынка рекламы» [1]. Целью исследования разработка анализа системы является поддержки зависимостей и проектирование принятия решений периодичности и для показателей объектов с пересекающимися параметрами. Для достижения поставленной цели необходимо выполнить следующие задачи: ● изучить методы анализа данных, методы анализа зависимостей параметров объектов; ● проанализировать источники данных и подготовить dataset для системы; ● применить алгоритмы обучения и выполнить оценку качества моделей обучения; ● разработать систему поддержки принятия решений, предлагающую смоделированные варианты состояний аукциона; ● выполнить апробацию предлагаемых решений системы на реальных данных. Научно-практическая новизна исследовательской работы заключается в применении результатов анализа зависимостей и периодичности показателей рекламных кампаний в процессе моделирования возможных решений 4

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

ГЛАВА 1. ОПРЕДЕЛЕНИЕ ЦЕЛЕЙ И МЕТОДОЛОГИИ ИССЛЕДОВАНИЯ § 1.1. Принципы работы аукциона в поисковой системе Объявления контекстной рекламы отображаются в результатах выдачи поисковой системы при каждом запросе пользователя проводится результатам поисковой аукцион в аукциона системы. режиме После ввода реального объявления всех запроса времени. По рекламодателей размещаются на позициях рекламного блока. Пример отображения рекламного блока поисковой выдачи и позиций конкурентов по результатам аукциона представлен на рисунке 1.1.1. Рисунок 1.1.1. Пример рекламного блока поисковой выдачи по запросу «курсы повышения квалификации Тюмень» 6

Позиция, на которой будет отображаться объявление, зависит от 3 параметров: ставка, которую рекламодатель готов заплатить за размещение в аукционе, кликабельность (отношение кликов к показам) объявлений и показатель эффективности, который рассчитывается поисковой системой [12]. При разработке рекламной кампании маркетологи настраивают параметры показа объявлений, и в первую очередь настраивается рекламодателей и ставка. конкуренции Однако все с ростом чаще числа используются инструменты оптимизации бюджета кампании. Например, настраивается временной таргетинг показа объявлений: день недели, числа настройка месяца, показа часы суток. объявлений определенной позиции, то есть, размещаться, например, на первой Также возможна исключительно при на невозможности строчке рекламного блока, объявление исключается из показа. Так как пользователи аукцион проводится выполняют запрос, каждый раз, когда невозможно без автоматизированных систем отследить результаты поисковой выдачи и возможные стратегии размещения конкурентов (всех рекламодателей, объявления которых отображаются при вводе одного и того же запроса). § 1.2. Обзор существующих инструментов анализа стратегий Анализ стратегии размещения конкурентов в поисковой выдаче является одним из первых этапов разработки рекламной кампании. На данный момент существует 2 подхода к решению задачи анализа стратегий - мониторинг 7

поисковой выдачи и использование специальных сервисов для анализа стратегий конкурентов. При ручном мониторинге поисковой выдачи специалисты анализируют список размещающихся в выдаче конкурентов и их позиции. Мониторинг производится с определенной периодичностью и по всем поисковым запросам, которые включены в рекламную кампанию. С помощью специальных сервисов возможно получение всех поисковых запросов, по которым отображаются объявления определенного конкурента. К таким сервисам относятся SimilarWeb, СайтРепорт. Сервис информацию SimilarWeb об позволяет источниках получать трафика, сводную ключевых словах, ссылках, присутствии в социальных сетях. Для того чтобы получить сводную информацию, необходимо ввести адрес сайта конкурента. Сервис СайтРепорт позволяет для указанного сайта получить информацию о рекламной активности – количестве поисковых запросов, по которым отображаются объявления владельца сайта. Специальные сервисы для анализа стратегий размещения объявлений в поисковой выдаче позволяют получить сводную информацию по домену, такую как средняя позиция, процент времени размещения на каждой позиции, количество показов на каждой позиции. К таким сервисам относятся «Инклюзив Медиа» и SpyWords. Сервис «Инклюзив Медиа» позволяет выгрузить отчет по видимости конкурентов с поисковой выдаче, получить подробную информацию о позициях рекламных объявлений сайтов конкурентов. 8

Сервис SpyWords позволяет выгрузить информацию о количестве и показателе CTR ключевых слов сайтов конкурентов. Стоит отметить, информации качестве по что для конкурентам источников данных мониторинга приведенные используют сводной сервисы в собственную накопленную базу данных, а не открытые источники. § 1.3. Применение методологии CRISP-DM в работе Для достижения цели разработки системы поддержки принятия решений необходимо провести анализ данных, включающий предварительную обработку исходных данных и анализ источников данных. Опишем процесс проведения научного исследования по методологии CRISP-DM (Cross Industry Standart Process for Data Mining) [26]. Согласно данной методологии разделим исследование на этапы (см. Рисунок 1.3.1): 1.Бизнес-анализ; 2.Анализ данных; 3.Подготовка данных; 4.Моделирование; 5.Оценка результата; 6.Внедрение. 9

Рисунок 1.3.1. Схема этапов методологии CRISP-DM Рассмотрим задачи, которые включены в каждый пункт детально и определим, какая работа в рамках каждого из этапов будет проведена. На этапе бизнес-планирования определяются бизнесцели проекта, выполняется оценка текущей ситуации, определяются цели аналитики и выполняется подготовка плана проекта [23]. В рамках проведенного исследования в этап бизнес-планирования входят следующие задачи: постановка задачи исследования, формулировка решаемой проблемы, анализ возможных источников данных, выполняется выбор метрик для оценки точности результата моделирования, определяются критерии успешности модели, формулируются требования к разрабатываемой системе и разрабатывается архитектура системы. «Этап анализа данных включает реализацию сбора данных, описание, изучение и проверку качества данных». В ходе проведенного исследования на этапе анализа данных 10

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

аукциона. На этапе внедрения в ходе проведенного исследования определяется, каким образом будет внедрен модуль анализа данных в систему и интегрирован с webприложением, реализован модуль визуализации данных. 12

ГЛАВА 2. ПРОЕКТИРОВАНИЕ СИСТЕМЫ «COMPETITOR» § 2.1. Постановка задачи Анализ стратегий продвижения рекламных кампаний с однотипными параметрами включает в себя отслеживание текущих показателей и позиций размещения всех объектов кампаний, выявление зависимостей между показателями и позициями как объектов одной рекламной кампании, так и между объектами разных кампаний. Знание однотипных стратегий кампаний и зависимостей позволяет для новой показателей рекламной кампании разработать такую стратегию, по которой владелец сайта будет получать наибольшее количество переходов посетителей на сайт с учетом ограничений на бюджет кампании. Мониторинг показателей однотипных кампаний пользователем является невыполнимой задачей, так как поисковые системы обновляют показатели с частотой до 1 минуты. Ручная обработка, анализ зависимостей постоянно обновляющихся и неструктурированных данных требует автоматизации процесса аналитики данных. Поэтому целью исследования является проектирование системы поддержки принятия решений на основе анализа зависимостей и периодичности однотипных объектов. Для достижения поставленной цели необходимо выполнить следующие задачи: ● изучить методы анализа данных, методы анализа зависимостей параметров объектов; ● определить требования к разрабатываемой системе; 13

● автоматизировать сбор данных; ● разработать алгоритм поддержки средств регулирования нагрузки на сервер; ● спроектировать и разработать хранилище данных системы; ● выполнить анализ и подготовку данных для обучения; ● применить алгоритмы обучения и выполнить оценку качества моделей обучения; ● разработать систему поддержки принятия решений, предлагающую смоделированные варианты состояний аукциона; ● с целью апробации проверить применимость предлагаемых решений системы на реальных данных. Разрабатываемое приложение должно удовлетворять следующим требованиям:  приложение должно быть написано с использованием web-технологий для обеспечения возможности доступа к системе с любого устройства;  приложение должно поддерживать средства регулирования нагрузки на сервер рекламной системы;  необходимо автоматизировать сбор данных из рекламной системы и поисковой системы: сбор цен позиций из рекламной системы и позиций конкурентов из поисковой системы;  в качестве входных данных система должна принимать данные рекламных кампаний посредством подключения к пользовательскому кабинету рекламной системы. Разрабатываемое приложение следующий функционал: 14 должно предоставлять

 визуализация поисковой выдачи рекламных объявлений с указанием цен позиций;  выявление стратегий размещения объявлений рекламных кампаний конкурентов;  генерация предложений возможных стратегий размещения объявлений конкурентов. Работа системы поддержки принятия решений должна быть разделена на следующие этапы: 1) формирование из набора данных о ценах позиций и результатах выдачи поисковой системы таблиц данных по каждому поисковому запросу; 2) предобработка данных для обеспечения высокой точности результатов прогнозирования; 3) проведение по каждому конкуренту анализа данных о позициях объектов поисковой выдачи кампаний на и наличие ценах на позиции зависимости, поиск функции для прогнозирования позиции; 4) обучение модели прогнозирования и статистический анализ полученных результатов; 5) моделирование состояния поисковой выдачи. Сбор данных из рекламной системы и поисковой выдачи должен осуществляться автоматически с указанным интервалом времени. Для того чтобы построить прогноз позиции, на которой будет размещаться объект кампании, проанализируем зависимость признаков объекта друг от друга. Пусть дано множество объектов A={a1 , a2 ,… , an|n ∈ N }, где ai= {a1i , a2i , … , am i } , гдеi=1.. n , m ∈ N . Для каждого объекта ai дано множество состояний наблюдаемых 15 Si ={ s1i , s2i , … , s ci } , гдеc –

порядковый номер последнего замера состояния объектов, то есть sij =aij= {a1ij , a2ij , … , amij } , j=1. . c. Схема объектов и их состояний представлена на рисунке 2.1.1. Рисунок 2.1.1. Схема объектов и их состояний Необходимо состояний Si и для каждого множество ai, имеющего соответствующих множество состояниям меток позиции amij ∈ M , найти отображение y :Si →a mij такое, что для неизвестного состояния sc+1 можно найти метку label ∈ M . i § 2.2. Алгоритмы и подходы, используемые в системе «Competitor» 2.2.1. Средства регулирования нагрузки на сервер Сервер API Яндекс.Директ имеет несколько средств регулирования нагрузки. Есть два обязательных средства для поддержки в приложении. 16

Во-первых, сервер API Яндекс.Директ накладывает ограничения на количество объектов, которое возвращает сервер в ответ на запрос, и ограничение на количество объектов, которое может быть отправлено серверу в одном запросе. Во-вторых, в качестве основного средства регулирования нагрузки на сервер применяются баллы. Нехватка баллов не позволяет выполнять запросы к серверу API. Баллы начисляются на счет аккаунта Яндекса и списываются при каждом запросе к серверу от имени этого аккаунта. В ответ на каждый запрос к API в HTTP-заголовке запроса возвращается параметр, в котором указано количество баллов:  израсходовано баллов при выполнении запроса;  доступный остаток баллов;  суточный лимит баллов аккаунта. Каждому суточный аккаунту лимит предоставляется баллов. Причем индивидуальный лимит зависит от активности и эффективности рекламных кампаний аккаунта – количества кликов и показов и израсходованного бюджета кампаний и всего аккаунта. Частые и объемные запросы к API считаются нерациональной нагрузкой на серверы API в тех случаях, когда количество кликов и показов кампаний аккаунта растет незначительно или когда на счете кампаний или аккаунта осталось немного средств. Яндекс использует сетку бюджетных порогов для расчета индивидуальных суточных лимитов. Эта сетка была разработана с учетом статистики кампаний Яндекса разных типов и тематик. 17

Индивидуальный суточный лимит баллов разделен на 24 часовых интервала и предоставляется по принципу скользящего окна (см. Рисунок 2.2.1). На счет аккаунта в начале каждого интервала начисляется 1/24 суточного лимита. В текущем интервале от имени аккаунта можно использовать 1/24 начисленные, но суточного не лимита использованные плюс за баллы, последние прошедшие 23 часа. Рисунок 2.2.1. Описание средства регулирования нагрузки на сервер При этом, время начала временного интервала может отличаться для разных аккаунтов и не совпадать с началом астрономического часа. Сервером API Яндекс.Директ списываются баллы в зависимости от произведенного действия: 1. успешный вызов метода; 2. вызов метода, завершившийся ошибкой; 3. получение объекта; 4. успешную операцию создания объекта; 18 или редактирования

5. ошибку выполнения операции создания или редактирования объекта. Пункты 4 и 5 не рассматриваются в данной работе, так как не входят в список задач исследования и разработки. Важность поддержки баллов как средства регулирования нагрузки на сервер обусловлена тем, что за ошибки при выполнении запросов к серверу списывается в разы большее количество баллов, чем за успешную отправку запросов. 2.2.2. Автоматизированный сбор данных Сбор из рекламной системы происходит посредством взаимодействия с сервером системы через API с помощью POST-запросов в формате JSON (см. Рисунок 2.2.2) и включает следующие этапы: 1. Формирование идентификаторов получить запроса, включающего ключевых значения цен слов, позиций и по группу позволяющего каждому из включенных ключевых слов; 2. Отправка получения необходимого цен всех количества ключевых слов запросов для кампании в соответствии с алгоритмом поддержки регулирования нагрузки на сервер и получение ответа в формате JSON; 3. Десериализация полученных данных в структуру для хранения исторических данных, включающую поля значений времени замера состояния, идентификатора ключевого слова, цен всех позиций аукциона, и запись в локальное хранилище данных. 19

Рисунок 2.2.2. Схема процесса выгрузки данных с сервера рекламной системы Сбор данных производится с о позициях помощью размещения объявлений синтаксического анализа HTML-кода страницы поисковой выдачи (см. Рис. 2.2.3). Процесс сбора можно разделить на следующие этапы: 1. Формирование строки URL, включающей ключевое слово, для отправки get-запроса на адрес поисковой системы; 2. Отправка запроса и получение ответа в виде HTML-кода страницы поисковой выдачи; 3. Синтаксический анализ HTML-кода страницы поисковой выдачи для извлечения данных объектов рекламного блока; 4. Запись параметров извлеченных объектов в локальное хранилище данных. 20

Рисунок 2.2.3. Схема процесса сбора данных о позициях размещения объявлений 2.2.3. Алгоритм поддержки средств регулирования нагрузки на сервер Необходимо разработать метод, который будет определять временные интервалы обновления параметров аккаунтов, так как за ошибочные запросы к серверу API списывается увеличенное количество баллов по сравнению с успешными запросами. При этом, временные интервалы должны рассчитываться таким образом, чтобы обмен данными между приложением и сервером был равномерно распределен внутри интервалов средства регулирования нагрузки на сервер. Разработанный метод состоит из двух частей. Во-первых, данные о баллах обновляются и пересчитываются при каждом запросе приложения к серверу API. Во-вторых, каждую минуту происходит пересчет текущих показателей и 21

проверка необходимости отправки запроса на сервер для обновления данных аккаунта. Для реализации метода необходимо хранить следующие данные в локальном хранилище приложения:  SMi - количество баллов, списываемое за вызов i-го метода API, и SOi - количество баллов, списываемое за объект при вызове i-го метода API;  SD - суточный лимит баллов аккаунта;  SC - текущий лимит баллов аккаунта;  SMin - количество баллов, необходимое для выгрузки всех объектов аккаунта;  UB - дата и время последней выгрузки всех объектов аккаунта;  UA - дата и время последнего пополнения баллов аккаунта. Алгоритм обновления данных о баллах, который выполняется при каждом запросе от приложения к серверу API (см. Рис. 2.2.4): Шаг 1) Считывание из HTTP-заголовка запроса значений SD и SC - показателей баллов аккаунта; Шаг 2) Обращение к локальному хранилищу приложения и получение SD и SC - текущих показателей баллов аккаунта; Шаг 3) Если новое значение SC больше текущего значения SC, которое записано в локальном хранилище приложения, то обновление UA в хранилище на текущее значение даты и времени; Обновление в локальном хранилище значения SC текущего доступного лимита баллов аккаунта; Шаг 4) Обращение к локальному хранилищу приложения и вычисление OC – количества объектов, параметры которых необходимо обновить, и QC – количества запросов, которые 22

необходимо отправить на сервер API для выгрузки всех дочерних объектов и параметров аккаунта, при условии включения в каждый запрос максимально возможного количества объектов; Шаг 5) Обращение к локальному хранилищу и получение значений SM и SO; Шаг 6) Вычисление количества баллов, необходимого для выгрузки всех объектов аккаунта, по формуле (2.1): n (2.1) SMin=∑ OC∗SO i +QC∗SM i , i=1 где i=1..n - номер типа запроса. Шаг 7) Обновление в локальном хранилище приложения значений SMi и SOi. Рисунок 2.2.4. Схема алгоритма обновления данных о баллах 23

Алгоритм пересчета текущих показателей и проверки необходимости отправки запроса на сервер API для обновления данных аккаунта выполняется каждую минуту (см. Рис. 2.2.5): Шаг 1) Обращение к локальному хранилищу приложения и получение текущих значений SMin, SC, UA и UB; Шаг 2) Вычисление количества выгрузок данных, которое может быть выполнено до следующего пополнения лимита баллов аккаунта, по формуле: (2.2) P=SC/SMin Рисунок 2.2.5. Алгоритм пересчета текущих показателей и проверки необходимости отправки запроса Шаг 3) Вычисление количества минут, через которое будет пополнен лимит баллов аккаунта, по формуле: 24

(2.3) M =60−|CT −UA| , где CT – значение текущего времени суток; Шаг 4) Вычисление временного периода, через который возможна равномерная выгрузка параметров всех объектов аккаунта в текущем интервале суточного лимита баллов аккаунта, по формуле: (2.4) PM =M / P Шаг 5) Если UB ≥ PM , то приложение формирует и отправляет запрос на сервер для выгрузки параметров объектов аккаунта и значение UB обновляется приложения. 25 в локальном хранилище

ГЛАВА 3. ПРОГНОЗИРОВАНИЕ СОСТОЯНИЯ АУКЦИОНА § 3.1. Подготовка данных Этап подготовки данных включается в себя отбор данных (признаков и объектов), очистку данных, генерацию, интеграцию и форматирование. Система поддержки принятия решений содержит модуль автоматизированного сбора данных, что позволяет не выполнять отбор и очистку данных. Автоматизированный сбор данных исключает ситуации, когда у объектов могут быть пропущенные значения атрибутов, ошибки в данных или несоответствующая кодировка. На этапе генерации проанализировать спроектировать гипотез о исходные данных атрибуты дополнительные повышении необходимо объектов атрибуты точности для модели и проверки обучения при добавлении дополнительных признаков. Сбор данных источника, поэтому происходит необходимо из более, выполнять чем одного интеграцию данных для подготовки обучающей выборки. Данные о ценах позиций объекта ai, получены от сервера поисковой множеством системы и представлены S1i ={s1,1 , s1,2 ,… , s1,c } i i i состояний, упорядоченным определенных в пункте 2.1, с соответствующим каждому элементу значением времени замера состояния, где c – порядковый номер последнего замера состояния объекта ai. Данные о позициях размещения рекламных объявлений объекта ai, полученные из поисковой выдачи представлены упорядоченным множеством 26 S2i ={s2,1 , s2,2 ,… , s2,c } i i i состоянийс

соответствующим каждому элементу значениемвремени замера состояния. |S1i |=¿ S2i ∨¿. При этом Объединим множества S1i и S2i j ∪ s2i , j. Примем за состояний в множество Si так, что sij =s1, i метку класса выборки значение ami позиции размещения рекламного объявления, а множество a i {a¿ mi за множество признаков объекта. Выборка содержит значения времени замера состояния, поэтому необходимо провести форматирование данных таким образом, что элементы множества были упорядочены по возрастанию по значению времени замера состояния. Данные о ценах POST-запроса от десериализуются в позиций, получаемые сервера объект посредством рекламной типа системы, динамический список структуры AuctionBids. Данные о позициях получаемые в формате размещения конкурентов, HTML в ответе на GET-запрос, извлекаются посредством синтаксического анализа в объект типа динамический список структуры SearchAd. Так как при настройке рекламных кампаний используются такие параметры таргетинга, как время, то выдвинем гипотезу о наличии зависимости между позициями объявлений поисковой выдачи и временем и проверим ее. Для этого выполним генерацию дополнительных признаков состояний аукциона: месяц, день недели, суточный временной интервал (по 3 часа), час, минута. Данные признаки будем генерировать из значения поля TimeStamp объекта структуры AuctionBids. Обучение модели прогнозирования состояния аукциона по каждому поисковому запросу 27 будет проводиться по

матрице данных, которая формируется путем интеграции данных о ценах позиций, данных о позициях размещения конкурентов и данных о времени замера состояния. Под интеграцией данных понимается «горизонтальное» соединение признаков. Схема процесса интеграции данных представлена на Рисунке 3.1.1. 28

Получение данных о ценах из Яндекс.Метрики Для каждого поискового запроса Выхо Обращение к хранилищу данных Получение данных о позициях из поисковой выдачи и синтаксический анал Создание объекта датасета Запись в объект значений цен и сгенерированных признаков времени Для каждого конкурента в поисковой выдаче да Конкурент есть в файле? нет Записать для конкурента номер позиции в поисковойДобавить выдаче в файл колонку конкурента и Рисунок 3.1.1. Схема процесса интеграции данных 29

Таким образом, для каждого поискового запроса рекламной кампании данные (признаки), выгружаемые из двух источников, интегрируются в один объект дата-сета – объект структуры CompetitorDatasetItem (см. Таблица 3.1.1). Таблица 3.1.1.Признаки объекта дата-сета № Название поля 1 stateID Тип int 2 pi 3 comp j int 4 month day_of_wee k int part_of_day int 5 6 long int Идентификатор состояния Более одного поля Более одного Позиция j-го конкурента конкурент а Номер месяца Номер дня недели, где понедельник = 1 Номер части дня, где Цены размещения на iой позиции par t ¿ =[hour /3] Значение часа, в которые был сделан замер состояния Значение минуты, в которую был сделан замер состояния 7 hour int 8 minute int После интеграции CompetitorDatasetItem переменную, Примеча ние Описание признаков объект преобразовывается соответствующую формату в структуры строковую CSV-файла для обрабатываемого поискового запроса, и записывается в конец этого файла. Для обучения модели прогнозирования состояния аукциона по определенному поисковому запросу в качестве выборки данных (дата-сета) используются данные, хранящиеся в соответствующем этому запросу CSV-файле. 30

Пример файла для поискового запроса № 49589305 представлен на Рисунке 3.1.2. Каждая строка представляет запись состояния аукциона, каждый столбец – признак состояния. Файл содержит более 12 000 строк и 24 столбца, данные взяты за 3 месяца с интервалом 10 минут. Рисунок 3.1.2. Пример CSV-файла поискового запроса Автоматизированный сбор данных для обучения модели гарантирует, что однозначно исключить из выборки можно только первый признак – идентификатор состояния аукциона (значения этого признака являются уникальными для каждого объекта выборки). § 3.2. Выбор алгоритмов и оценка качества моделей обучения Необходимо конкурентов. спрогнозировать В качестве позиции исходных каждого данных из для прогнозирования позиции возьмем признаки p 1 , p2 ,… , p z ( z – количество позиций рекламного 31 блока поисковой

выдачи),month, day_of_week, part_of_day, hour, minute, определенные в пункте 3.1. Поставленную задачу можно рассматривать как задачу многоклассовой классификации. Для решения задачи применим методы машинного обучения, рекомендованные документацией библиотеки scikit-learn в разделе «Подбор подходящей методами: оценочной функции» Стохастического [25]. градиентного Воспользуемся спуска (SGD), Метод опорных векторов (SVM) с линейным, радиальным базисным, полиномиальным ядрами и k-ближайших соседей. Также применим такие классические методы классификации, как Дерево решений и Байесовский классификатор. В статье [13] Алексея Натекина, члена сообщества «Open Data Science», говорится о том, что в задачах ранжирования выдачи поисковых систем используется метод Градиентного бустинга, поэтому применим этот метод для прогнозирования позиции конкурента в поисковой выдаче. Для оценки качества алгоритмов классификации воспользуемся такой метрикой, как матрица ошибок для C классов (см. Таблица 3.2.1). Пусть дана выборка xi (i=1 ,… , N , y i – метка класса -го объекта, y i ∈ {1,2 , … , C }), каждый объект которой относится к одному из C классов и классификатор a, который эти классы предсказывает. Матрицей ошибок для такого классификатора называется следующая матрица: C ij i, j=0 M ={m } N (3.1) , mij =∑ [ a ( x k ) = j ] [ y k=i ] k=0 Значение mi j означает, сколько объектов класса jбыли распознаны как объекты класса i. Таблица 3.2.1. Матрица ошибок классификатора y1 y2 … 32 yi … yC

y1 m11 m12 y2 m21 m22 … … … yi mi1 mi2 … … … yC mC 1 mC 2 Матрица ошибок определяются относительно друг многоклассовых m2i … mii … mCi позволит алгоритмом друга задачах, … … … … … … mij … … … … … … понять, mij m2C … miC … mCC какие (классификатором) в большинстве сводят классы неверно случаев. подсчет качества «В к вычислению одной из двухклассовых метрик. Выделяют два подхода к такому сведению: микро- и макро-усреднение» [11]. Введем следующие обозначения:  TP i – число корректно предсказанных элементов класса i ;  TN i – число элементов, не относящихся к классу i, предсказанных как не относящиеся к классу i;  FN i – число элементов, которые были некорректно предсказаны как элементы класса i;  FP i – число элементов класса i, которые были некорректно предсказаны как элементы других классов. «При микро-усреднении сначала эти характеристики усредняются по всем классам, а затем вычисляется итоговая метрика». Рассчитаем для каждой модели микро-меры для учета наиболее крупных классов. Рассчитаем точность - долю истинно положительных примеров среди предсказанных как положительные, по формуле: 33 примеров,

K ∑ TP i i=1 Precisionμ = (3.2) K ∑ (TPi + FP i ) i=1 Рассчитаем долю истинно положительных примеров среди фактически положительных примеров, то есть полноту, по формуле: K ∑ TPi i=1 Recallμ = (3.3) K ∑ (TP i + FN i ) i=1 Рассчитаем F-меру, которая представляет гармоническое среднее между точностью и полнотой, по формуле: F 1 −scoreμ = 2∗Precisionμ∗Recallμ Precisionμ + Recallμ (3.4) «При макро-усреднении сначала вычисляется итоговая метрика для каждого класса, а затем результаты усредняются по всем классам». Рассчитаем для учета всех классов с одинаковым весом без учета их размеров для каждой модели макро-меры – точность по формуле (3.5), полноту по формуле (3.6) и F-меру по формуле (3.7): K Precision M= K Recall M = TP i ∑ TP + FP i=1 i K F 1 −score M = (3.6) TP i ∑ TP + FN i=1 (3.5) i i i K (3.7) 2∗Precision M∗RecallM Precision M + RecallM Если классы отличаются по мощности, то при микроусреднении они практически никак не будут влиять на результат, поскольку их вклад в средние TP, FP, FN и TN 34

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

ГЛАВА 4. ОПИСАНИЕ ПРОГРАММНОГО ПРОДУКТА § 4.1. Используемые технологии и архитектура системы Модули сбора и визуализации системы «Competitor» были разработаны в среде Microsoft Visual Studio 2017 Comunity на языке программирования C# с использованием технологии ASP.NET Core и библиотеки JavaScript, FluentScheduler. В качестве СУБД использовалась СУБД PostgreSQL 9.6. ASP.NET Core – кроссплатформенная, высокопроизводительная среда от Microsoft с открытым исходным кодом для разработки web-приложений и webсервисов. JavaScript – объектно-ориентированный сценарный язык программирования. браузерах как Наиболее язык широко применяется сценариев для в придания интерактивности webстраницам. FluentScheduler – библиотека для выполнения программного кода приложения по расписанию. PostgreSQL 9.6 – реляционная система управления базами данных с открытым исходным кодом. Взаимодействие осуществлялось (интерфейса с с сервером API использованием прикладного 5-й Яндекс.Директ версии программирования) API сервера Яндекс.Директ. Модуль синтаксического анализа поисковой реализован с помощью библиотеки AngleSharp 0.9. 36 выдачи

Модуль анализа данных системы «Competitor» был разработан в среде Spyder дистрибутива Anaconda на языке программирования Python 3.6. Схема архитектуры системы поддержки принятия решений представлена на Рисунке 4.1.1. Система поддержки принятия решений включает в себя 2 основных программных блока – web-приложение и модуль анализа данных. Web-приложение включает следующие модули:  модуль расчета нагрузки и отправки запросов на сервер рекламной системы;  модуль синтаксического анализа HTML-страницы поисковой выдачи;  модуль интеграции данных;  модуль интерпретации и визуализации данных. Web-приложение взаимодействует с реляционной базой данных, сервером рекламной системы поcредством API и поисковой системой по HTTP-протоколу. Модуль интеграции данных осуществляет запись данных в NoSQL хранилище данных, которое представлено каталогом CSV-файлов. Модуль анализа данных хранилищем данных. 37 взаимодействует с NoSQL

Рисунок 4.1.1. Архитектура системы поддержки принятия решений

§ 4.2. Реализация автоматизированного сбора данных Для сбора данных о ценах позиций и получения данных рекламных кампаний реализован модуль взаимодействия с API рекламной системы Яндекс.Директ. Запросы к API Яндекс.Директ выполняются по протоколу HTTPS методом POST. Запрос должен содержать HTTP-заголовок Authorization с OAuth-токеном пользователя, от имени которого осуществляется запрос к API, а также может содержать другие заголовки, необходимые для обработки запроса. Ответ содержит заголовок RequestId – уникальный идентификатор запроса. Входные и выходные структуры данных передаются в теле запроса и ответа. Взаимодействие с API производится методом запросов в формате JSON. Преимущество JSON заключается в большей компактности по сравнению с SOAP/XML, а также в скорости анализа запросов на стороне сервера рекламной системы. Для извлечения данных о ценах позиций использовался сервис Bids и метод get, который возвращает цены для ключевых фраз по позициям показа. «После отправки POSTзапроса на сервер Яндекс.Директа приложению возвращается объект или массив объектов, представленный в формате JSON. Результирующие данные в формате JSON десериализуются в объект соответствующего класса, после чего информация, необходимая для дальнейшей работы, сохраняется в локальное хранилище данных приложения» [22].

Возвращаемый объект десериализуется в объект типа динамический список структуры AuctionBids (см. Рисунок 4.2.1), для которого Position - номер позиции объявлений в формате «PNM» (N – номер блока выдачи, M – номер позиции в блоке), Bid - ставка рекламодателя и Price - цена размещения на позиции. AuctionBids - Position: string - Bid: long - Price: long Рисунок 3.2.1. Описание структуры AuctionBids Для получения данных о позициях размещения конкурентов в результатах поисковой выдачи на языке программирования C# реализован метод GetTop (см. Листинг в Приложении 1), для которого входным параметром является значение поискового запроса строкового типа, и возвращаемый результат – список объектов структуры SearchAd (см. Рисунок 4.2.2), где pos – номер позиции объявления, site – ссылка на сайт конкурента. SearchAd - pos: int - site: string Рисунок 4.2.2. Описание структуры SearchAd Перед отправкой запроса на адрес поисковой системы необходимо для поискового запроса провести кодирование символов согласно таблице кодирования URL, то есть привести строку формата «word 1 word 2[wordN ]»к виду « word 1% 20 word 2[ %20 wordN ]» 40

По HTTP-протоколу отправляется запрос методом Getна URL-адрес «http://yandex.ru/search/» поисковой системы и в качестве параметра указывается кодированный поисковый запрос, для которого необходимо получить результаты выдачи. Результат запроса возвращается в формате HTML-кода страницы поисковой выдачи. С использованием библиотеки AngleSharp из кода страницы извлекаются в список все блоки типа «div», для которых атрибут «class» имеет значение «serp-adv-item». Для каждого извлеченного блока создается объект структуры SearchAd, в который записывается номер блока, где номер блока соответствует позиции в поисковой выдаче, и ссылка на сайт, которая извлекается из кода блока как элемент типа «a» со значением атрибута «class» содержащим значение «path__item». § 4.3. Реализация информационного обеспечения Для реализации системы поддержки принятия решений было спроектировано хранилище данных, которое включает реляционную базу данных и NoSQL хранилище данных. Реляционная база данных хранит данные пользователей системы, рекламных кампаний и информацию о баллах для поддержки средства рекламной системы. регулирования Схема нагрузки реляционной на базы сервер данных представлена на рисунке 4.3.1. База состоит из 12 таблиц: AspNetUsers, Tokens, YandexUsers, YandexAdGroups, YandexCampaigns, YandexKeywords, 41

YandexKeywordsCompetitors, YandexCompetitors, YandexDirectUpdates, YandexDirectScores, YandexDirectServices, YandexDirectScoresDictionary. Сущность AspNetUsers содержит основную информацию о пользователях системы (см. Приложение 2). Сущность Tokens (см. Приложение 2) содержит информацию об авторизационных OAuth-токенах пользователей рекламной системы. Токен указывается в заголовке HTTP-запроса при каждом обращении к серверу. YandexUser, YandexCampaigns, YandexAdGroups, YandexKeywords – сущности для десериализации данных рекламного аккаунта и хранения информации о кампаниях и их составляющих. Сущность YandexUser (см. Приложение 2) содержит основную Одному информацию пользователю несколько аккаунтов аккаунтов системы рекламной может рекламной системы. соответствовать системы. Сущность YandexCampaigns (см. Приложение 2) хранит информацию о рекламных кампаниях. Сущность YandexAdGroups (см. Приложение 2) содержит информацию о группах объявлений кампании. Сущность YandexKeywords (см. Приложение 2) содержит информацию о поисковых запросах кампании. Сущность содержит YandexCompetitors информацию о YandexKeywordsCompetitors предназначена для (см. Приложение конкурентах. (см. реализации связи 2) Сущность Приложение 2) многие-ко-многим между сущностями YandexKeywords и YandexCompetitors и хранения дополнительной информации для корректного чтения данных о позициях конкурентов из NoSQL хранилища. 42

Сущность содержит YandexDirectUpdates информацию о (см. времени Приложение обновления 2) данных объектов. Сущность YandexMinScores (см. Приложение 2) содержит информацию о текущих баллах и минимальном количестве баллов для получения информации об объектах. YandexDirectScoresDictionary, YandexDirectServices – справочники для хранения статической информации API Яндекс.Директ. Сущность YandexDirectScoresDictionary (см. Приложение 2) содержит информацию о количестве списываемых баллов за объект для каждого метода каждого сервиса API YandexDirectServices рекламной (см. системы. Приложение Сущность 2) информацию о сервисах API рекламной системы. 43 содержит

Рисунок 4.3.1. Схема реляционной базы данных NoSQL хранилище представляет собой каталог файлов модели «ключ-значение» формата CSV с наименованиями «keyword_[N].csv», где [N] - идентификатор поискового запроса. Название файла является ключом, содержание файла – значением. Каждый состояниях файл keyword_[N].csv аукциона для хранит поискового данные запроса о с идентификатором [N]. Для каждого файла строка – это объект структуры CompetitorDatasetItem, а столбцы соответствуют атрибутам объекта (см. Рисунок 3.1.2). 44

§ 4.4. Программная реализация web-приложения «Competitor» Веб-приложение состоит из 17 классов. Классы ClientsGetQuery, AdGroupsGetQuery, BidsGetQuery CampaignsGetQuery, AdsGetQuery, необходимы для KeywordsGetQuery, формирования структуры запросов на получение данных с сервера рекламной системы и сериализации структуры в JSON-строку. Классы ClientsGet, CampaignsGet, AdGroupsGet, AdsGet, KeywordsGet, BidsGet необходимы для десериализации JSONстрок, получаемых от сервера рекламной системы в объекты приложения. Класс APIYandexDirectRequestвключает методы для формирования, отправки запроса и получения ответа от сервера рекламной системы (см. Таблицу 4.4.1). Таблица 4.4.1. Описание методов класса APIYandexDirectRequest № Имя метода Результ ат Назначение 1 SendAPIRequ void est() Выполняется сериализация отправляемого объекта в JSONформат, отправка запроса, получение и десериализация ответа от сервера рекламной системы 2 GetAPIResult string () Возвращает ответ сервера рекламной системы в строковом формате 3 UpdateUsers void Scores(List<l ong> units, object model) Обновление в базе данных значений текущего и суточного лимита баллов аккаунта 46

Класс YandexDirectScores включает методы для пересчета баллов аккаунта рекламной системы (см. Таблицу 4.4.2). Таблица 4.4.2. Описание методов класса YandexDirectScores № Имя метода Результ ат Назначение 1 UpdateUsers void Units(List<lo ng>units) Обновление в базе данных значений текущего и суточного лимита баллов аккаунта 2 UpdateUsers Scores() Пересчет минимального количества баллов для получения всех данных и сохранение в базу данных 3 CountScores int ForObjectsTy pe(YandexDir ectServices service, intobjectsCou nt) Подсчет количества баллов, необходимого для получения данных определенного сервиса 4 GetBidsPerio d() Расчет интервала отправки запроса на сервер рекламной системы void int Класс CompetitorDataset необходим для формирования структуры объекта прогнозирования дата-сета состояния для аукциона. обучения Класс модели SearchAd необходим для формирования структуры объекта, который представляет результат поисковой выдачи в виде списка конкурентов и их позиций. Класс YandexDirectUpdater реализует интерфейс IJob и включает методы для автоматизации сбора данных из двух источников - рекламной системы и поисковой выдачи (см. Таблицу 4.4.3). 48

Таблица 4.4.3. Описание методов класса YandexDirectUpdater № Имя метода Результ ат Назначение 1 Execute() void Реализует метод интерфйеса IJob, для каждого аккаунта выполняет проверку возможности отправки запроса, получает данные о ценах позиций для поисковых запросов кампаний 2 CompetitorA ddData(Bids GetbidsGetR esult) void Для каждого поискового запроса получает результаты поисковой выдачи и интегрирует данные с последующим сохранением в хранилище данных 3 GetTop(strin g keyword) List<Sear Отправляет GET-запрос и chAd> получает данные поисковой выдачи в HTML-формате, производит синтаксический анализ результата и преобразовывает в объект поисковой выдачи Интерфейс страницы отображением высокочастотному рекламной прогноза аукциона поисковому рисунке 4.4.1. 49 запросу кампании по с наиболее представлен на

Рисунок 4.4.1. Интерфейс страницы системы § 4.5. Программная реализация модуля анализа данных и обучения Модуль анализа данных реализован на языке программирования Python 3.6 в среде Spyder. Для работы с dataset использовалась табличная структура данных DataFrame с помощью библиотеки pandas. Каждый столбец структуры данных DataFrame является объектом Series. Таким образом, набор признаков объектов выборки для задачи классификации представлен табличной структурой данных DataFrame, и последовательность меток классов для объектов выборки представлена объектом Series. Для построения матрицы парных коэффициентов корреляции использовался метод corr() библиотеки pandas. Реализации методов машинного обучения для решения задачи многоклассовой классификации производилась с использованием библиотек scikit-learnи xgboost. В таблице 4.5.1 приведены импортируемые 50 классы библиотек для

реализации классификаторов с вариантами передаваемых параметров. В качестве вспомогательных инструментов для анализа результатов обучения классификаторов использовались дополнительные методы библиотеки scikit-learn (см. Табл. 4.5.2). Методы библиотеки matplotlib использовались для вывода графиков анализируемых данных. Для нормализации использовался класс значений признаков цен sklearn.preprocessing.StandardScaler библиотеки scikit-learn. 51

Таблица 4.5.1. Классы библиотек для реализации классификаторов № 1 Библиотека scikit-learn Классификатор Стохастический градиентный спуск Класс библиотеки sklearn.linear_ model.SGDCla ssifier Параметры loss="hinge", penalty="l2" loss="modified_hube r", penalty="l2" loss="log", penalty="l2" loss="hinge", penalty="l1" loss="modified_hube r", penalty="l1" loss="log", penalty="l1" loss="hinge", penalty="elasticnet" loss="modified_hube r", penalty="elasticnet" loss="log", penalty="elasticnet" 2 scikit-learn Метод опорных векторов sklearn.svm.S VC kernel='linear', C=1,gamma='auto' kernel='rbf', C=1,gamma='auto' kernel='poly', C=1,gamma='auto' 3 scikit-learn Дерево решений sklearn.tree.D random_state=1 ecisionTreeCla ssifier 4 scikit-learn Мультиномиальны й Байесовский классификатор sklearn.naive_ bayes.Multino mialNB 5 scikit-learn Кближайших sklearn.ne n_neighbors = 10 ighbors.K 52

№ 6 Библиотека xgboost Классификатор Класс библиотеки соседей Neighbors Classifier Градиентный бустинг xgboost.XGBCl assifier Параметры max_depth=3, n_estimators=300, learning_rate=0.05 Таблица 4.5.2. Дополнительные методы библиотеки для анализа данных № Метод Назначение 1 sklearn.cross_validation.cross_val _score Выполнение кросс-валидации, возвращает массив оценок модели для каждого запуска 2 sklearn.metrics.confusio Возвращает матрицу ошибок n_matrix для классификатора 3 sklearn.metrics.classific Возвращает значения метрик ation_report классификатора: точность, полнота, F-мера § 4.6. Апробация работы системы Для апробации работы системы были созданы рекламные кампании 10 конкурентов, и для каждого из них была задана стратегия размещения объявлений кампании в поисковой выдаче. Апробация проводилась на данных за 3 месяца на более 12 000 записей состояний аукциона, взятых с интервалом 10 минут. Поисковая выдача содержит 8 позиций. Пример файла для поискового запроса №49589305 (см. Рис. 3.1.2). Каждая строка представляет запись состояния аукциона, каждый столбец – признак состояния. Файл содержит более 12 000 строк и 24 столбца. В каждой строке 53

для двух из десяти конкурентов значение позиции равно 0, так как поисковая выдача содержит всего 8 позиций, то есть, только 8 конкурентов отображаются в выдаче, а оставшиеся 2 в выдачу не попадают. Цель проведения апробации – сравнить состояния аукциона, спрогнозированные с помощью обученной модели, и реальные значения состояния аукциона. Пример заданных стратегий для каждого конкурента см. в Таблице 4.6.1. Таблица 4.6.1. Описание стратегий конкурентов № конкуре нта 1 Повышенная ставка Ограниченный Ставка по период времени умолчанию 3 120 110 120 130 120 с 18:00 до с 20:00 до с 20:00 до с 21:00 до выходные 4 130 руб./клик 5 120 руб./клик 6 120 руб./клик 2 руб./клик руб./клик руб./клик руб./клик руб./клик 20:00 22:00 21:00 22:00 в будние дни в период с 12:00 до 16:00 в будние дни в период с 09:00 до 22:00 в будние дни в период с 09:00 до 12:00 и с 18:00 до 22:00 7 10 руб./клик. 20 руб./клик. 40 руб./клик. 40 руб./клик. 50 руб./клик. 50 руб./клик. 70 руб./клик. 80 руб./клик. 90 руб./клик. 100 руб./клик. 8 9 10 54

Матрица корреляции для наиболее зависимых между собой признаков по результатам расчета представлена в таблице 4.6.2. Таблица 4.6.2. Матрица корреляции наибольших коэффициентов 1,00 part_of_d ay 0,99 0,99 1,00 0,64 -0,54 0,62 -0,53 0,70 0,64 -0,54 0,71 1,00 -0,45 0,78 -0,45 1,00 -0,70 hour hour part_of_da y comp1 comp5 comp7 comp5 comp7 0,62 -0,53 0,70 0,71 comp1 0,78 -0,70 1,00 Высокий коэффициент корреляции между значениями часа и позиции конкурента 1 объясняется стратегией конкурента на повышение ставки в течение четырех часов с 18:00 до 22:00. Для пары значений часа и позиции конкурента 5 коэффициент корреляции отрицательный, так как при увеличении часа, то есть, к концу дня, ставки начинают повышаться у конкурента 1 и 2. При этом позиция конкурента 5 снижается, то есть между часом и позицией конкурента 5 есть обратная зависимость. Коэффициент корреляции между значениями часа и позицией конкурента 7 выше, чем между значением часа и позицией конкурента 1, так как повышение позиции конкурента 1 происходит только в течение 4 часов (с 18:00 до 22:00), а для конкурента 7 позиция повышается в течение всего дня за счет более высокой фиксированной ставки (70 руб./клик). 55

Матрица парных корреляционных коэффициентов всей выборки приведена в Приложении 3. Построим графики зависимости позиции от времени для конкурентов 1 (см. Диаграмму 4.6.1) и конкурента 7 (см. Диаграмму 4.6.2). По оси абсцисс отложены значения часа, по оси ординат - позиция конкурента. График зависимости позиции конкурента 1 от часа 5 4 comp1 3 2 1 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 -1 hour Диаграмма 4.6.1. График зависимости позиции конкурента 1 от часа 56

График зависимости позиции конкурента 7 от часа 9 8 7 6 comp7 5 4 3 2 1 0 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 hour Диаграмма 4.6.2. График зависимости позиции конкурента 7 от часа Для разделена проведения на 5 кросс-валидации равных частей. выборка Выборка данных была была разделена на обучающую и тестовую в соотношении 80% и 20% соответственно. Показатели кросс-валидации выбранных методов классификации для всех конкурентов приведены в таблице 4.6.3. По результатам тестирования наибольшую точность показал метод кросс-валидации. соседей для k-ближайших Метрики соседей оценки прогнозирования метода позиций конкурентов представлены в таблице 4.6.4. 57 по метрике k-ближайших всех десяти

max_depth=3, Градиентный бустинг n_estimators=300 , К-ближайших n_neighbors = 10 соседей Дерево решений БайесовскийМультиномиальный loss="modified_hu penalty="elasticn et" loss="log", ber", loss="hinge", loss="log", penalty="elasticn et" penalty="l1" loss="modified_hu ber", penalty="l1" loss="hinge", penalty="l1" loss="log", loss="modified_hu penalty="l2" ber", penalty="l2" loss="hinge", penalty="l2" Параметры kernel='linear', C=1,gamma='aut o' kernel='rbf', C=1,gamma='aut o' kernel='poly', Метод опорных векторов Стохастический градиентный спуск C=1,gamma='aut Метод Таблица 4.6.3. Показатели кросс-валидации методов Конкурент 0,37 0,65 0,79 0,65 0,65 0,51 0,79 0,79 0,79 0,63 0,61 0,60 0,38 0,39 0,79 1 0,60 Конкурент 0,71 0,87 0,87 0,70 0,71 0,67 0,38 0,87 0,71 0,67 0,68 0,65 0,52 0,60 0,87 2 0,72 Конкурент 0,50 0,50 0,25 0,38 0,46 0,39 0,27 0,34 0,39 0,37 0,35 0,36 0,40 0,43 0,50 3 0,48 Конкурент 0,31 0,28 0,36 0,29 0,32 0,38 0,31 0,31 0,20 0,29 0,30 0,29 0,39 0,45 0,34 4 0,30 Конкурент 0,30 0,19 0,19 0,25 0,23 0,22 0,18 0,21 0,21 0,25 0,24 0,26 0,18 0,14 0,30 0,30

max_depth=3, Градиентный бустинг n_estimators=300 , К-ближайших n_neighbors = 10 соседей Дерево решений БайесовскийМультиномиальный kernel='linear', C=1,gamma='aut o' kernel='rbf', C=1,gamma='aut o' kernel='poly', loss="modified_hu penalty="elasticn et" loss="log", ber", loss="hinge", loss="log", penalty="elasticn et" penalty="l1" loss="modified_hu ber", penalty="l1" loss="hinge", penalty="l1" loss="log", loss="modified_hu penalty="l2" ber", penalty="l2" loss="hinge", penalty="l2" C=1,gamma='aut Метод Параметры 5 Метод опорных векторов Стохастический градиентный спуск Конкурент 0,17 0,18 0,22 0,21 0,26 0,26 0,21 0,21 0,20 0,25 0,23 0,22 0,30 0,32 0,25 6 0,26 Конкурент 0,15 0,25 0,24 0,29 0,25 0,21 0,19 0,27 0,27 0,27 0,28 0,29 0,30 0,35 0,26 7 0,26 Конкурент 0,18 0,22 0,25 0,23 0,20 0,25 0,25 0,20 0,18 0,23 0,22 0,22 0,38 0,39 0,26 8 0,25 Конкурент 0,28 0,22 0,26 0,20 0,22 0,25 0,18 0,20 0,27 0,25 0,23 0,24 0,38 0,39 0,26 9 0,25 Конкурент 0,24 0,24 0,22 0,27 0,26 0,23 0,23 0,22 0,19 0,26 0,25 0,23 0,38 0,35 0,26 0,25 59

Конкурент 1 loss="hinge", Параметры 0,79 0,79 loss="hinge", Оценка Точность по кросс(Микровалидаци мера) и Полнота (Микромера) 0,79 60 loss="hinge", loss="log", Таблица 4.6.4. Метрики оценки метода k-ближайших соседей F-мера (Микромера) Точность (Макромера) 0,79 0,38 Полнота (Макромера) 0,25 0,22 соседей max_depth=3, n_neighbors = 10 n_estimators=300 , Метод Дерево решений Метод опорных векторов Градиентный бустинг К-ближайших БайесовскийМультиномиальный kernel='linear', C=1,gamma='aut o' kernel='rbf', C=1,gamma='aut o' kernel='poly', C=1,gamma='aut loss="modified_hu penalty="elasticn et" loss="log", ber", penalty="elasticn et" penalty="l1" loss="modified_hu ber", penalty="l1" penalty="l1" loss="log", loss="modified_hu penalty="l2" ber", penalty="l2" penalty="l2" 10 Стохастический градиентный спуск F-мера (Макромера)

Конкурент 2 0,87 0,87 0,87 0,87 0,22 0,25 0,23 Конкурент 3 0,50 0,59 0,59 0,59 0,39 0,32 0,32 Конкурент 4 0,34 0,48 0,48 0,48 0,43 0,38 0,38 Конкурент 5 0,30 0,43 0,43 0,43 0,30 0,22 0,21 Конкурент 6 0,25 0,40 0,40 0,40 0,37 0,28 0,27 Конкурент 7 0,27 0,26 0,26 0,26 0,19 0,19 0,17 Конкурент 8 0,26 0,26 0,26 0,26 0,19 0,19 0,17 Конкурент 9 0,26 0,26 0,26 0,26 0,19 0,19 0,17 Конкурент 10 0,26 0,26 0,26 0,26 0,19 0,19 0,17 61

После обучения модели классификации с помощью метода k-ближайших соседей самым точным оказался прогноз позиций конкурента 2 равный 87%, а самым низким оказался прогноз позиции конкурента 5 равный 0,25%. Как видно по результатам расчета матрицы ошибок для каждого конкурента, занимаемых позиций уменьшается точность классификатора конкурента при 1 по увеличении конкурента классификации. методу представлена количества соответственно Матрица ошибок k-ближайших соседей для на 4.6.2 для рисунке и конкурента 5 представлена на рисунке 4.6.3. Рисунок 4.6.2. Матрица ошибок классификатора для конкурента 1

Например, по рисунку 4.7.2 можно увидеть, что конкурент 1 занимает всегда позицию 0, 2, 3 или 4. Рисунок 4.6.3. Матрица ошибок классификатора для конкурента 5 Например, по рисунку 4.7.3 можно увидеть, что конкурент 5 занимает любую позицию, кроме 4, что снижает точность прогноза позиции.  63

ЗАКЛЮЧЕНИЕ В результате работы над магистерской диссертацией была разработана система «Competitor» поддержки принятия решений на однотипных основе анализа объектов. зависимостей Система показателей позволяет проводить мониторинг рекламных блоков поисковой выдачи и получать прогноз позиций размещения объявлений конкурентов. Все поставленные задачи были достигнуты:  изучены методы анализа данных, методы анализа зависимостей параметров объектов;  определены требования к разрабатываемой системе;  автоматизирован сбор данных;  разработан алгоритм поддержки средств регулирования нагрузки на сервер;  выполнен анализ и подготовка данных для обучения;  применены алгоритмы машинного обучения и выполнена оценка качества моделей обучения;  работа системы апробирована на реальных данных, получены достоверные результаты. Знания позиций размещения объявлений конкурентов позволят специалисту по поисковой рекламе устанавливать дополнительные настройки показа объявлений с целью увеличения времени отображения объявлений на первых позициях поисковой выдачи. В результате проведения исследования сделан вывод о том, что подготовительный этап, включающий анализ, сбор и подготовку данных, занимает около 60% времени всего 64

исследования, а сам процесс моделирования около 10-15% за счет применения открытых библиотек анализа данных. Получено согласие со стороны ООО «Инкомтехнологии Групп» на внедрение разработанной системы «Competitor» в работу организации. «Инкомтехнологии настраивать Это позволит Групп» стратегии не специалистам только размещения более ООО точно объявлений своих клиентов, но и использовать наличие такой системы как конкурентное преимущество своей компании при проведении деловых переговоров. Программный код модуля автоматизированного сбора данных был государственной зарегистрирован регистрации №2017664023). 65 (свидетельство программы для о ЭВМ

СПИСОК ЛИТЕРАТУРЫ 1. 2017 was the year digital ad spending finally beat TV [Электронный ресурс]. URL: https://www.recode.net/2017/12/4/16733460/2017-digitalad-spend-advertising-beat-tv (дата обращения: 22.06.2018). 2. Аукцион [Электронный ресурс]. URL: https://support.google.com/adwords/answer/142918? hl=ru&ref_topic=24937 (дата обращения: 20.02.2018). 3. Бабаев, А., Евдокимов, Н., Иванов, А. Контекстная реклама — СПб.: Питер, 2011. — 304 с.: ил. ISBN 978-5459-00335-2. 4. Боганюк, Ю.В., Воробьева, М.С. Алгоритм взаимодействия с сервером контекстной рекламы для уменьшения нагрузки на сервер / МАТЕМАТИЧЕСКОЕ И ИНФОРМАЦИОННОЕ научных трудов. МОДЕЛИРОВАНИЕ: Вып.15. Тюмень: сборник Издательство Тюменского государственного университета, 2017. 534 с. 5. Боганюк, Ю.В., Воробьева, М.С. Разработка web- приложения для автоматизации управления контекстом интернет-страниц при Издательство выдаче Тюменского поисковой системы / государственного университета, 2016. 55 с. 6. Боганюк, Ю.В., Воробьев, А.М. Разработка алгоритма автоматического пересчета интернет-страниц ИННОВАЦИОННЫЕ при параметров поисковой ТЕХНОЛОГИИ контекста выдаче / НАУЧНОГО РАЗВИТИЯ: сборник статей Международной научно66

практической конференции (25 октября 2015 г. 2015 г., г.Пермь). / в 2 ч. Ч.2 – Уфа: АЭТЕРНА, 2015. – 286 с. 7. Боганюк, Ю.В. архитектуры управления Разработка веб-приложения контекстными высокоуровневой для автоматизации кампаниями с учетом ограничений / Материалы 54-й Международной научной студенческой конференции Информационные технологии / МНСК-2016: Новосиб. гос. ун-т. Новосибирск, 2016. 249 стр. 8. Виды поисковых запросов [Электронный ресурс]. URL: http://www.vsetyrabota.ru/semanticheskoe-yadro/184-vidypoiskovykh-zaprosov (дата обращения: 15.02.2018). 9. Давыдов, Д.В., Измалков, С.Б., Смирнов, А.С. Рынки контекстной рекламы: экспериментальные эмпирические работы / Журнал и Новой экономической ассоциации, №4 (28), с. 56-73 10. Клиентский сценарий на веб-страницах ASP.NET [Электронный ресурс]. URL: https://msdn.microsoft.com/ru-ru/library/3hc29e2a(v=vs.10 0).aspx (дата обращения: 22.02.2018). 11. Высшая классификация школа экономики. [Электронный Многоклассовая ресурс]. URL: https://www.coursera.org/lecture/vvedenie-mashinnoeobuchenie/mnoghoklassovaia-klassifikatsiia-P9Zun (дата обращения: 25.05.2018). 12. Нейский, И.М. Классификация и сравнение методов кластеризации [Электронный ресурс]. it-claim.ru/Persons/Neyskiy/Article2_Neiskiy.pdf (дата обращения: 18.04.2018). 67 URL:

13. Открытый курс машинного обучения. Тема 10. Градиентный бустинг [Электронный ресурс]. URL: https://habr.com/company/ods/blog/327250/ (дата обращения: 20.03.2018). 14. Первоначальные сведения [Электронный ресурс]. URL: https://tech.yandex.ru/direct/doc/dg-v4/concepts/WhereToB egin-docpage/ (дата обращения: 20.02.2018). 15. Подробно о контекстной рекламе [Электронный ресурс]/icontext. – режим доступа: http://www.icontext.ru/ context/context-in-depth/ (дата обращения: 15.04.2018). 16. Позиции на поиске [Электронный ресурс]. URL: https://yandex.ru/support/direct/general/positions.xml (дата обращения: 12.02.2018). 17. и Смирнов, А.С. Рынки контекстной рекламы: подходы теоретические модели / ЭКОНОМИКА И МАТЕМАТИЧЕСКИЕ МЕТОДЫ, 2015, том 51, № 4, с. 14– 24 18. Соколов Е. Выбор моделей и критерии качества [Электронный ресурс]. URL: http://www.machinelearning.ru/wiki/images/1/1c/Sem06_me trics.pdf 19. Требования к приложению [Электронный ресурс]. URL: https://tech.yandex.ru/direct/doc/dg-v4/concepts/requireme nts-docpage/ (дата обращения: 08.02.2018). 20. Троелсен Э. Язык программирования C# и платформа .NET 4.5 [Текст] / Троелсэн Э.; перевод с 68

английского Артеменко Ю. М. – 6-е изд. – М.: ООО «И. Д. Вильямс», 2013. – 1312 с. 21. Трейдинг и машинное обучение с подкреплением [Электронный ресурс]. URL: http://ai- news.ru/2018/02/trejding_i_mashinnoe_obuchenie_s_podkre pleniem.html (дата обращения: 24.04.2018). 22. Формат взаимодействия [Электронный ресурс]. URL: https://tech.yandex.ru/direct/doc/dg/concepts/formatdocpage/ (дата обращения: 15.03.2018). 23. Формат JSON [Электронный ресурс]. URL: https://tech.yandex.ru/direct/doc/dg-v4/concepts/JSONdocpage/ (дата обращения: 08.01.2018). 24. Х.Бринк, Дж. Ричардс, М. Феверолф. Машинное обучение. – СПб.: Питер, 2017. 25. Choosing the right estimator [Электронный ресурс]. URL: http://scikit- learn.org/stable/tutorial/machine_learning_map/index.html (дата обращения: 05.04.2018). 26. CRISP-DM: Scientist-ов проверенная методология [Электронный http://www.pvsm.ru/algoritmy/255490 для ресурс]. (дата Data URL: обращения: 15.03.2018). 27. JavaScript [Электронный ресурс]. https://developer.mozilla.org/ru/docs/Web/JavaScript URL: (дата обращения: 28.01.2018). 28. Microsoft. Руководство Microsoft по проектированию архитектуры приложений, 2е издание. 69

29. Боганюк, Ю.В., Воробьева, М.С. Свидетельство о государственной регистрации программы для ЭВМ № 2017664023 «Разработка модуля «SearchAdImport v2.2» для загрузки иерархических выдачи» от 14.12.2017. 70 объектов поисковой

ПРИЛОЖЕНИЕ 1 ЛИСТИНГ КОДА АВТОМАТИЧЕСКОЙ ВЫГРУЗКИ ДАННЫХ public List<SearchAd>GetTop(string keyword) { stringkeyword_format = keyword.Replace(" ", "%20"); stringurl = "http://yandex.ru/search/?lr=55&text="+keyword_format; List<SearchAd>searchAds = new List<SearchAd>(); using (HttpClient client = new HttpClient()) using (HttpResponseMessage response = client.GetAsync(url).Result) using (HttpContent content = response.Content) { string result = content.ReadAsStringAsync().Result; var parser = new HtmlParser(); var document = parser.Parse(result); varadsItems = document.All.Where(m =>m.LocalName == "li" &&m.ClassList.Contains("serp-adv-item")); intpos = 1; foreach (var ad in adsItems) { varadParse = parser.Parse(ad.InnerHtml); varsiteNode = adParse.All.Where(a =>a.LocalName == "a" &&a.ClassList.Contains("path__item")).FirstOrDefault(); if (siteNode != null) { varsiteNodeParse = parser.Parse(siteNode.InnerHtml); string site = siteNodeParse.All.Where(b =>b.LocalName == "b").First().InnerHtml; searchAds.Add(new SearchAd(pos, site)); pos++; } } } returnsearchAds; } 71

ПРИЛОЖЕНИЕ 2 ОПИСАНИЕ ТАБЛИЦ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ Таблица 1. Сущность AspNetUsers № Имя поля 1 Id (PK) 2 Email 3 4 Тип Назначение varchar(1 Идентификатор пользователя 28) varchar(2 Электронный адрес 55) пользователя PasswordHas varchar(2 Хэш пароля пользователя h 55) UserName varchar(2 Имя пользователя 55) Таблица 2. Сущность Tokens № Имя поля Тип Назначение 1 token_id (PK) Int 2 token_yandex user(FK) long 3 token_token 4 token_expire sin 5 token_type varchar(2 Тип токена (тип определяется 55) рекламной системой) 6 token_date timestamp Дата выдачи токена Идентификатор токена Идентификатор аккаунта Яндекс.Директ varchar(2 Значение токена 55) long Количество секунд до окончания действия токена Таблица 3. Сущность YandexUsers № Имя поля Тип 1 Yandexuser_I d (PK) long Назначение Идентификатор аккаунта в рекламной системе 72

№ Имя поля Тип Назначение 2 Yandexuser_aspNe tUser (FK) varchar(2 55) 3 Yandexuser_l ogin varchar(2 Логин аккаунта в рекламной 55) системе 4 Yandexuser_e varchar(2 mail 55) Email пользователя аккаунта 5 Yandexuser_t varchar(2 imestamp 55) Дата и время последней проверки наличия изменений данных 6 Yandexuser_ phone Идентификатор пользователя приложения varchar(2 Телефон пользователя 55) аккаунта Таблица 4. Сущность Campaigns № Имя поля Тип Назначение 1 Yandexcamp _Id (PK) int Идентификатор кампании 2 Yandexcamp _user (FK) long Идентификатор аккаунта рекламной системы 3 Yandexcamp _campId long Идентификатор кампании в рекламной системе 4 Yandexcamp _title varchar(2 Название кампании 55) 5 Yandexcamp _timestamp varchar(2 55) 6 Yandexcamp _startDate varchar(2 Дата запуска кампании в 55) рекламной системе 7 Yandexcamp _balance long Текущий баланс рекламной кампании 8 Yandexcamp _clicks long Количество кликов всех объявлений кампании 9 Yandexcamp _impressions long Количество показов всех объявлений кампании Дата и время последней проверки наличия изменений данных кампании 73

Таблица 5. Сущность YandexAdGroups № Имя поля Тип 1 Yandexadgro up_Id (PK) int Идентификатор группы объявлений int 2 Yandexadgro up_campaign Идентификатор кампании, которой принадлежит группа объявлений long 3 Yandexadgro up_group_ID 4 Name Назначение Идентификатор группы объявлений в рекламной системе varchar(2 Заголовок группы объявлений 55) Таблица 6. Сущность YandexKeywords № Имя поля Тип 1 Yandexkeyw ord_Id (PK) int long 2 Yandexkeyw ord_keyword Id Yandexkeyw 3 ord_adGroup 4 int Назначение Идентификатор поискового запроса Идентификатор поискового запросав рекламной системе Идентификатор группы объявлений, которой принадлежит поисковый запрос Yandexkeyw varchar(2 Значение поискового запроса ord_keyword 55) Таблица 7. СущностьYandexCompetitors № Имя поля Тип int 1 YandexCom petitor_id (PK) 2 YandexCom petitor_site long Назначение Идентификатор конкурента Адрес сайта конкурента 74

Таблица 8. СущностьYandexKeywordsCompetitors № Имя поля Тип Назначение int 1 Yandexkeywo rd_keywordId (PK) Идентификатор поискового запроса long Идентификатор конкурента 2 YandexComp etitor_Compe titorId (PK) int 3 YandexComp Keyword_nu m Номер конкурента в файле, соответствующем поисковому запросу Таблица 9. Сущность YandexDirectUpdates № Имя поля Тип 1 YandexkUser _Id (PK) long 2 3 4 5 6 7 ClientUpdate Назначение Идентификатор аккаунта datetime Дата и время обновления баллов аккаунта CampaignsUp datetime Дата и время обновления date данных кампании AdGroupsUp date datetime Дата и время обновления данных групп объявлений AdsUpdate datetime Дата и время обновления данных объявлений KeywordsUpd datetime Дата и время обновления ate данных поисковых запросов BidsUpdate datetime Дата и время обновления данных ставок Таблица 10. Сущность YandexMinScores № Имя поля Тип 1 YandexkUser _Id (PK) long Назначение Идентификатор аккаунта 75

№ Имя поля Тип Назначение 2 ClientDayLim it long Суточный лимит баллов аккаунта 3 ClientCurLim it long Текущий лимит баллов аккаунта long 4 CampaignsMi nScores Минимальное количество баллов для получения данных рекламной кампании long 5 AdGroupsMin Scores Минимальное количество баллов для получения данных групп объявлений long 6 AdsMinScore s Минимальное количество баллов для получения данных объявлений long 7 KeywordsMin Scores Минимальное количество баллов для получения данных поисковых запросов BidsMinScore 8 s long Минимальное количество баллов для получения данных ставок Таблица 11. Сущность YandexDirectScoresDictionary № Имя поля Тип 1 ScoresDict(PK ) int Идентификатор записи 2 Service (FK) int Идентификатор сервиса API 3 4 5 Method Назначение varchar(2 Метод сервиса API 55) ScoresPerReq uest int Количество баллов, списываемое за вызов метода API ScoresPerObje ct int Количество баллов, списываемое за 1 объект 76

Таблица 12. Сущность YandexDirectServices № Имя поля Тип 1 ServiceId (PK) int Идентификатор сервиса API 2 ServiceName int Название сервиса API 3 ServiceURL Назначение varchar(2 URL-адрес для отправки 55) запросов сервису API 77

ПРИЛОЖЕНИЕ 3 ekday_of_we ypart_of_da hour minute p11 p13 p14 p21 p22 p23 p24 comp1 comp2 comp3 comp4 comp5 comp6 comp7 comp8 comp9 comp10 month 1,0 0 0,0 3 0,0 0 0,0 0 0,0 0 0.0 2 0,00 0,00 0,0 1 0,0 1 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 2 0,0 0 0,0 0 0,0 1 0,0 1 0,0 1 0,0 1 0,0 1 day_of_we ek 0,0 3 1,0 0,00 0,00 0,00 0 0,0 0 0,0 0 0,0 0 0,0 1 0,0 1 0,0 0 0,0 0 0,0 0 0,0 6 0,0 4 0,5 1 0,1 5 0,3 7 0,3 8 0,0 5 0,0 5 0,0 5 0,0 5 part_of_da 0,0 1,0 0,00 0 0 y p12 Признак month МАТРИЦА ПАРНЫХ КОЭФФИЦИЕНТОВ ПРИЗНАКОВ ВЫБОРКИ 0,9 9 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,6 4 0,4 6 0,4 0 0,5 5 0,5 4 0,1 9 0,7 2 0,7 0 0,7 0 0,7 0 hour 0,0 0 0,00 0,9 9 1,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,6 2 0,4 6 0,3 9 0,5 3 0,5 3 0,1 7 0,7 0 0,6 9 0,6 9 0,6 9 minute 0,0 0 0,00 0,0 0 0,0 0 1,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 p11 0.0 2 0,0 0 0,0 0 0,0 0 0,0 0 1,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 p12 0,00 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 1,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0

Признак month ekday_of_we ypart_of_da hour minute p11 p12 p13 p14 p21 p22 p23 p24 comp1 comp2 comp3 comp4 comp5 comp6 comp7 comp8 comp9 comp10 p13 0,00 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 1,0 0 0,0 0 0,0 0 0,0 0 0,0 1 0,0 1 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 p14 0,0 1 0,0 1 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 1,0 0 0,0 1 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 p21 0,0 1 0,0 1 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 1 1,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 1 0,0 1 0,0 1 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 p22 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 1,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 p23 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 1 0,0 0 0,0 0 0,0 0 1,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 p24 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 1 0,0 0 0,0 0 0,0 0 0,0 0 1,0 0 0,0 1 0,0 1 0,0 0 0,0 0 0,0 0 0,0 1 0,0 1 0,0 1 0,0 1 0,0 1 comp1 0,0 0 0,0 6 0,6 4 0,6 2 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 1 1,0 0 0,4 4 0,4 2 0,4 1 0,4 5 0,4 4 0,7 8 0,7 8 0,7 8 0,7 8 comp2 0,0 0 0,0 4 0,4 6 0,4 6 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 1 0,4 4 1,0 0 0,4 3 0,5 7 0,4 0 0,3 1 0,6 3 0,6 3 0,6 3 0,6 3 comp3 - - - - 0,0 0,0 0,0 0,0 0,0 - 0,0 0,0 0,0 - - 1,0 0,0 - 0,0 - - - - 79

ypart_of_da hour minute p11 p12 p13 p14 p21 p22 p23 p24 comp1 comp2 comp3 comp4 comp5 comp6 comp7 comp8 comp9 comp10 0,4 0 0,3 9 0 0 0 0 0 0,0 1 0 0 0 0,4 2 0,4 3 0 4 0,1 1 9 0,4 9 0,4 9 0,4 9 0,4 9 comp4 0,0 0 0,1 5 0,5 5 0,5 3 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 1 0,0 0 0,0 0 0,0 0 0,4 1 0,5 7 0,0 4 1,0 0 0,5 5 0,0 3 0,6 0 0,6 0 0,6 0 0,6 0 comp5 0,0 0 0,3 7 0,5 4 0,5 3 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 1 0,0 0 0,0 0 0,0 0 0,4 5 0,4 0 0,1 1 0,5 5 1,0 0 0,3 5 0,7 0 0,7 0 0,7 0 0,7 0 comp6 0,0 1 0,3 8 0,1 9 0,1 7 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 1 0,4 4 0,3 1 0,0 9 0,0 3 0,3 5 1,0 0 0,4 7 0,4 7 0,4 7 0,4 7 comp7 0,0 1 0,0 5 0,7 1 0,7 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 1 0,7 8 0,6 3 0,4 9 0,6 0 0,7 0 0,4 7 1,0 0 1,0 0 1,0 0 1,0 0 comp8 0,0 1 0,0 5 0,7 0 0,6 9 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 1 0,7 8 0,6 3 0,4 9 0,6 0 0,7 0 0,4 7 1,0 0 1,0 0 1,0 0 1,0 0 comp9 0,0 1 0,0 5 0,7 0 0,6 9 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 1 0,7 8 0,6 3 0,4 9 0,6 0 0,7 0 0,4 7 1,0 0 1,0 0 1,0 0 1,0 0 comp10 0,0 1 0,0 5 0,7 0 0,6 9 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 0 0,0 1 0,7 8 0,6 3 0,4 9 0,6 0 0,7 0 0,4 7 1,0 0 1,0 0 1,0 0 1,0 0 ekday_of_we 0,5 1 month 0,0 2 Признак 80

ПРИЛОЖЕНИЕ 4 ЛИСТИНГ КОДА ОБМЕНА ДАННЫМИ public bool IsTimeToUpdateBids() { bool isTime = false; using (Data.YandexDirectDbContext _context = Data.YandexDirectDbContext.YandexDirectDbContextCreate()) { YandexDirectUpdates usersUpdates = _context.YandexDirectUpdates.FirstOrDefault(uu => uu.YandexuserId == YandexuserId); YandexDirectScores usersScores = _context.YandexDirectScores.FirstOrDefault(us => us.YandexuserId == YandexuserId); if (usersScores == null) return false; usersScores.UpdateUsersScores(); if (usersUpdates.BidsUpdate == null) return false; TimeSpan timeSpan = DateTime.Now.Subtract((DateTime) (usersUpdates.BidsUpdate)); isTime = (Convert.ToInt32(Math.Floor(timeSpan.TotalMinutes))) >= usersScores.GetBidsPeriod(); } return isTime; } public class APIYandexDirectRequest { YandexDirectDbContext _context; YandexDirectError apiResultError; string resultString; string units; private object apiModel; private string token; private string url; public APIYandexDirectRequest(object _apiModel, string _token, string _url) { apiModel = _apiModel; token = _token; url = _url; } public void SendAPIRequest() { string requestJson = JsonConvert.SerializeObject(apiModel); HttpClient client = new HttpClient(); client.DefaultRequestHeaders.Clear(); client.DefaultRequestHeaders.Add("Authorization", "Bearer " + token); client.DefaultRequestHeaders.Add("Accept-Language", "ru"); var answer = client.PostAsync(url, new StringContent(requestJson, Encoding.UTF8, "application/json")); var resultJson = JsonConvert.DeserializeObject(answer.Result.Content.ReadAsStringA sync().Result);

resultString = JsonConvert.SerializeObject(resultJson); apiResultError = JsonConvert.DeserializeObject<YandexDirectError>(resultString); if (apiResultError.error == null) LogRequest("", resultString, "request"); else LogRequest("", resultString, "error"); KeyValuePair<string, IEnumerable<string>> unit = answer.Result.Headers.FirstOrDefault(h => h.Key == "Units"); if (unit.Value == null) return; List<long> units = new List<long>(); foreach (var u in unit.Value.First().Split('/')) { units.Add(Convert.ToInt64(u)); } UpdateUsersScores(units, apiModel); } private void UpdateUsersScores(List<long> units, object model) { using (_context = YandexDirectDbContext.YandexDirectDbContextCreate()) { Tokens yandexuser_token; using (VKDbContext vkContext = VKDbContext.VKDbContextCreate()) { yandexuser_token = vkContext.Tokens.FirstOrDefault(t => t.TokenToken == token && t.TokenYandexuser != null); } if (yandexuser_token != null) { YandexUsers user = _context.YandexUsers.First(u => u.YandexuserId == yandexuser_token.TokenYandexuser); YandexDirectScores userScores = _context.YandexDirectScores .FirstOrDefault(s => s.YandexuserId == user.YandexuserId); YandexDirectUpdates userUpdates = _context.YandexDirectUpdates .FirstOrDefault(u => u.YandexuserId == user.YandexuserId); if (userScores == null) { userScores = new YandexDirectScores { YandexuserId = user.YandexuserId }; userScores.UpdateUsersUnits(units); userScores.UpdateUsersScores(); userUpdates.CampaignsUpdate = DateTime.Parse(user.YandexuserTimestamp, null, System.Globalization.DateTimeStyles.RoundtripKin d); userUpdates.ClientUpdate = DateTime.Now; _context.YandexDirectScores.Add(userScores); 82

_context.SaveChanges(); } else { if (units[0] + units[1] > userScores.ClientCurLimit) userUpdates.ClientUpdate = DateTime.Now; userScores.UpdateUsersUnits(units); userScores.UpdateUsersScores(); _context.SaveChanges(); } SimpleLogRequest(units, model, user.YandexuserId); } } } } 83

Рецензии:

Авторизуйтесь, чтобы добавить рецензию

- у работы пока нет рецензий -

Отзывы:

Авторизуйтесь, чтобы оставить отзыв