Raccomandazioni prodotto dinamiche in Magento 2: profili al posto di relazioni rigide

In molti progetti Magento 2 il tema delle raccomandazioni prodotto parte da un presupposto semplice: bisogna mostrare al cliente alcuni prodotti aggiuntivi nella pagina prodotto, nel carrello oppure durante il checkout. Il problema emerge molto in fretta. I meccanismi standard related, upsell e cross-sell di Magento sono utili, ma nella pratica spesso si rivelano troppo rigidi rispetto alle reali esigenze di implementazione.

Un negozio, infatti, non vuole mostrare gli stessi prodotti in ogni punto e in ogni situazione. Serve uno scenario per un prodotto semplice, un altro per un configurable, un altro ancora per una campagna stagionale e un altro per un carrello che contiene più prodotti diversi. Dal punto di vista delle agenzie e dei team di implementazione, questo di solito significa una cosa sola: iniziano ad accumularsi eccezioni, condizioni custom e ulteriori livelli di codice sempre più difficili da mantenere.

Kowal_RelatedProductsProfiles è stato progettato proprio per risolvere questo problema in modo diverso. Invece di costruire la logica attorno a singole relazioni prodotto-prodotto collegate manualmente, il modulo introduce il concetto di profilo di raccomandazione. È il profilo a definire dove deve funzionare, a quali condizioni deve attivarsi, come selezionare i prodotti e come renderizzarli. In questo modo le raccomandazioni diventano un livello configurabile, non l’ennesimo insieme di eccezioni una tantum nascoste nel codice del progetto.

Il modulo è disponibile qui: Automatic related products for Magento 2.

Perché le liste standard di Magento spesso non bastano

Le liste native related, upsell e cross-sell funzionano bene nei negozi semplici o nei contesti in cui il merchandising è gestito manualmente dal team e-commerce. Nelle implementazioni reali, però, emergono rapidamente scenari che il modello standard non copre:

• mostrare raccomandazioni solo per un gruppo clienti selezionato,
• attivare una lista specifica solo in un determinato intervallo di date,
• collegare i prodotti in base agli attributi di catalogo e non a relazioni manuali,
• comportamenti diversi sulla PDP, nel carrello e nel checkout,
• inserire una lista in un punto preciso del layout del tema senza riscrivere tutta la view,
• sostituire parzialmente o completamente le liste native di Magento con logiche di progetto.

Per le agenzie questo significa in genere due problemi. Primo, il meccanismo standard deve essere esteso con condizioni aggiuntive. Secondo, ogni nuova esigenza di business comincia a generare un’eccezione separata. A un certo punto, al posto di un meccanismo coerente di raccomandazione, si ottiene un insieme di workaround scollegati tra loro.

I profili come livello di logica merchandising

L’idea più importante del modulo è abbandonare il modo di pensare in termini di singola lista prodotti e sostituirlo con un profilo di raccomandazione.

Il profilo è un’entità di configurazione separata. Definisce:

• dove deve funzionare,
• per quale store e gruppo clienti è attivo,
• quale prodotto deve fare da contesto,
• quando il profilo deve attivarsi,
• come selezionare i candidati,
• come restringere il risultato,
• come ordinare i prodotti,
• come mostrarli,
• e se devono alimentare anche le liste native di Magento.

Dal punto di vista implementativo, questo è un cambiamento qualitativo importante. Invece di preparare custom code separato per ogni placement, si può costruire un insieme di profili che rispondano a diversi scenari di business. Questo modello è più facile da mantenere, più semplice da estendere e molto più leggibile per i team che lavoreranno sul progetto dopo il go-live.

Dove il modulo offre un vantaggio reale nelle implementazioni

Il punto di utilizzo più ovvio è la pagina prodotto. È proprio lì che più spesso vogliamo mostrare prodotti della stessa collezione, con uno stile simile o appartenenti alla stessa linea di comunicazione. Nella pratica, però, la PDP raramente è l’unico punto in cui le raccomandazioni hanno senso.

Il carrello apre uno scenario completamente diverso. Non è più il momento dell’ispirazione, ma una fase in cui si può lavorare per aumentare il valore del carrello. Qui funzionano bene i profili che suggeriscono accessori, complementi, aggiunte più economiche oppure prodotti provenienti da un’altra base assortimentale, ma comunque collegati a ciò che il cliente ha già scelto.

