Резюме на Проекта:
Имате онлайн приложение за стрийминг на видео или музика и виждате спад в броя на потребителите си или броят на абонатите намалява. Или още по-лошо, губите своите платени абонати.
Използвайки науката за данните, можем да знаем точно защо ги губим.
Когато потребител напусне или направи понижаване, потребителят показва някои знаци или модел за това как или защо е предприел тази стъпка. Посещението на помощни страници от потребителите или получаването на чести съобщения за грешка обикновено показва признаци за бъдещи опити на потребителите да преминат към по-ниска версия.
Изявление на проблема:
В тази публикация правим опит с данните от популярния доставчик на музикални услуги „Sparkify“ и идентифицираме възможните причини за оттеглянето на потребителите и подготвяме модел на машинно обучение, за да предвидим бъдещи възможности.
Използваме подмножество от данни, което е около 120 MB.
Метрика:
Предсказуемите модели рядко предвиждат всичко перфектно, така че има много показатели за ефективност, които могат да се използват за анализ на нашите модели.
В нашия случай ще се опитаме да получим резултат F1 за всеки модел на прогнозиране, защото не само се интересуваме от прецизността, но също така се нуждаем от измерване на припомнянето.
Формулата за F1 резултат е следната:
Анализ - Изследване на данни:
Схемата за тези данни е:
|-- artist: string (nullable = true) |-- auth: string (nullable = true) |-- firstName: string (nullable = true) |-- gender: string (nullable = true) |-- itemInSession: long (nullable = true) |-- lastName: string (nullable = true) |-- length: double (nullable = true) |-- level: string (nullable = true) |-- location: string (nullable = true) |-- method: string (nullable = true) |-- page: string (nullable = true) |-- registration: long (nullable = true) |-- sessionId: long (nullable = true) |-- song: string (nullable = true) |-- status: long (nullable = true) |-- ts: long (nullable = true) |-- userAgent: string (nullable = true) |-- userId: string (nullable = true)
Колоната „страница“ се състои от регистър на събития като Отмяна, Изпращане на понижаване, палец нагоре, палец надолу, влизане, излизане, регистрация, добавяне на приятел, добавяне на плейлист, надграждане и др.
Като вземем подмножество от тези данни и идентифицираме тенденцията, която потребителят е предприел преди понижаване или „Churn“, би трябвало да можем да правим прогнози, ако даден потребител е на път да напусне.
Затова дефинирах нова колона въз основа на стойностите в „Потвърждение за анулиране“ и „Изпращане на понижаване“ и създадох нова колона, наречена „понижена“, която по същество представлява числови стойности, базирани на оттока на потребителите.
Анализ — Визуализация на данни
Сега въз основа на стойността на изтичане и различните стойности в самия набор от данни, имах възможност да визуализирам различни аспекти на набора от данни и потребителските характеристики.
Проверено колко потребители използват какъв тип клиентски браузър:
Проверихте кои са предпочитаните операционни системи, използвани от потребителя:
Сортиране дали има някаква разлика в пола, които са по-склонни да напуснат:
Анализиране на отлив въз основа на потребителски тип като платен или безплатен:
Предпочитане на данни
Бяха предприети следните стъпки като част от предварителната обработка на данни, така че да имаме чисти и валидни данни за изграждане на нашия модел:
- Заредете данни от „mini_sparkify_event_data.json“, което е подмножество от действителни данни.
- Идентифицирайте нулеви стойности и недефинирани стойности в набора от данни.
- проверете дали стойностите „sessionId“, „userId“ са празни и изпуснете тези редове.
- Пуснете, ако има дубликати в колоните sessionId и userId.
- Дефинирайте отлив въз основа на две колони — „Потвърждение за анулиране“ и „Изпращане на по-ниска версия“ и обединете стойностите в една колона „понижена“, за да улесните изчисленията.
- Извличане на потребителски агент (браузър, използван от клиента) въз основа на браузъра на клиента.
- По същия начин извлечете коя операционна система се използва от потребителя.
Внедряване
След като получихме нашия нов набор от данни, който е изчистен и има няколко допълнителни колони, дефинирани въз основа на извлечените данни, ние погледнахме как всъщност изглеждат данните.
Най-важната идентифицирана колона е „страница“, която определя действията на потребителя.
Можем да използваме тази колона и да идентифицираме какви действия са предприети от потребителя и да изпълним нашия модел въз основа на резултатите, за да идентифицираме бъдещите действия на потребителя.
Инженеринг на характеристиките
След като проучихме и анализирахме набора от данни, стигнахме до следните въздействащи функции:
Категорични характеристики: пол, ниво на абонамент, операционна система. Категоричните стойности бяха преобразувани в индекси за измерване.
Числови характеристики: дължина на песента, продължителност на сесията, честота на действия като харесване нагоре, харесване надолу, посещения на страница за помощ, брой грешки
За машинно обучение трябва да работим с числови данни, така че в крайна сметка всички категорични и числови стойности бяха комбинирани и трансформирани във вектор за моделиране.
Усъвършенстване и моделиране:
В нашия случай използвахме резултат F1, за да предвидим и анализираме нашите модели. Наборът от данни беше разделен на 90% и 10% за обучение и тест.
За да изградим нашия модел, ние избираме следните алгоритми за контролирано обучение:
- Логистична регресия (LR)
- Класификатор на случайни гори (RF)
- Градиентно подсилен дървовиден класификатор (GBT)
Докато тествахме всеки модел на нашия набор от данни, получихме различни f1 резултати и точност. пуснахме всеки модел във влака и тестовия комплект, за да получим най-добрата прогноза за оттеглянето на потребителите.
Резултатите от нашите модели и F1 са по-долу:
Логистична регресия:
Accuracy for Logistic Regression Model is: 0.5 F1 score for Logistic Regression model is : 0.5494505494505495
Случаен класификатор на Forrest:
Accuracy for Random Forest Model is: 0.6 F1 score for Random Forest Model is: 0.6333333333333333
Дървовиден класификатор с подсилен градиент:
Accuracy for Gradient Boosting Tree Model is: 0.8 F1 score for Gradient Boosting Tree classifier is : 0.819047619047619
Нашият окончателен модел, базиран на най-добрите показатели в дървото Gradient Boost.
Оценка и валидиране на модела:
За кръстосано валидиране на ефективността на всеки модел, ние създаваме функция за кръстосано валидиране на всеки модел. За това използвахме пакет за машинно обучение pyspark „CrossValidator“.
Избираме да пуснем всеки модел на теста и да обучим комплекта 5 и 10 пъти, за да получим възможно най-добрите оценки.
Резултатът от функцията за кръстосано валидиране е по-долу:
Comparing models on fold 1
params: {'maxIter': 5} f1: 0.577255 avg: 0.577255
params: {'maxIter': 10} f1: 0.616158 avg: 0.616158
Comparing models on fold 2
params: {'maxIter': 5} f1: 0.645370 avg: 0.611313
params: {'maxIter': 10} f1: 0.645370 avg: 0.630764
Comparing models on fold 3
params: {'maxIter': 5} f1: 0.630077 avg: 0.617567
params: {'maxIter': 10} f1: 0.630077 avg: 0.630535
Best model:
params: {'maxIter': 10} f1: 0.630535
Обосновка:
Пуснахме всеки модел независимо, за да проверим кой има най-добра точност и f1 резултати. резултатът от всеки модел предполага, че Gradient Boosted Tree Classifier е най-добрият сред трите метода за моделиране в този случай.
След като приключихме, тествахме с помощта на ml кръстосано валидиране 5 пъти и 10 пъти, за да анализираме резултатите и да потвърдим най-добрия модел. И при това валидиране моделът с градиентно усилване беше този с най-добри резултати.
Заключение:
Отражение:
Машинното обучение беше направено на три класификационни модела, логистична регресия, класификатор на случайни гори и класификатор на градиентно усилващо дърво. Общите параметри, включени за изпълнение на моделите, бяха седем параметъра. В нашето сравнение открихме, че Gradient Boost Tree превъзхожда другите модели с моята доста голяма разлика. Въз основа на този модел имаме следните резултати, които показват как различните функции/параметри влияят на оттеглянето на потребителите. Виждаме, че най-важната функция е палец нагоре и добавяне на приятел.
Подобрение и мисли:
Можем да видим, че е по-вероятно потребителят да се придържа към услугата, ако добавя повече приятели и дава повече палци на песните. но ако същият потребител дава палец надолу, това означава, че той получава предложения за песни, които не харесва и по този начин вероятно е склонен да напусне услугата. Също така може да е важно да забележите, че не сме включили колко време потребителят използва услугата, преди да реши да напусне. Възможно е хората, които се оттеглят, да са тези, които са използвали тази услуга за кратко време, а дългосрочните потребители все още се придържат към услугата. Също така можем да разберем колко време отнема на потребителя, за да надстрои своя абонамент, може да се наложи да преосмислим нашия модел и подход.
Надявам се да намерите този подход за интересен. Моля, не се колебайте да посочите грешки и предложения.
Връзка към моя проект git hub за пълен подход https://github.com/mpbnka/Udacity_DataScientist_Capstone
