Atto IV: L'incastro
Portare un peso che Shopify avrebbe dovuto togliere
Un’ora o due dopo l’inizio del workshop di discovery, dopo le domande sul carrello e quelle sul catalogo e la lunga divagazione su come dovrebbero funzionare i resi, la conversazione arriva a search e merchandising, e la stanza risponde quasi prima che la domanda abbia finito di uscire dalla bocca di chiunque. Aggiungiamo Algolia. Lo si dice come si nomina una cosa ovvia—come diresti che porterai l’ombrello perché piove. Tutti annuiscono. Qualcuno lo scrive sulla lavagna. L’Head of Digital, che ha sentito un’ottima presentazione di un vendor circa tre settimane fa e aspettava un pretesto per pronunciare quel nome ad alta voce, prova una piccola soddisfazione privata nell’avere la risposta già pronta.
Nessuno nella stanza ha torto, esattamente. Algolia è un prodotto serio costruito da persone serie, e i brand che lo gestiscono bene ci fanno cose vere. Ma nessuno si è chiesto cosa significhi davvero aggiungere Algolia su Shopify, e lo scarto tra come suona quella frase in un workshop e in cosa si trasforma in un codebase è l’intero argomento di questo capitolo. La frase suona come installare un’app. Non è installare un’app. Ci arriveremo. Prima dobbiamo essere onesti sulla cosa da cui la stanza sta cercando di scappare, perché il riflesso di scappare è ragionevole, e la piattaforma quel riflesso se l’è guadagnato in modo legittimo.
Lo stack nativo di search e merchandising di Shopify è più capace di quanto la maggior parte dei brand si aspetti—e meno capace di quanto la maggior parte dei brand enterprise abbia bisogno. Entrambe le metà di questa frase sono vere nello stesso momento, e tenerle insieme è l’unico modo per prendere una buona decisione qui. I brand che sbagliano questa cosa la sbagliano perché credono a una sola metà. Quelli che credono solo alla prima metà fanno il deploy del nativo, sbattono contro un muro al quarto mese e ci appiccicano sopra un vendor nel panico. Quelli che credono solo alla seconda metà—e l’Head of Digital con la presentazione fresca del vendor è in pieno in questa categoria—saltano del tutto lo stack nativo, dando per scontato che un brand enterprise abbia ovviamente bisogno di search enterprise, e pagano per un workaround a un problema che forse non avevano.
Quindi, prima che qualcuno aggiunga qualcosa, vale la pena sapere con precisione cos’è lo stack nativo, perché è proprio nella precisione che vivono le sorprese. Ha tre livelli, e ognuno ha un soffitto reale che vale la pena nominare per nome.
Il primo livello sono le Collections, che esistono in due varianti. Le collection manuali sono esattamente ciò che il nome suggerisce: ci metti i prodotti a mano, li trascini nell’ordine che vuoi, fatto. Le smart collection si costruiscono da sole a partire da condizioni—il tag è uguale a regalo, il prezzo è sotto i quaranta, il tipo è olio d’oliva—e si mantengono aggiornate man mano che il catalogo cambia. È nelle smart collection che vive il primo soffitto, ed è basso. Le condizioni si combinano con AND, oppure si combinano con OR, ma mai entrambi nella stessa collection; non c’è annidamento, nessun queste due insieme e anche questa terza cosa. Non c’è il NOT—non puoi dire tutto in questa categoria tranne la linea fuori produzione. E una smart collection può decidere cosa ci entra, ma non può decidere in che ordine le cose escono al di là di una manciata di ordinamenti preimpostati. Filtrare, sì. Riordinare secondo una tua logica, no. Per un brand la cui strategia di merchandising è a novembre metti per primi i gift set ad alto margine, quell’ultima limitazione non è una nota a piè di pagina. È tutto il lavoro, e la piattaforma non lo fa.
Il secondo livello è Search & Discovery, ed è il pezzo più sottovalutato dello stack nativo—sottovalutato soprattutto perché le persone che si lanciano su Algolia hanno smesso di valutare la search di Shopify intorno al 2021 e non ci sono più tornate. È diventata silenziosamente buona. La search semantica funziona out of the box ora, il che significa che chi cerca qualcosa per mio padre che ama il piccante arriva all’olio al peperoncino senza che nessuno abbia mai taggato l’olio al peperoncino con la parola padre. L’autocomplete fa emergere prodotti e collection e articoli del blog e query suggerite tutti insieme, in un unico menu a tendina, configurato anziché programmato. Le faccette dei filtri si costruiscono dai tuoi metafield e metaobject e—questo conta più di quanto sembri—funzionano nativamente su più lingue, così i filtri dello storefront tedesco sono in tedesco senza una pipeline di traduzione di cui devi farti carico. Un numero sorprendente di brand che pensano di aver bisogno di un vendor di search hanno invece bisogno di passare un pomeriggio a configurare davvero Search & Discovery, prima di tutto. Alcuni di loro, dopo quel pomeriggio, scoprono di aver finito.
Ma non tutti, perché qui i soffitti nativi sono reali, e sono esattamente i soffitti contro cui sbatte un catalogo enterprise. I sinonimi sono solo equivalenze: puoi dire al motore che sneaker e scarpa da ginnastica significano la stessa cosa, il che è bidirezionale, ma non puoi dire una ricerca di “regalo” dovrebbe far emergere anche “gift set”, ma non il contrario—non c’è mappatura unidirezionale, nessun peso asimmetrico. La personalizzazione è zero; il motore mostra gli stessi risultati al cliente fedele e al visitatore alla prima volta, e non fa alcun uso di quello che ciascuno ha fatto prima. Le analytics sono scarne—puoi vedere cosa hanno cercato le persone, ma il cerchio che va da cosa hanno cercato a cosa dovresti cambiare sei perlopiù tu a doverlo costruire a mano. E la Recommendations API, il terzo livello, ti dà prodotti correlati e complementari calcolati a partire dalle relazioni del catalogo e dallo storico ordini, ma non ha alcun concetto di contesto: non può guardare cosa c’è nel carrello in questo momento e raccomandare di conseguenza. Raccomanda in base al prodotto, non al momento. Per un brand la cui intera strategia di upsell è cosa si abbina a quello che è già nel cestino, quella è la differenza tra una feature e una decorazione.
Adesso possiamo dire chiaramente cosa stava vendendo davvero il vendor dell’Head of Digital, e perché il workaround esista affatto. Perché ecco la cosa che la conversazione del workshop non raggiunge mai, e la cosa che determina tutto ciò che viene a valle: Shopify non ha alcun hook server-side per fare l’override dei risultati di ricerca o dell’ordinamento delle collection a livello di piattaforma. Non c’è alcun punto, nella richiesta, prima che la pagina venga renderizzata, in cui il tuo codice possa dire per questa query, restituisci questi prodotti in quest’ordine. Decide la piattaforma; a te non tocca il turno.
Fermati su questo, perché è la radice dell’intera situazione e il vincolo dà forma a tutto ciò che riguarda il funzionamento dell’integrazione nella pratica. Ogni vendor di search enterprise su Shopify—Algolia, Nosto, Constructor, l’intera categoria—è un workaround client-side travestito. Non possono vivere dove la search avviene davvero, perché Shopify non lascia vivere niente lì. Quindi vivono accanto: uno strato JavaScript parallelo che si carica nel browser, intercetta la query dello shopper prima che raggiunga Shopify, la manda all’indice del vendor stesso, ne ottiene i risultati del vendor stesso e li dipinge sopra la pagina che Shopify stava per renderizzare. La pagina di collection che hai impostato nel theme editor è, in questi setup, in parte o del tutto sostituita a runtime da markup di cui il theme editor non ha mai sentito parlare. La search vive fuori dal tema. Spesso vive anche fuori dalle normali superfici dell’ecosistema delle app. È un secondo storefront, che indossa i vestiti del tuo primo storefront, cucito addosso nel browser dove Shopify non può obiettare.
I vendor non sbagliano a fare così. Mettiamolo in chiaro, perché sarebbe facile leggere tutto questo come i vendor sono cattivi, e non è questo l’argomento. Stanno risolvendo un problema reale—merchandising e rilevanza enterprise che lo stack nativo davvero non riesce a fornire—con gli unici primitivi che Shopify mette a disposizione, che sono primitivi pessimi per il lavoro. Non hanno scelto l’architettura client-side per pigrizia. L’hanno scelta perché è l’unica porta che non è chiusa a chiave. Il peso che portano è un peso che Shopify avrebbe dovuto togliere ormai, esponendo un hook server-side, e non l’ha fatto. Finché non lo farà, i vendor continueranno a portarlo, e così farai anche tu, perché una volta che quello strato parallelo è nel tuo storefront è tuo da mantenere, debuggare e riconciliare con ogni modifica al tema per tutto il tempo in cui resta lì.
C’è un prodotto in questa categoria che non funziona così, e vale la pena nominarlo per la stessa ragione per cui vale la pena nominare gli altri: la specificità è l’unico modo onesto di avere questa conversazione. Depict è l’eccezione. Invece di tirare su uno storefront parallelo client-side, lavora dentro il modello di rendering nativo di Shopify—applica regole di merchandising alle collection di Shopify stesse, riordinando i prodotti nella collection che Shopify renderizzerà comunque, anziché sostituire il rendering in blocco. La conseguenza pratica è grande: il fardello di integrazione che definisce il resto della categoria perlopiù sparisce. Le tue pagine di collection sono ancora pagine di Shopify. Il tuo tema ne è ancora padrone. Non c’è un secondo storefront dipinto sopra il primo, nessun indice parallelo che possa divergere, nessun SDK nel percorso critico che decide in silenzio il tuo Largest Contentful Paint.
Il prezzo di questa grazia è che Depict fa di meno. È uno strato di merchandising, non un motore di ricerca—rende più intelligenti le collection di Shopify, ma non porta in tavola search semantica guidata dal machine learning né personalizzazione comportamentale, perché quelle cose richiedono esattamente l’architettura a indice parallelo che ha scelto di non costruire. Quindi non è tanto un concorrente dei vendor pesanti quanto una risposta diversa a una domanda diversa. Se il tuo gap è non riesco a fare il merchandising delle mie collection come mi serve, Depict lo chiude in modo economico e pulito. Se il tuo gap è la rilevanza della mia search è un problema di fatturato e mi serve un vero motore, Depict non è lo strumento, e ti ritrovi di nuovo in mezzo ai vendor client-side, a portare il peso, perché è lì che il peso al momento deve essere portato.
Il che ci dà, finalmente, la decisione—e va nella direzione opposta rispetto al workshop. Il workshop ragiona così: brand enterprise, quindi search enterprise. La decisione va dall’altra parte, dal basso verso l’alto, e ha tre passaggi.
Primo, esaurisci Search & Discovery. Esauriscilo davvero—siediti, configura la search semantica, costruisci le faccette dai tuoi metafield, imposta i sinonimi che puoi, e fai il deploy. Convivici su un catalogo reale con traffico reale abbastanza a lungo da sapere dove fallisce davvero per i tuoi shopper, non dove la presentazione di un vendor dice che fallisce in generale. Una quota significativa di brand si ferma qui e fa bene a farlo.
Secondo, se il punto in cui fallisce è la gestione delle collection—se la cosa che non riesci a fare è il merchandising che la tua strategia richiede, ma la rilevanza della tua search va sostanzialmente bene—allora lanciati su uno strato in stile Depict che lavora dentro il modello nativo. Ottieni il controllo del merchandising senza comprarti l’intera tassa d’integrazione.
Terzo, e solo come terzo, vai sulla search enterprise completa—e vacci solo quando i requisiti sono reali e al presente. Non un giorno potremmo volere la personalizzazione. Al presente significa: stai gestendo davvero più mercati e ti serve una rilevanza tarata per mercato; hai un team che si farà carico della dashboard di merchandising come un lavoro vero, non come una cosa che qualcuno tocca due volte l’anno; e la rilevanza della search è dimostrabilmente un problema di fatturato che puoi indicare nelle analytics, non una sensazione. Lanciati sul vendor pesante perché il gap è reale, qui, adesso—non come assicurazione contro ipotetici bisogni futuri. È così che integrazioni costose ottengono il via libera su assunzioni che non si materializzano mai, e a questo punto hai sentito che tipo di errore sia: il requisito che erediti non è sempre il requisito che hai, e il requisito che un vendor ti lusinga a immaginare non è affatto un requisito che hai finché le analytics non lo dicono.
La ragione per cui tutto questo merita un capitolo—la ragione per cui non è semplicemente leggi la documentazione e scegli uno strumento—è che il costo è cambiato. Su uno storefront piccolo, uno strato di search client-side è un’indulgenza gestibile; il traffico è modesto, il catalogo è piccolo, la manutenzione è il martedì di qualcuno. Su scala enterprise, lo stesso workaround è una voce di costo fissa con un proprietario fisso e un budget di performance fisso, e i workaround che gli storefront più semplici riuscivano ad assorbire in silenzio adesso compaiono nelle conversazioni sul ROI della piattaforma—il CFO che chiede, due anni dopo, perché la cosa che doveva semplificare lo stack ci ha aggiunto un vendor, una pipeline e un secondo sistema di merchandising che nessuno fuori dal team digital sa usare.
Quindi la domanda da portarsi fuori dal workshop non è quella su cui la stanza si è lanciata. Non è quale vendor ha il miglior set di feature. È se la tua organizzazione ha il business case, il team e la chiarezza architetturale per assorbire un workaround che la piattaforma avrebbe ormai dovuto rendere superfluo—e se, prima di firmare per la sua versione più pesante, hai passato il pomeriggio economico a scoprire quanta parte del tuo problema di search Shopify già risolve. Quel pomeriggio te lo devi. Il vendor sarà ancora lì dopo pranzo.