dataMesh Podcast

In riunione qualcuno chiede quanti acquisti sono arrivati su GA4 senza valore la settimana scorsa. Nessuno lo sa. Su Google Tag Manager i tag sono partiti tutti e il report del lunedì è uscito come sempre. Se l’errore c’era, poteva vederlo solo chi in quel momento aveva aperto l’anteprima di GTM, e non l’aveva aperta nessuno.

Quando i dati li leggeva un analista, un martedì con lo scontrino medio dimezzato lo faceva fermare: prima di commentarlo, chiedeva se quel giorno gli acquisti erano arrivati senza valore. Un agente AI quel martedì lo mette nella media con gli altri giorni e scrive il commento senza farsi la domanda.

Che cosa è cambiato

Con l’AI nella pipeline di analisi quella domanda non la fa più nessuno. Un modello non ha modo di accorgersi che valuearriva vuoto su una parte degli acquisti: per lui quel vuoto è un dato come gli altri, e lo mette nei conti. Ne ho scritto parlando dei guardrail dell’IA e dell’AI che guida fissando lo specchietto retrovisore: un’analisi sbagliata e ben scritta fa più danni di nessuna analisi.

Per questo la qualità va controllata quando il dato viene raccolto, e gli errori vanno contati e conservati: chi analizza, persona o agente, deve poter sapere quali giorni non usare.

Cosa fa GTM, e dove si ferma

GTM fa bene il suo lavoro. L’anteprima mostra, per la tua sessione, quali tag partono e con quali valori. La diagnostica del container segnala i problemi di configurazione del Google tag. La versione 360 aggiunge i controlli che servono a un’azienda grande su chi pubblica cosa: approvazioni, zone, workspace senza limite.

Nessuna delle due versioni però tiene un registro di cosa arriva in produzione dagli utenti veri, né verifica che il dataLayer contenga i campi previsti nel formato previsto. Una variabile che non trova il valore restituisce undefined, e l’opzione Format Value permette di trasformarlo in un valore a scelta: utile per non rompere i tag, ed è anche il modo più semplice per rendere invisibile un errore. Sul server-side Google rimanda a Cloud Logging, che mostra solo quello che hai deciso tu di scrivere nei log e non il contenuto delle richieste: se non l’hai previsto prima, non sai che cosa è arrivato.

Google ha tracciato il perimetro così: GTM governa chi cambia cosa nel container, mentre quello che arriva in produzione resta fuori. Il buco è abbastanza noto da avere un mercato: Code Cube, Trackingplan e ObservePoint vendono proprio questo. Chi resta su GTM e vuole questo controllo deve aggiungere un fornitore: un tag di monitoraggio in più, dentro lo stesso container che dovrebbe controllare, e un’integrazione da mantenere.

Dov’è l’occasione: errori di codice ed errori di contenuto

Su un tag manager enterprise lo stesso controllo è dentro il prodotto. Prendo come esempio Commanders Act, che lo divide in due momenti: prima di pubblicare il container e mentre i dati arrivano. La distinzione vale anche per chi usa altro.

Prima di pubblicare si cercano gli errori di codice. Ogni versione del container passa un test su otto combinazioni di browser e sistema operativo, con gli errori elencati per tag fino al numero di riga. Il test controlla che il JavaScript dei tag sia scritto bene e non vada in errore in un ambiente vuoto, dove le variabili di tc_vars, il data layer di Commanders Act, non esistono: per questo nei tag si scrivono controlli del tipo “se la variabile esiste”, che evitano errori come cannot read property of undefined. Una versione con errori non si pubblica finché l’errore non viene corretto o ignorato in modo esplicito, e i risultati del test restano salvati con ogni versione. Il test quindi dice se il codice si rompe su un browser, non se il valore che arriverà è giusto. La raccolta degli errori JavaScript sui browser degli utenti reali non c’è ancora: Commanders Act la sta valutando, senza una data.

Mentre il dato entra si cercano gli errori di contenuto. Qui lavora la Event Specification: per ogni evento le proprietà attese, il tipo, quali sono obbligatorie e cosa fare quando mancano, cioè accettare l’evento, togliere la proprietà o rifiutare tutto. Ogni evento raccolto riceve uno stato: valido, non valido ma accettato, rifiutato, filtrato, fallito. Lo stesso valore mancante che su GTM finisce in un undefined qui diventa un conteggio, una percentuale per sorgente e, se lo si vuole, un alert.

Quando i dati partono verso le destinazioni, cioè le piattaforme pubblicitarie e gli strumenti di analisi, il controllo si ripete: per ogni destinazione la quota di eventi consegnati, gli errori con la descrizione e la soluzione, un alert via email, Slack o Teams sotto una soglia scelta.

Il terzo punto da controllare è la configurazione del container. Al DMEXCO di Colonia, a settembre, Alessandro Gambato di Commanders Act ha mostrato l’audit dei 15 container web di un cliente. Dei 417 trigger, 176 (il 42%) erano finiti nel cestino, e c’erano due casi in cui la stessa conversione poteva essere inviata due volte. L’audit fotografa la configurazione in quel momento, e per chi misura il dato che pesa di più è il secondo: una conversione inviata due volte entra in un modello come due vendite.

Il connettore che legge la qualità

Ad agosto ho scritto del server MCP di Commanders Act come strumento per documentare un container. Lo stesso connettore serve a una seconda cosa: chiedere a un agente lo stato della raccolta prima di chiedergli l’analisi.

A ottobre 2026 il server è ancora in closed beta. Il tool sulla qualità della raccolta accetta un solo parametro, l’ID del sito, e restituisce sempre le ultime 24 ore, ora per ora: per ogni evento quelli raccolti, quelli validi e quelli accettati con un warning. Altri tool del server danno i totali per evento, gli alert aperti e il registro di chi ha modificato il container. L’agente non vede quale proprietà fallisce, che si consulta in piattaforma, né la consegna alle destinazioni né i risultati del test. Basta per mettere un controllo prima dell’analisi: se oggi purchase ha una quota di warning fuori dal normale, l’agente non fa l’analisi e una persona va a guardare.

Dove starei attento

Un warning non è un dato rotto. Basta che un campo presente su tutti gli eventi, che con gli acquisti non c’entra niente, arrivi in un formato diverso da quello della specifica (per esempio “1” invece di vero/falso) e quasi tutti gli eventi del sito risultano non validi, acquisti compresi, anche quelli con valore e ID transazione perfetti. Se il controllo che ferma l’analisi guarda la quota di warning, a quel punto restano due strade. O blocca l’analisi ogni giorno, e dopo una settimana nessuno gli dà più retta. O si alza la soglia finché smette di scattare, e da lì in poi non si accorge più degli acquisti senza valore. In tutti e due i casi il controllo non serve più. Nella specifica renderei bloccanti solo valore, valuta e ID transazione, e sistemerei i warning sui campi che non servono alla misura finché un warning torna a voler dire che c’è un problema da guardare.

Il 95% di consegna non basta. Nel report di consegna Commanders Act riassume lo stato di ogni destinazione con un’icona meteo, e mostra il sole quando arriva a destinazione più del 95% degli eventi. Una destinazione che perde 4 conversioni su 100 appare quindi in ordine. La soglia dell’alert si sceglie (l’esempio della documentazione usa il 90%): sulle destinazioni che alimentano le offerte automatiche e l’MMM la metterei al 98-99%.

Lo storico dura poco. Le statistiche di consegna restano un mese, e l’agente vede sempre e solo l’ultimo giorno. Lo stato di qualità va salvato ogni giorno nel warehouse, accanto ai dati che descrive. Se per una settimana di ottobre metà degli acquisti arriva senza valore e nessuno lo registra, a gennaio quella settimana sembra solo un calo delle vendite online. Un MMM, che lavora su due anni di dati, la legge così e attribuisce il calo a qualche canale. Nel pezzo di giovedì su Safari 27il problema era lo stesso: meno dati raccolti, letti come risultati peggiori.

Ogni correzione automatica va registrata. Con il Data Cleansing di Commanders Act si possono correggere i dati mentre arrivano, senza toccare il sito. La documentazione lo presenta come un modo per reagire subito mentre l’IT corregge la sorgente, e molti team tengono queste regole anche a lungo, perché costano meno di una modifica al sito. Va bene in tutti e due i casi, purché accanto a ogni regola siano scritti un responsabile, una data e il motivo. Altrimenti tra un anno nello storico non si distingue più quali dati sono arrivati giusti e quali sono stati corretti, e nessuno sa dire se la correzione serve ancora.

Serve una seconda fonte. Il riepilogo che l’agente legge dal connettore va confrontato con un numero che viene da un’altra parte: gli ordini nel gestionale contro gli acquisti raccolti dal tag manager. Se l’agente rifà la stessa domanda allo stesso connettore, ottiene la stessa risposta e non ha verificato niente.

Prima di chiedere a un modello cosa dicono i dati, chiedigli quanti ne sono arrivati rotti.

Filippo Trocca. Se stai mettendo un agente sopra i dati di marketing e vuoi capire quanto è affidabile quello che legge, scrivimi: [email protected]

Fonti

* Commanders Act, Event Specification

* Commanders Act, Data quality

* Commanders Act, Sources data quality

* Commanders Act, Data layer and data types

* Commanders Act, Testing (web container)

* Commanders Act, Event delivery

* Commanders Act, Data cleansing

* Commanders Act, MCP server (closed beta)

* Google Marketing Platform, Tag Manager e Tag Manager 360 a confronto

* Google for Developers, Monitoring your server-side tagging infrastructure

* Simo Ahava, Format Value option in Google Tag Manager variables

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit filippotrocca.substack.com

Il 19 ottobre il team di WebKit ha pubblicato un post per spiegare una cosa che Safari faceva già da cinque settimane. Da iOS, iPadOS, macOS e visionOS 27 il browser blocca le chiamate verso i provider di identity resolution: i servizi che ricevono la tua email al login o all’iscrizione a una newsletter e restituiscono un codice che ti riconosce da un sito all’altro. Il codice per bloccare questa tecnologia è stato implementato in WebKit a febbraio. Chi lavora con queste tecnologie se n’è accorto prima dai report che dal blog.

Prima di continuare leggere, prova il tuo browser. Ho misurato il blocco sul mio Mac. Per capire quanto è diffuso ho messo online un test di un minuto: ti dice che cosa blocca il tuo browser e raccoglie i risultati in forma anonima. Li pubblico qui nelle prossime settimane.

Cosa è cambiato

Da quando i cookie di terze parti hanno cominciato a sparire, a partire da Safari nel 2020, il mercato ha spostato l’identità sull’email: si tiene per anni, la gente la digita da sola, e un fornitore esterno la trasforma in un codice valido ovunque. Apple ora blocca proprio quel fornitore esterno. Il blocco vale per l’intero dominio, quindi cambiare la forma della richiesta non serve.

Apple non fa nomi e non pubblica la lista. Ho fatto la prova sul mio Mac, con Safari 27.0.1 e con Chrome come controllo, sulla stessa rete. Chrome raggiunge UID2, ID5, LiveRamp, Permutive e Audigent in 40-230 millisecondi. Safari li rifiuta prima che la richiesta esca, e nella console scrive Blocked by tracking protections. Stessa sorte per i due domini di The Trade Desk: Apple sembra averli resi di nuovo attiva nella beta iOS 27.2, ma la versione attuale li blocca. LiveIntent, Lotame, Meta, Microsoft, LinkedIn e Criteo passano, e passa anche Google Tag Manager. Quindi i tag di Meta Ads e di Google Ads si attivano in Safari come in Chrome.

