Анализ транзакционных данных

  Министерство образования и науки Российской Федерации
Федеральное государственное автономное образовательное учреждение высшего образования 
«КАЗАНСКИЙ (ПРИВОЛЖСКИЙ) ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»
ИНСТИТУТ ВЫЧИСЛИТЕЛЬНОЙ МАТЕМАТИКИ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ

Направление: 09.03.02 – Информационные системы и технологии
Профиль: Информационные системы в образовании

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА
Анализ транзакционных данных

Студент 4-го курса
группы 09-412 
"____"____________ 20__ г.	Хуснетдинов Д.Р.
	

Научный руководитель 
к. ф.-м. н., доцент
"____"____________ 20__ г.	Гафаров Ф.М.
	
Заведующий кафедрой	
д. т. н., профессор
"____"____________ 20__ г.                            			   Сулейманов Д.Ш.
	
Казань – 2018
СОДЕРЖАНИЕ
ВВЕДЕНИЕ	3
1 МАРКЕТПЛЕЙС	5
2 АНАЛИЗ СО СТОРОНЫ КЛИЕНТОВ	10
2.1 Парсинг	12
2.2 Откидывание столбца событий	14
2.3 Фильтрация данных за период	15
2.4 Агрегация данных за период и избавление от аутлаеров	17
2.5 Агрегация по группам	21
2.6 Метрики и кластеризация	23
3 АНАЛИЗ СО СТОРОНЫ МЕРЧАНТОВ	40
3.1 Агрегация данных за период относительно мерчантов и избавление от аутлаеров	41
3.2 Метрики и кластеризация мерчантов	45
3.3 Пересечение клиентов и мерчантов	50
ЗАКЛЮЧЕНИЕ	56
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ	57
ПРИЛОЖЕНИЕ	58
Скрипт connect_setting.py:	58
Скрипт Main_Script.py:	59
Скрипт CSV_Export(Step№1).py:	62
Скрипт Starting_Table(Step№2).py:	64
Скрипт Starting_Table_For_The_Period(Step№3).py:	66
Скрипт Aggregation_Of_Count_And_Sum_Of_Trans_By_Clients(Step№4.1).py:	67
Скрипт Aggregation_Of_Count_And_Sum_Of_Trans_By_Correct_Clients(Step№4.2).py:	68
Скрипт Transaction_Table_Of_Correct_Clients(Step№4.3).py:	70
Скрипт Aggregation_Count_Of_Trans_On_Groups(Step№5).py:	72
Скрипт Create_Procedure_CountOfTransForMonthOnClients(Step№6.1).py:	73
Скрипт Create_Main_Metric_Table_For_Clients(Step№6.2).py:	75
Скрипт Aggregation_Of_Count_And_Sum_Of_Trans_By_Clients_On_Merchants(Step№7.1).py:	83
Скрипт Aggregation_Of_Count_And_Sum_Of_Trans_By_Correct_Clients_On_Merchants(Step№7.2).py:	84
Скрипт Transaction_Table_Of_Correct_Clients_On_Merchants(Step№7.3).py:	86
Скрипт Create_Procedure_CountOfTransForMonthOnMerchants(Step№8.1).py:	88
Скрипт Create_Metric_Tables_On_Merchants_Extended(Step№8.2).py:	90
Скрипт Create_Comparison_Tables(Step№9).py:	97


