Jak zbudować prosty system rekomendacji produktów bez wielkiego działu data science

Po co małej firmie system rekomendacji i kiedy ma sens

Jakie realne problemy rozwiązuje prosty system rekomendacji

System rekomendacji produktów nie jest wyłącznie narzędziem „dla Amazona”. Nawet bardzo prosty mechanizm rekomendacji w małym sklepie internetowym może rozwiązać trzy konkretne problemy: zbyt małą wartość koszyka, niewykorzystany ruch oraz ręczną, czasochłonną pracę przy układaniu oferty.

Po pierwsze, zwiększenie średniej wartości koszyka. Jeśli klient ogląda tablet, obudowę i etui, ale wkłada do koszyka tylko tablet, system rekomendacji może dociągnąć pozostałe produkty w formie „Produkty, które klienci często kupowali razem z tym tabletem”. Prosty, oparty na współwystępowaniu system podpowie akcesoria bez wnikania w zaawansowane profile klienta. Efekt: większa szansa na cross-sell bez dodatkowej pracy działu marketingu.

Po drugie, lepsze wykorzystanie istniejącego ruchu. Jeśli sklep inwestuje w reklamy, SEO i kampanie płatne, to każdy użytkownik, który już trafił na stronę, jest cenny. System rekomendacji pomaga „uratować” wizytę, gdy użytkownik nie znajduje dokładnie tego, czego szukał: pokazanie podobnych produktów, alternatyw w innej cenie czy bestsellerów w danej kategorii zmniejsza ryzyko natychmiastowego wyjścia.

Po trzecie, odciążenie merchandisera lub właściciela. W małej firmie to często jedna osoba ręcznie ustawia listy produktów: „nowości”, „bestsellery”, „polecane w kategorii”. Gdy katalog rośnie, to zaczyna być nie do utrzymania. Nawet prosty system oparty na regułach typu „najczęściej kupowane wraz z X” lub „top sprzedaży w ostatnich 30 dniach” automatyzuje część tej pracy i reaguje na zmieniające się preferencje klientów bez interwencji człowieka.

Przykładowe zastosowania: elektronika, księgarnia, SaaS

Mały sklep z elektroniką może użyć prostego systemu rekomendacji, aby generować zestawy: do laptopa sugerowane są torby, myszki i stacje dokujące. Nie trzeba do tego rozbudowanych modeli – wystarczy analiza współwystępowania produktów w zamówieniach. Im więcej zamówień, tym lepiej dopasowane pary.

Księgarnia online ma naturalne pole do rekomendacji „klienci, którzy kupili tę książkę, kupili także…”. Dla książek działa zarówno współwystępowanie w koszyku, jak i podobieństwo treści: kategorie, gatunki, autorzy. Prosty system content-based pokaże książki w tym samym gatunku lub od tej samej autorki, nawet jeśli nie ma jeszcze wielu transakcji.

Produkt SaaS z różnymi planami abonamentowymi może użyć rekomendacji, aby podpowiadać upgrade’y: „Użytkownicy korzystający z funkcji X najczęściej przechodzili na plan Y”. Tutaj rekomendacje opierają się bardziej na zachowaniach (aktywność w funkcjach systemu) niż na koszykach zakupowych, ale logika jest podobna: szukanie wzorców współwystępowania i podobnych profilów użytkowników.

Kiedy prosty system rekomendacji przestaje być „gadżetem”

Granica opłacalności pojawia się tam, gdzie ręczne zarządzanie ofertą przestaje nadążać za katalogiem i ruchem. Przy bardzo małym sklepie z kilkudziesięcioma produktami i kilkoma zamówieniami dziennie system rekomendacji będzie bardziej ciekawostką niż realnym narzędziem sprzedaży. Im większa liczba produktów i transakcji, tym więcej dane „mówią” i tym lepiej działają nawet proste algorytmy.

Przydaje się kilka orientacyjnych punktów:

• liczba produktów: od kilkuset w górę – wtedy robi się problem z ręczną ekspozycją i doborem alternatyw;
• ruch: od kilkuset–kilku tysięcy sesji miesięcznie – rekomendacje zaczynają mieć szansę działać statystycznie sensownie;
• liczba transakcji: co najmniej kilkadziesiąt zamówień miesięcznie, aby współwystępowanie produktów nie było przypadkowe.

System rekomendacji ma sens, gdy z jednego dnia danych da się wyciągnąć sygnał, a nie tylko szum. W praktyce oznacza to: pojedyncze zakupy tych samych par produktów powinny się powtarzać, a nie być jednorazowymi zbiegami okoliczności.

Czego nie da się osiągnąć prostym systemem

Prosty system rekomendacji produktów ma swoje granice. Nie zapewni pełnej, silnie spersonalizowanej obsługi omnichannel, w której uwzględnia się historię offline, aplikację mobilną, web, e-maile i komunikację w czasie rzeczywistym na poziomie „klient wszedł do sklepu stacjonarnego, więc zmień rekomendacje w aplikacji”.

Bez dużego działu data science trudno też o rozbudowane systemy bandytów kontekstowych, automatyczne testowanie setek wariantów layoutów czy zaawansowane modele sekwencyjne (np. oparte na sieciach neuronowych), które analizują długie ścieżki zachowań użytkownika. To nie jest cel małej firmy na pierwszym etapie.

Prosty system rekomendacji nie rozwiąże także wszystkich problemów z ofertą. Jeśli opisy produktów są niepełne, kategorie chaotyczne, a zdjęcia słabe, sama rekomendacja niewiele zmieni. Będzie porządkować to, co już jest, ale nie przykryje braków w podstawach merchandisingu.

Pytania kontrolne na start: co wiemy, czego nie wiemy

Przed budową systemu rekomendacji konkretna lista pytań porządkuje sytuację:

• Co wiemy o naszych danych? Czy mamy uporządkowane transakcje, logi kliknięć, sensowne ID produktów i użytkowników?
• Co wiemy o klientach? Czy posiadamy stabilne identyfikatory (konto, e-mail, ciasteczko)? Czy umiemy odróżnić nowego użytkownika od powracającego?
• Czego nie wiemy? Czy źródła danych nie są połączone, brakuje informacji o kategoriach produktów, nie śledzimy oglądanych stron?

Im lepiej odpowiedzi są zdefiniowane, tym łatwiej świadomie zdecydować: zaczynamy od prostych rekomendacji opartych na współwystępowaniu, czy najpierw porządkujemy katalog produktów i sposób zbierania danych.

Jakie dane są naprawdę potrzebne do prostych rekomendacji

Absolutne minimum: logi zakupów i oglądania produktów

Najprostszy, a jednocześnie kluczowy element to dane o interakcjach użytkownika z produktem. Dla systemu rekomendacji najczęściej liczy się:

• kto – identyfikator użytkownika (user_id),
• co – identyfikator produktu (product_id),
• kiedy – znacznik czasu (timestamp).

W praktyce wystarczą dwie główne tabele lub ich odpowiedniki:

• Transakcje (zakupy) – każda linia to pojedynczy zakup produktu przez użytkownika, najlepiej z numerem zamówienia, aby odtworzyć koszyk.
• Logi oglądania produktów – informacje, który użytkownik (lub anonimowy identyfikator sesji) oglądał które produkty i kiedy.

Jeśli firma nie zbiera jeszcze logów oglądania, można zacząć wyłącznie od danych transakcyjnych. Systemy oparte na współwystępowaniu i proste collaborative filtering na bazie zakupów już pozwalają generować sensowne rekomendacje. Logi oglądania stają się ważne, gdy transakcji jest mało, a ruchu dużo – wtedy kliknięcia są sygnałem zainteresowania.

Dane o produktach: które pola są kluczowe

Aby działały rekomendacje oparte na podobieństwie produktów (content-based filtering), potrzebny jest opis produktu w postaci cech. Zazwyczaj wystarczają:

• kategoria / podkategoria – hierarchiczna struktura lub jedno pole typu „Laptopy”, „Książki / Kryminał”;
• marka / producent – szczególnie w elektronice, modzie, kosmetykach;
• cena – warto ją później znormalizować (np. w koszykach cenowych, tzw. binning),
• tagi / słowa kluczowe – kolor, materiał, przeznaczenie („do biegania”, „dla dzieci”).

Pełne, „idealne” dane produktowe nie są konieczne. Ważniejsze, aby podstawowe informacje były spójne: ten sam typ produktu zawsze trafia do tej samej kategorii, marka nie ma pięciu wariantów pisowni, a cena jest w jednej walucie. Nawet prosty wektor cech: kategoria + marka + zakres cenowy pozwala znaleźć produkty bliskie sobie.

Dane o użytkownikach: zachowania ważniejsze niż deklaracje

Wielu właścicieli sklepów zakłada, że do rekomendacji konieczne są szczegółowe dane demograficzne: wiek, płeć, miasto, zainteresowania z ankiet. W prostym systemie rekomendacji nie jest to konieczne, a nierzadko wręcz zbędne na pierwszym etapie.

Znacznie silniejszym sygnałem są zachowania:

• jakie produkty użytkownik kupił,
• co oglądał,
• co dodał do koszyka, ale nie kupił,
• jak reagował na wcześniejsze rekomendacje (kliki w proponowane produkty).

Jeśli identyfikacja użytkownika opiera się na e-mailu lub zalogowanym koncie, łatwiej łączyć historię wizyt. W przeciwnym razie można posiłkować się identyfikatorem sesji lub ciasteczkiem – to mniej stabilne, ale nadal użyteczne dla rekomendacji w obrębie jednej wizyty.

Jakość danych: szybkie diagnozowanie problemów

Bez sprawdzenia jakości danych nawet najlepszy algorytm będzie generować przypadkowe lub błędne rekomendacje. Typowe problemy:

• duplikaty transakcji – ten sam zakup zapisany kilka razy;
• brakujące ID użytkownika lub produktu – wiersze, w których user_id lub product_id jest puste;
• niekonsekwentne kategorie – ten sam produkt w różnych kategoriach w różnych rekordach;
• produkty wycofane lub niedostępne – nadal obecne w danych historycznych, ale nienadające się do rekomendacji.

Prosta diagnostyka może wyglądać tak:

• policzenie liczby unikalnych user_id, product_id w transakcjach i porównanie z tabelą użytkowników i produktów,
• sprawdzenie, ile rekordów ma puste lub zerowe ID,
• wyliczenie top 10 najczęściej kupowanych produktów oraz top 10 najrzadziej – anomalie rzucają się w oczy (np. produkt „testowy”).

Nawet surowy eksport danych do arkusza kalkulacyjnego i kilka prostych filtrów pomaga wykryć problemy, zanim zaczną psuć rekomendacje.

Prosty schemat danych: transakcje, produkty, użytkownicy

Najbardziej podstawowy model danych dla prostego systemu rekomendacji można przedstawić w trzech tabelach: transactions, products, users. Ich role są jasne:

• transactions: transaction_id, user_id, product_id, quantity, timestamp;
• products: product_id, name, category, brand, price, tags;
• users: user_id, registration_date, ewentualnie kilka prostych atrybutów (np. kraj).

Kluczowe jest, aby klucze się zgadzały: każdy product_id z transactions musi istnieć w products, a każdy user_id z transactions – w users (jeśli prowadzona jest tabela użytkowników). Przy anonimowych zakupach user_id można zastąpić identyfikatorem sesji lub zostawić puste – wtedy rekomendacje koncentrują się na współwystępowaniu produktów, a nie na profilach użytkowników.

Wybór strategii: prosty system oparty na regułach vs. uczenie maszynowe

Najprostsza baza: „klienci kupili również” i „bestsellery w kategorii”