Poi la prova decisiva. Ho spento “Impedisci il tracciamento cross-site” e ho rifatto il test: tutti i domini bloccati sono tornati raggiungibili. Il blocco è legato a un’impostazione che Safari accende di fabbrica su ogni Mac, iPhone e iPad. Nessuno deve installare niente: chi usa Safari senza toccare le impostazioni ce l’ha già.

Quanto pesa, e dove

Safari vale il 15,7% del traffico web mondiale e il 17,6% di quello italiano (StatCounter, settembre 2026). Sono medie, e nascondono la realtà di tutti i giorni: la quota cambia parecchio da un settore all’altro. Su un brand di moda di lusso che seguo, Safari porta il 55% del traffico. Chi vende a un pubblico alto-spendente ha un’esposizione tre volte superiore alla media, e proprio sugli utenti che valgono di più.

Cosa si rompe nella misura

Chi compra media sull’open web raramente ha un contratto diretto con UID2 o LiveRamp. Ci arriva tramite la DSP, il publisher, il fornitore di audience. Per questo il blocco si vede in tre punti, e nessuno porta un’etichetta.

L’audience. Un segmento costruito sulle email dei clienti e attivato tramite questi identificativi raggiunge meno utenti Apple. La campagna non si ferma: spende sul resto, e il report non dice chi manca.

La misurazione. Collegare un’esposizione su CTV o streaming a una visita sul sito passa spesso da LiveRamp o UID2, come ricostruisce AdExchanger. Su Safari quel collegamento non si fa più.

Il tempo. Le serie storiche hanno una rottura a metà settembre, quando iOS 27 ha cominciato a diffondersi. Nei report sembra un calo dei risultati su iPhone e Mac. In realtà si è ridotto il segnale, ed è la differenza fra tagliare una campagna e correggere un dato.

Cosa resta aperto

Il blocco ha un confine preciso: colpisce le richieste verso domini di terzi. Quelle verso il dominio del sito restano fuori, e le chiamate da server a server Safari non le vede. È la linea che Apple traccia anche a parole: “la personalizzazione in prima parte non è tracciamento”.

Qui sta l’occasione per chi misura. A luglio ne avevo scritto parlando di gateway first-party: servire i tag dal proprio dominio. Google Tag Gateway lo fa per i tag di Google, e solo per quelli: Meta, TikTok, Snapchat, Bing e i partner di affiliazione come Awin continuano a caricarsi dai loro domini. Commanders Act Gateway serve da un unico path sul tuo dominio gli script di tutti i partner, compreso il passaggio verso Google Tag Gateway, e filtra i cookie all’uscita.

Meta e gli altri non sono nella lista di Safari 27, quindi il gateway non sblocca niente: tiene tutti i tag fuori dagli ad blocker e lascia a te la decisione su che cosa esce verso ciascun partner. Dato raccolto dal sito, usato dal sito, con un controllo esplicito su chi riceve che cosa: è l’architettura che sta al momento dal lato giusto della linea di Apple. Vale lo stesso per i dati di conversione mandati dal server, come le Enhanced Conversions.

Dove starei attento

Il server non è un nascondiglio. Dopo il blocco, la tentazione è spostare la chiamata al fornitore di identità sul server, dove Safari non arriva. Apple però ha già scritto come la pensa. Nel post spiega che un fornitore esterno di identity resolution resta un terzo anche quando lavora sui dati di una sola azienda, perché mette insieme dati di molti siti, dispositivi e aziende: crea "una capacità di tracciamento che nessuna prima parte ha da sola". Oggi il blocco colpisce il browser, ma lo stesso ragionamento vale per le chiamate fatte dal server. E Apple ha già uno strumento che non passa dalla rete: Hide My Email, che dà a ogni sito un indirizzo email diverso. Se l'email cambia da un sito all'altro, il fornitore non ha più niente da abbinare.

I numeri d’impatto non ci sono. Quelli che circolano vengono dai fornitori colpiti. AdExchanger riporta che Apple vuole estendere la lista a centinaia di aziende, e Apple non l’ha confermato. Non costruirei una decisione di budget su nessuno dei due.

Cosa farei questa settimana

Guarda la console di Safari sul tuo sito. Attiva gli strumenti per sviluppatori e apri le pagine di login, newsletter e carrello: Blocked by tracking protections è il blocco di Apple, Resource blocked by content blocker viene da un content blocker, di solito un’estensione che blocca la pubblicità. Segmenta i report per versione del sistema operativo da metà settembre e confronta con gli ordini del gestionale. Chiedi alla tua DSP quale parte dell’audience passava da questi identificativi.

Filippo Trocca scrive di misurazione avanzata, attribuzione e infrastruttura di tracciamento first-party su dataMesh. Se vuoi capire quanto della tua misura passava da un fornitore di identità, scrivimi a [email protected].

Fonti

* Blocking Identity Resolution Infrastructure — WebKit, 19 ottobre 2026

* Browser Market Share Italy — StatCounter, settembre 2026

* Apple’s Safari crackdown threatens advertisers’ cross-channel measurement — eMarketer, 13 ottobre 2026

* How data and ad tech vendors are preparing for the iOS 27 fallout — AdExchanger, 8 ottobre 2026

* Apple has far-reaching plans to block hundreds of programmatic data companies from iOS — AdExchanger, 2 ottobre 2026

* ADOTAT: ID5 stays on Safari blocklist as Trade Desk gets 13-day fix — PPC Land

* IAB Tech Lab says Apple can block ad vendors remotely with no appeal — PPC Land

* Safari 27 blocks adtech domains at the network layer — FASilytics

* Google tag gateway for advertisers — Google for Developers

* Tracking Optimisation: Commanders Act Gateway — Commanders Act Community

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit filippotrocca.substack.com

Uno spot visto lunedì può spingere un acquisto la settimana dopo. Una campagna display chiusa quindici giorni fa porta ancora qualcuno sul sito oggi. Chiunque abbia lavorato su una pianificazione lo sa, eppure il modo più semplice di misurare la pubblicità lo cancella: mette in fila la spesa di oggi e le vendite di oggi, e dà per scontato che l’effetto di un euro si esaurisca nel periodo in cui lo spendi. È come dire che il termosifone scalda solo finché resta acceso, e che la temperatura crolla nell’istante in cui lo spegni.

Questo “effetto memoria” ha un nome, adstock (o carryover), ed è uno dei pochi numeri che decide il risultato di un Marketing Mix Model: è il motivo per cui due MMM costruiti sugli stessi dati possono dire cose opposte sullo stesso canale. Una cosa da fissare subito: l’adstock è un’ipotesi. Un parametro che il modello stima, o peggio che qualcuno imposta a mano.

Grazie per leggere dataMesh! Iscriviti gratuitamente per ricevere nuovi Post e sostenere il mio lavoro.

Cos’è, in parole povere

L’adstock distribuisce l’effetto di un’esposizione su una coda di periodi successivi, con un peso che cala nel tempo. Fa due cose insieme. Accumula, perché l’adstock di questa settimana è la spesa di questa settimana più il residuo non ancora svanito delle precedenti. E decade, perché quando smetti l’effetto non sparisce di colpo: si spegne piano.

La metafora che uso con i clienti è un serbatoio con una piccola falla sul fondo. Ogni euro di pubblicità è acqua che versi dentro, e il livello di oggi non è quanto hai versato oggi: è quanto hai versato più ciò che è rimasto dal passato dopo che la falla ha fatto il suo lavoro. Il tasso di decadimento è la dimensione della falla.

Quel tasso è un numero tra 0 e 1, e a un responsabile marketing un coefficiente di 0,7 non dice niente. Lo stesso numero si può dire in un modo che chiunque capisce al volo: la half-life, cioè dopo quanti periodi l’effetto si è dimezzato. È il modo in cui Recast suggerisce di leggerlo, e ha ragione: in riunione porti quella. Con un decadimento settimanale del 50% l’effetto si dimezza in una settimana, con il 70% in due, con il 90% in quasi sette.

I canali più funzionali, come search e social, hanno di solito una coda corta; TV e video di brand la hanno più lunga, perché vendono molto dopo l’esposizione. E la coda pesa più di quanto sembri. Con un adstock geometrico l’effetto totale di un euro si ottiene dividendo quello della prima settimana per 1 meno il tasso di decadimento. A 0,7, cioè con una half-life di due settimane, il divisore è 0,3 e l’effetto totale vale più di tre volte quello immediato. Chi confronta la spesa e le vendite della stessa settimana ne vede meno di un terzo. Stessi dati, un canale che vale il triplo, per un parametro solo.

Come scegliere la curva senza tirare a indovinare

Non c’è un pulsante che ti dice quale half-life è giusta, ma c’è un ordine di lavoro. Si parte dal canale, non dal modello. Prima di guardare i dati, immagina quale potrebbe essere il risultato per te: questo canale ha un effetto che parte forte e cala, o uno che matura nel tempo? Search e social hanno effetto quasi immediato e coda breve, e per loro basta la forma più diffusa, quella geometrica, che ha il picco subito e da lì cala soltanto. Un canale a considerazione lunga ha il picco qualche periodo dopo: lì serve un adstock di tipo Weibull, che modella anche il ritardo, al prezzo di un secondo parametro che con uno storico corto non reggi. La forma decide quando arriva l’effetto, non solo per quanto dura — e tra due curve che spiegano i dati altrettanto bene, tieni la più semplice.

Poi si lascia stimare ai dati, ma dentro paletti. Fissare la half-life a mano è una scommessa; lasciarla libera di vagare tra 0 e 1 è l’estremo opposto, e con poche decine di osservazioni il modello insegue il rumore. La via di mezzo è un intervallo plausibile o un prior, e tutti e tre gli strumenti open source più usati lo permettono: l’intervallo di theta in Robyn, il prior su alpha in PyMC-Marketing, quello sul decadimento in Meridian. Stai dicendo al modello: cercala qui dentro, non dove ti pare.

Infine si valida su tre fronti. Stabilità: rifai la stima su finestre temporali diverse, e se la half-life salta da una settimana a sei stai guardando rumore, non un parametro. Sensibilità: muovi il decadimento di poco e guarda se la decisione di budget cambia, perché se cambia stai appoggiando migliaia di euro su un numero fragile. Riscontro esterno: confronta l’adstock con un lift test o un geo-test, l’unica prova causale che hai, a una condizione. Il test deve continuare a misurare dopo la fine del flight. Quello commerciale di solito si ferma due settimane dopo, proprio quando la coda comincia a vedersi, ed è per questo che il carryover è il parametro che la calibrazione standard misura peggio. Se il modello dice che la TV ha una coda di sei settimane ma un geo-test spento per un mese non mostra quel calo, a sbagliare è il modello.

La curva giusta non è quella che riproduce meglio lo storico: è quella che regge fuori campione e non litiga con gli esperimenti.

Adstock e saturazione non sono la stessa cosa

Le due trasformazioni si confondono di continuo, e in un MMM moderno agiscono entrambe prima della regressione. Conviene tenerle separate: rispondono a domande diverse.

L’ordine, in Robyn come in Meridian e PyMC, è: spesa, poi adstock che la spalma nel tempo, poi saturazione che le applica i rendimenti decrescenti, poi la regressione. Quando i risultati calano, è perché ho spinto troppo in alto sulla curva di saturazione o perché ho tagliato la spesa e la coda residua si è esaurita? Sono due diagnosi opposte.

