# [ IUM projekt – 2022Z ] Etap 1

Andrii Demydenko - 317084
Bartosz Okoń - 304093

*wersja z niepełnymi danymi*

## 1. Temat projektu *(zadanie 07 wariant 01)* i kontekst

Portal "Pozytywka" pozwala użytkownikom na odtwarzanie ich ulubionych utworów online. Zbiera on dane na temat dostępnych artystów i utworów muzycznych, bazę użytkowników, historię sesji użytkowników i techniczne informacje dot. poziomu cache dla poszczególnych utworów.
Na podstawie tych danych powinniśmy przygotować i wdrożyć rozwiązanie, które usprawni działanie systemu.

Zadanie brzmi:
“Gdybyśmy tylko wiedzieli, kiedy użytkownik będzie chciał przesłuchać bieżący utwór w
całości, a kiedy go przewinie – moglibyśmy lepiej zorganizować nasz cache”

## 2. Definicja problemu biznesowego

Celem biznezowym jest zmniejszenie kosztów operowania systemem oraz zwiększenie szybkości działania usługi dla naszych klientów. Zapewnić to ma lepsza organizacja istniejącej struktury pamięci cache, którą osiągniemy dzięki zastosowaniu dobrego modelu predykcyjnego, przewidującego na podstawie ostatnich odtworzeń utworów i danych o użytkowniku, czy piosenka aktualnie odtwarzana zostanie odtworzona w całości i czy trzeba cachować ją całą, czy tylko pierwszych kilka sekund.
Nasz model będzie jedynie zapewniał predykcje co do tego ostatniego, a wykorzystaniem tej informacji w praktyce i implementacją lepszego systemu zarządzania cachem zajmie się inny zespół.

## 3. Kryterium sukcesu biznesowego

Za sukces możemy uznać zmniejszenie kosztów działania systemu wynikający z lepszej organizacji cache. Oszacowanie konkretnych liczb i mierzenie kosztów użytkowania jest zadaniem dla zespołu zajmującego się użyciem naszych predykcji do organizowania cache.

## 4. Zadanie modelowania

Po analizie wymagań i dostępnych danych stwierdziliśmy, że najlepszym modelem będzie model klasyfikacji (predykcji) binarnej, czy obecny utwór zostanie przez danego użytkownika przesłuchany do końca, czy też pominięty.
Wejściem modelu będą atrybuty utworu (liczbowe, z pliku tracks), dla którego ma odbyć się predykcja, atrybuty użytkownika (ulubione gatunki) i ewentualnie gatunki muzyczne artysty wykonującego dany utwór. Dokładne atrybuty zostaną dobrane podczas trenowania.
Rozszerzeniem modelu może być predykcja na podstawie sekwencji poprzednich utworów w sesji i decyzji ich dotyczących podjętych przez użytkownika. Jest duża szansa na to, że poprawiłoby to dokładność predykcji z uwagi na to, że nastrój użytkownika zmienia się w czasie, i może nie mieć takiej samej ochoty na odtworzenie danego utworu cały czas.
W dalszym toku prac, będzie można odpowiednio dobrać próg dla klasyfikatora tak, aby błędne predykcje wskazujące na to, że utwór będzie odtworzony w całości, nie zawyżały zbytnio kosztu działania systemu.

## 5. Kryterium sukcesu analitycznego

Z racji braku istniejącego systemu predykcji, zakładamy że sukcesem będzie stworzenie modelu działającego lepiej od losowego, czyli od 50% trafień modelu klasyfikacji binarnej.
Trudno jest ustalić na podstawie dostępnych danych konkretny próg sukcesu dla naszego klasyfikatora. W tekscie zadania nie podano wymagań dotyczących "ulepszenia organizacji cache", a nawet gdyby podano, nie wiemy jak zastosowanie modelu miałoby na nie wpłynąć.

## 6. Założenia

Zakładamy że model będzie poprawnie działał dla działąń większości użytkowników, lecz zawsze mogą zdarzyć się tacy, którzy na przykład nigdy nie pomijają utworów. W takich przypadkach predykcje mogą być niestabilne.
Mimo to zakładamy, że istnienie modelu istotnie wpłynie na koszt utrzymania systemu.

## 7. Produkt końcowy

Wyniki działania modelu predykcyjnego będą uwzględnione w algorytmach portalu "Pozytywka" i pozwolą lepiej zorganizować cache.

## 8. Podsumowanie przeprowadzonej analizy danych

Analizę przeprowadzono na danych mających wiele braków w powodu braku dostępu do lepszych danych.
Plik artists.jsonl informuje nas o nazwie artysty oraz gatunkach w których tworzy.
Track_storage.jsonl zawiera dane dotyczące przynależenia danego utworu do klasy cachowania oraz dziennym koszcie jego przechowywania.
Users.jsonl zawiera dane osobowe użytkowników, ich ulubione gatunki muzyczne oraz czy są oni użytkownikami premium.
W tracks.jsonl znajdują się liczbowe dane dotyczące konkretnych utworów oraz id ich wykonawcy i tytuł.
Wreszcie sessions.jsonl zawiera dane dotyczące sesji użytkowników - każda aktywność przez nich wykonana opatrzona jest timestampem, id utworu, użytkownika i sesji jej dotyczących oraz typ akcji - odtworzenie, pominięcie lub polubienie utworu.
Niestety dostępne dla nas dane mają sporo wartości null, co zmniejsza ilość użytecznych danych do analizy.
Niektóre braki danch można naprawić, np. id użytkownika w ramach sesji nie zmienia się, a przed pominięciem danego utworu zawsze występuje wydarzenie "PLAY" dotyczącego tego samego track_id.
Każdy użytkownik odtworzył przyzwoitą liczbę utworów.
Zbilansowanie klas "odtworzona" i "pominięta" jest bardzo dobre, ich wystąpień jest niemal po równo.
Atrybut timestamp w pliku sessions nie może być użyty, gdyż

Każdy użytkownik (dla którego akurat nie ma braku danych) ma przypisane 3 ulubione gatunki muzyczne.
Różnych gatunków jest 45.
Artyści z kolei mają przypisaną różną liczbę gatunków, w których tworzą.

Koszta przechowywania utworów w różnych klasach cache, przeliczone na jedno odtworzenie wyglądają tak:
Zgodnie z przewidywaniami, im szybsza pamięć, tym droższe jest przechowywanie.
Macierz korelacji artybutów utworów oraz atrybutu "skipped" - jak widać żaden pojedynczy atrybut nie ma wpływu na chęć odtwarzania. Zależności są bardziej złożone.

Zauważyć można natomiast sporą korelację loudness i energy oraz acousticness oraz energy. To pozwala zastanowić się nad redukcją wymiarowości dla tych atrybutów.

*szczegółowa analiza danych została przeprowadzona w Jupiter Notebook - [data_analysis](https://gitlab-stud.elka.pw.edu.pl/ademyden/ium_projekt_z07w01/-/tree/main/notebooks/data_analysis)*