Nel corso degli anni, progettando e gestendo storefront su Adobe Commerce, ho imparato a diffidare degli annunci che promettono di cambiare le regole. Ma quello che Adobe ha portato sul palco del Summit di marzo mi ha fatto rizzare le antenne, perché tocca due nervi scoperti di chi vende online oggi: la performance dello storefront e il vincolo al backend commerce. Parlo di Adobe Commerce Optimizer e degli Edge Delivery Services. Provo a spiegare cosa promettono e, soprattutto, cosa ne penso da consulente che con questa piattaforma ci lavora tutti i giorni.
Cosa promette Adobe Commerce Optimizer
Il punto che mi ha colpito è la premessa. Storicamente, se volevi il layer di storefront e catalogo di Adobe, dovevi avere Adobe Commerce come motore transazionale sotto. Punto. Commerce Optimizer, così com’è stato presentato, rompe questa dipendenza: è un layer di merchandising e discovery pensato per stare sopra un backend anche di terze parti. Nei materiali Adobe si citano esplicitamente scenari con motori commerce non Adobe, tipo SAP o Salesforce, sotto il cofano.
In pratica il valore che Adobe vuole portare non è più “l’intero commerce engine”, ma i pezzi in cui è forte da anni: il catalog service, la ricerca, le regole di merchandising, la personalizzazione data-driven, sempre più assistita da AI. Tu tieni il tuo backend con la sua logica di prezzo, stock e ordini, e appoggi sopra il layer di catalogo e storefront di Adobe per far vedere e vendere i prodotti.
In una riga: Adobe Commerce Optimizer è un layer di storefront, catalogo e merchandising AI progettato per funzionare anche su un backend commerce di terze parti, non solo su Adobe Commerce. Chi conosce l’ecosistema capisce subito che è un cambio di postura, non una feature in più.
E qui aggiungo subito la parte che nelle slide non c’è, perché è la lezione che mi porto dietro da ogni progetto di merchandising: un layer AI sopra un catalogo disordinato non mette ordine, amplifica il disordine. Attributi incoerenti, tassonomie stratificate da tre replatforming, regole di prezzo che si contraddicono: se il dato sotto è sporco, la personalizzazione “intelligente” ti serve in vetrina prodotti sbagliati, solo più in fretta. Il layer moltiplica il valore se chi lo governa ha catalogo, attributi e regole in ordine. Senza quello, moltiplica il rumore.
Edge Delivery Services: la parte che i merchant sentono davvero
La seconda gamba sono gli Edge Delivery Services. Qui il tema è puramente tecnico ma con conseguenze molto commerciali: servire le pagine dello storefront da edge, ottimizzate per i Core Web Vitals, con l’obiettivo dichiarato di Lighthouse score alti “di default”. Chi ha passato notti a spremere millisecondi da un tema Luma o da un PWA capisce di cosa parlo.
La promessa è duplice. Da un lato la performance: pagine che caricano più in fretta, meno abbandoni, checkout più fluido. Dall’altro la SEO: HTML pulito, tempi di risposta bassi, content authoring che passa anche da strumenti tipo documenti, con la parte tecnica gestita dalla piattaforma. Per un merchant mid-market, dove spesso non c’è un team frontend dedicato, questo è il genere di cosa che sposta i numeri veri, non le slide.
In sostanza gli Edge Delivery Services puntano a garantire performance e SEO dello storefront a livello di infrastruttura, riducendo il lavoro custom di ottimizzazione frontend. Che poi è quello che succede da sempre quando un problema smette di essere un mestiere artigianale e diventa una proprietà della piattaforma.
Perché è una mossa che apre Adobe oltre i suoi confini
Qui arrivo alla mia lettura. Per come la vedo io, questa non è una feature: è una scelta strategica di posizionamento. Adobe smette di dire “vieni tutto da me” e comincia a dire “prendi il pezzo dove sono più forte, il resto tienilo dove ce l’hai”.
È un cambio importante, e non nasce dal nulla. Il mercato si è spostato verso il composable commerce: aziende che non vogliono più il monolite unico ma componenti best-of-breed collegati via API. In questo mondo, un vendor che pretende di essere l’intero stack perde clienti che hanno già investito parecchio in un ERP o in un OMS che non toccheranno. Aprendo Commerce Optimizer a backend di terzi, Adobe si mette in una posizione dove può entrare in aziende che non avrebbe mai preso col commerce engine completo. Vende il layer dove eccelle, e mette un piede in casa del cliente.
La mia opinione, senza giri: è la mossa giusta, e arriva nel momento giusto. Le architetture ibride le vedo ormai in quasi ogni RFP mid-market, e una piattaforma che si lascia comporre è una piattaforma che resta nel gioco. Chi legge questa apertura come una resa non ha capito dove si sta spostando il valore: non è più nel possedere tutto lo stack, è nel possedere i pezzi che gli altri non sanno fare, catalogo e merchandising assistito da AI in testa. Adobe ha scelto di giocare lì. Io, che quei pezzi li configuro per mestiere, sono contento che li abbia scollegati dal resto.
La mia opinione: chi ci guadagna davvero
Vengo alla domanda che conta. Chi ci guadagna? Secondo me la risposta non è uniforme, e vale la pena distinguere.
Ci guadagnano i merchant con un backend non-Adobe già consolidato. Penso a un caso che ho in testa, un merchant fashion sui 15M di GMV con un ERP pesante e customizzato che nessuno ha voglia di rimpiazzare. Per loro, poter mettere un layer di storefront e catalogo moderno sopra l’esistente, senza replatforming del transazionale, è esattamente il genere di scorciatoia che sbloccherebbe progetti fermi da anni. Il replatforming full è la cosa che i CFO temono di più, e questa impostazione lo aggira.
Con una condizione, però, che nello stesso progetto ho visto costare mesi. Quando abbiamo provato a esporre quel catalogo verso un layer esterno, la parte difficile non è stata l’integrazione: è stato scoprire che lo stesso prodotto aveva tre varianti di taglia modellate in tre modi diversi, a seconda dell’anno in cui era stato caricato. Nessun layer di merchandising, per quanto AI-assisted, ci avrebbe cavato un ragno dal buco. Abbiamo dovuto rimettere le mani sugli attributi prima di poter fare qualsiasi cosa interessante. È il motivo per cui, quando un merchant mi chiede da dove cominciare, la risposta è sempre la stessa e non è mai quella che spera: prima i dati.
Ci guadagna Adobe, ovviamente, che allarga il mercato indirizzabile. Ma qui metto un’avvertenza da consulente: aprirsi a backend di terzi è facile a dirsi. La qualità reale dipende da quanto sono robusti i connettori verso SAP, Salesforce e gli altri, da come si gestisce la sincronizzazione del catalogo e da chi possiede la source of truth su prezzo e stock. Sono i punti dove i progetti composable si incagliano sempre. Finché non ci metto le mani su un’integrazione vera, tengo l’entusiasmo al guinzaglio.
Chi invece deve fare i conti con qualche domanda scomoda è il merchant già tutto su Adobe Commerce full. Per lui il messaggio è più ambiguo: la stessa Adobe gli sta dicendo che il layer di storefront può vivere separato dal commerce engine. Ottimo per la flessibilità, ma apre anche la porta a chiedersi come si comporrà il suo stack tra qualche anno. È una domanda legittima, e onestamente non ho ancora una risposta netta. Ci sto ancora ragionando, e se qualcuno ce l’ha più chiara di me sono qui.
Un’ultima cosa, perché non voglio vendere favole. Questi sono annunci, con roadmap e disponibilità che si chiariranno nei prossimi mesi. Ho visto abbastanza lanci per sapere che la distanza tra il palco del Summit e il primo progetto in produzione si misura in trimestri, non in settimane. Il concetto però mi convince: Adobe che apre i suoi pezzi migliori e li porta dove il cliente li vuole, invece di chiedere al cliente di venire tutto da lei. Da consulente, è la conversazione che avrei voluto poter fare da tempo. Da qui in avanti la differenza la farà chi arriva a quella conversazione con i dati in ordine.
Mini-FAQ
Cos’è Adobe Commerce Optimizer?
È un layer di storefront, catalogo e merchandising con AI, annunciato da Adobe, progettato per funzionare anche sopra un backend commerce di terze parti come SAP o Salesforce, non solo su Adobe Commerce.
A cosa servono gli Edge Delivery Services?
Servono a erogare lo storefront da edge con performance elevate e SEO ottimizzata a livello di infrastruttura, riducendo il lavoro custom di ottimizzazione frontend.
Serve avere Adobe Commerce come backend per usarli?
No, ed è proprio la novità. L’impostazione presentata prevede di usare il layer di storefront e catalogo Adobe anche mantenendo un motore transazionale di terze parti.
Chi ne trae il maggiore vantaggio?
Secondo la mia lettura, i merchant mid-market con un backend non-Adobe già consolidato che vogliono un frontend moderno senza affrontare un replatforming completo del transazionale. A patto di avere catalogo e attributi in ordine: sui dati sporchi, un layer di merchandising AI amplifica il disordine invece di risolverlo.
Chi sono. Sono un consulente Adobe presso il gruppo Lutech, certificato Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Da anni progetto e gestisco storefront e-commerce, e in questo periodo approfondisco l’AI agentica e il suo impatto su chi vende online.