10mila ordini MySQL a settimana trasformati in marketing HubSpot personalizzato
Come abbiamo portato i dati d’ordine di un’azienda di welfare aziendale dentro HubSpot come oggetti di prima classe, e costruito sopra asset personalizzati.
L’azienda gestisce pasti aziendali agevolati per chi lavora in ufficio.
Tutto quello che vale la pena sapere di un cliente sta nel database di produzione: cosa ordina, da quale sede, quanto spesso, quanto gli resta nel portafoglio, che voto ha dato all’ultimo pasto.
Il marketing vive nel CRM, e il CRM non sapeva niente di tutto questo.
Ogni campagna cominciava con un’esportazione manuale, e “personalizzazione” voleva dire un nome di battesimo nell’oggetto.
Fra i dati e le campagne c’erano due ostacoli:
Step 1: Far arrivare i dati, di continuo
Un database di produzione non si può interrogare ai ritmi di uno strumento di marketing, e un’esportazione manuale la mattina dopo è già vecchia.
Un Cloudflare Worker interroga il database MySQL di produzione direttamente tramite Hyperdrive, ogni dieci minuti, su dodici tabelle.
Lo stato incrementale sta in KV, quindi ogni esecuzione sposta solo ciò che è cambiato dalla precedente — la sincronizzazione resta leggera che la settimana sia tranquilla o intensa, e il database di produzione risponde sempre e solo per il delta.
Step 2: Renderli usabili una volta arrivati
Copiare gli ordini dentro proprietà del contatto li avrebbe resi visibili ma non componibili. Un’email non può ragionare su “gli ordini di questo destinatario” se gli ordini sono testo dentro un campo.
Così la sincronizzazione scrive dentro HubSpot come oggetti personalizzati: ordini, sedi, piatti, menù, recensioni, movimenti di portafoglio.
Una volta che gli ordini sono oggetti di prima classe dentro il CRM, un’email si può comporre a partire dallo storico reale di chi la riceve. Il lavoro lo fanno due moduli HubL su misura.
Il primo costruisce un riepilogo d’ordine. Interroga gli oggetti ordine del destinatario e raggruppa tutto ciò che cade nella stessa finestra di quindici minuti in un unico messaggio — ordini tre piatti, ricevi una conferma invece di tre.
Il secondo compone una griglia di quattro piatti in evidenza, con i prezzi della sede di chi legge. Stesso modulo, prezzi diversi a seconda di dove lavori.
Un database di produzione da non affaticare
10mila ordini a settimana, ogni settimana, e la sincronizzazione deve stare fuori dai piedi di ciò che serve i clienti.
Personalizzazione che regge in un client di posta
Qualunque cosa componga il modulo deve sopravvivere all’apertura in un software scritto dieci anni fa.
Dodici tabelle, uno stato incrementale
Ogni esecuzione sposta ciò che è cambiato, altrimenti il costo della sincronizzazione segue la dimensione del database invece di quella del cambiamento.
10mila ordini a settimana, trasformati in email che sembrano scritte a mano.
Un solo template produce migliaia di email davvero diverse, e la differenza è dato reale, non un campo unito.
Le campagne smettono di cominciare con un’esportazione. I dati che servono al marketing sono già nella piattaforma in cui costruisce, e non hanno più di dieci minuti.
I due moduli sono il punto di partenza, non il limite. Gli oggetti ordine sono interrogabili da qualsiasi template HubSpot, quindi ogni asset costruito da qui in avanti — email, pagine, campagne — può essere composto dallo storico reale di chi lo riceve invece che da un campo unito.
Gli stessi oggetti alimentano nativamente la reportistica, quindi il comportamento d’acquisto è interrogabile dove si costruiscono le campagne e non in uno strumento separato.
E niente di tutto questo ha richiesto di sostituire la piattaforma di marketing. Il CRM che già usavano ha semplicemente imparato a fare qualcosa che non sapeva fare.
Problemi di dati di questa forma?
Se qualcosa qui somiglia alla tua situazione, dicci quale parte. Risposta garantita entro 2 ore lavorative (CET).
Arrigo Lupori
Fondatore e Amministratore