ВВЕДЕНИЕ

     Сейчас медлительным и неэффективным компаниям, не готовым к переменам, остаётся мало шансов на выживание. Компании должны эволюционировать, их важнейшими преимуществами, активами должны стать информация и знания.
     Извлечением информации из данных с последующим формированием в знание занимается аналитика. Под аналитикой подразумевается широкое использование данных, количественного и статистического анализа, описательных и прогнозных моделей для принятия решений и действий, на основе реальных признаков и фактов.
     Некоторые отрасли, больше других склонны к использованию аналитики. Если в бизнесе генерируется много данных о транзакциях – скажем, это финансовые услуги, перевозки, туризм или игорный бизнес – то конкуренция на основе аналитики является естественной и правильной стратегией. Хотя многие фирмы всё же пренебрегают аналитикой. Если в основе вашей бизнес-модели факторы трудноизмеримы – допустим, человеческие отношения, в том числе поиска необходимых кадров, или стиль, как в индустрии моды – для соперничества на основе аналитики необходимы намного более изобретательные приёмы.
      Сотни миллионов транзакций ежедневно проходят через банки, поэтому на серверах накапливаются большие данные: информация о клиентах, шаблоны покупок, правила в целом. Таким образом, банки превращаются в IT-ориентированные компании, как это произошло с телекоммуникационными операторами. Они предоставляют все больше услуг и цифровых сервисов, а собираемые ими данные и извлекаемая из них информация активно используются в создании новых предложений, и тех же услуг, и сервисов. 
     Применить эту информацию можно во множестве сфер и приложений, таких как: классические задачи оптимизации, обработка транзакций, распознавание мошенничества, кибербезопасность, создание персональных финансовых ассистентов. 
     Современные банки прекрасно понимают, чем живут их клиенты, и могут моделировать их поведение: будь это социальная группа в конкретном городе, отдельная промышленность или индустрия, или страна в целом. Это информация помогает финансовым учреждениям управлять своими рисками и рисками своих клиентов.
     С развитием Data Science(DS) в банках и IT-компаниях стало популярным концентрировать R&D отделы c DS. Концентрированная практика DS внутри компаний способствует более продуктивному созданию новых IT-продуктов, а также решений бизнес-задач, при этом не утрачивая и не отставая в технологиях по всему спектру и перечню связанных с DS задач.
     
     
     
     
     
     
     