Perché ti riguarda anche se non costruisci MMM

Sembra un tecnicismo da data scientist, e invece decide su quale finestra giudichi un canale: un canale di brand con coda lunga sembra inefficace se lo valuti sui risultati immediati, ed è l’errore che condanna TV, video e branding, etichettati come “che non convertono” quando convertono più tardi. E pesa su come pianifichi: con coda corta le pause si pagano subito, con coda lunga l’effetto regge tra un flight e l’altro.

E riguarda di chi ti fidi. Se l’adstock è stato imposto a mano, perché era l’impostazione predefinita dello strumento o perché “facciamo due settimane e via”, l’intero ROI poggia su un’ipotesi che nessuno ha verificato. Stimarlo dai dati è più difficile di quanto sembri: con un anno di dati settimanali hai una cinquantina di osservazioni per separare l’effetto immediato dalla sua coda, mentre si muovono stagionalità, promozioni e festività. Il modello troverà comunque un decadimento che ricalca benissimo lo storico, salvo ribaltarsi appena cambi una settimana di dati. È qui che servono regolarizzazione e prior, il lavoro che aprire la black box dell’MMM descrive in dettaglio.

C’è infine il punto più sottile, il travaso con la baseline. Un adstock troppo corto lascia l’effetto residuo della pubblicità nella baseline, dove finisce scambiato per domanda organica. Un adstock troppo lungo fa l’opposto: attribuisce al media di mesi fa vendite che non gli appartengono. In entrambi i casi stai dando per organico ciò che era a pagamento, o viceversa, e nessuno se ne accorge guardando il ROI finale.

Le tre domande

Prima di credere al ROI che uno strumento ti tira fuori, fai tre domande su ogni canale. Qual è l’adstock ipotizzato. Come è stato scelto, stimato dai dati o messo a mano. E quanto cambiano i risultati se lo muovi di poco. Sono le stesse domande che separano un MMM che guida le decisioni da uno che guida fissando lo specchietto retrovisore: se chi ti ha venduto il modello non sa rispondere a tutte e tre, quel ROI in riunione non lo difendi. L’adstock decide quanto a lungo la tua pubblicità lavora dopo che l’hai pagata, e lasciarlo com’è uscito dalla scatola vuol dire lasciare quella decisione a chi ha scritto il software.

Grazie per leggere dataMesh! Questo Post è pubblico, quindi sentiti libero di condividerlo.

Filippo Trocca scrive di misurazione avanzata, attribuzione e Marketing Mix Modeling su dataMesh. Se vuoi confrontarti su come scegliere e validare l’adstock del tuo MMM invece di accettare i valori predefiniti, scrivimi a [email protected].

Fonti citate

* Advertising adstock — Wikipedia

* Adstock rates: accounting for the lagged effect of advertising — Recast

* Dynamic Effects (carryover, half-life) — Ashok Charan, Marketing Analytics

* Adstock transformation: geometrico e Weibull — Robyn (rdrr.io)

* Key Features (iperparametro theta) — documentazione Robyn

* GeometricAdstock (alpha, l_max) — PyMC-Marketing

* Set the adstock_decay_spec parameter — Google Meridian

* Set the max_lag parameter — Google Meridian

* How modern MMM works: adstock, saturation & Bayesian — PyMC Labs

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit filippotrocca.substack.com

Partiamo dal fatto scomodo. Meridian è l’MMM di Google. Robyn è l’MMM di Meta. Entrambi open-source, gratuiti, ben documentati. Ed entrambi costruiti dalle due aziende che vendono lo spazio pubblicitario che quel Marketing Mix Model dovrebbe valutare. I due arbitri sono anche le due squadre in campo.

Non voglio farne una requisitoria Google-contro-Meta. Mi interessa una cosa più utile: ogni MMM va testato, chiunque lo firmi. Testare significa calibrarlo e verificarlo con lift test di vario genere e mettere alla prova allocazioni di budget alternative. Il verdetto arriva da lì, da qualcosa che vive fuori dal modello.

Prima di tutto, grazie

Prima di Robyn (open-source dal 2020) e Meridian (2024), l’MMM era rinchiuso in pochi laboratori: econometristi specializzati, vendor da centinaia di migliaia di euro l’anno, scatole nere. Questi due progetti hanno democratizzato la conoscenza e aperto il mercato su cui oggi prosperano anche i vendor indipendenti.

Cosa sono, in due righe

Meridian (Google): bayesiano, gerarchico a livello geografico, uncertainty-aware. Esigente su dati e competenze, pensato per l’ecosistema Google: Query Volume come variabile di controllo, reach e frequency di YouTube, export in Looker Studio.

Robyn (Meta): ridge regression con tuning evolutivo degli iperparametri, decomposizione delle serie storiche via Prophet. Più automatizzato e accessibile: una catena end-to-end in meno di un giorno, su serie storiche, senza dimensione geografica.

Due filosofie diverse. Stesso conflitto d’interessi alla radice.

Open-source non vuol dire neutrale

Il codice di entrambi è su GitHub, lo può leggere chiunque: l’accusa di scatola nera non regge. Il bias sta nelle scelte che il modello porta con sé.

Primo: i default e i prior. Le assunzioni di partenza orientano i risultati, e quelle di fabbrica le ha scelte il fornitore, non tu. Secondo: le variabili di controllo. Meridian incorpora segnali dell’ecosistema Google, Robyn ha default Meta-centrici: ogni modello “vede” meglio il canale di casa. Terzo: la calibrazione. I primi due punti si possono correggere, ma solo se qualcuno sa di doverlo fare e sa come farlo. È questo terzo punto a decidere tutto, ed è lì che quasi tutti si fermano.

Un MMM non è plug-and-play

I modelli open-source hanno fatto credere che dare in input i valori a un framework equivalga a sviluppare un modello MMM. Non è così: una volta lanciato, il modello restituisce i default e i prior di fabbrica, che non sono quelli del tuo specifico business. Se questi strumenti sono così configurabili, è perché sono pensati per essere calibrati da un esperto.

In Meridian puoi, e devi, impostare ROI prior personalizzati per canale e calibrarli sui risultati degli esperimenti, oltre ad inserire trend, stagionalità e carryover. La documentazione lo dice apertamente: non esiste una formula per tradurre un esperimento in un prior, si combinano dati, conoscenza di dominio e giudizio soggettivo. I prior esistono proprio perché i dati MMM sono pochi e rumorosi: con poca informazione il loro peso sul risultato è alto. Se nessuno li calibra, quello che ottieni è l’assunzione di fabbrica con l’aspetto di una misura.

Con Robyn la sostanza non cambia: i lift test entrano via calibration_input e con 10 canali ti ritrovi 32 iperparametri da delimitare. Soprattutto, Robyn non restituisce un modello: ne restituisce decine, tutti statisticamente plausibili, e quale usare per allocare il budget lo decide una persona competente.

La ricetta è la stessa per tutti: modello, specialista, calibrazione con esperimenti indipendenti. Il rischio vero è il set-and-forget: prendere il numero così com’è e scambiare la fiducia statistica per verità. La democratizzazione ha abbassato la barriera d’accesso allo strumento, non quella alla competenza per usarlo bene.

Quando l’arbitro ospita la partita

Finché Meridian era codice da gestire in prima persona, il conflitto restava un’avvertenza. Adesso è architettura: Meridian dentro Google Analytics 360 è la versione ospitata da Google, con ingestione first-party, pull cross-channel e interfaccia agentica (ne ho scritto qui). E le Qualified Future Conversions, conversioni previste da Gemini addestrato sul comportamento dentro Google Ads, sono candidate a diventare input del modello. Un segnale che esiste solo per Google Ads e ne valorizza l’investimento, dato in pasto al modello che dovrebbe giudicarlo: doping legalizzato.

Se l’MMM di Google è calibrato su una previsione di Google, neanche lo specialista basta: l’indipendenza del giudizio si è spostata dentro il modello. Lo sottolinea anche la critica tecnica di Aryma Labs: un buon modello, con un conflitto che nessuna eleganza statistica cancella.

La via indipendente

Il terzo polo è PyMC-Marketing, toolbox bayesiano dei PyMC Labs: open-source ma vendor-neutral. Non vende media, quindi il bias del canale di casa non c’è per costruzione. Richiede competenze, ma non tifa per nessuna piattaforma.

Tra i vendor il discrimine è uno: chi calibra con esperimenti causali indipendenti e chi resta a correlazione pura. Mutinex, Measured e Keen affiancano all’MMM esperimenti di geo-holdout: pausa della spesa in alcuni mercati, misura del lift, lift usato come prior. Se il modello dice ROAS 5 e l’esperimento dice 2, riconciliano.

E i default contano. Recast racconta di un brand CPG con carryover del video a 12 settimane che, con l’adstock di default a 7 giorni, si vedeva sottostimato il contributo TV del 40%. Qualcuno deve sapere che la TV ha un decay basso, e impostarla di conseguenza.

Cosa pretendere da un MMM credibile

Quattro cose, sempre insieme. Indipendenza del validatore: calibrazione e verifica con esperimenti di incrementalità che nessuna piattaforma controlla (per partire: il Playbook del Primo Lift Test). Triangolazione: MMM, esperimenti e attribution insieme, mai una fonte sola (è il metodo del capitolo 4 di MMM Strategico). Trasparenza del metodo: prior dichiarati, variabili di controllo esplicite, intervalli di incertezza. Budget per la verità: misurare costa, ma è l’investimento che rende credibile il resto (ne ho scritto qui).

Smettete di credere al modello e iniziate a testarlo

Il modo standard per verificare la qualità di un MMM, qualunque ne sia il motore, l’ha messo sul tavolo proprio Mutinex con mmm-eval: framework di validazione open-source e model-agnostic, stessi test su Meridian, PyMC, Robyn o una scatola nera proprietaria. Il dato di partenza del whitepaper: su 20 RFP recenti, il 70% non chiedeva alcun test di governance o stabilità. La proposta: rendere i test obbligatori in fase di RFP. Quattro prove con soglie esplicite:

* Accuratezza predittiva (holdout): MAPE oltre il 15-20% o R² sotto 0,7 segnalano problemi strutturali.

* Cross-validation: deviazione standard del MAPE sotto il 5-7% tra le finestre temporali.

* Stabilità del ROI: oltre il 15-20% di oscillazione tra un refresh e l’altro, c’è da indagare.

* Robustezza: si sporcano leggermente i dati di spesa (un 5% di scarto casuale, a simulare gli errori di tracciamento reali) e si controlla quanto si muove il risultato. Un modello solido cambia meno del 10-15%; aggiungendo un canale finto, che per costruzione non può aver prodotto vendite, il modello deve attribuirgli effetto zero.

Questi test servono a evitare errori da milioni di euro, e il whitepaper ne porta uno concreto. Un brand CPG sposta 5 milioni dal digitale alla TV perché l’MMM gli dà un ROI TV altissimo, e la campagna manca gli obiettivi. Quel ROI non era affidabile, e i test l’avrebbero mostrato prima di muovere il budget: oscillava tra 3,5x e 0,8x da un refresh all’altro, e bastava sporcare i dati del 5% per farlo crollare a 1,2x. Un numero instabile preso per certezza. È lo stesso meccanismo del caso Recast citato prima, all’inverso: là il default sottostimava la TV, qui un modello fragile la sopravvalutava. In entrambi mancava chi validasse.

