Dynamische productaanbevelingen in Magento 2: profielen in plaats van starre relaties

In veel Magento 2-projecten begint het onderwerp productaanbevelingen met een eenvoudige aanname: je wilt de klant een paar extra producten tonen op de productpagina, in de winkelwagen of tijdens de checkout. Het probleem verschijnt echter al snel. De standaardmechanismen related, upsell en cross-sell in Magento zijn nuttig, maar blijken in de praktijk vaak te star voor echte implementatiebehoeften.

Een shop wil immers niet op elke plek en in elke situatie dezelfde producten tonen. Voor een simpel product is een ander scenario nodig dan voor een configurable, voor een seizoenscampagne weer een ander, en voor een winkelwagen met meerdere verschillende producten nog weer een ander. Vanuit het perspectief van agencies en implementatieteams betekent dit meestal één ding: er ontstaan uitzonderingen, maatwerkvoorwaarden en extra lagen code die steeds moeilijker te onderhouden zijn.

Kowal_RelatedProductsProfiles is precies ontworpen om dit probleem op een andere manier op te lossen. In plaats van de logica te bouwen rond losse, handmatig gekoppelde productrelaties introduceert de module het begrip aanbevelingsprofiel. Het profiel bepaalt waar het moet werken, onder welke voorwaarden het moet starten, hoe producten moeten worden geselecteerd en hoe ze moeten worden gerenderd. Daardoor worden aanbevelingen een configureerbare laag in plaats van opnieuw een verzameling eenmalige uitzonderingen in de projectcode.

De module is hier beschikbaar: Automatic related products for Magento 2.

Waarom standaardlijsten in Magento vaak niet genoeg zijn

De native related-, upsell- en cross-sell-lijsten werken goed in eenvoudige shops of in omgevingen waar merchandising handmatig door het e-commerce-team wordt beheerd. In echte implementaties verschijnen echter al snel scenario’s die het standaardmodel niet afdekt:

• aanbevelingen alleen tonen voor een geselecteerde klantgroep,
• een specifieke lijst alleen activeren binnen een bepaald datumbereik,
• producten koppelen op basis van catalogusattributen in plaats van handmatige relaties,
• ander gedrag op de PDP, ander gedrag in de winkelwagen en weer ander gedrag in de checkout,
• een lijst op een concrete plek in de themalayout plaatsen zonder de hele view te herschrijven,
• Magento’s native lijsten gedeeltelijk of volledig vervangen door projectspecifieke logica.

Voor agencies betekent dit meestal twee problemen. Ten eerste moet het standaardmechanisme worden uitgebreid met extra voorwaarden. Ten tweede begint elke nieuwe businessbehoefte een aparte uitzondering te creëren. Op een gegeven moment ontstaat er in plaats van één samenhangend aanbevelingsmechanisme een verzameling losstaande workarounds.

Profielen als laag van merchandisinglogica

Het belangrijkste idee achter de module is dat je niet meer denkt in termen van één productlijst, maar dit vervangt door een aanbevelingsprofiel.

Het profiel is een aparte configuratie-entiteit. Het definieert:

• waar het moet werken,
• voor welke store en klantgroep het actief is,
• welk product als context moet dienen,
• wanneer het profiel moet starten,
• hoe kandidaten worden geselecteerd,
• hoe het resultaat wordt beperkt,
• hoe producten worden gesorteerd,
• hoe ze worden weergegeven,
• en of ze ook Magento’s native lijsten moeten voeden.

Vanuit implementatieperspectief is dit een duidelijke kwaliteitsverbetering. In plaats van voor elke placement aparte custom code te maken, kun je een set profielen bouwen die verschillende businessscenario’s afdekt. Dit model is makkelijker te onderhouden, eenvoudiger uit te breiden en veel leesbaarder voor teams die na de livegang met het project verder werken.

Waar de module echte meerwaarde biedt in implementaties

De meest voor de hand liggende plek is de productpagina. Juist daar willen we het vaakst producten tonen uit dezelfde collectie, met een vergelijkbare stijl of uit dezelfde communicatielijn. In de praktijk is de PDP echter zelden de enige plek waar aanbevelingen zinvol zijn.

De winkelwagen opent een heel ander scenario. Dit is niet langer het moment van inspiratie, maar een fase waarin je kunt werken aan een hogere winkelwagenwaarde. Hier werken profielen goed die accessoires, aanvullingen, goedkopere add-ons of producten uit een andere assortimentsbasis voorstellen, zolang ze maar aansluiten op wat de klant al heeft gekozen.