1 МАРКЕТПЛЕЙС

     Есть кейс: Банк предоставляет данные о транзакциях своих клиентов – 1 244 890 записей 22 794 клиентов. Необходимо выполнить анализ предоставленных данных и получить некоторую полезную информацию, которая поспособствует развитию банка. Ожидаемые результаты: предиктивная модель, выделение наиболее значимых признаков, описание процесса анализа, любые другие инсайты.
     Зачем это нужно банку? Мотивация: Развитие банка как единого поля для продвижения товаров и услуг нефинансовых организаций является важной частью стратегии развития банка.
     Эта цель может достигаться разными способами, но банк предлагает следующую методику: Определение наиболее популярных мерчантов (торговец, коммерсант, бизнес-лицо. Часто это название связанно со службой, которая предоставляет возможность принимать платежи с использованием банковской карты) среди клиентов банка для развития сотрудничества с данными организациями с целью проведения совместных маркетинговых кампаний и разработка совместных продуктов для привлечения клиентской базы.
     Перед тем как решать данный кейс, необходимо ознакомиться с предоставленными данными. Данные представляют собой транзакции случайной выборки владельцев пластиковых карт банка за период с 2016.01–2017.06 гг.(файл расширения .csv). Среди транзакций выделены только успешные расходные операции, которые совершены в рамках рассматриваемых МСС групп(код категории продавца — представляет собой четырёхзначный номер, определяющий род деятельности торговой точки в операции оплаты с помощью банковских карт в торгово-сервисном предприятии). Записи в файле имеют следующие поля:
 event_id – идентификатор транзакции, тип данных long_integer
 cli_id – идентификатор клиента, тип данных long_integer
 trans_date – дата/время транзакции, тип данных datetime
 trans_amount_rub – сумма операции в рублях, тип данных decimal(38,2)
 document_channel – канал совершения операции, тип данных integer
 document_channel_group – группа канала документа, например: банкомат, покупки в интернете, касса и т.д. Тип данных integer
 our_device – терминал приема оплаты, предоставленный банком, тип данных boolean
 merchant_id – идентификатор мерчанта, тип данных long_integer
 code – MCC/SIC код мерчанта. Определяет основной вид деятельности торговой точки, тип данных integer
 group – категория мерчанта. Группировка MCC/SIC кодов по схожим тематикам, например: рестораны, медицина, еда и т.д. Тип данных string.
     Для анализа нам понадобятся следующие инструменты:
 Microsoft SQL Server – для хранения данных в виде наборов DataSet в таблицах. Для манипуляции данными при помощи SQL-запросов и скриптов, созданных и вызывающихся динамически из программы
 Python 3.6 и PyCharm IDE – для автоматизированного создания аналитической модели на любой машине с помощью написанных скриптов на языке Python, включая: парсинг файла, формирование и вызова SQL-скриптов, создание наборов данных, вычисление новых метрик, применение алгоритмов машинного обучения
 Git – распределённая система контроля версий. Для быстрого разделения и слияния версий, включая инструменты навигации по нелинейной истории разработки
 GitHub – хостинг проекта для совместной разработки. Любой желающий может скачать проект, присоединится к нему, или предложить свои улучшения по проекту, если вы дадите на то согласие. Проект размещён по следующему url: https://github.com/KhusDM/BankDataAnalysisRelease
 GitKraken – кроссплатформенный графический Git-клиент для визуализации веток с удобным интерфейсом. Отображает историю разработки.
     Наши данные содержат истории двух сущностей – клиентов и мерчантов. Поэтому анализ будет проводится как со стороны клиента, так и со стороны мерчанта. В ходе анализа мы выясним детально как связаны эти две сущности между собой, каково их взаимодействие, по каким правилам проводятся операции, обнаружим неявные закономерности. С учётом поставленных целей выработан предполагаемый порядок работы анализа:
 Парсинг данных из файла формата .csv и их перенос в SQL Server
 Знакомство с данными, валидация данных, описательная статистика транзакций во временной динамике
  Поиск пропущенных/нелогичных значений 
 Отбор признаков для построения моделей
 Избавление от аутлаеров относительно клиентов(выбросов, ложных точек) 
 Группировка транзакций по продуктовым группам относительно клиентов, описательная статистика по клиентам во временной динамике  
 Генерирование статистических метрик на основе признаков, рассмотренных во временной динамике(мат.ожидание, дисперсия, среднеквадратичное отклонение, коэффициент вариации и т.д.) 
 Кластеризация клиентов на основе метрик
 Избавление от аутлаеров относительно мерчантов(выбросов, ложных точек) 
 Группировка транзакций по продуктовым группам относительно мерчантов, описательная статистика по мерчантам во временной динамике 
 Генерирование статистических метрик на основе признаков, рассмотренных во временной динамике(мат.ожидание, дисперсия, среднеквадратичное отклонение, коэффициент вариации и т.д.) 
 Кластеризация мерчантов на основе метрик
 Пересечение мерчантов и клиентов, создание таблиц сопоставлений мерчантов с клиентами.
     В результате у нас получатся таблицы сопоставлений мерчантов и клиентов по определенным продуктовым группам, с помощью которых банк может делать предложения по взаимодействию мерчантов со своими клиентами в зависимости от принадлежности к определённому кластеру как мерчантов, так и клиентов. По выполнению проделанных работ, каталог таблиц в SQL Server должен иметь следующий вид, изображённый на рисунке 1.1:
      
     
     Выбранный порядок действий не является единственно верным. Всё зависит от поставленных целей и решаемых задач, от специалистов и их методик по анализу. В любом случае процесс стоит сделать постепенным и итеративным. 
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
2 АНАЛИЗ СО СТОРОНЫ КЛИЕНТОВ

     Прежде чем приступить непосредственно к анализу, необходимо сказать пару слов про строение проекта. Проект представляет собой набор скриптов на языке Python, которые вызываются друг за другом по очереди, запустив главный скрипт с названием Main_Script.py. В Main_Script.py определён порядок вызова скриптов, выполняющихся через подпроцессы. Таким образом проект имеет итеративный характер, каждый запускаемый скрипт – это определённый шаг на пути к построению модели. В каждом скрипте происходит обращение к SQL Server’y с помощью библиотеки pypyodbc, которая является адаптером, определяющая интерфейс DB API 2.0 – интерфейс прикладной программы с базой данных. Этот интерфейс, должен реализовывать все модули расширения, которые предназначаются для связи программ на языке Python с базами данных. Единый API позволяет абстрагироваться от марки используемой СУБД, при необходимости будет довольно просто поменять одну СУБД на другую, изучив всего один набор методов и функций.
     Для корректного обращения программы к СУБД нужно задать настройки соединения. Для этого есть connect_setting.py, являющийся по сути конфигурационным файлом, в котором задаются такие настройки соединения как DRIVER(драйвер, т.е. СУБД), SERVER(сервер, принадлежащий пользователю СУБД), DATABASE(БД, в которой выполняются все операции). Затем из этих настроек формируется строка соединения с нашей СУБД. Помимо этого, в конфигурационном файле присутствует имя файла с данными, который необходимо парсить. Также определены некоторые константы, которые будут использоваться в скриптах, о них будет упоминаться непосредственно при разборе шагов построения.
     Общий каталог проекта выглядит следующим образом на рисунке 2.1:
 Папка scripts содержит скрипты и папку connection_setting, в которой содержится конфигурационный файл connect_setting.py 
 Папка venv c некоторыми файлами создаётся по умолчанию. В последующем в эту папку будут добавляться некоторые файлы внешних библиотек, скаченных с помощью менеджера пакетов pip
 Файл с набором данных Dataset_for_KFU.06_07_2017.csv
 В External Libraries содержатся файлы внешних библиотек. 
   
      