Il checkout è un’altra fase che richiede cautela. Non tutti i negozi vogliono sviluppare il merchandising in quel punto, ma per alcune implementazioni può essere un buon posto per una lista breve e semplice di prodotti che supporti l’AOV, a condizione che logica e rendering siano molto controllati.

Ma le possibilità del modulo non finiscono qui. Un profilo può anche alimentare i blocchi nativi di Magento:

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

È importante sottolineare che l’integrazione non si limita a una semplice sostituzione della lista. Per ciascuno di questi meccanismi si può decidere se i risultati del profilo debbano essere aggiunti ai prodotti nativi (append) oppure sostituirli completamente (replace). Per le agenzie questo è molto pratico, perché consente di introdurre la logica per fasi senza dover riscrivere subito l’intera esperienza d’acquisto.

Come funziona la logica del modulo

Sebbene il form del profilo sia piuttosto esteso, il modello di funzionamento può essere descritto in modo chiaro. Ogni volta il modulo passa attraverso diverse fasi consecutive.

Per prima cosa viene determinato il placement, cioè il punto in cui il profilo viene eseguito. Una logica funziona nella pagina prodotto, un’altra nel carrello. Successivamente viene selezionato il prodotto di contesto. Nella PDP di solito è il prodotto corrente, mentre nel carrello e nel checkout bisogna decidere quale prodotto del quote diventa il punto di riferimento.

Una volta definito il contesto, il modulo verifica le condizioni di attivazione. Questo è il primo filtro e risponde alla domanda: questo profilo deve davvero attivarsi nella situazione corrente?

Se le condizioni vengono superate, il modulo passa alle matching rules. È qui che avviene il vero matching. Gli attributi del prodotto di contesto vengono mappati sugli attributi dei prodotti candidati, in modo da trovare prodotti della stessa collezione, serie, grafica, categoria o di qualsiasi altra caratteristica rilevante dal punto di vista del business.

Dopo il matching, il risultato può ancora essere ristretto tramite filtri statici sui prodotti target. È un punto comodo per limitare la lista a specifici tipi di prodotto, visibilità, stati o persino a determinate basi prodotto.

Alla fine, i prodotti vengono ordinati, tagliati al limite previsto e renderizzati in una posizione separata del layout oppure all’interno dei blocchi nativi di Magento.

In pratica, questo significa che il modulo non si basa su una singola relazione prodotto-prodotto, ma su una sequenza di decisioni controllabili dal pannello di amministrazione.

Creare un nuovo profilo: come si lavora con il form

La forza più grande del modulo emerge davvero quando si guarda il form del profilo non come una lista di campi, ma come uno strumento per modellare uno scenario di merchandising.

Il processo inizia dalla sezione generale. Name è il nome amministrativo che aiuta il team a trovare il profilo nel pannello. Code è l’identificatore tecnico. È proprio questo valore che conviene usare nei log, nella comunicazione di progetto e nella documentazione di implementazione. Enabled permette di disattivare rapidamente un profilo senza cancellarne la configurazione, mentre Sort Order decide l’ordine con cui i profili vengono valutati all’interno dello stesso placement.

La seconda sezione riguarda il perimetro di funzionamento. Qui si selezionano placement, store view e gruppi clienti. Dal punto di vista implementativo è molto importante, perché consente di mantenere un solo meccanismo differenziando comunque il comportamento tra negozi, lingue o segmenti di clientela.

Il campo Context Strategy è particolarmente importante. Nella pagina prodotto la questione è semplice, perché il modulo lavora sul prodotto corrente. Nel carrello e nel checkout, invece, bisogna definire quale elemento del quote diventa il contesto. In pratica può essere il primo prodotto, l’ultimo aggiunto o il prodotto con il prezzo più alto. Questo campo apparentemente piccolo ha un impatto enorme sul risultato finale, soprattutto nei carrelli che contengono più articoli diversi.

I campi From Date e To Date permettono di limitare un profilo a una finestra temporale definita. Grazie a questo, lo stesso modulo può gestire anche campagne stagionali e azioni commerciali di breve durata senza aggiungere interruttori separati.