Najłatwiej zacząć od rekomendacji, które nie wymagają zaawansowanego uczenia maszynowego ani rozbudowanego środowiska analitycznego. Trzy typowe mechanizmy:

• „Klienci kupili również” – rekomendacje oparte na współwystępowaniu produktów w tym samym zamówieniu lub koszyku.
• „Często oglądane wspólnie” – podobna idea, ale zamiast zakupów bazuje na tym, co było oglądane w tej samej sesji.
• „Bestsellery w kategorii” – lista najczęściej kupowanych produktów w danej kategorii, w określonym przedziale czasowym.

Te trzy rodzaje rekomendacji można policzyć z użyciem prostych agregacji w bazie danych lub narzędzi typu Excel/Sheets (przy małej skali). Nie ma tu jeszcze mowy o modelach, macierzach czy parametrach – to system rekomendacji oparty na regułach, ale w wielu małych sklepach już potrafi zwiększyć sprzedaż.

Reguły oparte na współwystępowaniu i top-N – kiedy wystarczą

Reguły bazujące na współwystępowaniu oraz listach top-N sprawdzają się, gdy:

• katalog produktów nie jest ogromny (do kilku–kilkunastu tysięcy pozycji),
• liczba transakcji jest ograniczona, ale powtarzające się schematy są widoczne,
• nie ma zasobów, aby utrzymywać i stroić modele ML.

Proste przykłady reguł:

• Na karcie produktu: pokaż 4 produkty najczęściej kupowane razem z tym produktem.
• W koszyku: do każdego produktu w koszyku wygeneruj listę powiązanych produktów, usuń duplikaty i wybierz kilka najpopularniejszych.
• Na stronie kategorii: pokaż „bestsellery w kategorii” z ostatnich 30 dni.

Kiedy prosty system przestaje wystarczać

Reguły współwystępowania i listy top-N mają swój próg skuteczności. Po pewnym czasie pojawiają się sygnały, że to za mało. Co je zwykle zdradza?

• Duża część katalogu nigdy nie pojawia się w rekomendacjach, bo nie ma historii współzakupów.
• Nowe produkty nie mają jak „wejść do gry” – zanim zbiorą transakcje, minie kilka tygodni.
• Użytkownicy z długą historią zakupów widzą rekomendacje zbyt ogólne – wciąż te same bestsellery, a nie coś dopasowanego do ich profilu.

Na tym etapie pojawia się pytanie: czy inwestować w uczenie maszynowe, czy da się jeszcze coś „wycisnąć” z prostych reguł? Odpowiedź jest zwykle pośrodku – pierwsze elementy ML można wprowadzać stopniowo, a nie jako pełną, skomplikowaną platformę.

Prosty „silnik reguł”: łączenie kilku źródeł rekomendacji

Zanim wejdą w grę modele predykcyjne, można poukładać istniejące mechanizmy w prosty silnik reguł. Celem jest jasna odpowiedź: co, kiedy i komu pokazujemy. Przykładowy schemat:

• Jeśli użytkownik ogląda produkt X:
  • najpierw: 4 produkty „klienci kupili również”,
  • jeśli lista jest krótka: uzupełnij „bestsellerami w kategorii X”.
• Jeśli użytkownik ma w koszyku min. 2 produkty:
  • policz zbiorczą listę powiązanych produktów ze wszystkich produktów w koszyku,
  • usuń produkty już kupione/znajdujące się w koszyku,
  • pokaż 3 najczęstsze.
• Jeśli użytkownik jest nowy i nie ma historii:
  • na stronie głównej pokaż ogólne bestsellery,
  • po wejściu w kategorię – bestsellery w tej kategorii.

Takie reguły da się zaimplementować w kodzie aplikacji lub – przy małej skali – nawet jako kilka przygotowanych zestawień SQL, które są okresowo odświeżane i zapisywane w prostych tabelach pomocniczych.