L’MMM giusto non è quello di Google né quello di Meta. È quello che scegli tu, messo alla prova con esperimenti che nessuna piattaforma controlla. Meridian e Robyn ti hanno regalato lo strumento e aperto il mercato per costruire quel giudice. Sta a te non confondere il pacco con il giudizio.

Filippo Trocca scrive di misurazione avanzata, attribuzione e Marketing Mix Modeling su dataMesh. Se vuoi confrontarti su come impostare un framework di validazione MMM indipendente nella tua organizzazione, scrivimi a [email protected].

Fonti

* Meridian on GitHub — Google

* Meta Robyn on GitHub — Meta

* Meridian — ROI priors and calibration — Google

* Meridian — Set custom ROI priors using past experiments — Google

* Robyn — Key features e calibrazione — Meta

* PyMC-Marketing — PyMC Labs

* Google Analytics 360 + Meridian — Google Blog

* Qualified Future Conversions — Google Business

* Mutinex

* mmm-eval — Open MMM validation framework — Mutinex

* Advancing MMM Transparency — whitepaper — Mutinex

* Measured

* Keen Decision Systems

* Recast — Adstock rates

* Hits and Misses of Meridian — Aryma Labs

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit filippotrocca.substack.com

Il 3 giugno Google ha annunciato i Search Generative AI performance report dentro Search Console: una vista dedicata che mostra quante volte le tue pagine compaiono in AI Overviews, AI Mode e nelle funzioni generative di Discover. Chi fa SEO lo chiedeva da due anni: dal giugno 2025 i dati delle risposte AI sono confluiti nei totali “Web” senza filtro, indistinguibili da quelli della ricerca classica. L’attesa era tale che a settembre circolò perfino uno screenshot falso del filtro, smentito da John Mueller.

Ora il report esiste, al suo interno troviamo: impression, pagine, paesi, dispositivi e date, fino al dettaglio orario. Manca una colonna: i clic. Niente CTR, niente query, niente posizione.

I primi feedback: la colonna che non c’è

La community SEO ha reagito in poche ore, con un tono solo: meglio di niente, ma il dato che serviva non c’è. Barry Schwartz ha chiesto a Google se i clic arriveranno; risposta: “introdurremo metriche aggiuntive nel tempo”. La sua chiosa: “Google non ci dirà quanti utenti cliccano dalle risposte AI verso i nostri siti, nessuna sorpresa”. Search Engine Journal taglia corto già nel titolo: “Still No Click Data For SEOs”. La frustrazione è fondata: il report dice quanto sei visibile, non quanti clic ti stanno costando le risposte AI. Con cali di CTR fino al 58% quando compare un AI Overview, è quel numero a decidere se la visibilità vale qualcosa. Google lo possiede, ma non vuole mostrarlo.

Seconda critica: il rollout. Il report parte da un sottoinsieme di siti nel Regno Unito; l’AI Performance report di Bing Webmaster Tools è globale da febbraio. Anche Bing conta citazioni e non clic, ma il confronto nei commenti è impietoso: chi insegue ha reso leggibile la transizione ovunque, chi domina la concede a rate.

Perché il Regno Unito? Lo stesso 3 giugno la Competition and Markets Authority ha imposto a Google il primo conduct requirement vincolante sotto il Digital Markets, Competition and Consumers Act: opt-out dalle funzioni AI per i publisher senza penalizzazioni sul ranking e, entro dicembre 2026, clic e CTR disaggregati. A febbraio Google definiva questi controlli “un enorme progetto di ingegneria”; quattro mesi e un ordine vincolante dopo, eccoli. I clic arriveranno perché un regolatore li ha messi per iscritto. Non perché Google abbia cambiato idea.

E per chi i report li riceve in riunione: senza clic, le impression dalle risposte AI sono un KPI che può solo crescere. Aspettati dashboard in miglioramento mentre il traffico organico cala — convivono benissimo. Quando comparirà la riga “visibilità AI” in crescita, la domanda è una: misurata in cosa, e dove sono i clic.

La prima pagella era arrivata due settimane prima

Il quadro si era aperto al Google Marketing Live del 21 maggio con AI Performance Insights: una vista dentro Merchant Center che misura quanto spesso i tuoi prodotti vengono scoperti in AI Mode, nell’app Gemini e negli AI Overviews, e confronta la tua share of voice con quella dei competitor. È lo strumento di “AI share of voice” che fino a ieri compravi da vendor terzi — gratis e in casa Google. Tre viste:

* I journey stages: dove sei visibile lungo il percorso d’acquisto (scoperta, valutazione, acquisto).

* I product terms: i dettagli che contano per chi cerca prodotti come i tuoi (”montaggio facile” per le tende, “lunga durata della batteria” per le lampade portatili), sono le query conversazionali della categoria.

* Gli structured attributes: le specifiche cercate dai clienti (dimensioni, peso, materiali, colori), con un completeness score che segnala le schede incomplete.

Più le raccomandazioni su cosa sistemare, tipicamente quali attributi completare.

Due avvertenze. Il rollout parte da USA, Canada, Australia, India e Nuova Zelanda: per l’Italia è una finestra di preparazione. E va distinto dai Conversational Attributes, i nuovi campi del feed con rollout globale: quelli sono cosa compili, questo è come ti vedono. Nel post sul feed come vetrina lo scrivevo: i dati prodotto pensati per le parole chiave non bastano più a farsi trovare dall’IA, AI Performance Insights misura quanto ti sta già costando.

Sui numeri da palco — AI Mode a 1 miliardo di utenti mensili, AI Overviews a 2,5 miliardi — guardia alta: a fine maggio un censimento di Originality.ai trovava una ventina di implementazioni pubbliche dello Universal Commerce Protocol su oltre tre milioni di domini, nessuna dei brand del keynote. Quanto possiamo fidarci dei numeri annunciati da Google?

Le due pagelle, lette insieme

Google misura la tua visibilità AI sui due lati del suo ecosistema e in entrambi sceglie le colonne. Sull’organico dà le impression e trattiene i clic. Sullo shopping regala la metrica più ricca, la share of voice, perché lì l’incentivo è suo: più vedi, più investi in campagne e feed. Lo stesso schema di Meridian: Google che ci dice quanto bene funziona Google.

AI Performance Insights non è ancora disponibile, e al lancio il punto da guardare è il metodo: una share of voice vale quanto la formula e il denominatore che la generano. Cosa conta come “rilevante”? Su quale universo è calcolata la quota? Se il metodo resterà opaco, sarà un voto scritto dall’insegnante che ha interesse a promuoverti.

Limite comune: vedono solo Google. Niente ChatGPT Shopping, niente Perplexity, niente Copilot, niente Rufus (l’assistente AI di Amazon). Misurare solo dentro Google è una parte spacciata per il tutto, e la misura cross-platform Google non può dartela: non vede fuori da casa propria.

Il traffico, intanto, resta senza nome

Dal 13 maggio GA4 ha il canale nativo “AI Assistant” nei Default Channel Group: riconosce il referrer di ChatGPT, Gemini, Claude, Copilot e Perplexity senza configurazione. Ma dentro le app mobile il referrer spesso si perde, e la sessione atterra come traffico diretto. Soprattutto, AI Mode e AI Overviews non passano attribuzione: proprio le superfici delle due pagelle qui restano invisibili. La riga “AI Assistant” è il minimo garantito del traffico da AI, mai il totale.

Cosa farei adesso

Niente di questo rende i due tool inutili: vanno verificati prima di finire in una slide. Per l’Italia, dove non sono ancora disponibili, è una finestra per prepararci. Le quattro mosse che vi consiglio.

Controllerei subito le proprietà Search Console che servono il mercato UK: se rientrano nel campione, il report è già acceso. Lì leggi la visibilità; per stimare i clic persi dovrai incrociare quelle impression con i clic totali della proprietà.

Mapperei gli account Merchant Center sui mercati del rollout: la dashboard si accenderà lì prima, e la leggi mentre i competitor non la guardano.

Compilerei i Conversational Attributes partendo dai prodotti che fanno più fatturato, con descrizioni in linguaggio naturale scritte da un LLM, non incollate da una regola marca-modello-colore. È l’intervento che il tool stesso ti suggerirà: tanto vale partire ora.

Soprattutto, costruirei una baseline esterna prima che le dashboard di Google si accendano: quanto vieni citato sui motori AI che Google non vede. Otterly, Peec e Profound mandano set di prompt sui modelli e contano le citazioni. Conta solo la frequenza — quante volte su cento compari, su un paniere ampio di query reali — mai il singolo tentativo.È il rank tracking trapiantato sugli LLM, con i suoi limiti: il paniere lo scegli tu, la metrica la definisce lo strumento. Il suo valore non è la precisione: è l’indipendenza da Google. Quando le dashboard si accenderanno, avrai qualcosa di tuo con cui confrontarle.

La domanda è quella di sempre: chi misura la mia visibilità, e quanto guadagna dal voto che mi dà?

Filippo Trocca scrive di misurazione avanzata, attribuzione e Marketing Mix Modeling su dataMesh. Se vuoi confrontarti su come impostare una baseline indipendente di visibilità AI, scrivimi a [email protected].

Fonti citate

* Introducing Search Generative AI performance reports in Search Console — Google Search Central Blog

* New controls for website owners — blog.google

* Google Search Console AI performance reports and controls to block your content — Search Engine Land

* Google reacts to UK order with a Search Console AI opt-out toggle — PPC Land

* Google finally gives Search Console its own generative AI visibility reports — PPC Land

* CMA secures fairer deal for publishers — gov.uk

* Google lets sites opt out of AI search results — The Decoder

* AI Overviews Reduce Clicks by 58% (update) — Ahrefs

* Google AI Mode traffic data comes to Search Console — Search Engine Land

* Introducing AI Performance in Bing Webmaster Tools (Public Preview) — Bing Blogs

* AI Performance Insights — annuncio ufficiale Google

* Google launches AI Performance Insights and Conversational Attributes — Search Engine Land

* Shopping updates from Google Marketing Live — blog.google

* Merchant Center Help — Insights for AI-powered shopping

* Google Analytics Adds AI Assistant as Default Channel Group — Search Engine Journal

* UCP / Agentic Commerce Adoption: Live Dashboard & Study — Originality.ai

* GEO Rank Tracker: how to monitor your brand’s AI search visibility — Search Engine Land

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit filippotrocca.substack.com

Per anni il feed prodotto è stato la parte noiosa dell’e-commerce. Titolo, GTIN, prezzo, una tassonomia di base, e via verso i caroselli di Shopping. Lo gestiva il reparto tecnico, non lo guardava nessuno, e finché i prodotti restavano “approvati” andava bene così.

Quel mondo sta finendo. Con gli aggiornamenti al Merchant Center arrivati nel 2026, il feed ha smesso di essere un archivio di metadati ed è diventato la base da cui l’intelligenza artificiale tira fuori le sue risposte. Quando chiedi a Gemini o ad AI Mode “qual è il portatile giusto per montare video sotto i 1500 euro?”, il modello non ti mostra più dieci link blu, dà una risposta, e la costruisce con le informazioni inserite nel feed. Se nel feed non c’è, in quella risposta tu non esisti.

Qui c’è un cambio che pesa più di qualsiasi dettaglio tecnico. Per chi viene dalla misurazione, “dato” ha sempre significato numeri e dimensioni: sessioni, conversioni, ricavi. Adesso il significato si allarga: è un dato l’attributo di prodotto, è un dato una coppia domanda-risposta. Lo sono il PDF della garanzia, l’immagine ad alta risoluzione, il video, il modello 3D in formato .glb. Sono questi i dati su cui l’IA decide chi mostrare e chi consigliare. Il feed di Shopping è il primo posto dove questo principio smette di essere teoria e diventa una casella da compilare o lasciare vuota: da quella casella dipende la visibilità. Se continui a pensare ai dati come righe di un report, stai guardando metà di questo nuovo mondo.

