Dynamiczne rekomendacje produktów w Magento 2: profile zamiast sztywnych relacji

W wielu projektach Magento 2 temat rekomendacji produktowych zaczyna się od prostego założenia: trzeba pokazać klientowi kilka dodatkowych produktów na karcie produktu, w koszyku albo przy finalizacji zamówienia. Problem pojawia się bardzo szybko. Standardowe mechanizmy related, upsell i cross-sell w Magento są przydatne, ale w praktyce często okazują się zbyt sztywne jak na realne potrzeby wdrożeniowe.

Sklep nie chce przecież wyświetlać tych samych produktów w każdym miejscu i dla każdego przypadku. Inny scenariusz będzie potrzebny dla produktu prostego, inny dla configurable, inny dla kampanii sezonowej, a jeszcze inny dla koszyka, w którym znajduje się kilka różnych produktów. Z perspektywy agencji i zespołów wdrożeniowych oznacza to zwykle jedno: zaczynają się wyjątki, customowe warunki i kolejne warstwy kodu, które coraz trudniej utrzymać.

Kowal_RelatedProductsProfiles został zaprojektowany właśnie po to, żeby ten problem rozwiązać inaczej. Zamiast budować logikę wokół pojedynczych, ręcznie spiętych relacji produktowych, moduł wprowadza pojęcie profilu rekomendacji. To profil opisuje, gdzie ma działać, na jakich warunkach ma się uruchomić, jak dobrać produkty i jak je wyrenderować. Dzięki temu rekomendacje stają się warstwą konfigurowalną, a nie kolejnym zbiorem jednorazowych wyjątków zaszytych w kodzie projektu.

Moduł jest dostępny tutaj: Automatyczne produkty powiązane dla Magento 2.

Dlaczego standardowe listy Magento często nie wystarczają

Natywne related, upsell i cross-sell dobrze sprawdzają się w prostych sklepach albo tam, gdzie merchandising jest ręcznie ustawiany przez zespół e-commerce. W praktyce wdrożeniowej bardzo szybko pojawiają się jednak scenariusze, których standardowy model nie obejmuje:

• pokazanie rekomendacji tylko dla wybranej grupy klientów,
• uruchamianie konkretnej listy tylko w określonym przedziale dat,
• powiązanie produktów na podstawie atrybutów katalogowych, a nie ręcznych relacji,
• inne zachowanie na PDP, inne w koszyku i inne w checkout,
• wpinanie listy w konkretne miejsce layoutu motywu bez przepisywania całego widoku,
• częściowe lub całkowite zastąpienie natywnych list Magento logiką projektową.

Dla agencji oznacza to zwykle dwa problemy. Po pierwsze, standardowy mechanizm trzeba obudowywać dodatkowymi warunkami. Po drugie, każda kolejna potrzeba biznesowa zaczyna generować osobny wyjątek. W pewnym momencie zamiast spójnego mechanizmu rekomendacji powstaje zestaw niepowiązanych obejść.

Profile jako warstwa logiki merchandisingowej

Najważniejszą ideą modułu jest odejście od myślenia w kategoriach pojedynczej listy produktów i zastąpienie go profilem rekomendacji.

Profil jest osobnym bytem konfiguracyjnym. To on definiuje:

• gdzie ma działać,
• dla jakiego sklepu i grupy klienta jest aktywny,
• jaki produkt ma być kontekstem,
• kiedy profil ma się uruchomić,
• jak dobierać kandydatów,
• jak zawężać wynik,
• jak sortować produkty,
• jak je wyświetlać,
• oraz czy mają dodatkowo zasilać natywne listy Magento.

Z punktu widzenia wdrożeniowca jest to duża zmiana jakościowa. Zamiast przygotowywać odrębny custom code dla każdego placementu, można zbudować zestaw profili odpowiadających różnym scenariuszom biznesowym. Taki model jest łatwiejszy w utrzymaniu, prostszy do rozwijania i znacznie bardziej czytelny dla zespołów, które będą pracować z projektem po wdrożeniu.

Gdzie moduł daje realną przewagę we wdrożeniach

Najbardziej oczywistym miejscem użycia jest karta produktu. To właśnie tam najczęściej chcemy pokazać produkty z tej samej kolekcji, w podobnym stylu albo z tej samej linii komunikacyjnej. W praktyce jednak PDP bardzo rzadko jest jedynym miejscem, w którym rekomendacje mają sens.

