Google Analytics introduce Data Manager in beta: un punto di gestione per collegamenti, flussi e dati proprietari. Prima di attivare nuove connessioni serve però ricostruire quelle già operative: uno stesso dato può arrivare alla stessa destinazione attraverso più percorsi.
Google ha annunciato la novità il 6 novembre 2026 nelle note di rilascio di Analytics. La copertura di settore del 9 novembre riguarda quell’annuncio: non identifica una seconda data di lancio.
Il nuovo pannello rende visibili le connessioni: l’audit parte dalla loro funzione
La guida ufficiale di Data Manager descrive una mappa di sorgenti, tipi di dato, proprietà e destinazioni, affiancata dalla gestione di stream e prodotti collegati. L’accesso è nell’amministrazione di Analytics, sotto “My preferences”. È una beta aperta, soggetta a modifiche; servono permessi adeguati e la pagina iniziale non supporta sottoproprietà e proprietà di raggruppamento.
La prima verifica tecnica riguarda lo scopo di ciascun collegamento. Per ogni linea della mappa, il team dovrebbe poter rispondere a quattro domande: quale sistema produce il dato, che cosa viene trasferito, quale proprietà lo riceve e quale decisione usa quel dato. Se manca una risposta, conviene completare l’inventario prima di aggiungere una connessione.
La direzione dei dati decide dove configurare la pipeline
Google distingue le nuove connessioni, da iniziare in Analytics, da quelle esistenti in Ads o Google Marketing Platform, da continuare a gestire lì. Gli import Analytics esistenti compaiono nel nuovo pannello. La guida avverte che i dati acquisiti attraverso Data Manager in Analytics possono proseguire verso gli account Ads/GMP collegati, non nel verso inverso: attivare la stessa pipeline nelle due interfacce può contare due volte le conversioni.
Il controllo operativo consiste quindi nell’identificare una responsabilità di configurazione per ciascun percorso. Questo non impone che un ordine possa essere misurato da un solo sistema: impone di sapere perché ogni invio esiste e come viene riconciliato con gli altri. Spegnere un’integrazione soltanto perché appare simile a un’altra, senza confrontarne destinazione e funzione, rischia di interrompere una misurazione utile.
Prima di collegare il CRM, distinguere eventi e arricchimenti
La documentazione Data Import distingue l’importazione di eventi dagli arricchimenti di prodotto, utente o campagna. Anche il momento di associazione cambia: alcuni dati vengono uniti durante l’elaborazione, altri quando si consulta un report. La cancellazione di un file non va quindi interpretata come un annullamento universale dei suoi effetti.
Per esempio, aggiungere la categoria merceologica a un prodotto e inviare un acquisto completato sono due operazioni con obiettivi diversi. Nell’inventario devono avere righe separate, anche quando provengono dallo stesso gestionale. Prima di intervenire, annotare il tipo di importazione, le chiavi di associazione e l’effetto atteso sul report.
Una matrice tecnica per censire le connessioni
La seguente è una struttura di lavoro proposta per l’audit, non un’esportazione dell’interfaccia né una configurazione già verificata su un account.
| Campo da registrare | Verifica da eseguire | Evidenza da conservare |
|---|---|---|
| Sorgente e responsabile | Individuare chi produce il record e chi può modificare il connettore. | Sistema, ambiente e referente. |
| Destinazione esatta | Controllare proprietà, stream, account e azione di conversione interessati. | Identificatori, non soltanto nomi visualizzati. |
| Tipo di dato e significato | Distinguere acquisto, richiesta, vendita conclusa e arricchimento. | Definizione dell’evento e campi mappati. |
| Identità del record | Ricostruire come un ordine o evento viene riconosciuto nei diversi passaggi. | Chiave, regola di generazione e gestione dei reinvii. |
| Pianificazione e recuperi | Controllare frequenza, intervallo elaborato e comportamento dopo un errore. | Ultima esecuzione, registro dei tentativi e lotto. |
| Configurazione attiva | Verificare dove viene amministrata la pipeline e quali alternative restano accese. | Stato iniziale, modifica prevista e piano di ripristino. |
ID transazione: la deduplicazione ha un ambito preciso
Per gli acquisti, Google Analytics documenta la deduplicazione di eventi purchase con lo stesso transaction_id. L’identificatore deve essere univoco per ordine e non vuoto; riutilizzarlo per acquisti diversi può sottostimare i risultati. Sono requisiti da controllare nella sorgente, come spiega la guida agli ID transazione di Analytics.
Google Ads descrive invece il riconoscimento dei duplicati rispetto alla stessa azione di conversione e allo stesso identificatore. Per le conversioni offline usa la denominazione “Order ID”. La guida Ads richiede coerenza degli ID fra tag e invii server-to-server nei percorsi che li combinano.
Per l’audit, questo significa verificare l’ambito della deduplicazione prima di considerare sicuri due invii. La presenza di un ID non dimostra che due azioni diverse vengano riconciliate. E un evento di richiesta informazioni e una successiva vendita possono rappresentare due fasi distinte: vanno confrontati usando la definizione commerciale concordata, non soltanto il numero delle righe.
Come verificare una nuova connessione senza alterare tutti i flussi
Quella che segue è una procedura di collaudo proposta, da adattare al connettore e all’ambiente disponibili.
- Fotografare lo stato iniziale. Salvare configurazione, destinazioni e criterio di conteggio dei percorsi interessati. Registrare data e ora dell’intervento.
- Scegliere un campione identificabile. Usare record di prova in un ambiente idoneo, con esito atteso dichiarato. Separare i test dai dati utilizzati per valutare le campagne.
- Verificare la mappatura. Confrontare identità, timestamp, valore e valuta ove applicabili. Documentare trasformazioni e campi esclusi.
- Seguire il record fino alla destinazione. Raccogliere le evidenze di invio, ricezione ed elaborazione previste dal prodotto. Annotare le latenze, evitando confronti su finestre ancora incomplete.
- Collaudare il reinvio, dove consentito. Ripetere lo stesso record di test e confrontare il risultato con le regole documentate. Non usare una nuova identità per simulare il recupero dello stesso evento.
- Estendere gradualmente. Procedere sul flusso successivo soltanto dopo aver spiegato le discrepanze del campione e predisposto il ripristino.
Le discrepanze vanno spiegate per record e per finestra temporale
Un ordine presente nel gestionale e assente da un report richiede una diagnosi diversa da un ordine contato due volte. Per ogni eccezione conviene registrare l’ultimo passaggio dimostrabile: prodotto dalla sorgente, inviato, elaborato oppure visibile nella destinazione.
Prima del confronto, allineare fuso orario, periodo, significato del valore e stato commerciale: un ordine annullato non va confrontato con una vendita confermata senza esplicitare la differenza. Anche il criterio di attribuzione deve far parte della verifica. L’uguaglianza immediata fra tutti i totali non è un criterio di accettazione sufficiente.
Un esito tecnico utile è un elenco di record riconciliati e di eccezioni spiegate, accompagnato da una configurazione di cui siano noti responsabile e destinazione. Solo a quel punto il team può decidere se estendere il collegamento e quali dati usare nei report aziendali.