Checkout is een volgende fase die voorzichtigheid vraagt. Niet elke shop wil daar merchandising uitbreiden, maar voor sommige implementaties kan het een goede plek zijn voor een korte, eenvoudige productlijst die AOV ondersteunt, mits logica en rendering strak gecontroleerd blijven.

Daar houden de mogelijkheden van de module niet op. Een profiel kan ook Magento’s native blokken voeden:

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

Belangrijk is dat de integratie niet beperkt is tot simpelweg het vervangen van de lijst. Voor elk van deze mechanismen kun je bepalen of de profielresultaten aan de native producten moeten worden toegevoegd (append) of ze volledig moeten vervangen (replace). Voor agencies is dit erg praktisch, omdat de logica gefaseerd kan worden ingevoerd zonder meteen de hele shopervaring te herschrijven.

Hoe de modulogica werkt

Hoewel het profielformulier behoorlijk uitgebreid is, kan het werkingsmodel zelf vrij duidelijk worden beschreven. De module doorloopt telkens een aantal opeenvolgende stappen.

Eerst wordt de placement bepaald, dus de plek waar het profiel wordt uitgevoerd. Op de productpagina werkt andere logica dan in de winkelwagen. Daarna wordt het contextproduct gekozen. Op de PDP is dat meestal het huidige product, terwijl je in winkelwagen en checkout moet bepalen welk product uit de quote het referentiepunt wordt.

Zodra de module de context kent, controleert ze de activatievoorwaarden. Dit is het eerste filter en het beantwoordt de vraag: moet dit profiel in de huidige situatie überhaupt draaien?

Als de voorwaarden slagen, gaat de module door naar de matching rules. Daar vindt de eigenlijke matching plaats. Attributen van het contextproduct worden gekoppeld aan attributen van kandidaatproducten om producten te vinden uit dezelfde collectie, serie, grafische lijn, categorie of een andere businessrelevante eigenschap.

Na de matching kan het resultaat nog verder worden beperkt met statische targetfilters. Dit is een handige plek om de lijst te beperken tot specifieke producttypes, zichtbaarheid, statussen of zelfs geselecteerde productbasissen.

Tot slot worden de producten gesorteerd, teruggebracht tot de ingestelde limiet en gerenderd op een aparte plek in de layout of binnen Magento’s native blokken.

In de praktijk betekent dit dat de module niet steunt op één product-tot-productrelatie, maar op een reeks beslissingen die vanuit het adminpanel kunnen worden aangestuurd.

Een nieuw profiel aanmaken: hoe het werken met het formulier eruitziet

De grootste kracht van de module wordt pas echt zichtbaar wanneer je het profielformulier niet ziet als een lijst velden, maar als een hulpmiddel om een merchandisingscenario te modelleren.

Het proces begint met de algemene sectie. Name is de administratieve naam die het team helpt het profiel in het panel terug te vinden. Code is de technische identifier. Juist die waarde is zinvol om in logs, projectcommunicatie en implementatiedocumentatie te gebruiken. Enabled maakt het mogelijk een profiel snel uit te schakelen zonder de configuratie te verwijderen, en Sort Order bepaalt de volgorde waarin profielen binnen dezelfde placement worden geëvalueerd.

De tweede sectie gaat over het toepassingsbereik. Hier worden placements, store views en klantgroepen gekozen. Vanuit implementatieperspectief is dit erg belangrijk, omdat je hiermee één mechanisme kunt behouden en tegelijk gedrag kunt differentiëren tussen shops, talen of klantsegmenten.

Het veld Context Strategy is bijzonder belangrijk. Op de productpagina is het eenvoudig, omdat de module met het huidige product werkt. In de winkelwagen en checkout moet je echter bepalen welk quote-item als context dient. In de praktijk kan dat het eerste product zijn, het laatst toegevoegde product of het duurste product. Dit ogenschijnlijk kleine veld heeft een grote invloed op het eindresultaat, vooral in winkelwagens met meerdere verschillende items.

Met de velden From Date en To Date kun je een profiel beperken tot een bepaald tijdvenster. Daardoor kan dezelfde module ook seizoenscampagnes en kortlopende verkoopacties ondersteunen zonder extra schakelaars te bouwen.

Activation Conditions, Matching Rules en Target Product Filters

Precies deze drie secties zijn verantwoordelijk voor de businesslogica van de module.