Koszyk otwiera zupełnie inny scenariusz. To już nie jest moment inspiracji, tylko etap, w którym można pracować nad zwiększeniem wartości koszyka. W tym miejscu sprawdzają się profile sugerujące akcesoria, dodatki, tańsze uzupełnienia albo produkty z innej bazy asortymentowej, ale nadal powiązane z tym, co klient już wybrał.

Checkout to kolejny etap, który wymaga ostrożności. Nie każdy sklep chce tam rozbudowywać merchandising, ale dla części wdrożeń może to być dobre miejsce na krótką, prostą listę produktów wspierających AOV, pod warunkiem że logika i renderowanie są bardzo kontrolowane.

Na tym jednak możliwości modułu się nie kończą. Profil może dodatkowo zasilać natywne bloki Magento:

• Related Products,
• Upsell Products,
• Crosssell Products.

Co ważne, integracja nie ogranicza się do prostego zastąpienia listy. Dla każdego z tych mechanizmów można zdecydować, czy wyniki profilu mają zostać dodane do natywnych produktów (append), czy całkowicie je zastąpić (replace). Dla agencji jest to bardzo praktyczne, bo pozwala wdrażać logikę etapami, bez konieczności od razu przepisywania całego doświadczenia zakupowego.

Jak działa logika modułu

Choć formularz profilu jest dość rozbudowany, sam model działania można opisać dość jasno. Moduł za każdym razem przechodzi przez kilka kolejnych etapów.

Najpierw określany jest placement, czyli miejsce uruchomienia profilu. Inna logika będzie działać na karcie produktu, a inna w koszyku. Następnie wybierany jest produkt kontekstowy. Na PDP jest to zwykle bieżący produkt, natomiast w koszyku i checkout trzeba zdecydować, który produkt z quote stanie się punktem odniesienia.

Kiedy moduł zna już kontekst, sprawdza warunki aktywacji. To pierwszy filtr, odpowiadający na pytanie: czy ten profil powinien w ogóle zadziałać dla bieżącej sytuacji?

Jeśli warunki przejdą, moduł przechodzi do matching rules. To tutaj dzieje się właściwe dopasowanie. Atrybuty produktu kontekstowego są mapowane na atrybuty kandydatów, tak aby znaleźć produkty z tej samej kolekcji, serii, grafiki, kategorii albo innej cechy istotnej biznesowo.

Po dopasowaniu można jeszcze zawęzić wynik statycznymi filtrami targetowymi. To wygodne miejsce na ograniczenie listy do określonych typów produktów, widoczności, statusu, a nawet wybranych baz produktowych.

Na końcu produkty są sortowane, przycinane do limitu i renderowane albo w osobnym miejscu layoutu, albo w natywnych blokach Magento.

W praktyce oznacza to, że moduł nie opiera się na jednej relacji produkt-produkt, tylko na sekwencji decyzji, które można kontrolować z poziomu administracji.

Tworzenie nowego profilu: jak wygląda praca z formularzem

Największa siła modułu ujawnia się dopiero wtedy, gdy spojrzy się na formularz profilu nie jak na listę pól, ale jak na narzędzie do modelowania scenariusza merchandisingowego.

Proces zaczyna się od sekcji ogólnej. Name to nazwa administracyjna, która ma pomóc zespołowi odnaleźć profil w panelu. Code jest identyfikatorem technicznym. To właśnie jego warto używać w logach, w komunikacji projektowej i w dokumentacji wdrożenia. Enabled pozwala szybko wyłączyć profil bez kasowania konfiguracji, a Sort Order decyduje o kolejności oceny profili w obrębie tego samego placementu.

Druga sekcja to zakres działania. Tutaj wybierane są placementy, store view i grupy klientów. Z wdrożeniowego punktu widzenia jest to bardzo istotne, bo pozwala utrzymać jeden mechanizm i jednocześnie różnicować zachowanie między sklepami, językami albo segmentami klientów.

Szczególnie ważne jest pole Context Strategy. Na karcie produktu sprawa jest prosta, bo moduł pracuje na bieżącym produkcie. W koszyku i checkout trzeba jednak określić, który element quote stanie się kontekstem. W praktyce może to być pierwszy produkt, ostatnio dodany produkt albo produkt o najwyższej cenie. To drobne pole ma bardzo duży wpływ na końcowy wynik, zwłaszcza w koszykach zawierających kilka różnych pozycji.

Pola From Date i To Date pozwalają zamknąć profil w określonym oknie czasowym. Dzięki temu ten sam moduł może obsługiwać również kampanie sezonowe i krótkie akcje sprzedażowe bez konieczności dorabiania oddzielnych przełączników.