Najprostsze rekomendacje oparte na współwystępowaniu produktów

Co oznacza „współwystępowanie” w praktyce

Współwystępowanie to fakt, że dwa produkty pojawiły się razem w tym samym koszyku lub zamówieniu. Im częściej występują wspólnie, tym silniejszy jest między nimi związek – niezależnie od tego, czy są z tej samej kategorii, czy nie.

Podstawowy krok to zbudowanie macierzy współwystępowania. Dla każdego produktu A chcemy wiedzieć, z którymi produktami B najczęściej się pojawia. Jak to policzyć na bazie transakcji?

Jak ręcznie policzyć rekomendacje „kupowane razem”

W mniejszym sklepie da się to zrobić prostą sekwencją kroków, nawet w arkuszu kalkulacyjnym (choć baza danych będzie wygodniejsza):

1. Z transakcji wyciągnij listę koszyków: numer zamówienia + lista product_id.
2. Dla każdego zamówienia wygeneruj wszystkie pary produktów z tego koszyka (A,B), ignorując kolejność.
3. Policz, ile razy każda para (A,B) pojawiła się w transakcjach.
4. Dla każdego produktu A posortuj produkty B według liczby współwystąpień malejąco.

W SQL sprowadza się to do złączenia tabeli transakcji samej ze sobą po numerze zamówienia i policzenia liczności par. W arkuszu – do kilku kroków kopiuj/wklej i użycia funkcji zliczających. Po stronie biznesowej wynik jest prosty: dla każdego produktu mamy listę „klienci kupili również”.

Filtry, które zapobiegają absurdalnym rekomendacjom

Surowe współwystępowanie bywa mylące. Potrzebne są proste filtry:

• Minimalna liczba współwystąpień – odrzuć pary, które pojawiły się razem tylko raz; zwykle są przypadkowe.
• Wykluczenia biznesowe – np. nie rekomenduj przedłużonej gwarancji konkurencyjnej marki, nie pokazuj produktów wycofanych.
• Ograniczenie do sensownych kategorii – np. przy telewizorze nie ma sensu proponować papieru do drukarki, mimo że raz pojawiły się razem w gigantycznym koszyku firmowym.

Najprostsza forma to dopisanie do tabeli produktów pola typu is_recommendable (czy produkt może być w rekomendacjach) i używanie go jako warunku w zapytaniach.

Co zrobić z produktami, które nie mają współwystąpień

W małym katalogu sporo pozycji nie ma żadnej historii wspólnych zakupów. Wtedy pojawia się luka: jakie rekomendacje pokazać na ich kartach?

Najczęstsze rozwiązania:

• Bestsellery w kategorii – domyślna lista, gdy brak powiązań.
• Produkty z tej samej podkategorii i zbliżoną ceną – prosta forma „podobieństwa” bez zaawansowanego modelu.
• Ręcznie zdefiniowane powiązania – dla kilku kluczowych produktów (np. flagowe modele) marketing może wskazać produkty komplementarne.

To jeszcze nie jest pełnoprawne content-based filtering, ale już krok w tę stronę: zaczyna liczyć się opis produktu, a nie tylko historia zakupu.

Rekomendacje oparte na podobieństwie produktów (content-based filtering)

Idea: rekomendujemy „podobne do tego, co już znasz”

Content-based filtering opiera się na założeniu: jeśli użytkownik interesuje się produktem X, zaproponuj mu produkty podobne do X. Podobieństwo wynika z cech produktu, a nie z historii współzakupów innych klientów.

Taki mechanizm jest szczególnie użyteczny w trzech sytuacjach:

• dużo nowych produktów – brak jeszcze danych transakcyjnych,
• rzadkie zakupy – mało współwystąpień, za to rozbudowane opisy,
• specjalistyczne katalogi – gdzie cechy (parametry techniczne, gatunki, rozmiary) dobrze opisują różnice między pozycjami.

Budowa prostego wektora cech produktu