Activation Conditions, Matching Rules e Target Product Filters

Sono proprio queste tre sezioni a gestire la logica di business del modulo.

Activation Conditions vanno trattate come il livello di ingresso. Qui definiamo quando un profilo deve attivarsi davvero. Se, per esempio, un profilo deve funzionare solo per prodotti di una certa base, marca o visibilità di catalogo, queste condizioni vanno impostate qui.

Matching Rules sono il cuore dell’intero meccanismo. Trasferiscono le caratteristiche del prodotto di contesto ai prodotti target. In pratica significa che si può dire al modulo: trova prodotti che abbiano la stessa grafica, la stessa collezione, la stessa categoria oppure qualsiasi altro attributo che abbia senso dal punto di vista del business.

Qui sono particolarmente importanti due campi: Required e Empty Value Policy.

Required decide se una determinata regola è obbligatoria. Se è attivo, la mancanza di corrispondenza scarta il candidato. Se è disattivo, la regola funziona più come un ulteriore livello di restringimento, ma un mismatch non blocca tutto il risultato. Nella pratica questo è molto importante nei progetti in cui il contesto sulla PDP e nel carrello può apparire diverso, per esempio con un configurable parent nella pagina prodotto e un simple child nel quote.

Empty Value Policy indica al modulo cosa fare quando il prodotto di contesto non ha un valore nell’attributo sorgente. La regola può essere saltata, considerata fallita oppure eseguita usando un valore predefinito. Questo campo spesso decide se un profilo resterà stabile in un catalogo complesso con diversi tipi di prodotto.

Target Product Filters sono l’ultimo livello di restringimento. Non lavorano più sulla relazione contesto-candidato, ma direttamente sui prodotti target. È un buon punto per imporre stato, visibilità, tipo di prodotto o limitare il risultato a specifiche famiglie assortimentali.

Ordinamento e modalità di presentazione

Dal punto di vista implementativo conta non solo quali prodotti vengono trovati, ma anche in quale ordine e in quale forma vengono mostrati.

Il modulo consente di definire un attributo di ordinamento principale e uno secondario. In questo modo si possono costruire liste più prevedibili, invece di affidarsi soltanto al comportamento standard della collection.

Sul lato della presentazione sono disponibili diverse varianti di rendering, tra cui grid, slider e compact. Questo permette di adattare la lista allo spazio disponibile nella pagina senza creare tipi di profilo separati solo per cambiare markup o disposizione visiva.

È importante anche che il profilo possa controllare in modo indipendente elementi come:

• prezzo,
• prezzo regolare,
• pulsante di aggiunta al carrello,
• nome del prodotto,
• descrizione breve,
• ruolo dell’immagine.

In pratica, questo significa che lo stesso motore di raccomandazione può essere usato sia per sezioni più ricche nella PDP sia per liste più essenziali nel carrello o nel checkout.

Alimentare le liste native di Magento

Una delle caratteristiche più interessanti del modulo è la possibilità di alimentare i blocchi nativi di Magento. È particolarmente importante per le agenzie che non vogliono ricostruire subito il frontend esistente oppure che lavorano su progetti in cui una parte dello store usa ancora le classiche liste related, upsell e crosssell.

In questo scenario, il profilo non deve essere renderizzato come blocco separato. Può essere collegato alla lista nativa e funzionare in una delle due modalità disponibili.

La modalità append lascia i prodotti nativi e aggiunge a essi i risultati del profilo. È una buona soluzione nei casi in cui il team e-commerce voglia ancora mantenere una parte delle relazioni impostate manualmente, ma allo stesso tempo abbia bisogno di un ulteriore livello di automazione.

La modalità replace va oltre e sostituisce completamente la lista nativa con i risultati del profilo. È un’opzione particolarmente interessante per i negozi che non vogliono più gestire relazioni manuali e si aspettano che la logica dei profili diventi il principale meccanismo di raccomandazione.

Questa architettura offre molta flessibilità implementativa. Si può introdurre il modulo gradualmente, prima estendendo le liste native e solo in seguito assumendo il controllo completo.

XML come livello di integrazione flessibile

Dal punto di vista dell’implementazione è molto importante che il modulo non si fermi alla logica di selezione dei prodotti. È altrettanto importante il controllo sul punto in cui vengono renderizzati.