Activation Conditions, Matching Rules i Target Product Filters

To właśnie te trzy sekcje odpowiadają za logikę biznesową modułu.

Activation Conditions należy traktować jako warstwę wejściową. To tutaj definiujemy, kiedy profil w ogóle ma się aktywować. Jeśli na przykład profil ma działać wyłącznie dla produktów z określoną bazą, marki albo z konkretną widocznością w katalogu, to właśnie tutaj powinny znaleźć się takie warunki.

Matching Rules są sercem całego mechanizmu. To one przenoszą cechy produktu kontekstowego na produkty docelowe. W praktyce oznacza to, że można powiedzieć modułowi: znajdź produkty, które mają tę samą grafikę, tę samą kolekcję, tę samą kategorię albo dowolny inny atrybut, który ma sens biznesowy.

Szczególnie istotne są tutaj dwa pola: Required oraz Empty Value Policy.

Required decyduje, czy dana reguła ma być obowiązkowa. Jeśli jest włączona, brak dopasowania odrzuca kandydata. Jeśli jest wyłączona, reguła działa raczej jako warstwa zawężająca, ale mismatch nie blokuje całego wyniku. W praktyce to bardzo ważne przy projektach, gdzie kontekst na PDP i w koszyku może wyglądać inaczej, na przykład dla configurable parent na karcie produktu i simple child w quote.

Empty Value Policy mówi modułowi, co zrobić, gdy produkt kontekstowy nie ma wartości w atrybucie źródłowym. Można pominąć regułę, uznać ją za nieudaną albo użyć wartości domyślnej. To pole często decyduje o tym, czy profil będzie stabilny w złożonym katalogu z różnymi typami produktów.

Target Product Filters to ostatnia warstwa zawężająca. Nie pracują już na relacji kontekst-kandydat, tylko bezpośrednio na produktach docelowych. To dobre miejsce na wymuszenie statusu, widoczności, typu produktu albo ograniczenie wyniku do wybranych rodzin asortymentowych.

Sortowanie i sposób prezentacji

Po stronie wdrożeniowej ważne jest nie tylko to, jakie produkty zostaną znalezione, ale też w jakiej kolejności i w jakiej formie zostaną pokazane.

Moduł pozwala zdefiniować atrybut sortowania podstawowego i dodatkowego. Dzięki temu można budować bardziej przewidywalne listy, a nie polegać wyłącznie na domyślnym zachowaniu kolekcji.

Po stronie prezentacji dostępne są różne warianty renderowania, w tym grid, slider i compact. To pozwala dopasować listę do miejsca na stronie bez konieczności tworzenia osobnych typów profili tylko po to, żeby zmienić markup lub układ wizualny.

Istotne jest też to, że profil może niezależnie sterować takimi elementami jak:

• cena,
• cena regularna,
• przycisk dodania do koszyka,
• nazwa produktu,
• krótki opis,
• rola obrazka.

W praktyce oznacza to, że ten sam silnik rekomendacji może zostać użyty zarówno do bardziej rozbudowanych sekcji na PDP, jak i do skromniejszych list w koszyku lub checkout.

Zasilanie natywnych list Magento

Jedną z ciekawszych cech modułu jest możliwość zasilania natywnych bloków Magento. To ważne szczególnie dla agencji, które nie chcą od razu burzyć istniejącego frontendu albo mają projekt, w którym część sklepu nadal korzysta z klasycznych list related, upsell i crosssell.

W takim scenariuszu profil nie musi być renderowany jako osobny blok. Może zostać podpięty pod natywną listę i działać w jednym z dwóch trybów.

Tryb append zostawia produkty natywne i dokłada do nich wyniki profilu. To dobre rozwiązanie tam, gdzie zespół e-commerce nadal chce utrzymać część ręcznie ustawionych relacji, ale jednocześnie potrzebuje dodatkowej warstwy automatyki.

Tryb replace idzie krok dalej i całkowicie zastępuje natywną listę wynikami profilu. To opcja szczególnie ciekawa tam, gdzie biznes nie chce już ręcznie zarządzać relacjami i oczekuje, że logika profilu stanie się głównym mechanizmem rekomendacji.

Taka architektura daje dużą elastyczność wdrożeniową. Można wejść z modułem etapami, najpierw rozszerzając natywne listy, a dopiero później całkowicie przejmując nad nimi kontrolę.

XML jako warstwa elastycznego osadzania

Z perspektywy wdrożeniowca bardzo istotne jest to, że moduł nie kończy się na logice doboru produktów. Równie ważna jest kontrola nad miejscem ich renderowania.