Pierwszy krok to przedstawienie produktu jako zestawu cech. Nie trzeba skomplikowanych metod – wystarczy konsekwentne nazwanie i zakodowanie kilku pól. Przykładowy zestaw:

• kategoria – zamieniona na prostą wartość (np. „buty_bieganie”),
• marka – np. „Nike”, „Adidas”, „NoName”,
• przedział cenowy – np. tanie/średnie/drogie, wyznaczone na podstawie rozkładu cen w katalogu,
• tagi – kolor, materiał, przeznaczenie (np. „czarne”, „skóra”, „zimowe”).

Technicznie oznacza to zamianę tych pól na formę, którą da się porównać. Często stosuje się proste kodowanie „1/0”: produkt ma daną cechę – 1, nie ma – 0. W efekcie każdy produkt ma swój wektor: ciąg zer i jedynek, czasem uzupełniony liczbami (np. znormalizowaną ceną).

Jak mierzyć podobieństwo między produktami bez skomplikowanej matematyki

Znając wektory cech, potrzebna jest funkcja, która powie, jak bardzo dwa produkty są do siebie podobne. W praktyce wystarczą dwa proste warianty:

• współczynnik Jaccarda – stosunek liczby cech wspólnych do wszystkich cech, które występują w którymkolwiek z produktów,
• zliczanie cech wspólnych – im więcej cech wspólnych (ta sama kategoria, marka, podobny przedział cenowy, ten sam kolor), tym wyższy wynik.

Na start można pójść jeszcze prostszą drogą: zdefiniować priorytety. Przykład:

• produkty z tej samej podkategorii i tej samej marki – bardzo podobne,
• ta sama podkategoria, ale inna marka – podobne,
• inna podkategoria, ale podobny przedział cenowy i te same tagi (np. „na prezent”) – umiarkowanie podobne.

Takie reguły łatwo zapisać w SQL lub w kodzie aplikacji jako proste warunki i sortowanie po liczbie trafionych kryteriów.

Przykład: proste „podobne produkty” na karcie produktu

Załóżmy, że klient ogląda buty do biegania. Co wiemy? Kategoria: „obuwie sportowe / bieganie”, marka: X, cena: średnia półka, tagi: „męskie”, „amortyzacja”. Na tej podstawie można ułożyć zapytanie:

1. Wybierz produkty z tej samej podkategorii,
2. odfiltruj produkty, które nie są dostępne,
3. policz „punkty podobieństwa”:
   • +2 punkty za tę samą markę,
   • +1 punkt za ten sam przedział cenowy,
   • +1 punkt za każdy tag wspólny (np. „męskie”).
4. Posortuj malejąco po punktach i pokaż top 4.

Taki system można zbudować bez bibliotek ML – wystarczy konsekwentnie zdefiniować cechy i prostą funkcję „liczenia punktów podobieństwa”.

Łączenie podobieństwa produktów z zachowaniami użytkownika

Content-based filtering można połączyć z historią użytkownika, nawet w bardzo prosty sposób. Zamiast patrzeć tylko na jeden produkt, bierzemy lista ostatnio oglądanych lub kupionych produktów danego użytkownika. Następnie:

• działamy jak wyżej: dla każdego z tych produktów szukamy podobnych,
• sumujemy punkty podobieństwa dla powtarzających się produktów,
• odrzucamy już zakupione pozycje.

Efekt to „spersonalizowana” lista, oparta na tym, co użytkownik faktycznie oglądał/kupował, ale liczona wciąż prostą metodą punktową.

Collaborative filtering w wersji „light” – bez własnych algorytmów od zera

Na czym polega collaborative filtering w uproszczeniu

Collaborative filtering wykorzystuje informacje o relacjach między użytkownikami a produktami. Kluczowa idea: jeśli wielu użytkowników kupowało podobne produkty, to produkty, których brakuje w historii jednego z nich, mogą być dla niego dobrymi rekomendacjami.