È proprio per questo che il profilo include campi XML assegnati ai singoli placement. Consentono di inserire il risultato del profilo in un contenitore specifico o sotto un determinato blocco di layout, senza costruire un modulo separato solo per posizionare la lista nel punto desiderato.

Nella pratica questo è fondamentale quando si lavora con temi personalizzati. Ogni frontend ha una propria struttura di layout. Alcuni temi spostano la descrizione prodotto in un altro parent, altri costruiscono wrapper propri, altri ancora ricostruiscono quasi completamente i blocchi prodotto nativi di Magento. La possibilità di controllare il placement tramite XML offre qui un grande vantaggio.

È proprio questo livello a fare del modulo non solo un motore di raccomandazione, ma anche uno strumento di integrazione. Per le agenzie significa un concreto risparmio di tempo, perché il modo di inserimento può essere adattato al progetto specifico senza toccare la logica principale.

Esempi di scenari implementativi

Lo scenario più semplice è la classica raccomandazione "stessa collezione, base diversa". Un profilo può attivarsi per un prodotto di una determinata base e, attraverso le matching rules, trovare prodotti con la stessa grafica ma appartenenti a un’altra famiglia assortimentale. In questo modo il negozio può promuovere set o ampliare l’acquisto con altri tipi di prodotto senza costruire relazioni manuali.

Il secondo scenario riguarda accessori o complementi nel carrello. In questo caso, il contesto può essere il primo prodotto o quello con il prezzo più alto nel quote, e i target filters restringono il risultato finale a prodotti che abbiano senso come estensione dell’acquisto. Questo è particolarmente utile dove il cross-sell standard di Magento non offre un controllo sufficiente.

Il terzo scenario riguarda le campagne stagionali. Un profilo può funzionare solo in un intervallo di date selezionato, solo per specifiche store view e solo per determinati gruppi clienti. Dal punto di vista del team di implementazione, questo significa che la campagna può essere costruita all’interno dello stesso meccanismo, senza sviluppare un modulo promozionale separato.

Il quarto scenario è la sostituzione parziale o totale degli upsell nativi. È particolarmente interessante per negozi con molto assortimento, molte caratteristiche di catalogo e senza la volontà di mantenere relazioni manuali tra prodotti.

Perché questo approccio scala bene nella manutenzione del progetto

Per le agenzie, la domanda più importante non è solo "funziona?", ma anche "sarà gestibile tra sei mesi?".

Ed è proprio qui che l’approccio basato sui profili mostra il suo vantaggio più grande. La logica non è sparsa tra observer separati, plugin e classi dedicate a singoli casi. Al contrario, esiste un unico modello di configurazione e un unico motore di raccomandazione che può essere sviluppato per livelli.

Questa impostazione offre diversi vantaggi:

• è più facile consegnare il progetto al team di manutenzione,
• è più facile aggiungere nuovi scenari senza riscrivere quelli esistenti,
• è più facile diagnosticare il comportamento dei profili perché la logica è concentrata in un solo punto,
• è più facile lavorare con frontend personalizzati grazie al livello XML,
• è più facile separare le decisioni di business dai dettagli implementativi.

In pratica, questo significa che il modulo offre a un’agenzia non solo nuove possibilità nella fase di implementazione, ma anche una base sensata per lo sviluppo futuro del progetto.

Riepilogo

Kowal_RelatedProductsProfiles non è solo un meccanismo per mostrare un’altra lista di prodotti su una pagina. È uno strumento per progettare scenari di raccomandazione in Magento 2.

Per i team di implementazione e per le agenzie contano soprattutto tre aspetti. Primo, il modulo permette di costruire la logica di raccomandazione attorno ai profili invece che attorno a eccezioni una tantum. Secondo, offre controllo su placement, contesto, selezione dei prodotti e rendering. Terzo, si adatta bene alla realtà dei progetti, dove bisogna conciliare aspettative di business, limiti del tema e necessità di evolvere ulteriormente lo store.

Se un progetto richiede più di semplici relazioni prodotto impostate manualmente, questo modello offre molta più libertà rispetto ai meccanismi standard di Magento. Ed è proprio qui che sta il suo valore più grande.