To właśnie dlatego profil ma pola XML przypisane do poszczególnych placementów. Pozwalają one osadzić wynik profilu w konkretnym kontenerze albo pod konkretnym blokiem layoutu, bez budowania osobnego modułu tylko po to, żeby wpiąć listę w wybrane miejsce.

W praktyce to bardzo ważne przy pracy z niestandardowymi motywami. Każdy frontend ma własną strukturę layoutu. Jedne motywy przenoszą opis produktu do innego parenta, inne budują własne wrappery, jeszcze inne przebudowują natywne bloki produktu niemal całkowicie. Możliwość sterowania placementem przez XML daje tu dużą przewagę.

To właśnie ta warstwa sprawia, że moduł nie jest tylko silnikiem rekomendacji, ale także narzędziem integracyjnym. Dla agencji to realna oszczędność czasu, bo można dostosować sposób osadzenia do konkretnego projektu bez naruszania głównej logiki.

Przykładowe scenariusze wdrożeniowe

Najprostszy scenariusz to klasyczna rekomendacja "ta sama kolekcja, inna baza". Profil może aktywować się dla produktu z określoną bazą i na podstawie matching rules znaleźć produkty o tej samej grafice, ale należące już do innej rodziny asortymentowej. Dzięki temu sklep może promować zestawy lub rozszerzać zakup o kolejne typy produktów bez ręcznego budowania relacji.

Drugi scenariusz to akcesoria lub dodatki w koszyku. W tym przypadku kontekstem może być pierwszy albo najdroższy produkt z quote, a target filters zawężają końcowy wynik do produktów, które mają sens jako rozszerzenie zakupów. To jest szczególnie przydatne tam, gdzie standardowy cross-sell Magento nie daje wystarczającej kontroli.

Trzeci scenariusz to kampanie sezonowe. Profil może działać tylko w wybranym przedziale dat, wyłącznie dla określonych store view i tylko dla wybranych grup klientów. Z perspektywy zespołu wdrożeniowego oznacza to, że kampanię da się zbudować w ramach tego samego mechanizmu, bez dorabiania osobnego modułu promocyjnego.

Czwarty scenariusz to częściowe lub całkowite zastąpienie natywnych upselli. Jest to szczególnie ciekawe dla sklepów, które mają dużo asortymentu, wiele cech katalogowych i nie chcą utrzymywać ręcznych relacji między produktami.

Dlaczego to podejście dobrze skaluje się w utrzymaniu projektu

Dla agencji najważniejsze pytanie nie brzmi tylko "czy to działa", ale również "czy będzie dało się to utrzymać za pół roku".

To właśnie tutaj profilowe podejście ma największą przewagę. Logika nie jest porozrzucana po osobnych observerach, pluginach i dedykowanych klasach dla pojedynczych przypadków. Zamiast tego mamy jeden model konfiguracyjny i jeden silnik rekomendacji, który można rozwijać warstwowo.

Taki układ daje kilka korzyści:

• łatwiej przekazać projekt do utrzymania,
• łatwiej dopisywać nowe scenariusze bez przepisywania istniejących,
• łatwiej diagnozować zachowanie profili, bo logika jest skupiona w jednym miejscu,
• łatwiej pracować z niestandardowymi frontendami dzięki warstwie XML,
• łatwiej rozdzielić decyzje biznesowe od implementacyjnych.

W praktyce oznacza to, że moduł daje agencji nie tylko nowe możliwości na etapie wdrożenia, ale też sensowną bazę do dalszego rozwoju projektu.

Podsumowanie

Kowal_RelatedProductsProfiles nie jest tylko mechanizmem do wyświetlania kolejnej listy produktów na stronie. To narzędzie do projektowania scenariuszy rekomendacyjnych w Magento 2.

Dla wdrożeniowców i agencji najważniejsze są trzy rzeczy. Po pierwsze, moduł pozwala budować logikę rekomendacji w oparciu o profile, a nie jednorazowe wyjątki. Po drugie, daje kontrolę nad placementem, kontekstem, doborem produktów i sposobem renderowania. Po trzecie, dobrze wpisuje się w realia projektowe, w których trzeba pogodzić oczekiwania biznesowe, ograniczenia motywu i potrzebę dalszej rozbudowy sklepu.

Jeżeli projekt wymaga czegoś więcej niż proste, ręcznie spięte relacje produktowe, taki model pracy daje znacznie większą swobodę niż standardowe mechanizmy Magento. I właśnie w tym tkwi jego największa wartość.