Malo: gli acquisti in boutique dentro Klaviyo
Case study
- Il mio ruolo
- Ho sviluppato il middleware seguendo l'architettura e le linee guida di Giuseppe Guarino di Ride On, che lo ha progettato: lettura degli export, coda, invio a Klaviyo e deploy sul server, più le verifiche sui dati con Malo e le prove con il supporto Klaviyo.
- Durata
- Da giugno a ottobre 2026
Il problema
Malo, marchio italiano del cashmere, vende online su Shopify e in 18 boutique. Gli ordini online arrivavano già in Klaviyo con l'integrazione nativa, quelli in boutique no: per le analisi predittive chi comprava solo in negozio era un cliente inattivo. Il gestionale dei negozi esporta ordini e profili in una cartella condivisa, la maggior parte degli scontrini non ha né email né telefono, e il primo invio doveva caricare dodici anni di storico.
Cosa ho fatto e perché
- Sull'architettura di Giuseppe, una coda su SQLite su una sola VM: ogni file letto dalla cartella condivisa diventa una riga per ordine o profilo, con chiavi e stato ma senza il contenuto, che il worker ricostruisce dal file archiviato al momento dell'invio. Nessun servizio cloud da gestire.
- Nessun duplicato, anche rileggendo: deduplica per file e per ordine, un unique_id stabile su Klaviyo e gli ordini di un cliente inviati in sequenza dopo il suo profilo. Un file riletto o un invio ripetuto non crea nulla due volte.
- Dati personali che non escono dal processo: email e telefoni stanno in coda solo come hash, log e telemetria non contengono dati dei clienti, chiavi e credenziali sono oscurate.
- Online e boutique nelle stesse predittive: un evento inviato via API non può scrivere nella metrica di Shopify, l'ho verificato con prove sull'account di test e confermato con il supporto Klaviyo. La soluzione è una metrica di conversione personalizzata che unisce i due canali e alimenta le predittive di ogni profilo.
- Consensi e collezioni pronti per il marketing: i consensi raccolti in negozio arrivano sul profilo, l'iscrizione parte solo quando c'è una data di consenso, con liste separate per lingua. Ogni prodotto riceve le collezioni Shopify del suo SKU, così si segmenta allo stesso modo online e in boutique.
- Un servizio che gira da solo: daemon systemd con watchdog, release immutabili con un installer, preflight offline, un comando di stato in sola lettura, eventi ed eccezioni su PostHog, invii al ritmo consentito da Klaviyo e attesa sui 429.
Risultati
- 99.386ordini in boutique dal 2014, importati senza errori
- 18boutique collegate
- 8 sper importare tutto lo storico, 2.069 file
- 0email o telefoni in chiaro nella coda e nei log
- 0duplicati rileggendo lo stesso file
- 262test automatici
Stack in evidenza
- Node.js
- Typescript
- SQLite (better-sqlite3)
- Zod
- Klaviyo API
- pino
- PostHog
- systemd
Hai un progetto simile? Parliamone.
ScrivimiQuando il gestionale delle boutique deposita nuovi file nella cartella condivisa, il middleware li legge, scarta i record non validi, mette in coda profili, ordini e resi e li invia a Klaviyo al ritmo che l'API consente. Lo scontrino arriva sulla timeline del cliente accanto ai suoi ordini online, con importi, prodotti, boutique e collezioni Shopify, e con la metrica combinata entra nelle previsioni di spesa e di riacquisto. Il team CRM segmenta su un cliente intero, non su due metà.
Cosa porto a un'agenzia o a una PMI da questo progetto
- Integrazioni dati che reggono i casi scomodi: file riletti, invii ripetuti, limiti dell'API, dati incompleti.
- Il formato dei dati verificato sui file veri, record per record, con le incongruenze portate a chi produce l'export insieme agli esempi.
- Un servizio backend consegnato con installer, monitoraggio e diagnostica, non solo il codice.
Realizzato per Malo in collaborazione con Ride On
