Skip to main content

Webinar - Futuro senza cookie EP 3: Attivare le audiences con meno dati

Migrazione Server-side: perché procedere passo dopo passo

| , ,

La migrazione al tagging server-side deve avvenire gradualmente, partner per partner. L’obiettivo è gestire le tempistiche per “testare e apprendere” e di lavorare sulla qualità dei  dati.

 

Optare per il tagging server-side non significa che tutti i partner debbano essere migrati nello stesso momento. Al contrario, le best-practices sul tema indicano che oggi la strategia migliore per le aziende è seguire un approccio progressivo. Le ragioni sono almeno due. In primo luogo, non tutti i partner sono ancora pronti per un’implementazione dei tag server-side. In secondo luogo, è consigliabile gestire le tempistiche per testare e apprendere le metodologie più corrette di implementazione.

Di conseguenza, almeno per i prossimi mesi, la gestione dei tag non sarà né totalmente client-side né totalmente server-side ma… ibrida. Come procedere? Innanzitutto, preparando la vostra organizzazione al tagging server-side, poi seguendo i seguenti passi per l’implementazione.

 

Fase #1: scegliere l’architettura

Oggi sono possibili due metodi per implementare una raccolta server-side: Le API e  il “master tag” – questi due metodi possono essere anche adottati contemporaneamente. Il primo consiste nell’utilizzare le API server-side fornite da una piattaforma come Commanders Act per trasmettere tutti gli eventi previsti nel contesto dei vostri casi d’uso. A tal fine, è necessario catalogare gli eventi per ciascuno di questi casi.

Il metodo “master tag”, è così chiamato perché, anche nel  server-side, prevede l’implementazione di un unico tag. È questo il tag che raccoglie tutti gli eventi richiesti dai vostri scenari all’interno del browser, per comunicarli alla soluzione server-side per l’elaborazione.

In questo caso, è necessario prendere una precauzione: questo tag deve essere implementato in modalità first-party. In caso contrario, browser come Safari o Firefox   (e Chrome l’anno prossimo) inibiscono questo tag, con conseguente perdita di dati. Fortunatamente, tramite il processo di delega del sottodominio, è possibile posizionare il master tag Commanders Act come tag di prima parte.

 

Fase 2: lavorare sulla qualità dei dati

Questa è una fase critica e necessita massima attenzione. I dati raccolti dal server-side rappresentano il vostro “hub di dati”: la base di dati su cui si baseranno le

attivazioni dei vostri partner. Questo è anche il momento giusto per rivedere il datalayer e il catalogo degli eventi da integrare. L’obiettivo è quello di migliorare la raccolta dei dati, naturalmente, ma anche di anticipare la diffusione di nuovi casi d’uso.

Questa attività dovrebbe essere l’occasione per impostare la “ricezione dei dati”. Gli obiettivi sono due: in primo luogo, garantire che il consenso sia propagato correttamente, in modo che le informazioni diffuse ai vari partner siano in linea con le preferenze dell’utente. In secondo luogo, garantire che i dati siano normalizzati e quindi formattati in modo da poter essere utilizzati.

Per questo Commanders Act mette a disposizione diversi strumenti (source data quality o live events inspector) per ricevere i dati inviati al data hub e verificarne la qualità. Questa attività può essere svolta in tempo reale e la piattaforma fornisce gli strumenti necessari, in particolare con una funzione di “data cleansing” che consente di correggere automaticamente i dati errati prima di inviarli ai partner.

Dedicare tempo alla qualità dei dati è un prerequisito e un vantaggio. Un prerequisito perché, senza dati di qualità, il meccanismo server-side si inceppa rapidamente. Un vantaggio, perché la maggiore qualità genera anche attivazioni più precise, e quindi un ritorno tangibile sugli sforzi e campagne più efficaci.

 

Passo #3: Migrare un primo partner

Il metodo di raccolta è stato concordato? I dati sono stati elaborati? È il momento di migrare un primo partner, se possibile un “buon candidato”, cioè un partner che ha ben documentato il processo di migrazione. È il caso, ad esempio, di Facebook, che, come altri, raccomanda di conservare entrambi i flussi di dati, client-side (dal pixel classico) e server-side (dalla “Conversion API”), per un periodo di osservazione.

Questo periodo servirà a controllare la qualità dei dati inviati. A tal fine, Commanders Act offre diversi strumenti di monitoraggio e di allerta nella sua piattaforma, in modo che questo lavoro di “test and learn” possa essere svolto in tutta tranquillità.

 

 

Una volta impostato il connettore server-side, è necessario un periodo di osservazione, ad esempio due settimane, per garantire che non si verifichino interruzioni del servizio. Dopo questo periodo, il tag client-side può essere disattivato per mantenere solo l’attivazione server-side.

La buona notizia è che questa attività è automaticamente a vantaggio degli altri partner e quindi contribuisce ad accelerare le migrazioni successive. Attingete al catalogo delle destinazioni di Commanders Act e pianificate queste migrazioni.

 

 

Per completare con successo la migrazione server-side, non rimanete intrappolati in un   sistema di project management pressato da scadenze. Date priorità alla migrazione dei partner in base alle linee guida aziendali e coinvolgete i team media nelle varie fasi del progetto. Soprattutto, datevi il tempo di lavorare sulla qualità dei vostri dati e di testare le implementazioni, un partner alla volta. I vostri  dati meritano il tempo e l’attenzione necessaria.

Perché il server-side diventerà il vostro miglior alleato? Scopritelo nel nostro white paper.

Per non perdere nessuna delle ultime notizie di Commanders Act, iscriviti alla nostra newsletter!  

© Commanders Act. Tutti i diritti riservati.
Powered by CREAATION.