МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ
ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное
учреждение
высшего образования
«ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
ИНСТИТУТ МАТЕМАТИКИ И КОМПЬЮТЕРНЫХ НАУК
Кафедра программного обеспечения
РЕКОМЕНДОВАНО К ЗАЩИТЕ В ГЭК
И ПРОВЕРЕНО НА ОБЪЕМ
ЗАИМСТВОВАНИЯ
Заведующий кафедрой
д.п.н., профессор
____________________И.Г. Захарова
______________________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
Отзывы:
Авторизуйтесь, чтобы оставить отзыв