Activation Conditions moeten worden gezien als de ingangslaag. Hier definiëren we wanneer een profiel überhaupt moet activeren. Als een profiel bijvoorbeeld alleen moet werken voor producten uit een bepaalde basis, van een bepaald merk of met een specifieke cataloguszichtbaarheid, dan horen die voorwaarden hier.

Matching Rules vormen het hart van het hele mechanisme. Ze dragen kenmerken van het contextproduct over naar de doelproducten. In de praktijk betekent dit dat je de module kunt vertellen: vind producten met dezelfde afbeelding, dezelfde collectie, dezelfde categorie of welk ander attribuut dan ook dat zakelijk relevant is.

Hier zijn twee velden bijzonder belangrijk: Required en Empty Value Policy.

Required bepaalt of een regel verplicht is. Als deze aanstaat, verwerpt een ontbrekende match de kandidaat. Als deze uitstaat, werkt de regel meer als een extra vernauwingslaag, maar blokkeert een mismatch niet het hele resultaat. In de praktijk is dit erg belangrijk in projecten waar de context op de PDP en in de winkelwagen anders kan zijn, bijvoorbeeld bij een configurable parent op de productpagina en een simple child in de quote.

Empty Value Policy vertelt de module wat ze moet doen wanneer het contextproduct geen waarde heeft in het bronattribuut. De regel kan worden overgeslagen, als mislukt worden beschouwd of met een standaardwaarde worden uitgevoerd. Dit veld bepaalt vaak of een profiel stabiel blijft in een complexe catalogus met verschillende producttypes.

Target Product Filters vormen de laatste vernauwingslaag. Ze werken niet langer op de relatie context-kandidaat, maar direct op de doelproducten. Dit is een goede plek om status, zichtbaarheid, producttype of een beperking tot geselecteerde assortimentsfamilies af te dwingen.

Sortering en presentatie

Vanuit implementatieperspectief is niet alleen belangrijk welke producten worden gevonden, maar ook in welke volgorde en in welke vorm ze worden getoond.

De module laat je een primair en secundair sorteerattribuut definiëren. Daarmee kun je beter voorspelbare lijsten opbouwen in plaats van alleen te vertrouwen op het standaardgedrag van de collectie.

Aan de presentatiekant zijn verschillende renderingsvarianten beschikbaar, waaronder grid, slider en compact. Zo kun je een lijst aanpassen aan de beschikbare ruimte op de pagina zonder aparte profieltypen te maken alleen om markup of visuele opmaak te wijzigen.

Het is ook belangrijk dat het profiel onafhankelijk elementen kan aansturen zoals:

• prijs,
• reguliere prijs,
• add-to-cartknop,
• productnaam,
• korte beschrijving,
• afbeeldingsrol.

In de praktijk betekent dit dat dezelfde aanbevelingsengine zowel voor uitgebreidere secties op de PDP als voor bescheidener lijsten in winkelwagen of checkout kan worden gebruikt.

Magento’s native lijsten voeden

Een van de interessantere kenmerken van de module is de mogelijkheid om Magento’s native blokken te voeden. Dit is vooral belangrijk voor agencies die de bestaande frontend niet meteen willen ombouwen of die werken aan projecten waarbij een deel van de shop nog steeds gebruikmaakt van klassieke related-, upsell- en crosssell-lijsten.

In zo’n scenario hoeft het profiel niet als apart blok te worden gerenderd. Het kan aan de native lijst worden gekoppeld en in een van twee modi werken.

De modus append laat de native producten staan en voegt daar de profielresultaten aan toe. Dit is een goede oplossing voor situaties waarin het e-commerce-team een deel van de handmatig ingestelde relaties wil behouden, maar tegelijk behoefte heeft aan een extra automatiseringslaag.

De modus replace gaat een stap verder en vervangt de native lijst volledig door de profielresultaten. Dit is vooral interessant voor shops die relaties niet langer handmatig willen beheren en verwachten dat profiellogica het belangrijkste aanbevelingsmechanisme wordt.

Deze architectuur biedt veel implementatieflexibiliteit. Je kunt de module gefaseerd invoeren, eerst de native lijsten uitbreiden en pas later de volledige controle overnemen.

XML als laag voor flexibele inbedding

Vanuit implementatieoogpunt is het belangrijk dat de module niet stopt bij de logica voor productselectie. Minstens zo belangrijk is de controle over de plek waar producten worden gerenderd.