2.1 Парсинг

     Первый шаг любого анализа данных это выгрузка данных. В рамках кейса, нам предоставлен файл с данными в формате .csv. На рисунке 2.1.1 можно увидеть содержимое файла и его структуру:


     Как видите, данные сложно интерпретировать в таком формате, не говоря о проведение над ними операций. Поэтому нужно произвести парсинг файла и перенести полученные данные в таблицу SQL Server’a. Парсинг файла производится в скрипте CSV_Export(Step№1).py. В нём подключается ссылка на модуль pypyodbc, чтобы программа могла взаимодействовать с СУБД. Стоит сказать, что практически во всех скриптах производится подключение этого модуля, поэтому в дальнейшем будем опускать повествование об этом.
     Также в скрипте подключается модуль pandas, который создан для обработки и анализа данных. pandas предоставляет специальные структуры данных в виде dataframe(датафрейм представлены в  виде виртуальных таблиц, хранящихся в оперативной памяти во время runtime момента) и операции для управления таблицами и временными рядами.
     После того как все необходимые модули подключены, дальше в скрипте происходит считывание данных, парсинг, небольшая обработка для дальнейшей вставки в таблицу в SQL Server’а. Также происходит подключение к самой СУБД, формирование динамического SQL-скрипта для создания таблицы с последующей вставкой данных, выполнение SQL-скрипта. В результате появилась таблица dbo.CSV_Export. Код скрипта и реализация в целом всего проекта находится в разделе «Приложение».
     Результат выполнение изображён на рисунке 2.1.2, таблица dbo.CSV_Export:




2.2 Откидывание столбца событий

     Изучив таблицу с импортированными данными, автор пришёл к выводу, что данные столбца event_id не будут участвовать в проводящемся анализе(решается конкретная задача, поэтому данное решение не является единственно верным. Всё зависит от целей, задач и методик), поэтому, за счёт ненадобности, стоит откинуть этот столбец. Данное действие выполняется в скрипте Starting_Table(Step№2).py. В скрипте происходит формирование SQL-скрипта на создание новой таблицы dbo.Starting_Table на основе таблицы dbo.CSV_Export, только при этом опускается столбец event_id. Результат операции изображён на рисунке 2.2.1, таблица dbo.Starting_Table:






2.3 Фильтрация данных за период

     Следующим шагом будет отбор данных за определённый временной период, и в дальнейшем последующие шаги анализа будут проводиться в рамках этого периода. Нужные границы временного интервала задаются в конфигурационном файле connect_setting.py, заполнением полей DATA_BEGIN(начало) и DATA_END(конец). Значение этих полей будут участвовать в построение запроса SQL.  Значение задаётся в формате yyyy-mm-dd(год-месяц-день). Фильтрация данных происходит в скрипте с названием Starting_Table_For_The_Period(Step№3).py. В нём формируется динамический SQL-запрос, при выполнения которого у нас останутся данные за определённый временной интервал. В данном случае был выбран период за 2016.01.01-2017.05.31. Стоит сказать, что количество дней не будет играть роли, поскольку анализ во временной динамике будет проводиться по месяцам. Поэтому рекомендуется выбирать временные интервалы с учётом полных месяцев. Предоставленные нам данные содержат транзакции с 2016.01.01 по 2017.06.10. Как видите, получается, что за последний месяц неполные данные, если включать эти данные за неполный месяц как за равноценный полный месяц, то наш анализ ухудшится. Поэтому откидываются транзакции за этот неполный месяц, указав правую границу временного интервала – последний полный месяц. Таким образом анализ будет более чистым. Результаты данного шага изображены на рисунке 2.3.1, таблица dbo.Starting_Table_For_The_Period:

 
