Tre cose da mettere a fuoco: cosa è cambiato, dov’è l’occasione, e dove starei attento. Una alla volta.

Grazie per leggere dataMesh! Iscriviti gratuitamente per leggere nuovi post e supportare il mio lavoro.

Cosa è cambiato

Da maggio 2026 Google ha lanciato in tutto il mondo un blocco di attributi conversazionali, che si affiancano ai campi di sempre senza sostituirli. Il più importante è question_and_answer: fino a 30 coppie domanda-risposta per prodotto, che finiscono dritte nel motore RAG. L’utente chiede “Supporta il Bluetooth 6.0?”, e l’IA risponde con la tua risposta invece di tirare a indovinare. Poi ci sono document_link (fino a 5 PDF — manuali, garanzie — che l’IA legge per estrarre dettagli che in una descrizione non ci starebbero mai), related_product per dirle cosa serve insieme al prodotto, variant_option per le varianti che vanno oltre taglia e colore, e popularity_rank, un numero da 0 a 100 che la orienta quando trova più prodotti che andrebbero bene.

C’è poi un campo che esiste da anni ma che quasi nessuno ha mai compilato come si deve: product_detail. Ha una struttura rigida — sezione, attributo, valore — ed è esattamente quello che l’IA legge quando costruisce una tabella di confronto dentro la chat. Lascialo vuoto e il tuo prodotto da quel confronto sparisce. Non finisce più in basso: non c’è proprio.

L’occasione

Una logica c’è, e regge. Il problema più serio dell’IA nello shopping sono le allucinazioni, e un modello che si inventa una specifica o un prezzo è una grana legale, non un dettaglio estetico. Darle fatti certi, scritti da te — è questo che fanno question_and_answer e document_link — abbassa di colpo il margine di errore. Il feed diventa la fonte verificata, e il Business Agent che Google sta lanciando può rispondere ai clienti con la voce del tuo marchio, non con il tono neutro di un LLM qualsiasi.

Se vendi prodotti complessi — elettronica, attrezzatura, articoli tecnici — qui c’è un’occasione vera. Tutte le domande di nicchia che oggi ti arrivano via ticket o restano sepolte nelle recensioni puoi trasformarle in risposte che l’IA dà al posto tuo, al momento giusto, mentre il cliente sta ancora decidendo.

Il titolo torna a vendere

Questo è il pezzo che quasi tutti si perdono, perché è travestito da burocrazia.

Per dichiarare un contenuto scritto dall’IA, Google ti chiede due attributi dedicati: structured_title e structured_description. Funzionano uguali: dentro ci metti il testo nel sotto-attributo content (stesso limite del titolo classico, 150 caratteri, stesse regole) e segnali la provenienza con digital_source_type impostato su trained_algorithmic_media. Per le immagini lo stesso lavoro lo fanno i metadati IPTC DigitalSourceType (TrainedAlgorithmicMedia, CompositeSynthetic, AlgorithmicMedia), che non vanno mai cancellati dai file usciti da strumenti come Product Studio.

A leggerla così sembra un adempimento per tenere buoni i legislatori. E in parte lo è. Ma chi si ferma qui non ha capito la mossa. Google sa benissimo che il feed di mezzo mondo è generato in automatico: una regola che mette insieme brand, modello, colore e taglia e produce “Nike Air Max 90 – Rosso – 42” per diecimila prodotti. Funzionale, freddo, identico a quello di tutti gli altri. Aprendo un canale apposta per i contenuti scritti dall’IA, Google sta chiedendo un’altra cosa: adesso voglio qualcosa che venda.

Lo dice il suo stesso esempio ufficiale. Stesso prodotto, due titoli:

* automatico: “Original Google shoes, mens, size 8, blue and orange”

* scritto dall’IA: “Stride & Conquer: Original Google Men’s Blue & Orange Power Shoes (Size 8)”

Il secondo ha un gancio, il primo è un’etichetta da magazzino. structured_title è la porta che fa rientrare nel feed il copy persuasivo che dieci anni di “titoli a regola” avevano escluso. Ed è qui che nasce la confusione che vedo ovunque. Non è “scritto a mano” contro “scritto da un software”, perché il feed lo genera sempre un software. È generativo (un modello che scrive) contro deterministico (una regola che combina i campi). Solo il primo va etichettato. Il secondo resta un title normale.

Due avvertenze, perché qui gli errori si pagano.

La prima è tecnica, e fa sprecare il lavoro a molti. Se vuoi che il titolo persuasivo venga usato davvero, devi mandare solo structured_title. Se gli lasci accanto anche il title classico, Google usa quello classico, e il tuo titolo — etichetta IA compresa — non lo vede nessuno.

La seconda pesa di più. Un titolo che si legge meglio non è automaticamente un titolo che si posiziona meglio. Il titolo resta il segnale con cui il motore aggancia il prodotto alle ricerche: una stringa piena di keyword come “memory foam king size medium firm” prende più query, un titolo elegante ne prende meno. Solo che il motore sta cambiando sotto i piedi mentre fai questo ragionamento. Quel calcolo valeva quando posizionarsi voleva dire incrociare parole chiave. Dentro AI Mode, Gemini, il Business Agent, l’IA non cerca la corrispondenza esatta: legge e riassume. Lì un titolo che spiega davvero il prodotto può battere la stringa-keyword. Il titolo perfetto del 2024 e quello del 2026 potrebbero non essere lo stesso, e per un bel po’ ti toccherà ottimizzare per due motori che convivono.

Dove starei attento

Primo: la parola “facoltativo”. Google ripete che questi attributi sono opzionali e che senza non perdi l’approvazione del prodotto. Vero, e fuorviante. Facoltativo vuol dire che il prodotto resta a catalogo, in un catalogo che però l’IA smette di citare. Lo scrive la documentazione stessa: ometterli “garantisce quasi certamente un calo della visibilità nelle risposte generate dall’intelligenza artificiale”. È facoltativo come è facoltativo avere un sito che si carica. Tecnicamente sì, nella realtà no.

Secondo: chi fa il lavoro? Tutta questa impalcatura scarica sul venditore il compito di rendere accurata l’IA di Google. Sei tu a spacchettare le schede tecniche, a scrivere 30 domande e risposte per ogni prodotto, a produrre i PDF. Google ti vende il beneficio — meno allucinazioni, più visibilità — ma il conto, su un catalogo da migliaia di referenze, lo paghi tu. E lo paghi nel modo peggiore: più il catalogo è ricco e tecnico, più la fatica si concentra proprio sui prodotti che avrebbero più da guadagnarci.

Cosa farei se gestissi un e-commerce

Non aspetterei la “fase di applicazione rigorosa”. Quando arriva, chi ha popolato il feed prima è già davanti.

Partirei dai prodotti che contano. Prendi il 20% di referenze che fa l’80% del fatturato e su quelle compila product_detail, question_and_answer e variant_option come se la visibilità dipendesse da lì, perché dipende da lì. Le 30 domande non te le devi inventare: sono già scritte nei ticket dell’assistenza e nelle richieste che ti arrivano ogni settimana.

Sui contenuti scritti dall’IA smetterei di trattarli come un adempimento normativo e li userei per quello che sono: spazio per fare copy. Guarderei chi in azienda genera testo con un LLM, lo farei passare da structured_title e structured_description con l’etichetta giusta — solo lo strutturato, senza il campo classico accanto — e proverei a scrivere titoli più persuasivi della solita stringa, misurando se vendono di più. Tenendo a mente la regola che salva l’account: se un umano scrive e l’IA ritocca, non si etichetta; se il testo lo produce la macchina, anche col tuo prompt, si etichetta.

E non perderei di vista il quadro grande: la vecchia Content API chiude il 18 agosto 2026 in favore della Merchant API, e l’Universal Commerce Protocol porta il checkout dentro l’IA. Gli attributi sono quello che dici all’IA; quell’infrastruttura è quanto in fretta glielo dici e dove si chiude la vendita. Messi insieme — feed ricco e acquisto automatico — non sono il solito aggiornamento di Google Shopping. Sono altro.

Il bersaglio è Amazon

Mettiamo in fila i due pezzi. Da una parte un feed così ricco che l’IA scopre, confronta e consiglia un prodotto senza che l’utente apra nemmeno un sito. Dall’altra l’Universal Commerce Protocol e l’Universal Cart, che chiudono l’acquisto dentro la conversazione, con Google Pay già pronto, senza uscire dalla chat. Trovi, confronti e compri senza cambiare schermata.

Quel “senza cambiare schermata”, fino a ieri, aveva un nome solo: Amazon. Il fossato di Amazon non l’ha mai costruito il prezzo, l’ha costruito l’assenza di attrito: cerchi, leggi recensioni e domande, compri con un tocco. È per questo che una grossa fetta delle ricerche di prodotto parte da lì, saltando Google. Ricostruendo quell’esperienza sul web aperto, con dentro il feed dei venditori, Google prova a riprendersi il terreno che Amazon gli aveva tolto.

E c’è una differenza che a chi vende interessa più di ogni altra cosa. Su Amazon sei un venditore terzo: il cliente è suo, i dati sono suoi, la relazione è sua, e per stare nel marketplace paghi. Nel modello di Google il venditore resta il seller of record: i dati di vendita, il cliente, la fedeltà e la logistica restano tuoi. La promessa è seducente: la comodità di Amazon senza diventare uno dei tanti dentro Amazon.

Per questo non leggo gli attributi del feed come l’ennesimo adempimento tecnico. Sono munizioni in una guerra tra piattaforme. Il feed ricco è quello che fa scegliere te invece del concorrente; l’attributo native_commerce è quello che accende il tasto “Acquista” dentro la risposta. Senza, ti citano ma non ti comprano: sei in vetrina, ma la cassa è da un’altra parte. Lo stesso lavoro che ti rende visibile è quello che ti rende vendibile, nell’arena dove Google ha deciso di sfidare Amazon.

In sintesi

Il feed non è più un accessorio del marketing. Nell’epoca della ricerca conversazionale è diventato il primo ingresso alla tua vetrina, spesso l’unico, e con il checkout dentro l’IA anche la cassa. Chi lo tratta ancora come un file tecnico da aggiornare una volta al mese si ritroverà fuori dalle conversazioni in cui i clienti scelgono cosa comprare, senza nemmeno accorgersene.

La domanda da portare in riunione non è più “il feed è approvato?”. È “il mio feed è abbastanza ricco perché un’IA scelga me e non il concorrente che ha compilato gli attributi che io ho saltato perché tanto erano facoltativi?”.

Filippo Trocca scrive di misurazione avanzata, attribuzione e analytics su dataMesh. Se vuoi confrontarti su come misurare le performance del tuo business, scrivimi a [email protected].

Grazie per aver letto dataMesh! Condividi il post

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit filippotrocca.substack.com

Mercoledì 20 maggio, durante il Google Marketing Live, Google ha presentato due novità che, viste insieme, valgono più di tutto il resto del keynote: Meridian integrato dentro Google Analytics 360 e le Qualified Future Conversions, una metrica che usa Gemini per prevedere conversioni fino a sei mesi nel futuro.

