Acquire Valued Shoppers Challenge

Змагання на kaggle.com класні тим, що незалежно від вашої поточної робочої області можна працювати над реальними заваданнями будь-якої предметної області. Також з плюсів - великі датасети.
Тут опишу досвід роботи з  Acquire Valued Shoppers Challenge.
Завдання: на основі історії покупок, визначити ймовірність, що покупець, який отримав купон на знижку, купить товар повторно.



Структура вхідних даних:
Таблиці:

• transactions.csv - історія транзакцій всіх клієнтів (300 тисяч) мінімум за рік до того, як їм запропонували купон на знижку(отримана пропозиція - останній запис, середній клієнт має 1000 транзакцій) - 350 мільйонів записів.
• offers.csv - інформація про купони на знижку(offers) - 37 записів.
• trainHistory.csv - інформація, який купон(offer) запропоновано клієнту, та його реакцію (повернувся чи ні, якщо так - кількість раз) - 160 тисяч записів.
• testHistory.csv - інформація, який купон(offer) запропоновано клієнту - 150 тисяч записів.

Опис таблиць:
history:
id - ідентифікатор покупця
chain - код магазину
offer - ідентифікатор купона
market - ідентифікатор георафічного регіону
repeattrips - кількість повторних покупок після отримання пропозиції купона
repeater - повернувся чи ні після отирмання пропозиції купона
offerdate - дата отирмання пропозиції
transactions:
id - дивись вище
chain - дивись вище
dept - узагальнена група категорії(category), наприклад "вода".
category - категорія (напр. "газована вода")
company - ідентифікатор компанії, яка продала товар
brand - ідентифікатор бренду товару
date - дата покупки
productsize - кількість купленого товару (напр. 3 пляшки води)
productmeasure - одиниці вимірювання товару (кг, л)
purchasequantity - кількість куплених одиниць
purchaseamount - сума покупки (може бути і від'ємною, якщо покупець повернув товар пізніше)
offers: 
offer - дивись вище
category -дивись вище
quantity - кількість товару, яку необхідно придбати, щоб отримати знажку
company - дивись вище
offervalue - сума прпозиції
brand - дивись вище

Перша проблема, яку необхідно вирішити: transactions.csv розміром 20 Гб і має 350 млн. записів. Вирішується доволі просто - завантаженням у базу даних. Була вибрана Vertica.
Крім того, ще налаштувала зв'язок між R і базою через JDBC, що дозволило працювати з даними не лише вокристовуючи можливості SQL, але й R (про процес налаштування можна прочитати тут).

Бенчмарки:

1. Для всіх користувачів вказати ймовірність повторного повернення 0 або 1 - точність 0.5 (що означає, що кількість тих що повернулись та тих, що не повернулись у тестсеті однакова)
2. Для користувача, який придбав товар  бренду, вказаного в пропозиції принаймі один раз ймовірність повернення 1, для решти - 0. Точність 0.52517
3. ля користувача, який придбав товар  бренду, компанії та категорії вказаних у пропозиції принаймі один раз ймовірність повернення 1, для решти - 0. Точність - 0.55294

Робоча гіпотеза:
Повернувся користувач чи ні - це міра його лояльності. Виглядає логічним виразити цю лояльність як залежність від кількості всіх покупок цього користувача та покупок конкретного товару. В якості характеристики товару можна обрати три поля: company, brand, category. Також мірою лояльності може бути і розмір повернень всіх товарів/конкретного товару за певний період.
Також логічно було б використовувати властивості конкретних пропозицій, але враховуючи, що пропозицій 37, а користувачів 300 000 (тобто варіативність пропозицій надзвичайно мала і дасть нам додаткової інформації).
Отже, для кожного користувача формуємо нові фічі:

• кількість покупок/повернень всього/за останні 30/за останні 60/за останні 90/за останні 180 днів
• кількість покупок/повернень бренду, вказаному в пропозиції всього/за останні 30/за останні 60/за останні 90/за останні 180 днів
• кількість покупок/повернень категорії, вказаній у пропозиції всього/за останні 30/за останні 60/за останні 90/за останні 180 днів
• кількість покупок/повернень компанії, вказаній пропозиції
• кількість покупок/повернень цих категорії, компанії та бренду всього/за останні 30/за останні 60/за останні 90/за останні 180 днів
• кількість покупок/повернень цих категорії та бренду всього/за останні 30/за останні 60/за останні 90/за останні 180 днів
• кількість покупок/повернень цих компанії та бренду всього/за останні 30/за останні 60/за останні 90/за останні 180 днів
• кількість покупок/повернень цих компанії та категорії всього/за останні 30/за останні 60/за останні 90/за останні 180 днів

Технічно це робиться записом результату SQL запиту в .csv файл з допомогою R.

В зв'язку з тим, що ми маємо в таблиці trainHistory два поля: repeater - бінарне і repeattrips - числове можемо це виразити як задачу класифікації, так і регресії.

Оскільки дані з кількістю покупок (всього і за певні періоди) мають дуже високу варіативність (тобто шуму) і 70% значень  для поля repeater має значення 0 (на практиці, це означає що алгоритми ML тяжіють до передбчення значення repeater = 0 в більшості випадків ) - досягти навіть точності 3-го бенчмарку не вдалося.
Більш вдалою виявилась Гіпотеза 2:

Для зменшення шуму дані, які мають високу варіативність (і, відповідно, вносять занадто багато шуму) у було перетворено у вектор (1, 2, 3, 4), який реперезентує відповідну квартиль. (положення в квартилі визначаєтьтся після об'єднання тестового і тренінг датасетів). Дані, які, навапаки мають малу варіативність і не можуть бути розбиті на квартилі - перетворюємо у вектор (0, 1), де 1- значення, які більші 0. Точність на цьому етапі 0.58918 (алгоритм - логістична регресія). 

Подібний підхід описаний на форумі тут: http://www.kaggle.com/c/acquire-valued-shoppers-challenge/forums/t/7688/feature-engineering-and-beat-the-benchmark-0-59347. Найкращий результат такого feature engineering 0.59347 (результат переможця - 0.6314).

За 2 тижні до закінчення змагання у з'явилася Гіпотеза 3, яка буда найбільш багатообіцяючою, але я  не встигла з обчисленнями для її перевірки. Це використання підходів, які широко використовуються при побудові персоналізованих рекомендаційних систем. Алгоритм наступний:

1. для кожного користувача знайти N подібних за поведінкою користувачів (в нащому випадку подібність - кількість покупок бренду або категорії + компанії + бренду)
2. визначити, який відсоток з цих подібних за купівельною поведінкою користувачів раніше купував бренд, вказаний у пропозиції та бренд+категорія+ компанія, вказані у пропозиції
3. В якості фіч використовувати:

• придбав товар цього бренду, компанії та категорії принаймі один раз
• придбав товар цього бренду принаймі один раз
• відсоток  від N подібних користувачів, які придбали бренд, вказаний в пропозиції,  хоча б один раз
• відсоток  від N подібних користувачів, які придбали товар бренду, категорії та компанії, вказаних в пропозиції, хоча б один раз.

Спочатку крок 1 було імплементовано на R, для оптимізації обчислень було використано паралелізацію між ядрами. Оцінка часу прорахунку подібностей між користувачами в цьому випадку (на 4 ядрах Core i5, 2.6 Ггц) - 15-20 днів, що було занадто багато. Тому алгоритм обрахунку подібності між користувачами було переписано на Pig Latin.
Опис цього процесу, а також як запустити цей обрахунок на Amazon Web Services використовуючи Elastic Map Reduce читайте у продовженні.