2.4 Агрегация данных за период и избавление от аутлаеров

     Теперь можно произвести агрегацию количества транзакций и суммы этих транзакций за весь рассматриваемый период, сгруппировав результаты по клиентам. Этот шаг необходим, чтобы выделить клиентов, на которых у нас есть информация. Дело в том, что в данных присутствуют записи о клиентах, которые совершили одну-две транзакции за весь период. По сути получается, что на этих клиентов недостаточно данных, следовательно, мы не можем моделировать, предсказывать их поведение и включать их в анализ, основываясь на неполных данных. Такие записи будут считаться как аутлаеры(выбросы, ложные точки). Во время анализа, важной частью является избавление от аутлаеров, поскольку они искажают результирующую модель. Показателем того, есть ли у нас информация по клиенту или нет, является количество транзакций. Чем больше клиент совершил транзакций, тем больше есть информации на него, следовательно, его можно включить в анализ.
     Первоначальная агрегация выполняется в скрипте Aggregation_Of_Count_And_Sum_Of_Trans_By_Clients(Step№4.1).py. Результат шага изображён на рисунке 2.4.1, таблица dbo.Aggregation_Of_Count_And_Sum_Of_Trans_By_Clients:
      

     В агрегированной таблице содержатся аутлаеры – записи с минимальным количеством транзакций. На данном этапе необходимо понять: какая должна быть нижняя граница у количества транзакций? Сколько минимально должно быть количество транзакций, чтоб клиент не считался аутлаером? Один из вариантов можно посчитать, что если клиент выполняет в среднем хотя бы одну транзакцию в неделю на протяжение всего периода, то можно считать, что на него есть данные. Временная динамика рассматривается по месяцам, следовательно, за месяц должно быть в среднем четыре транзакции. Таким образом, нижняя граница будет равна 4 транзакции * количество месяцев в периоде. Все клиенты, у которых количество транзакций не удовлетворяют нижней границе, считаются аутлаерами. Это лишь один из примеров как может формироваться нижняя граница. Нижнюю границу можно рассчитывать по-разному.
     Избавление от аутлаеров происходит в скрипте Aggregation_Of_Count_And_Sum_Of_Trans_By_Correct_Clients(Step№4.2). Результат изображён на рисунке 2.4.2, таблица dbo.Aggregation_Of_Count_And_Sum_Of_Trans_By_Correct_Clients:
      

     После этого в агрегирующей таблице остались только корректные клиенты. Теперь надо учесть этот момент в общей таблице транзакций dbo.Starting_Table_For_The_Period, найдя пересечение по клиентам. Таким образом, в общей таблице будут содержаться транзакции только корректных клиентов. Пересечение выполняется в скрипте Transaction_Table_Of_Correct_Clients(Step№4.3).py. Результат пересечения изображён на рисунке 2.4.3, таблица dbo.Transaction_Table_Of_Correct_Clients:
















2.5 Агрегация по группам

     Анализ клиентов в частности проводится в разрезе определённых продуктовых групп. В каких именно группах проводить анализ указывается в конфигурационном файле connect_setting.py, перечислив значения в поле GROUPS. И тут возникает вопрос: какие именно группы необходимо указать, относительно каких групп должен происходить анализ? Чтобы определить наиболее значимые группы, которые востребованы у клиентов, необходимо агрегировать количество и суммы транзакций сгруппировав их по продуктовым группам. Агрегация по продуктовым группам выполняется в Aggregation_Count_Of_Trans_On_Groups(Step№5).py. Результат выполнения скрипта изображён на рисунке 2.5.1, таблица dbo.Aggregation_Count_Of_Trans_On_Groups:
      

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