Sembra l’ennesima release di prodotto. Non lo è. È il cambio di paradigma più importante nella misurazione del marketing da quando è stato lanciato GA4. Per la prima volta un Marketing Mix Model — tool che fino a ieri vivevano solo data scientist e vendor da 200k all’anno — diventa un tool di business intelligence interrogabile in linguaggio naturale, integrato nativamente dentro Google Analytics 360.

C’è una parte buona, e c’è una parte che mi preoccupa. Provo a raccontarvele entrambe.

La parte buona

Meridian dentro GA360 non è un fork: il codice resta open-source su GitHub. Quello che Google ci ha messo sopra è la parte che ha sempre tenuto fuori dal gioco la maggior parte delle aziende: ingestione dei dati first-party (BigQuery, HubSpot, Shopify, Salesforce) attraverso il Data Manager — l’API unificata che dal 2025 alimenta Google Ads, Analytics e DV360 — pull cross-channel di spesa e impression da Meta, TikTok, Pinterest e Snap, e un’interfaccia agentica che ti permette di chiedere “se sposto 100k da Performance Max a TikTok, cosa cambia?” senza scrivere una riga di Python. Il demo sul palco mostrava un piano annuale che, ottimizzato dal modello, faceva +50% di ROAS sul baseline.

Le Qualified Future Conversions sono un animale diverso. Non sono modeled conversion che riempiono buchi di tracking. Sono una stima probabilistica generata da Gemini su un evento non ancora accaduto, ancorata a comportamenti intermedi osservabili: ricerche brandizzate, like o subscribe su YouTube, add-to-cart, avvio di lead form.

Il dato interno che le giustifica dovrebbe far rizzare le antenne a chiunque gestisca budget upper-funnel: solo il 70% delle conversioni Google Ads cade dentro la finestra standard 30-day click / 3-day engaged-view. Per Performance Max si scende al 50%. Per Demand Gen al 40%. Tradotto: per metà delle campagne di brand building, le finestre di attribuzione di oggi stanno tagliando via metà del valore reale. È il primo serio tentativo di metterci una pezza dentro la stessa piattaforma che vende il media.

Da qui in poi, però, le cose si complicano.

La parte che mi preoccupa

Il piano dichiarato — scritto nei comunicati e ripreso da PPC Land — è che i segnali QFC verranno usati come input per Meridian. Cioè: Gemini, addestrato sul comportamento osservato dentro Google Ads, sputerà fuori una previsione che diventerà uno degli ingredienti del Marketing Mix Model che dovrebbe dirci se i nostri soldi su Google Ads stanno rendendo. Lo stesso Google che ci dice quanto bene sta funzionando Google.

Jordan Taylor-Bartels, CEO di Prophet, intervistato da Mi3, l’ha sintetizzata meglio di come potrei fare io: “It wouldn’t be very Googley if Meridian recommends all spend goes to Meta.”

Non è l’unico problema. Ne vedo altri due.

Il primo è la stazionarietà. Lo dice la documentazione ufficiale: Meridian non modella l’efficacia dei canali come time-varying. Cioè assume che il rendimento di ogni canale resti costante nella finestra che stai osservando. Chiunque abbia gestito campagne sa che non è così — creative fatigue, saturazione dell’audience, stagionalità, lanci dei competitor, sono la regola. Michael Kaminsky di Recast, autore della critica tecnica più dettagliata su Meridian, indica questa come la lacuna principale.

Su questo vale la pena guardare cosa fanno realtà con approccio metodologicamente diverso. AD cube — spinoff del Politecnico di Milano nato dal dipartimento DEIB — restituisce l’andamento di ciascun canale settimana per settimana, come serie storica. Differenza concettuale, non solo operativa: Meridian ti dà un coefficiente per canale valido per l’intera finestra modellata; AD cube ti mostra come quel coefficiente si muove nel tempo — quando un canale entra in saturazione, quando la creatività perde colpi, quando una campagna stagionale funziona e quando smette. Per chi rinfresca le creatività ogni due o tre settimane (chiunque venda online seriamente nel 2026), cambia la natura della decisione: non stai più validando la strategia di un trimestre, stai correggendo il portafoglio in corsa.

Il terzo problema è il più sottile. È il conflitto di interesse strutturale, raccontato meglio di tutti da Aryma Labs e Keen Decision Systems: Google e Meta sono insieme i paladini dell’open-source MMM e i vendor dello spazio pubblicitario che quel MMM dovrebbe valutare. Aryma ha aggiunto un dettaglio statistico importante: i Bayesian MMM mostrano la media della distribuzione posteriore invece dell’Highest Density Interval, e per la natura lognormale questa scelta gonfia sistematicamente i ROI dei canali. Non è un bug, è una conseguenza matematica del modo in cui il modello è impacchettato.

Nessuno di questi tre rischi rende Meridian inutilizzabile. Ma messi insieme, rendono la validazione indipendente una cosa che fino al 20 maggio era opzionale e da oggi è obbligatoria.

Cosa farei se fossi un CMO

Partiamo da un dato di realtà che la narrazione sull’agentic UI tende a nascondere: un MMM non si usa da solo, neanche se è dentro GA360 con un’interfaccia in linguaggio naturale. Un Marketing Mix Model è un modello statistico complesso, e perché restituisca valore vero — non solo dashboard belle — ti serve qualcuno che lo sappia leggere, calibrare, interrogare. Un consulente esterno, un’agenzia specializzata, o un data scientist in casa. Le agentic UI riducono la frizione della query, non quella dell’interpretazione.

A quel consulente chiederei due cose insieme, non in alternativa. Una: portare avanti Meridian-in-GA360 come baseline, se l’azienda ha già la licenza. Due: girare in parallelo un MMM indipendente come strumento di verifica. È la stessa logica del doppio audit di bilancio: il secondo serve a esporre il bias del primo quando c’è.

Il test specifico è semplice: prendi la stima di channel contribution dei due modelli e confrontala. Se i canali Google appaiono il 10-30% più incrementali in Meridian rispetto al modello indipendente, hai trovato la direzione del bias.

E se non hai GA360? È la situazione della stragrande maggioranza delle aziende italiane. Tre opzioni realistiche.

La prima: un MMM open-source girato da un partner o consulente. “Open-source MMM” non significa “Meridian”: c’è Robyn di Meta (R, ridge regression, community ampia), PyMC Marketing (Python, fully Bayesian, più flessibile di Meridian), Orbit di Uber per serie con stagionalità marcata. È nella scelta dello strumento che il consulente fa la differenza rispetto a chi “fa girare Meridian”.

La seconda: una piattaforma MMM self-serve indipendente — AD cube, Cassandra, Mutinex Self-Serve, Recast, Measured, Sellforte — con il consulente che la pilota.

La terza, per chi ha budget pubblicitari sotto i 500k all’anno: rinunciare all’MMM strutturato e costruire un setup minimo basato su esperimenti di incrementalità geografica e attribution model.

In tutti e tre i casi, il pezzo non delegabile resta la persona che interpreta i risultati.

Sulle QFC, attivale subito in un account pilota. Il tracking parte dal giorno dell’attivazione, e quando deciderai di usarle come segnale per le bidding strategy ti servirà uno storico di almeno sei mesi da validare contro l’LTV osservato. Meglio iniziarli oggi che fra sei mesi.

Calibra sempre con esperimenti. Meridian GeoX è la risposta nativa quando arriverà; fino ad allora si scelgono i vendor — Haus, Measured, Sellforte, Lifesight (unified MMM + geo experimentation), INCRMNTAL (always-on via causal inference, senza geo holdout), LiftLab (disegno di esperimenti controllati), e Cassandra che integra incrementality testing nella sua piattaforma — oppure si costruisce un framework geo in casa su librerie open-source mature: GeoLift di Meta (Synthetic Control Methods end-to-end in R) e CausalImpact di Google (Bayesian structural time series, R e Python). Un MMM non calibrato contro un esperimento controllato non è uno strumento di budgeting difendibile in un comitato esecutivo — è un’opinione.

Cosa farei se fossi un CFO

Prima di firmare qualunque riallocazione di budget basata su QFC, chiederei al fornitore documentazione metodologica sulla pipeline QFC→Meridian. Come gestisce la circolarità? Come isola il segnale di Gemini dai dati di input che già contengono comportamento Google Ads? Se nessuno risponde, non firmo.

Il TCO, qui, si fa serio. GA360 a ~50k l’anno è il biglietto di ingresso. Aggiungi il consulente o l’agenzia (60-150k l’anno se interno, 30-80k se contractor part-time: la voce più sottovalutata di tutte), validazione indipendente (5-15k), esperimenti di incrementalità (10-30k per ciclo, due o tre cicli l’anno), eventualmente un MMM vendor indipendente per la triangolazione (50-150k per la fascia enterprise). Il numero finale rende “MMM gratis dentro GA360” un’etichetta da marketing, non una verità da bilancio.

Disciplina aggiuntiva: validare le previsioni QFC contro l’LTV osservato. Ogni cohort di QFC attivate oggi va seguita per sei mesi. Quante delle conversioni previste si sono materializzate, e con quale margine? È lo stesso backtesting che il vostro team finance fa già sui modelli di forecasting. Applicatelo qui senza fare sconti.

In pratica si fa così. Step uno: ogni mese registri il numero di QFC che Google attribuisce a ciascuna campagna nell’interfaccia di Google Ads — quello è il tuo predetto, il numero da battere. Step due: nel data warehouse (BigQuery se sei già nell’ecosistema Google, Snowflake o altro se non lo sei) ricostruisci la stessa cohort che Google sta valutando — gli utenti GA4 che nel mese hanno performato una delle Leading User Actions (branded search via Search Console, engagement profondo su YouTube, add-to-cart, avvio lead form). Tutte attivabili in GA4 con eventi custom o lette dalle API delle rispettive piattaforme. Step tre: a 30, 60, 90 e 180 giorni, conta quanti utenti di quella cohort hanno effettivamente convertito, con quale valore d’ordine e con quale margine. Step quattro: confronti l’osservato con il predetto. Se Google ti aveva dato la cohort di maggio per 24.000 conversioni future e a sei mesi ne hai contate 14.000, hai un’over-prediction del 70% — il tipo di errore che, davanti a un comitato di forecasting finanziario, fa ridiscutere il modello. Soglia operativa: errore medio sotto il 20% per tre cicli consecutivi per accettare QFC come segnale per le bidding strategy; sopra il 30%, è ancora rumore — utile per direction, non per allocation.

Soglia decisionale: sotto i 2-3 milioni di spend pubblicitario annuo, o 25M eventi al mese, GA360 non è giustificabile economicamente. Meglio orientarsi su tool open-source via partner o su piattaforme indipendenti che includono il supporto del data scientist nel pacchetto: AD cube e Cassandra — due nomi italiani ed europei che stanno crescendo bene — integrano MMM, incrementality testing e attribuzione in self-service con un loro data scientist a supporto. Per scale più grandi: Mutinex Self-Serve, Recast, Measured, Paramark, Sellforte.

Dove sta andando la misurazione

Meridian-in-GA360 è inevitabile. Diventerà la baseline cross-channel della misurazione enterprise nei prossimi due anni, e chi non la valuta seriamente passerà tre anni a giustificare perché non l’ha fatto.

Ma una baseline non è un oracolo. La differenza tra chi userà bene questa tecnologia e chi finirà per sbatterci la testa contro non sarà la qualità del modello — Meridian è un buon modello, lo dico senza ironia — ma la disciplina con cui lo si valida. Il setup difendibile davanti a un comitato esecutivo è fatto di quattro pezzi che lavorano insieme: il modello di Google come baseline, un modello indipendente in parallelo per due o tre cicli di refresh, esperimenti geografici per calibrare i prior, un framework di confronto che esponga le divergenze. Soprattutto, una persona che sa leggerli.

