Le liste Customer Match scadono dopo 540 giorni

Customer Match in scadenza: Google punta sulle API, Amazon automatizza i flussi first-party

Google promette che i tuoi dati sono al sicuro dietro un hash SHA256 e una certificazione ISO 27001. Peccato che la vera minaccia per la misurazione non sia una violazione: è il silenzio. Lo si legge nella documentazione ufficiale di Google Ads: il sistema trasforma le informazioni di contatto degli account Google in codici hash usando SHA256, un meccanismo unidirezionale che Google non decifra. Se non aggiorni le liste, il pubblico Customer Match smette di essere un asset e si riduce a un errore.

La stessa documentazione aggiunge che Google non utilizza i file caricati per scopi diversi dalla creazione dei pubblici Customer Match e dalla verifica di conformità alle politiche, e cita la certificazione ISO 27001 ottenuta per sistemi, applicazioni, persone, tecnologia, processi e data center che servono diversi prodotti Google, incluso Customer Match. Il punto, però, non è cosa Google promette di non fare con i dati: è cosa succede quando chi carica i dati smette di farlo.

La promessa di sicurezza (e la scadenza che non ti aspetti)

La promessa ufficiale si concentra sulla protezione: hashing unidirezionale, uso limitato dei file, certificazione ISO 27001. Ma lascia in secondo piano un vincolo molto più operativo: le liste Customer Match hanno una durata massima di appartenenza di 540 giorni. Non si tratta di una nota a margine: è il ciclo di vita del pubblico. La sicurezza descritta da Google è statica, la lista è dinamica, e il documento non mette in evidenza con la stessa forza cosa accade allo scadere della finestra.

È un paradosso per chi si occupa di misurazione. Da un lato, l’infrastruttura è raccontata come certificata e protetta; dall’altro, il dato che alimenta la misurazione ha una data di scadenza implicita. La domanda che resta aperta è semplice: cosa succede se non aggiorni? La risposta non è una notifica, ma un errore.

L’errore che arriva quando non fai nulla

Per rimanere idonea, una lista Customer Match deve avere almeno 100 membri aggiunti o aggiornati negli ultimi 540 giorni. La soglia non misura la qualità del pubblico, non valuta la somiglianza con i clienti reali, non stima il valore incrementale: misura soltanto se qualcuno continua ad alimentare il flusso. È un requisito di attività, non di accuratezza.

La conseguenza pratica è già formalizzata da marzo 2026. Secondo la documentazione per sviluppatori, chi non ha adottato Customer Match, o non ha caricato dati su una lista Customer Match tra ottobre 2025 e marzo 2026, riceve un errore se tenta di caricare su una lista Customer Match. Non un avviso con un periodo di grazia, non un suggerimento per riattivare la lista: un errore. Per un analyst che deve giustificare la spesa, questo cambia il significato del pubblico. Un audience non è un dato stabile, un record che resta fermo e utilizzabile nel tempo: è un flusso che richiede manutenzione costante.

Il rischio è il decadimento silenzioso. Una lista inattiva non scompare con un allarme nel cruscotto: diventa inutilizzabile al momento dell’upload, spesso quando il team si accorge del problema soltanto in fase di campagna. Il danno non si vede nel report di sicurezza, ma nel confronto tra il pubblico pianificato e il pubblico realmente disponibile. E quando Google sposta l’infrastruttura verso le API, il costo di questa fragilità rischia di emergere soltanto a conti fatti.

Dalle liste statiche alle API: il vero campo di gara

Mentre le liste statiche scadono, l’infrastruttura si muove. La scorsa settimana Search Engine Journal ha segnalato che Google sta ampliando la Data Manager API adottando uno standard cross-platform di IAB Tech Lab ed estendendo Data Manager a Google Analytics e DV360. La direzione è chiara: meno caricamenti manuali, più integrazioni continue, con l’obiettivo di spostare la misurazione dalle liste statiche ai flussi di dati.

La concorrenza si sta già muovendo sullo stesso terreno. Nella documentazione di Amazon Ads si legge che le audience vengono automaticamente hashati e trasferite in Amazon DSP per l’uso diretto nelle campagne. Come per l’hashing SHA256 di Google su email e telefono, Amazon hasha in automatico i segnali first-party e li streamma in Amazon DSP, consentendo agli inserzionisti di unire chiavi hashate di email, telefono, nome e indirizzo.

La contrapposizione è significativa: da un lato, Google ancora insiste sulla manutenzione minima delle liste; dall’altro, Amazon spinge sull’automazione e sullo streaming continuo. La competizione non si gioca più su chi ha la certificazione migliore o l’hash più robusto, ma su chi controlla l’integrazione tra dati first-party, DSP e ambienti di analytics. Resta aperta la domanda su chi, alla fine, controllerà la chiave della misurazione cross-platform.

Il cliente non dovrebbe sentirsi rassicurato dall’hashing. Dovrebbe chiedersi se i suoi strumenti di misurazione stanno già marcendo silenziosamente, e se la prossima certificazione conterà davvero quando la chiave dei dati è in mano alle piattaforme. La sicurezza dichiarata protegge il dato nel passaggio, ma non protegge la continuità del pubblico. E la continuità, più della crittografia, è ciò che tiene in piedi il confronto tra pianificato e reale.