2.6 Метрики и кластеризация

     Поскольку анализ проводится во временной динамике, где за единицу времени взят месяц, необходимо пронаблюдать как клиент совершает операции из месяца в месяц на протяжение всего наблюдаемого периода. Показателем за месяц всё также будет выступать количество транзакций, агрегированные по клиентам. Таким образом нашей целью становится создания таблицы, где каждый столбец будет содержать количество транзакций клиента за определённый месяц. Для создания такой таблицы удобно было бы иметь функцию, которая агрегировала транзакции. Поэтому создадим такую функцию. Создание функции происходит в скрипте Create_Procedure_CountOfTransForMonthOnClients(Step№6.1).py. В этом скрипте формируется SQL-запрос на создание хранимой процедуры, которая будет использоваться для агрегирования.
     Следует сказать, что данный параграф будет объёмным по количеству проделанных операций. На данном этапе мы получим не только таблицы с прослеживанием количества операций по клиентам во временной динамике в продуктовых группах, но и ещё целый ряд таблиц, которые будут содержать в себе сгенерированные статистические метрики, а также принадлежность к кластеру, на основе предыдущих таблиц. Также получим таблицу, которая содержит данные по продуктовым группам в разрезе относительно данных по всем продуктовым группам. Все эти шаги будут подробно рассмотрены в дальнейшем. Данный этап выполняется в скрипте с названием Create_Main_Metric_Table_For_Clients(Step№6.2).py.
     После создание хранимой процедуры, можно приступить к созданию таблиц временной динамики. Создание таких таблиц являются частью алгоритма прописанного в скрипте Create_Main_Metric_Table_For_Clients(Step№6.2).py. Такие таблицы создаются не только относительно продуктовых групп в отдельности, но и относительно всех продуктовых групп, а имена таблиц будут иметь следующий формат: Count_Of_Trans{0}_For_Months_Table, где {0} – наименование продуктовой группы, если она есть.
     Приведём часть результирующих таблиц данного шага. Количество появившихся таблиц равняется количеству продуктовых групп, указанных в поле GROUPS конфигурационного файла, и плюс таблица, включающая данные относительно всех продуктовых групп. Результаты изображены на рисунках 2.6.1 и 2.6.2, таблицы dbo.Count_Of_Trans_For_Months_Table(по всем продуктовым группам) и dbo.Count_Of_Trans_Food_For_Months_Table(по группе Food в отдельности) соответственно:





     В данном случае, поскольку анализ проводится в двух продуктовых группах: Food и Medical, то создались три таблицы:
 dbo.Count_Of_Trans_For_Months_Table(по всем продуктовым группам)
 dbo.Count_Of_Trans_Food_For_Months_Table(по группе Food)
 dbo.Count_Of_Trans_Medical_For_Months_Table(по группе Medical)
     Как видно по рисункам 2.6.1 и 2.6.2, помимо столбцов количества транзакций за месяцы присутствуют агрегированные столбцы количества транзакций за весь период и их общая сумма. В данном случае, с учётом выбранного временного интервала, столбцы отображают временную динамику на протяжении 17 месяцев.
     Теперь, когда есть таблицы содержащие данные о динамике изменений, следующим шагом на основе этих показателей будет создание таблиц с сгенерированными метриками-вариациями, такими как: математическое ожидание, дисперсия, среднеквадратичное отклонение, коэффициент вариации, а также принадлежность к кластеру после процесса кластеризации. Данные таблицы будут иметь название следующего формата: Metric_Table{0}_Extended, где {0} – наименование продуктовой группы, если она есть.
     Стоит уделить внимание метрикам и немного окунуться в курс математической статистики и теории вероятности. Теория вероятности изучает случайные величины. Для этого строятся различные характеристики, которые описывают их поведение. Математическое ожидание является одной из основных характеристик случайной величины являющееся своего рода центром, вокруг которого группируются остальные значения.
     Формула мат.ожидания имеет следующий вид:
     M(X)=???x_i p_i ?
     где M(X) – математическое ожидание, x_i – это случайные величины, p_i – их вероятности.	
     То есть, математическое ожидание случайной величины — это взвешенная сумма значений случайной величины, где веса равны соответствующим вероятностям. Математическая статистика предоставляет несколько вариантов оценки математического ожидания. Основное среди них – среднее арифметическое, обладающие рядом полезных свойств. Например, среднее арифметическое – это несмещенная оценка, т.е. мат.ожидание средней равно оцениваемому математическому ожиданию. Для нашего случая мат.ожидание будет являться средней арифметической количества транзакций за рассматриваемый период.
     Следующей рассматриваемой метрикой является дисперсия случайной величины. Это очень значимый показатель, который используется в различных методах математической статистики (анализ причинно-следственных связей, проверка гипотез и др.). Дисперсия отражает меру разброса данных вокруг средней величины.
     Как и мат.ожидание, дисперсия является важной характеристикой случайной величины. Если мат.ожидание отражает центр случайной величины, то дисперсия дает характеристику разброса данных вокруг этого центра.
     В теории вероятности формула дисперсии имеет следующий вид:
     D(X)=?^2=M[X-M(X)]^2
     То есть дисперсия – это математическое ожидание отклонений от математического ожидания.
     При анализе выборок на практике математическое ожидание, как правило, не известно. Поэтому вместо него используют оценку – среднее арифметическое.
     S^2=(?_(i=1)^n??(X-X ?)?^2 )/n
     где S^2 - выборочная дисперсия, рассчитанная по данным наблюдениям, X – отдельное рассматриваемое значение, X ?- среднее арифметическое по выборке.
     Стоит отметить, что у такого способа расчета дисперсии есть недостаток – она получается смещенной, т.е. ее мат.ожидание не равно истинному значению дисперсии. Но ситуация исправляется при увеличении объема выборки, она все-таки приближается к своему теоретическому аналогу, т.е. является асимптотически не смещенной. Поэтому при работе с большими размерами выборок как у нас можно использовать формулу выше.
     Получается, что дисперсия - это средний квадрат отклонений. То есть вначале рассчитывается среднее значение, затем берется разница между каждым рассматриваемым исходным и средним значением, разница возводится в квадрат, суммируется и затем делится на количество наблюдений в данной совокупности. Разница между отдельным рассматриваемым значением и средней отражает меру отклонения. В квадрат возводится только для того, чтобы все отклонения стали исключительно положительными числами, и чтобы избежать их взаимоуничтожения при суммировании отрицательных и положительных отклонений. Затем, имея сумму квадратов отклонений, просто рассчитываем среднюю арифметическую.
     Однако в чистом виде, как, например, средняя арифметическая, дисперсия не используется. Это скорее вспомогательный и промежуточный показатель, который необходим для других видов метрик статистического анализа.
     Следующая метрика – среднеквадратичное отклонение.  Дабы использовать дисперсию в более приземленных целей, из нее извлекают квадратный корень. Получается так называемое среднеквадратичное(стандартное) отклонение.
     Формула стандартного отклонения имеет следующий вид:
     ?=?(M?[X-M(X)]?^2 )
     Для получения показателя по выборке используется формула:
     S=?((?_(i=1)^n??(X-X ?)?^2 )/n)
     
     Стандартное отклонение, также характеризует меру рассеяния данных, но теперь (в отличие от дисперсии) его можно сравнивать с исходными данными, так как единицы измерения у них одинаковые. Но и этот показатель в чистом виде не очень информативен, так как в нем заложено слишком много промежуточных расчетов, которые сбивают с толку. Тем не менее, со стандартным отклонением уже можно работать непосредственно, потому что свойства данного показателя хорошо изучены и известны. К примеру, есть такое правило трех сигм, которое гласит, что у нормально распределенных данных 997 значений из 1000 находятся в пределах ±3 сигмы от средней арифметической. Стандартное отклонение, как мера неопределенности, также участвует во многих статистических расчетах. С ее помощью устанавливают степень точности различных оценок и прогнозов. Если вариация очень большая, то стандартное отклонение тоже получится большим, следовательно, и прогноз будет неточным, что выразится, к примеру, в очень широких доверительных интервалах.
     И напоследок остаётся коэффициент вариации. Стандартное отклонение дает абсолютную оценку меры разброса. Поэтому чтобы понять, насколько разброс велик относительно самих значений (т.е. независимо от их масштаба), требуется относительный показатель. И этим показателем называется коэффициент вариации.
     Коэффициент вариации рассчитывается по следующей формуле:
     V=S/X ?  
     где V – коэффициент вариации, S – стандартное отклонение, X ? – среднее арифметическое по выборке.
     Коэффициент вариации измеряется в процентах (если умножить на 100%). По этому показателю сравнивается однородность самых разных явлений независимо от их масштаба и единиц измерения. Это и делает коэффициент вариации столь популярным.
     В статистике принято, что, если значение коэффициента вариации менее 33%, то совокупность считается однородной, если больше 33%, то – неоднородной. Это считается аксиомой.
     Зачем нам нужно рассчитывать эти метрики? Посчитав эти вариации, особенно коэффициент вариации, мы сможем определять стабильность поведения клиентов. Посчитав коэффициент вариации по выборке количества транзакций во временной динамике, можно сказать стабильно ли клиент совершает транзакции или нет, или другими словами насколько он стабилен? Ведь в зависимости от этого фактора банк или мерчант могут предложить клиенту участие в какой-то маркетинговой кампании, карту с бонусами и т.д.. В таком случае у нас получается два вида клиентов: относительно стабильный и относительно нестабильный. Почему относительно? Потому что большинство клиентов будут иметь коэффициент вариации больше 33%, то есть основная масса является нестабильной. В такой ситуации можно смягчить нижнюю границу, повысив её, если это устраивает банк. Насколько повысить границу решает также банк.
     После генерирование метрик, можно провести кластеризацию клиентов на основе метрик. Для начала, что такое кластеризация и зачем она нужна в нашем анализе?
     Кластеризация (или кластерный анализ) — это задача разбиения множества объектов на группы, называемые кластерами. Внутри каждой группы должны оказаться «похожие» объекты, а объекты разных группы должны быть как можно более отличны.
     Применение кластерного анализа в общем виде сводится к следующим этапам:
 Отбор выборки объектов для кластеризации.
 Определение множества признаков, по которым будут оцениваться объекты в выборке. При необходимости можно нормализовать значения признаков.
 Вычисление значений меры сходства между объектами.
 Применение метода кластерного анализа для создания групп сходных объектов (кластеров).
 Представление результатов анализа.
     После получения результатов анализа возможна корректировка выбранной метрики и метода кластеризации до получения оптимального результата.
     Как же определяется схожесть объектов? Для начала необходимо составить вектор характеристик(признаков) для каждого объекта — как правило, это набор числовых значений, например, рост-вес человека. Однако существуют также алгоритмы, работающие с качественными характеристиками.
     После того, как мы определили вектор характеристик, при необходимости можно провести нормализацию, чтобы все компоненты давали одинаковый вклад при расчете расстояния. В процессе нормализации все значения сводятся к некоторому диапазону, например, [-1, 1] или [0, 1].
     Наконец, для каждой пары объектов измеряется расстояние между ними — степень похожести. Существует несколько способов высчитывания расстояния между парой объектов. Но приведём только один из них:
     Евклидово расстояние - наиболее распространенная функция расстояния. Представляет собой геометрическое расстояние в многомерном пространстве:
     ?(x,x^' )=?(?_i^n??(x_i-x_i^')?^2 )
     где x_i и x_i^' – это координаты пар объектов по определенной оси.
     Геометрическая интерпретация алгоритма изображена на рисунке 2.6.3:


     Алгоритмы кластеризации имеют многообразную классификацию. Но не будем углубляться в данную тему. Скажем только, что для нашего анализа был выбран алгоритм k-Means(k - Средних). Расскажем о нём подробнее.
     Алгоритм k-Means кластеризует данные, пытаясь разделить выборку на n групп равной дисперсии, минимизируя критерий, известный как инерция или внутрикластерная сумма квадратов. Этот алгоритм требует указания количества кластеров. Алгоритм хорошо масштабируется на большом количестве наблюдений и был использован в широком диапазоне областей применения в различных сферах.
     Алгоритм k-Means делит множество выборки X на K непересекающихся кластеров, каждый из которых описывается средним значением µ_i  выборки в i-ом кластере. Значение µ_i  обычно называют центроидом кластера; стоит обратить внимание, что они, как правило, не являются точками из выборки X, хотя они живут в одном и том же пространстве. Алгоритм k-Means предназначен для выбора центроидов, минимизирующих инерцию, или критерий внутрикластерной суммы квадратов: 
     
     Инерцию, или критерий суммы квадратов внутри кластера, можно распознать как меру того, насколько внутренне кластеры когерентны(непротиворечивы). Алгоритм может страдать от различных недостатков:
     Инерция делает предположение, что кластеры выпуклые и изотропные, что не всегда так. Плохо реагирует на удлиненные скопления или многообразия неправильной формы.
     Инерция не является нормализованной метрикой: мы просто знаем, что более низкие значения лучше, а .......................