La domanda da portarsi in sala riunioni non è più qual è il mio ROAS. È chi sta misurando il mio ROAS, e quanto ha da guadagnare dal numero che mi sta restituendo?

Quella domanda, fino a ieri, era teorica. Da oggi è la prima cosa che ogni CFO dovrebbe scrivere nella prossima vendor review.

Filippo Trocca scrive di misurazione avanzata, attribuzione e Marketing Mix Modeling su dataMesh. Se vuoi confrontarti su come impostare un framework di validazione MMM nella tua organizzazione, scrivimi a [email protected].

Filippo Trocca scrive di misurazione avanzata, attribuzione e Marketing Mix Modeling su dataMesh. Se vuoi confrontarti su come impostare un framework di validazione MMM nella tua organizzazione, scrivimi a [email protected].

Fonti citate

* Google Analytics 360 helps you turn data into decisions — Google Blog

* Google Marketing Live 2026: turn your data into decisions — Google Blog

* Qualified future conversions — Google Business

* Meridian lands inside Analytics 360 as Google links ad spend to future sales — PPC Land

* Google brings Meridian marketing mix modeling into Analytics 360 — Search Engine Land

* MMM unmuddled: Mutinex lands industry-wide backing for open-sourced model comparison framework — Mi3

* Mutinex Pips Google By Launching Self-Serve Commercial Mix Model — B&T

* Hits and Misses of Meridian – A Thorough Deep Dive — Aryma Labs

* Bayesian MMM inflates ROIs — Aryma Labs

* Google Ads Launches New Tools For Mapping Incrementality — AdExchanger

* Open MMM Validation Framework — Mutinex

* Meridian documentation — Google for Developers

* Meridian on GitHub

* AD cube — Marketing Mix Model — ML cube, spinoff del Politecnico di Milano

* Cassandra — Marketing Mix Modeling Software

* Data Manager API helps advertisers improve measurement — Google Blog

* Robyn — Open Source MMM by Meta

* PyMC Marketing — Open Source Marketing Analytics

* Orbit on GitHub — Uber

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit filippotrocca.substack.com

l'Identity protocol: Smettete di investire su "Profili Fantasma".Se i dati non sono vivi il vostro margine è in pericolo: la checklist per arrestare l'emorragia.A: Il Board Da: The Revenue Architect Oggetto: Diagnostica Week 1 / Il Problema “Dead Data”

La diagnosi della scorsa settimana è stata chiara: La vostra AI si sta addestrando su dati “morti”. State pianificando campagne su fantasmi, questo gonfia artificialmente il CAC e Rende il LTV una metrica di pura fantasia.

Oggi programmiamo la soluzione: non si tratta di fare “pulizia dati”, ma di installare il sistema operativo per rendere i ricavi efficienti: il protocollo di Identity Resolution.

L’Equazione Economica: Un Cliente, Dodici Costi.

Il vostro cliente non è statico. Nel 2026, un utente high-value interagisce con voi ovunque: Laptop, App, Instagram, Negozio Fisico e molto altro.

Nel vostro database grezzo, quella singola persona non esiste, esistono invece 12 frammenti scollegati:

* Fantasma 1: Un cookie anonimo del browser (Utente X).

* Fantasma 2: Una email da “guest checkout” (Utente Y).

* Fantasma 3: Un ID del programma fedeltà del 2021 (Utente Z).

* Fantasmi 4-12: ID Mobile, Email aziendali, IP della Connected TV, Cookie scaduti e Click ID di Facebook.

Il Buco di Bilancio: Pagate per acquisire l’utente X. Pagate ancora per il retargeting sull’utente Y. Pagate una terza volta per inviare email all’utente Z.

Pagate tre volte per acquisire la stessa persona.

L’Identity Resolution ricuce questi 12 fantasmi in un unico Golden Record, ferma lo spreco; crea il segnale pulito di cui la vostra AI ha bisogno per prevedere il futuro.

La Strategia: Eliminare la “Black Box”

Fino a ieri, il problema si risolveva acquistando una CDP (Customer Data Platform) monolitica, una “Black Box”. Inviavate i dati a un fornitore esterno, loro li elaboravano, li rivendevano a voi

Questo modello è obsoleto.

* Rischio: Inviate PII (Dati Personali) fuori dal perimetro aziendale.

* Costo: Pagate un “doppio affitto” (Storage nel vostro cloud + Storage nel cloud del vendor).

* Cecità: Non avete visibilità sul perché due profili siano uniti.

Il Nuovo Standard: Warehouse-Native (Zero-Copy) Non spostate i dati verso lo strumento, ma lo strumento si connette ai vostri dati. I moderni motori di identità girano direttamente sulla vostra infrastruttura (Snowflake/Databricks/BigQuery/AWS ecc).

* Sicurezza: I dati non lasciano mai la vostra governance.

* Velocità: Risoluzione in tempo reale.

* Costo: Zero-copy. Pagate per la logica, non per lo storage ridondante.

La Decisione: scegliere il Vostro Profilo di Rischio

Non chiedete “Qual è il tool migliore?”. Chiedetevi: “Qual è il trade-off strategico che accettiamo?”. Esistono 4 architetture valide per il 2026, Sceglietene una.

L’Esecuzione: Direttive Operative

Una volta definita la strategia, questo è il mandato operativo per il vostro Data Team:

* Speed: Contrattualizzare una Composable CDP (es. Hightouch, Bytek Prediction Platform). Connetterla ai vostri dati. Dare al Marketing le chiavi per sincronizzare le audience direttamente su Meta/TikTok/Google Ads

* Automated: Contrattualizzare un Vendor di AI Identity (es. Amperity). Ingerire tutte le tabelle legacy grezze. Lasciare che il loro modello costruisca il grafo. Non tentare sviluppo interno.

* Control: Costruire un Private Graph usando AWS Entity Resolution. Le PII non devono lasciare il nostro VPC. Il Marketing richiede le audience tramite ticket.

* Google: Centralizzare tutto in BigQuery. Utilizzare la risoluzione ID nativa di Google. Inviare i segmenti direttamente a Ads Data Hub.

La Checklist Tecnica (Audit)

Consegnatela al vostro Head of Data. Richiedete una risposta “Pass/Fail” entro fine giornata.

Test 1: Il Muro del Login (The “Logged-In” Wall)

* La Domanda: “Siamo in grado di identificare i visitatori del sito prima che effettuino il login?”

* La Risposta Sbagliata: “No, tracciamo i cookie ma sappiamo chi sono solo dopo il login.”

* Il Costo: State ignorando il 95% del vostro funnel. State facendo bid su sconosciuti.

Test 2: Audit dei Costi Ridondanti (Double Rent)

* La Domanda: “Stiamo pagando un vendor esterno per archiviare dati che sono già presenti nel nostro Warehouse?”

* La Risposta Sbagliata: “Sì, il marketing cloud necessita di una propria copia dei dati per funzionare.”

* Il Costo: State pagando due volte per lo storage e aumentando la superficie di attacco. Migrazione immediata a Warehouse-Native.

Test 3: Rapporto Utenti/Profili

* La Domanda: “Qual è il rapporto tra ‘User ID’ unici e ‘Profili di Fatturazione’ nel database?”

* La Risposta Sbagliata: “Circa 5 a 1.” (o superiore)

* Il Costo: State trattando un cliente fedele come fossero cinque estranei. Il vostro modello di LTV è un’allucinazione.

Riepilogo

L’Identity Resolution non è una pratica IT, è la differenza tra un’AI che prevede il fatturato e un’AI che ha allucinazione.

Sistemate il livello dati, ricucite i profili fantasma: arrestate l’emorragia.

Settimana Prossima: Valideremo tutto questo con l’unica persona a cui importano davvero i soldi: il CFO. Analizzeremo il Report McKinsey: conferma che il 90% dei budget marketing sta navigando alla cieca.

Notizie Per me interessanti

Dinners are the new trade shows. Here’s how to run them well by Emily Kramer

How to do AI analysis you can actually trust by Lenny Rachitsky

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit filippotrocca.substack.com

È lunedì mattina, ore nove, la riunione del Consiglio di Amministrazione procede con quella familiarità rassicurante che caratterizza gli incontri di routine. Il Direttore Commerciale apre l’immancabile Excel per dimostrare che i target trimestrali sono stati raggiunti, il CMO indica una dashboard con il ROAS in verde, il CFO annuisce compiaciuto.

Tutto sembra sotto controllo, eppure c’è un problema che nessuno percepisce: state guardando un referto autoptico. Celebrate transazioni chiuse settimane fa, costruite strategie su indicatori che per loro natura raccontano solo il passato. Che vendiate software enterprise o borse di lusso, gestire un’azienda affidandosi esclusivamente a CRM e report finanziari equivale a guidare a centocinquanta all’ora fissando lo specchietto retrovisore: sapete da dove venite, ma la strada davanti - dove il mercato sta andando, chi sta per lasciarvi - rimane invisibile.

Il paradosso è che tutti corrono ad implementare l’AI, ma la maggior parte delle aziende la sta alimentando con dati già morti. Costruiscono modelli sofisticati su transazioni storiche e poi si stupiscono quando le “insight predittive” assomigliano alle tabelle pivot dell’anno scorso con una veste grafica più moderna. Il problema non è l’AI che avete scelto, ma quello che le date in pasto.

Grazie per leggere dataMesh! Iscriviti gratuitamente per supportare il mio lavoro.

Il Buco Nero dell’Offline

C’è una verità scomoda: il novanta percento del valore di un cliente non sta nella transazione finale, ma nel percorso comportamentale che la precede. Il CRM registra che Giulia ha comprato una borsa nel negozio di via Montenapoleone, ma non vede le cinque visite al sito, le ads su Instagram, le recensioni consultate nelle due settimane precedenti.

Senza Identity Resolution, il team Digital vede zero conversioni e un costo per acquisizione alle stelle, il team Retail si prende tutto il merito, e il CFO taglia il budget digital perché “non performa” - segando il ramo su cui l’azienda era seduta. Con Identity Resolution, invece, scoprite che i touchpoint digitali hanno influenzato il quaranta percento del percorso d’acquisto di Giulia, e invece di difendere il budget alla prossima riunione vi trovate a chiedere investimenti aggiuntivi sulle campagne che portano clienti alto-spendenti in negozio.

Nel B2B la cecità è altrettanto grave. Mentre leggete, tre ingegneri di un potenziale cliente potrebbero star studiando la vostra documentazione tecnica senza aver compilato alcun form. Per il vostro CRM non esistono. Nel frattempo un competitor con Identity Resolution ha già identificato il loro IP aziendale, sa cosa stanno valutando, e ha fatto partire l’outreach. Quando il vostro Sales si sveglia, la partita è già persa.

Il Segnale: Dove l’AI Incontra l’Intenzione

È qui che l’intelligenza artificiale smette di essere una buzzword da presentazione e diventa un’arma competitiva concreta. Identity Resolution vi fornisce i dati giusti - quelli che collegano l’identità di un cliente attraverso i diversi touchpoint. L’AI vi dà la velocità e la scala per agire su quei dati prima che l’opportunità svanisca. Separati, nessuno dei due basta. Insieme, creano un sistema che non solo registra cosa è successo, ma prevede cosa sta per succedere e vi dice esattamente cosa fare.