Precies daarom bevat het profiel XML-velden die aan afzonderlijke placements zijn gekoppeld. Daarmee kan het profielresultaat in een specifieke container of onder een bepaald layoutblok worden ingebed, zonder een aparte module te bouwen alleen om de lijst op de juiste plaats te zetten.

In de praktijk is dit erg belangrijk bij het werken met custom thema’s. Elke frontend heeft zijn eigen layoutstructuur. Sommige thema’s verplaatsen de productbeschrijving naar een andere parent, andere bouwen eigen wrappers, en weer andere herstructureren Magento’s native productblokken bijna volledig. De mogelijkheid om placement via XML te sturen geeft hier een duidelijk voordeel.

Juist deze laag maakt de module niet alleen een aanbevelingsengine, maar ook een integratietool. Voor agencies betekent dit echte tijdswinst, omdat de manier van inbedding kan worden aangepast aan een concreet project zonder de kernlogica aan te tasten.

Voorbeeldscenario’s voor implementatie

Het eenvoudigste scenario is de klassieke aanbeveling "dezelfde collectie, andere basis". Een profiel kan activeren voor een product uit een bepaalde basis en op basis van matching rules producten vinden met dezelfde grafische lijn, maar die al tot een andere assortimentsfamilie behoren. Zo kan de shop sets promoten of de aankoop uitbreiden met extra producttypes zonder handmatige relaties op te bouwen.

Het tweede scenario zijn accessoires of aanvullingen in de winkelwagen. In dat geval kan de context het eerste of het duurste product uit de quote zijn, terwijl de target filters het eindresultaat beperken tot producten die logisch zijn als uitbreiding van de aankoop. Dit is vooral nuttig waar Magento’s standaard cross-sell onvoldoende controle biedt.

Het derde scenario bestaat uit seizoenscampagnes. Een profiel kan alleen draaien binnen een geselecteerd datumbereik, alleen voor specifieke store views en alleen voor geselecteerde klantgroepen. Vanuit het perspectief van het implementatieteam betekent dit dat de campagne binnen hetzelfde mechanisme kan worden gebouwd, zonder een aparte promotiemodule te maken.

Het vierde scenario is een gedeeltelijke of volledige vervanging van native upsells. Dit is vooral interessant voor shops met een groot assortiment, veel cataloguskenmerken en zonder de wens om handmatige productrelaties te onderhouden.

Waarom deze aanpak goed schaalt in projectonderhoud

Voor agencies is de belangrijkste vraag niet alleen "werkt het?", maar ook "is het over een half jaar nog onderhoudbaar?".

Juist hier heeft de profielgebaseerde aanpak het grootste voordeel. De logica ligt niet verspreid over aparte observers, plugins en dedicated classes voor individuele gevallen. In plaats daarvan is er één configuratiemodel en één aanbevelingsengine die laag voor laag kan worden uitgebreid.

Deze opzet biedt verschillende voordelen:

• het is eenvoudiger om het project over te dragen voor onderhoud,
• het is eenvoudiger om nieuwe scenario’s toe te voegen zonder bestaande te herschrijven,
• het is eenvoudiger om profielgedrag te diagnosticeren omdat de logica op één plek geconcentreerd is,
• het is eenvoudiger om met custom frontends te werken dankzij de XML-laag,
• het is eenvoudiger om zakelijke beslissingen te scheiden van implementatiedetails.

In de praktijk betekent dit dat de module een agency niet alleen nieuwe mogelijkheden geeft tijdens de implementatiefase, maar ook een verstandige basis voor de verdere ontwikkeling van het project.

Samenvatting

Kowal_RelatedProductsProfiles is niet alleen een mechanisme om nog een productlijst op een pagina te tonen. Het is een tool voor het ontwerpen van aanbevelingsscenario’s in Magento 2.

Voor implementatieteams en agencies zijn vooral drie dingen belangrijk. Ten eerste maakt de module het mogelijk aanbevelingslogica op te bouwen rond profielen in plaats van eenmalige uitzonderingen. Ten tweede geeft ze controle over placement, context, productselectie en rendering. Ten derde past ze goed bij echte projectsituaties, waarin zakelijke verwachtingen, beperkingen van het thema en de behoefte aan verdere groei van de shop met elkaar moeten worden verzoend.

Als een project meer nodig heeft dan eenvoudige handmatig gekoppelde productrelaties, biedt dit model veel meer vrijheid dan de standaardmechanismen van Magento. En precies daarin zit de grootste waarde.