W pełnej wersji stosuje się zaawansowane algorytmy (np. faktoryzację macierzy). W małej firmie nie trzeba tego implementować samodzielnie. Da się użyć uproszczonych metod, lub – co często jest rozsądniejsze – skorzystać z gotowych bibliotek i usług.

Uproszczone collaborative filtering: podobieństwo użytkowników

Najłagodniejsza wersja to user-based collaborative filtering w formie zbliżonej do współwystępowania, ale w przestrzeni użytkowników. Mechanizm:

1. Dla każdego użytkownika przygotuj listę produktów, które kupił (lub oglądał).
2. Dla analizowanego użytkownika U znajdź innych użytkowników, którzy mają z nim wspólne produkty w historii.
3. Policz podobieństwo między użytkownikami, np. jako:
   • liczba wspólnych produktów (im więcej, tym bardziej podobni),
   • proporcja wspólnych produktów do wszystkich produktów w ich historiách.
4. Weź kilku najbardziej podobnych użytkowników i zbierz produkty, których U nie kupił, a oni tak.
5. Posortuj te produkty według częstotliwości lub wagi (bardziej podobni użytkownicy ważą więcej).

To nadal nie wymaga specjalistycznych narzędzi ML, ale przy większej liczbie użytkowników i produktów robi się ciężkie obliczeniowo. Dlatego w małych sklepach ten wariant opłaca się stosować głównie do aktywnych klientów z dłuższą historią, a nie dla wszystkich.

Item-based collaborative filtering: bliżej współwystępowania, ale „sprytniej”

Drugi popularny wariant to item-based collaborative filtering. W praktyce jest bliższy macierzy współwystępowania, ale uwzględnia to, kto konkretnie kupował produkty. Idea:

• budujemy macierz użytkownik–produkt (czy użytkownik kupił dany produkt),
• na tej podstawie mierzymy podobieństwo między produktami – ale nie po cechach, tylko po tym, którzy użytkownicy je kupili,
• produkty kupowane przez podobne grupy użytkowników trafiają do tej samej „rodziny”.

Z punktu widzenia małej firmy różnica względem prostego współwystępowania jest taka, że podobieństwo uwzględnia nie tylko wspólny koszyk, ale całe profile zakupowe. W praktyce jednak obie metody można policzyć podobnymi narzędziami (agregacje w bazie, proste skrypty), szczególnie przy niewielkiej skali.

Gdzie skorzystać z gotowych bibliotek i usług

Zamiast samodzielnie kodować collaborative filtering, można sięgnąć po istniejące rozwiązania:

• Biblioteki open source – w językach takich jak Python działają pakiety do rekomendacji, które implementują podstawowe algorytmy CF (często wystarczy macierz użytkownik–produkt jako wejście).

Najczęściej zadawane pytania (FAQ)

Kiedy w małym sklepie internetowym system rekomendacji ma w ogóle sens?

Najprościej: wtedy, gdy ręczne ustawianie „polecanych” i „bestsellerów” przestaje nadążać za liczbą produktów i ruchem. Przy kilkudziesięciu produktach i kilku zamówieniach dziennie system rekomendacji będzie raczej ciekawostką niż realnym wsparciem sprzedaży.

Przydatnym punktem odniesienia są trzy liczby: co najmniej kilkaset produktów, kilkaset–kilka tysięcy sesji miesięcznie i kilkadziesiąt zamówień w miesiącu. Wtedy powtarzające się pary i zestawy produktów nie są już przypadkiem i nawet prosty algorytm ma z czego „wyciągać” wzorce.

Jakie problemy biznesowe może rozwiązać prosty system rekomendacji w małej firmie?

Najczęściej chodzi o trzy rzeczy: podniesienie średniej wartości koszyka, lepsze wykorzystanie istniejącego ruchu oraz odciążenie osoby odpowiedzialnej za ekspozycję oferty. Rekomendacje typu „kupowane razem z…” lub „podobne produkty” dodają naturalne cross-selle bez dodatkowych kampanii i ręcznego dobierania akcesoriów.