Considerate il rischio di abbandono nel B2B. Avete un cliente storico che paga puntuale e rinnova ogni anno - tutte le metriche sono verdi, ma collegando l’identità aziendale al comportamento di navigazione, l’AI vede una storia diversa: tre persone di quell’azienda hanno passato le ultime quarantotto ore sulle vostre pagine “Disdetta contratto” ed “Esportazione dati.” Non stanno curiosando, stanno preparando l’uscita.

Il sistema riconosce il pattern—l’ha già osservato in centinaia di account che poi hanno disdetto - calcola una probabilità di abbandono del settantatré percento entro trenta giorni, e allerta automaticamente l’Account Manager con un piano d’intervento suggerito. Sapete che stanno per andarsene prima che loro stessi ve lo comunichino. Le aziende che usano questi segnali comportamentali potenziati dall’AI riducono il churn del 15%/25% - non perché abbiano Account Manager migliori, ma perché agiscono su intenzioni predittive invece di reagire a una PEC di disdetta.

Lo stesso vale per l’attribuzione nel retail. Quando unite i dati della carta fedeltà con i cookie di navigazione e ci sovrapponete un layer di AI, le opinioni diventano fatti: il modello vi dice quali combinazioni di campagne generano conversioni in-store, quali segmenti rispondono all’awareness e quali alla performance, dove il prossimo euro investito avrà l’impatto maggiore. Smettete di litigare sull’attribuzione nelle riunioni e lasciate che sia il modello a darvi la risposta.

“Ma con il GDPR si può fare?”

L’obiezione sulla compliance emerge sempre, ma è qui che l’AI risolve il problema della privacy invece di aggravarlo.

Il GDPR non è un muro, è un filtro qualitativo. Non potete tracciare il cento percento degli utenti, ma non vi serve: in un ecosistema sano ottenete il consenso dal 60%-75% dei visitatori. E questo basta!

Il meccanismo: usate i dati di alta qualità degli utenti consenzienti per addestrare i modelli di machine learning, che imparano i pattern comportamentali di “Churner”, “High Spender”. Poi applicate quei modelli probabilistici al traffico anonimo. Non state identificando nessuno senza consenso - state riconoscendo comportamenti. L’AI dice: “Questa sessione anonima si comporta all’ottanta percento come i nostri High Spender conosciuti”. Personalizzate l’esperienza senza mai sapere chi sia quella persona.

Non state aggirando la legge, state costruendo un motore predittivo conforme che diventa più intelligente a ogni interazione. Le aziende che trattano il GDPR come un ostacolo stanno perdendo terreno rispetto a quelle che lo usano come leva per una data strategy più solida.

Da Archivio a Motore: Il Data Stack Pronto per l’AI

Se i vostri dati restano fermi in attesa del report mensile, avete un archivio polveroso - un centro di costo che produce slide per il CdA. Qui sta la verità che pochi vendor vi raccontano: potete montare l’AI più sofisticata del mercato su un archivio polveroso, ma otterrete solo polvere elaborata più velocemente. Garbage in, garbage out.

Con l’Identity Resolution, quell’archivio diventa un motore predittivo in tempo reale. Create la base dati unificata di cui l’AI ha effettivamente bisogno per mantenere le promesse, e smettete di nutrire i modelli con le transazioni di ieri per dar loro le intenzioni di oggi.

Le aziende che domineranno i prossimi tre anni non saranno quelle con i budget AI più grossi, ma quelle che avranno risolto prima il problema dei dati - quelle che hanno smesso di guidare fissando lo specchietto retrovisore e hanno iniziato a fidarsi di un GPS potenziato dall’AI che non si limita a mostrare il percorso, ma prevede il traffico, suggerisce scorciatoie, e vi fa cambiare corsia prima che vi accorgiate del problema.

Da Dove Partire

Se sospettate che la vostra azienda stia investendo in AI senza la base dati per farla funzionare, fate queste tre domande ai vostri team Sales e Data questa settimana:

“Riusciamo a collegare un acquisto in negozio alla visita sul sito che lo ha generato?” Se no, avete un buco nell’attribuzione che falsa ogni decisione di investimento e qualsiasi AI implementiate erediterà quella distorsione.

“Sappiamo quando un cliente esplora la sezione del sito come uscire dal contratto?” Se no, la vostra retention è reattiva, non predittiva, e state lasciando sul tavolo il caso d’uso AI a più alto ritorno.

“Quale percentuale dei visitatori del sito riusciamo a identificare anche senza form compilati?” Se siete sotto il trenta percento, i vostri modelli AI si addestrano su una fetta distorta della realtà.

Se avete risposto “no” a una qualsiasi di queste domande, non state facendo Business Intelligence: s tate facendo contabilità con un chatbot sopra.

Cosa vi hanno risposto i vostri team? Scrivetemi: leggo ogni messaggio, e le conversazioni più interessanti diventano spesso i prossimi articoli.Per approfondire scarica il mio ebook Non Puoi Fare AI se i tuoi dati sono nel caos

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit filippotrocca.substack.com

La promessa della nuova “Agentic Era” è seducente. L’idea di agenti autonomi in grado di costruire i tuoi modelli, acquistare i tuoi spazi media e modificare le tue creatività sembra la soluzione perfetta per qualsiasi leader. Ma se guardi da vicino come funziona l’automazione, questa promessa non dovrebbe solo entusiasmarti: dovrebbe preoccuparti.

Il pericolo sta nel fatto che l’IA è, essenzialmente, un acceleratore: è una macchina progettata per ottimizzare esattamente l’obiettivo che le assegni. Se la nutri con dati distorti o metriche sbagliate, non si limiterà a commettere errori, ma scalerà quegli errori a una velocità che nessun team umano potrà mai gestire.

Negli ultimi dieci anni, siamo stati ossessionati dalla ricerca di una “Single Source of Truth”, questa ricerca ci ha lasciato con strumenti disconnessi e dipartimenti in conflitto. Per sopravvivere al passaggio verso processi decisionali guidati dall’AI, dobbiamo smettere di cercare: non abbiamo bisogno di una verità unificata; abbiamo bisogno di un sistema di Decisioni Unificate, dove il Marketing Mix Model (MMM) e l’Attribution smettono di farsi la guerra e iniziano a collaborare sotto il controllo della Sperimentazione.

Grazie per leggere dataMesh! Iscriviti per ricevere nuovi post e supportare il mio lavoro

La Guerra Civile: Strategia contro Comfort

Abbiamo passato anni a combattere una guerra civile tra due metodologie che avrebbero dovuto essere alleate:

* Da una parte c’è il CFO e il consiglio di amministrazione, che preferiscono il Marketing Mix Model. Lo vedono come una bussola strategica perché parla la lingua della finanza, tiene conto della stagionalità e resiste a esami approfonditi. Tuttavia, per i team operativi, l’MMM spesso appare troppo lento, troppo “macro” e scollegato dal lavoro quotidiano di ottimizzazione delle campagne.

* Dall’altra parte, i team Growth e Media si aggrappano alla Digital Attribution. La amano non perché sia precisa, ma perché è facile: agisce come un calmante per la nostra ansia, fornendoci numeri immediati e dettagliati che sembrano azionabili. Ma conosciamo il segreto: l’attribuzione standard è sbilanciata verso il “bottom of the funnel”, adora prendersi il merito per ricavi che sarebbero arrivati comunque.

Nell’era dell’IA, dobbiamo renderci conto che queste sono semplicemente due facce della stessa medaglia: non puoi avere una strategia senza esecuzione, ma non puoi nemmeno lasciare che un agente IA ottimizzi il tuo budget basandosi solo sull’attribuzione. Se lo fai, la macchina smetterà di acquistare annunci per nuovi clienti e spenderà tutto il budget per fare retargeting su persone che stavano già per acquistare: ottimizzerà l’efficienza fino a uccidere la tua crescita.

La Rivoluzione Meta: Ottimizzare per la Causalità (Il Caso Zalando)

Questa non è solo teoria. La più grande “Black Box” del settore , Meta, ha recentemente validato questo cambiamento, utilizzando l’IA per spostare l’obiettivo dalla correlazione alla causalità.

Per anni, lo standard è stato ottimizzare il ROAS basandosi sull’attribuzione per eventi, ma come sappiamo, un clic ti dice che qualcuno era interessato, non che l’annuncio ha causato l’acquisto. È qui che il business case di Zalando cambia la narrazione.

Zalando non voleva solo misurare il lift (l’incremento); voleva ottimizzare per esso. Per farlo hanno utilizzato l’Attribuzione Incrementale di Meta, un’impostazione avanzata che cambia il modo in cui l’algoritmo apprende.A differenza dell’attribuzione standard, che conteggia qualsiasi conversione avvenuta dopo una visualizzazione o un clic, l’Attribuzione Incrementale utilizza modelli di machine learning per prevedere se una conversione è stata veramente causata dall’annuncio. Rimuove il “rumore” ,le persone che avrebbero comprato comunque, e concentra il motore solo su quelle conversioni che non sarebbero avvenute senza l’inserzione.

Il risultato è enorme: sposta l’obiettivo da “Chi cliccherà?” a “Chi ha bisogno di questo annuncio per convertire?”.Zalando ha così allineato il proprio media buying con il reale impatto di business, generando conversioni incrementali vere invece di limitarsi a gonfiare delle vanity metrics.

La Sperimentazione è la Rete di Sicurezza

Tutto questo implica un massiccio cambiamento operativo: non puoi indovinare la causalità. L’IA è un motore di predizione , prevede chi è probabile che acquisti basandosi su pattern, ma senza i giusti dati, le manca il contesto per capire perché hanno acquistato. Qui la Sperimentazione diventa lo strato più importante del tuo stack tecnologico. È il guardrail che impedisce ai tuoi agenti automatizzati di vedere successi dove non ce ne sono.

Pensa alla tua architettura dati come a un tribunale: l’Attribution è solo un testimone, che offre un resoconto soggettivo e limitato degli eventi da un’unica angolazione. L’MMM è la giuria, che soppesa le prove per formare un consenso. Ma la Sperimentazione? La Sperimentazione è il test del DNA: è la scienza che batte le opinioni e fornisce la vera prova del valore.

La Nuova Architettura per il 2026

Per costruire una revenue stack in grado di utilizzare l’IA in sicurezza, il flusso di lavoro deve cambiare da un processo lineare a un ciclo continuo.

* Usa l’econometria e l’MMM per soddisfare il board e definire il tuo macro-budget, ottenendo il supporto strategico per operare.

* Lascia che le piattaforme e i loro agenti IA gestiscano l’esecuzione e il buying, ma abilita funzionalità come l’Attribuzione Incrementale per assicurarti che inseguano l’obiettivo giusto.

* Infine, costruisci un livello di validazione dedicato. Questo significa destinare una percentuale fissa del tuo budget esclusivamente ai test: devi eseguire Geo-Lift test sui nuovi canali e mantenere gruppi di controllo (holdout groups) sulle tue campagne “best performing”.

In futuro, gli architetti della crescita di maggior successo non saranno quelli con l’IA più potente. Saranno quelli che forniranno ai propri modelli le regole e i dati con qualità più alta.

Non lasciare che la macchina si dia i voti da sola: sii tu l’insegnante.

Notizie che hanno destato il mio interesse

The state of Marketing Measurement in 2026 and Beyond by Aryma Labs

Incremental Attribution - Optimizing ad delivery for incremental conversions by Meta

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit filippotrocca.substack.com