Rynkowa analiza koszykowa – Metoda Assosiation i algorytm a priori w kontekście statystycznej analizy klienta

Metodolog - statystyczna analiza data minig

Metodolog.pl – Analiza Statystyczna w nauce

Firma statystyczna METODOLOG

Rynkowa analiza koszykowa: rozpoznawanie produktów i treści, które dobrze ze sobą współgrają

 

Analiza koligacji i dziedzina reguł asocjacyjnych obejmuje rozległy zestaw technik analitycznych mających na celu odkrywanie związków i stosunków pomiędzy konkretnymi obiektami: mogą być nimi odwiedzający twoją stronę internetową (klienci albo goście), produkty w twoim sklepie albo treść różnych pozycji na twoim portalu społecznościowym. Z w/w, najpopularniejszym chyba przykładem jest właśnie „rynkowa analiza koszykowa”. W niej właśnie sprawdzasz czy występują kombinacje produktów, które często współwystępują w transakcjach. Na przykład, być może ludzie, którzy kupują mąkę i cukier są także skłonni być kupić jajka (ponieważ wielu z nich planuje pieczenie ciasta). Detalista może wykorzystać taką informację by poinstruować:

  • Rozmieszczających produkty na półkach (by ułożyli współgrające ze sobą koło siebie, tak aby jeszcze ułatwić klientowi robienie zakupów)
  • Dział marketingu (np. wcelować w klientów kupujących mąkę promocję na jajka, tak aby zachęcić ich by wydali więcej)

Internetowi detaliści i wydawcy mogą wykorzystać taki typ analizy do:

  • Lepszego rozmieszczenia treści na swoich portalach społecznościowych albo katalogach produktów
  • Uruchomienia systemów rekomendacyjnych (jak w Amazonie: klienci, którzy kupili ten produkt, również kupowali te produkty…)
  • Usprawnić marketing (np. poprzez uściślenie do jakich klientów warto wysyłać maile z jakimi ofertami produktów tak aby zwiększyć szansę zainteresowania ich)

Jest szeroki wachlarz algorytmów, dostępny na szerokiej gamie platform, do przeprowadzania rynkowej analizy koszykowej.

RYNKOWA ANALIZA KOSZYKOWA: PODSTAWY

 

Terminologia

 

Pozycje są obiektami między którymi rozpoznajemy związki. Dla internetowego detalisty, każda pozycja jest produktem w sklepie. Dla wydawcy, każda pozycja może być artykułem, blogiem, postem, video itd. Grupa pozycji jest zestawem pozycji.

I = {i1, i2, …, in}

 

Transakcje są przypadkami grup pozycji współwystępujących ze sobą. Dla internetowego detalisty, transakcja to, mówiąc wprost, transakcja. Dla wydawcy, transakcja może być grupą artykułów przeczytanych podczas jednej wizyty na stronie (to nawet pomaga analitykowi ustalić ponad jaki okres zmierzyć transakcję).

tn = {ii, ij, …, ik}

 

Zasady są stwierdzeniami formy

{i1, i2, …} à {ik}

Np. jeżeli masz pozycje w zestawie pozycji (po lewej stronie (LHS z ang. Left hand side) zasady np. {i_1, i_2, …}), wtedy jest prawdopodobne, że odwiedzający będzie zainteresowany pozycją po prawej stronie (RHS right hand side) np. {i_k}. W naszym przykładzie zasada byłaby taka:

{mąka, cukier} à {jajka}

 

Wydajność rynkowej analizy koszykowej jest generalnie zestawem zasad, które możemy wykorzystać przy podejmowaniu decyzji biznesowych (związanych przykładowo z marketingiem albo lokowaniem produktu).

Wsparcie pozycji albo zestawu pozycji jest ułamkiem transakcji w naszym zbiorze danych, który zawiera tę pozycję albo zestaw pozycji. Generalnie fajnie jest identyfikować zasady, które mają wysokie wsparcie, jako że takie będą pasować do dużej liczby transakcji. Dla detalistów z supermarketów, jest prawdopodobne że będą to produkty popularne dla całego przekroju użytkowników (np. chleb, mleko). Sprzedawcy nabojów do drukarek, na przykład, mogą nie mieć produktów z wysokim wsparciem, ponieważ każdy klient kupuje tylko takie naboje jakie pasują do jej/jego drukarki.

Ufność zasady jest prawdopodobieństwem tego, że prawdą jest dla nowej transakcji, że zawiera pozycje na LHS tej zasady. (i.e. jest to prawdopodobieństwo, że transakcja zawiera także pozycje na RHS). Formalnie wygląda tak:

ufność(im à in) = wsparcie(im ᴗ in) / wsparcie(im)

Podnośnik zasady jest stosunkiem wsparcia pozycji na LHS zasady współwystępującej z pozycjami na LHS zasady współwystępowania z pozycjami na RHS podzielonym przez prawdopodobieństwo tego, że LHS i RHS współwystępują jeżeli oba są niezależne.

podnośnik(im à in) = wsparcie(im ᴗ in) / wsparcie(im) x wsparcie(in))

Jeżeli podnośnik jest większy niż 1, sugeruje to, że obecność pozycji na LHS zwiększyła prawdopodobieństwo tego, że pozycje na prawej stronie wystąpią w tej transakcji. Jeżeli podnośnik jest poniżej 1, sugeruje to, że obecność pozycji na LHS tworzy prawdopodobieństwo tego, że pozycje na RHS będą częścią transakcji niżej. Jeżeli podnośnik wyniesie 1, sugeruje to, że obecność pozycji na LHS i RHS jest od siebie naprawdę niezależna: wiedząc, że pozycje na LHS są obecne nie robi żadnej różnicy w prawdopodobieństwie, że pozycje wystąpią w RHS.

Kiedy przeprowadzamy rynkową analizę koszykową, szukamy zasad z podnośnikiem większym niż jeden. Zasady z większą ufnością są tymi gdzie prawdopodobieństwo pozycji pojawiających się na RHS jest wysokie biorąc pod uwagę obecność pozycji na LHS. Jest także preferowane (wyższa wartość) do zasad akcji, które mają wysokie wsparcie – jako, że te nadadzą się do większej liczby transakcji. Jednakże, w przypadku sprzedawców długoterminowych, może to nie być możliwe.

DZIAŁANIE RYNKOWEJ ANALIZY KOSZYKOWEJ Z UŻYCIEM ALOGRYTMU APRIORI WYKORZYSTUJĄC R I PAKIET ARULES

 

Gwoli ścisłości: celem tej analizy jest stworzenie zestawu zasad, który łączy dwa lub więcej produktów. Każda z tych zasad powinna mieć podnośnik większy niż 1. Dodatkowo, jesteśmy zainteresowani wsparciem i ufnością tych zasad: zasady o wyższej ufności to te, w których występuje większe prawdopodobieństwo, że pozycje na RHS będą częścią transakcji biorąc pod uwagę obecność pozycji na LHS. Oczekujemy rekomendacji opartych na tych zasadach by napędzić, przykładowo, wyższy wskaźnik odpowiedzi. Także jesteśmy za wprowadzeniem najpierw do akcji zasad o wyższym wsparciu, jako że te mogą być użyte w szerszym wachlarzu przypadków.

W tym przykładzie, mamy zamiar przeprowadzić analizę dla internetowego sprzedawcy prowadzącego firmę „Pług śnieżny”. Zrobimy klasyczną rynkową analizę koszykową: przez to rozumiem, że poszukamy zasad opartych na rzeczywistych transakcjach (później w tym tekście pochylimy się nad plusami i minusami ustalania naszego „pola”).

Użyjemy R (interpretowany język programowania oraz środowisko do obliczeń statystycznych i wizualizacji wyników) by wykonać rynkową analizę koszykową. R jest świetnym statystycznym narzędziem, dobrym też analiz graficznych, w sam raz skrojonym do zaawansowanych analiz. Użyjemy pakietu arules, który implementuje algorytm apriori, jeden z najpowszechniej używanych algorytmów do znajdowania powiązań między pozycjami.

By rozpocząć, musimy wydobyć dane transakcyjne z „Pługu śnieżnego”, które identyfikują grupy pozycji przez transakcje. Następujące polecenia SQL wydobywają je bezpośrednio: to przywraca linijkę danych dla każdej linijki pozycji z każdej transakcji, z id transakcji i nazwą pozycji:

/* PostgreSQL / Redshift */SELECT”ti_orderid” AS „transaction_id”,”ti_name” AS „sku”FROM”events”WHERE”event” = ‚transaction_item’

Możemy przeciągnąć te dane bezpośrednio w R z R. Najpierw, ładujemy R i łączymy go z tabelką z naszego „Pługu śnieżnego” w Redshitcie poprzez wprowadzenie do wiersza poleceń w R następującego:

library(„RPostgreSQL”)con <- dbConnect(drv, host=”<<REDSHIFT ENDPOINT>>”, port=”<<PORT NUMBER>>”, dbname=”<<DBNAME>>”, user=”<<USERNAME>>”, password=”<<PASSWORD>>”)

Upewnij się, że wstawiłeś odpowiednie wartości dla <<REDSHIFT ENDPOINT>>  <<PORT NUMBER>>  , <<DBNAM>>  I   <<USERNAME>> .

Następnie egzekwujemy nasze poniższe polecenia SQL, wydobywające dane jako ramka danych w R:

t <- dbGetQuery(con, „SELECT\”ti_orderid\” AS \”transaction_id\”,\”ti_name\” AS \”sku\”FROM\”events\”WHERE\”event\” = ‚transaction_item'”)

Możemy wrócić na samą górę do pierwszych pięciu rekordów naszej ramki danych komendą „head(t)”.

Teraz każda linijka danych reprezentuje pojedynczą linijkę pozycji, tak więc pierwsza transakcja (zawierająca dwie pozycje) ma rozpiętość dwóch linijek.

Teraz musimy uporządkować linijki według id transakcji, tak aby pojedyncze produkty, który należą do każdej transakcji były zespolone przez rekordy w pojedynczy rekord jako szereg produktów. Wykonuje się to poprzez wpisanie następującej komendy do wiersza poleceń R:

i <- split(t$sku, t$transaction_id)

Znowu, w taki sam sposób jak poprzednio wędrujemy na samą górę:

Teraz przekształcamy dane w „transakcję” obiektu zoptymalizowanego do algorytmu alures:

library(„arules”)txn <- as(i, „transactions”)

W końcu, możemy uruchomić nasz algorytm:

basket_rules <- apriori(txn, parameter = list(sup = 0.005, conf = 0.01, target=”rules”))

Uruchamiając zasadę ustawiamy minimalne progi ufności i wsparcia, poniżej których R ignoruje każdą zasadę. Są one wykorzystane do optymalizacji działania algorytmu: rozpracowywanie związków zasad może być obliczeniowo kosztowne, ponieważ dla firmy z dużym katalogiem pozycji, liczba kombinacji pozycja jest gigantyczna (rośnie gwałtownie wraz ze wzrostem liczby pozycji). Dlatego wszystko co dajemy algorytmowi by zmniejszyć obciążenie obliczeniowe jest mile widziane.

W naszym przypadku, bierzemy pod uwagę niskie liczby dla wsparcia i ufności. To dlatego, że nasz przykładowy test jest oparty na sprzedaży długoterminowej, detalista oferuje ponad 10 tys. pozycji katalogowych i ma za sobą 90 tys. transakcji. Maksymalne wsparcie każdego z produktów jest bardzo niskie: to może zostać potwierdzone przez nakreślenie względnej częstotliwości dla każdej pozycji (i.e. ułamek transakcji) dla topowych 25 pozycji przez częstotliwość pozycji (i.e. ułamek transakcji, w których występuje poszczególna pozycja). To może zostać zrobione używając:

itemFrequencyPlot(txn, topN = 25)

Zauważ, że najczęściej pojawiająca się pozycja występuje w mniej niż 2% zapisanych transakcji.

W twoim przypadku rozkład pozycji według transakcji może wyglądać zupełnie inaczej, i zupełnie różne wartości wsparcia i ufności mogą się okazać dobre do zastosowania. By ustalić co działa najlepiej, musisz poeksperymentować z różnymi parametrami: zobaczysz, że jeśli je zredukujesz, liczba generowanych zasad wzrośnie, co da ci więcej materiału do pracy. Jednakże, będziesz musiał uważniej przesiewać zasady żeby zidentyfikować te bardziej wpływające na twój biznes. Jeszcze do tego wrócimy.

Zbadajmy w końcu właściwe zasady wygenerowane przez algorytm:

inspect(basket_rules)

W naszym przypadku, algorytm rozpoznał 9 zasad. Pierwsze 7 nie jest pomocne: nie ma pozycji na LHS (dla tych siedmiu zasad, zauważ jak z powodu braku pozycji na LHS, wsparcie = ufność i podnośnik = 1).

Ostatnie dwie zasady są za to interesujące: sugerują, że ludzie, którzy kupują „Memo Block Apple” z większym prawdopodobieństwem kupią „Memo Block Pear” i vice-versa. Co więcej, nie tyle kupią to prawdopodobniej, co kupią znacznie prawdopodobniej: ufność wynosi 66 – to sugeruje, że te zakupy są ze sobą mocno związane.

OPEROWANIE NA BARDZO DUŻYCH ZESTAWACH WYNIKÓW: WIZUALIZACJA ZASAD Z WYKORZYSTANIEM PAKIETU ARULESVIZ

 

W poprzednim przykładzie tak ustaliliśmy parametry dla wsparcia i ufności, że tylko mały zestaw zasad został wypluty. Jak wspomniano, często lepiej jest jednak otrzymać większe zestawy, by zwiększyć szanse, że wygenerujemy więcej istotnych zasad dla naszego biznesu.

Powróćmy do algorytmu, tym razem zmniejszymy parametry dla wsparcia i ufności, i zapiszemy zestaw wyników jako inny obiekt.

basket_rules_broad <- apriori(txn, parameter = list(sup = 0.001, conf = 0.001, target=”rules”))

W naszym przypadku zwrócone zostało 3,2 miliona zasad. To o wiele za dużo, żeby wizualnie je zbadać – możemy jednak przyjrzeć się 20 najlepszym według podnośnika:

 

Możemy rozrysować nasze zasady przez ufność, wsparcie i podnośnik, wykorzystując pakiet arulesViz:

library(„arulesViz”)plot(basket_rules_broad)

Wykres pokazuje, że zasady z wysokim podnośnikiem zwykle mają słabe wsparcie (nie jest to matematycznie zaskakujące). Możemy użyć wykresu, jak ten powyższy, do rozpoznania zasad z zarówno wysoką ufnością jak i wsparciem: pakiet arulesViz pozwala nam wyrysować graf w interaktywnym trybie, tak że możemy klikać na pojedyncze punkty i eksplorować związane z nimi dane.

Jak wiele zasad uda się wytworzyć i jaki im nadamy priorytet, zależy od tego na jakie pytania biznesowe chcemy odpowiedzieć naszą analizą. Jest to omówione w dalszej części.

PODEJMOWANIE DECYZJI BIZNESOWYCH W OPARCIU O ANALIZY

 

Zanim użyjemy danych do podjęcia jakiekolwiek decyzji biznesowej, ważnym jest aby cofnąć się o krok i pamiętać o czymś ważnym:

To co wydobyliśmy z analizy pokazuje jak często pozycje współwystępują w transakcjach. Jest to funkcja zarówno siły związku pomiędzy pozycjami jak i sposobu w jaki właściciel strony je zaprezentował.

Innymi słowy: pozycje mogą współwystępować nie dlatego, że są „naturalnie” ze sobą związane, ale dlatego, że my, ludzie zarządzający tą stroną, zaprezentowaliśmy je razem.

To jest przykład bardziej ogólnego problemu w analityce internetowej: nasze dane odzwierciedlają sposób zachowania użytkowników jak również sposób w jaki zachęciliśmy ich do danego zachowania, poprzez podjęte przez nas decyzje o designie naszej strony. Musimy być tego świadomi, ponieważ, jak wcześniej sugerowaliśmy w tym tekście, używamy wyników by informować gdzie są umiejscowione pozycje zbliżone jedna do drugiej, musimy kontrolować jak blisko są one umieszczone dziś na stronie internetowej, tak abyśmy nie wylądowali przypadkiem potwierdzając to co wcześniej założyliśmy. Zatem jeśli pozycje k i l pokazują silny związek, ale już znajdują się obok siebie na stronie, to nie jest to specjalnie interesujące. Jeżeli są daleko do siebie, wtedy owszem – może powinniśmy ustawić je blisko siebie. Jeżeli pozycje są blisko siebie, ale analiza pokazuje, że nie ma między nimi silnego związku, wtedy, wydaje się, powinniśmy je rozdzielić: nasze poprzednie założenie, że powinny być umiejscowione razem raczej było błędne.

Wykorzystanie danych do zarządzania organizacją strony

 

Jest kilka sposobów by wykorzystać dane do zarządzania organizacją strony:

  • Duże grupy współwystępujących pozycji powinny prawdopodobnie posiadać własną kategorię.
  • Pary pozycji, które powszechnie współwystępują powinny być umieszczone razem wewnątrz granic kategorii na stronie. Jest to wyjątkowo ważne gdy jedna pozycja z pary jest bardzo popularna, a druga ma bardzo duże rezerwy.
  • Długa lista zasad (licząc te z niskim wsparciem i ufnością) może być użyta przy umieszczaniu rekomendacji na dole strony z produktami albo na stronach kart produktu. Jedyne co jest ważne dla tych zasad to by podnośnik był większy od jeden (i to żebyśmy wybierali te zasady, które mają zastosowanie do danego produktu z wysokim podnośnikiem gdzie produkt rekomendowany ma duże rezerwy).
  • W sytuacji gdy zrobimy powyższe (3) i da to istotny wzrost profitu, wzmocni to wniosek by zainwestować w system rekomendacyjny, który używa podobnego algorytmu w kontekście operacyjnym by wzmocnić automatyczny system rekomendacji na twojej stronie.

Wykorzystanie danych do ukierunkowania kampanii marketingowej

 

Te same dane mogą zostać użyte do zarządzania kampanią marketingową. Dla każdego użytkownika, bierzemy garść produktów opartych na produktach, które wcześniej kupił, a które oba mają wysokie współczynniki i wysyłamy je np. spersonalizowanym mailem albo pokazową reklamą itd.

Jak używamy analizy mającej znaczące implikacje dla analizy samej w sobie: jeżeli karmimy analizą automatyczny system dostarczający rekomendacje, jesteśmy dużo bardziej zainteresowani wygenerowaniem kosztownych zestawów zasad. Jeśli jednak eksperymentujemy z kampanią marketingową po raz pierwszy, dużo sensowniejsze jest wybranie garści zasad o szczególnie wysokiej wartości i posługiwanie się tylko nimi, przed wywnioskowaniem czy inwestować w wysiłek zbudowania zasobów potrzebnych do zarządzania znacznie szerszym i bardziej skomplikowanym zestawem zasad.

POSZERZENIE ANALIZY: ODDALENIE SIĘ OD KOSZYKA BY PRZYJRZEĆ SIĘ ZACHOWANIU KLIENTA W DŁUŻSZYM OKRESIE CZASU I INNYCH WYDARZENIACH

 

W powyższym przykładzie użyliśmy rzeczywistej transakcji zdarzeń do rozpoznania związków pomiędzy produktami dla internetowego sprzedawcy.

Trzymając się przykładu naszego sprzedawcy, jednakże, moglibyśmy poszerzyć obszar naszej definicji transakcji. Zamiast tylko patrzeć na koszyk z zakończonymi sukcesem transakcjami, moglibyśmy spojrzeć na całościowe koszyki użytkowników (niezależnie czy chcą kupować czy nie). Kolejne kroki analizy byłby niemal identyczne, jednakże, zamiast użycia danych transakcji z „Pługu śnieżnego”, wyciągnęlibyśmy dodane-do-koszyka dane na zewnątrz, używając następujących komend:

/* PostgreSQL / Redshift */

SELECT

„domain_userid” + ‚-‚ + „domain_sessionidx” AS „transaction_id”,

„ev_property” AS „sku”

FROM

„events”

WHERE

„ev_action” = ‚add-to-basket’

Moglibyśmy dalej powiększać obszar, więc zamiast patrzeć na dodane-do-koszyka-zdarzenia, spójrzmy na każdy produkt, który został obejrzany przez danego odwiedzającego, i połączmy grupy produktów, które oglądali pojedynczy użytkownicy w trakcie jednej sesji:

/* PostgreSQL / Redshift */

SELECT

„domain_userid” + ‚-‚ + „domain_sessionidx” AS „transaction_id”,

„page_urlpath”

FROM

„events”

WHERE

„event” = ‚page_view’

Zauważ jak tym razem każdy produkt jest identyfikowany przez URL zamiast SKU. Być może dobrze by było przefiltrować URL-e, które nie odpowiadają stronom z produktami.

Wreszcie, możemy rozszerzyć nasze okno jeszcze dalej, tak że zamiast ograniczać się do jednej sesji, możemy przyjrzeć się temu samemu użytkownikowi podczas wielokrotnych sesji, i.e.:

/* PostgreSQL / Redshift */

SELECT

„domain_userid” AS „transaction_id”,

„page_urlpath”

FROM

„events”

WHERE

„event” = ‚page_view’

Zauważ, że są to prawie takie same komendy jak wtedy gdy nasz obszar był pre-sesją, tylko pozbyliśmy się domain_sessionidx (tak jak gdy szeregujemy przez „transaction_id”), szeregujemy przez użytkownika i całą jego aktywność, a nie każdego po prostu w czasie danej sesji.

Te końcowe, szersze przykłady obszaru, są bardziej naturalne dla wydawców i właścicieli mediów społecznościowych, którzy chcą zidentyfikować związki pomiędzy artykułami, autorami, producentami i kategoriami zawartości niż dla produktów w sklepie.