Drugi efekt to niższy odsetek „pustych wizyt”. Jeśli ktoś nie znajdzie dokładnie tego modelu, który wpisał, system może zaproponować alternatywy w podobnej cenie, bestseller w tej kategorii lub produkt o zbliżonych parametrach. Trzecia korzyść jest organizacyjna: mniej ręcznego układania list „nowości” i „bestsellerów”, które i tak szybko się dezaktualizują.

Jakie dane są absolutnie konieczne, żeby zacząć z prostymi rekomendacjami?

Na start wystarczy podstawowy zapis interakcji: kto, co i kiedy. W praktyce sprowadza się to do dwóch tabel lub ich odpowiedników: transakcji (zakupów) i logów oglądania produktów. Każdy wiersz zawiera identyfikator użytkownika lub sesji, identyfikator produktu oraz znacznik czasu.

Jeżeli sklep nie zbiera jeszcze logów oglądania, można uruchomić pierwszą wersję systemu wyłącznie na danych zakupowych. Na tej podstawie da się policzyć współwystępowanie produktów w koszykach i zbudować proste rekomendacje „klienci, którzy kupili X, kupili również Y”. Logi z kliknięć przydają się szczególnie wtedy, gdy transakcji jest mało, a wizyt dużo.

Czy da się zbudować system rekomendacji bez działu data science i skomplikowanych modeli?

Tak. W wielu małych firmach wystarczy połączenie prostych statystyk i kilku reguł. Najczęściej używa się analiz współwystępowania (produkty kupowane razem w tych samych zamówieniach) oraz prostych filtrów opartych na treści (kategoria, marka, zakres cenowy). To bardziej inżynieria danych niż zaawansowany machine learning.

Przykład: sklep z elektroniką może generować listy akcesoriów do laptopów czy telefonów, licząc, które produkty najczęściej pojawiały się razem w koszykach w ostatnich tygodniach. Taki mechanizm, choć prosty, bywa wystarczający, by sensownie podpowiadać torby, myszki czy etui przy przeglądaniu głównego produktu.

Jakie ograniczenia ma prosty system rekomendacji produktów?

Podstawowe ograniczenie dotyczy personalizacji i złożoności scenariuszy. Prosty system nie obejmie pełnej, spójnej ścieżki omnichannel z uwzględnieniem historii offline, aplikacji, strony www, e‑maili i reakcji w czasie rzeczywistym. Nie obsłuży też zaawansowanych algorytmów testujących setki wariantów układu strony czy sekwencyjnych modeli śledzących długie zachowania użytkownika.

Druga granica to jakość samej oferty. Jeśli produktom brakuje opisów, kategorie są chaotyczne, a zdjęcia zniechęcają, nawet najlepszy algorytm tylko uporządkuje ten stan, ale go nie „naprawi”. Pytanie kontrolne brzmi: co wiemy o stanie katalogu, a czego nie wiemy? Czasem większy efekt niż wdrożenie rekomendacji daje najpierw uporządkowanie podstawowych danych produktowych.

Czy system rekomendacji ma sens przy małej liczbie transakcji miesięcznie?

Przy pojedynczych zakupach dziennie skuteczność systemu opartego wyłącznie na współwystępowaniu będzie ograniczona, bo powtarzalnych wzorców jest zwyczajnie za mało. W takiej sytuacji lepiej skupić się na rekomendacjach opartych na treści (kategoria, marka, cechy produktu) oraz na poprawie widoczności bestsellerów i najbardziej dochodowych pozycji ręcznie lub półautomatycznie.

Gdy liczba transakcji zacznie rosnąć do kilkudziesięciu miesięcznie, można ostrożnie włączać moduł „kupowane razem z…”. Istotne pytanie brzmi: czy te same pary produktów zaczynają się regularnie powtarzać, czy nadal każdy koszyk jest zupełnie inny? Od odpowiedzi zależy, czy dane dają już sygnał, czy wciąż głównie szum.