Creazione di una CDP personalizzata e arricchimento dei dati sugli eventi con GTM server-side

Prima di effettuare un acquisto, i clienti interagiscono con i brand attraverso vari canali, sia online che offline. Ciò può rendere difficile per gli specialisti di marketing e analytics monitorare queste interazioni in un unico posto. Gli strumenti standard come Google Analytics o il tracciamento server-side di Matomo spesso non riescono a tracciare gli eventi offline. Per risolvere questo problema, si utilizzano solitamente le Customer Data Platform (CDP). 

Un modo per utilizzare una CDP consiste nell'acquistare uno strumento già pronto, che tuttavia può risultare costoso. Un'altra opzione è creare la propria CDP. In questo articolo mostreremo come realizzare una versione semplice di CDP utilizzando il Google Tag Manager server-side e un database. 

Questa configurazione consente di combinare tutte le informazioni sui clienti in un unico posto, rendendo più semplice comprenderli e contattarli in modo più efficace. Che Lei sia agli inizi con il tracciamento o uno specialista esperto, questa guida La aiuterà a creare una CDP che migliorerà notevolmente la gestione dei dati dei clienti.

Il contenitore server di Google Tag Manager riceverà le richieste relative a tutte le interazioni dell'utente, sia online che offline. È possibile utilizzare client standard come GA4 o Data Client per ricevere eventi online dal GTM web. Per recuperare gli eventi offline, è possibile utilizzare i webhook. Più avanti nell'articolo mostrerò come inviare ed eseguire il debug dei dati dei webhook all'interno di sGTM.

Indipendentemente dal tipo di dati ricevuti da sGTM, questi verranno archiviati nel database. Esistono diversi database con cui sGTM può essere integrato, ad esempio Firebase, Supabase (molto più economico di Firestore) o Data Store. In questo caso utilizzerò Stape Data Store, poiché si tratta di una funzionalità integrata all'interno di Stape ed è gratuita per i clienti con un piano a pagamento di Stape (piani Pro o superiori).

Oltre a sGTM e allo store, utilizzeremo anche un identificatore univoco dell'utente, che aiuterà ad archiviare i dati di un singolo utente nello stesso documento. 

1. Sorgente di dati (CRM, SDK, CMS, app mobile, sito web, ecc.).

2. Contenitore server GTM.

3. Database (in questa guida utilizzerò Data Store. È possibile utilizzare anche Firestore o Supabase, per il quale Stape ha creato il tag Supabase writer).

4. Per leggere/scrivere dati dal database è possibile utilizzare questi modelli sGTM:

• Tag Stape Store writer
• Variabile Stape Store lookup
• Variabile Stape reStore
• Tag Firestore Writer (nel caso in cui si utilizzi Firestore)
• Variabile Firestore reStore
• Tag Supabase Writer (nel caso in cui si utilizzi Supabase)
• Variabile Supabase Lookup

5. Identificatori utente univoci. In questa guida utilizzerò uno User ID univoco o lo User ID di WordPress generato dal plugin WordPress di Stape. 

Ecco come fluiscono i dati dell'utente dalla sorgente di dati (CRM) alla CDP:

1. 1.
   Ogni volta che un utente effettua un acquisto, il CRM invia un webhook a sGTM. 
2. 2.
   Il Data Client in sGTM elabora la richiesta in arrivo in sGTM e la mappa nel formato di sGTM. 
3. 3.
   Nel contenitore server GTM utilizziamo la variabile reStore per verificare se l'utente che ha effettuato l'acquisto esiste già nel database. Se l'utente esiste, verifichiamo se la richiesta contiene nuove informazioni sull'utente e uniamo i dati più recenti con quelli nel database. Dopodiché, scriviamo le informazioni arricchite. Se l'utente non esiste, creiamo semplicemente un nuovo record cliente. 
4. 4.
   Unire i dati dell'utente nella richiesta in arrivo con i dati dell'utente nel database. Ad esempio, se il parametro città manca nel webhook del CRM e non è presente il campo city, questo campo verrà recuperato dallo Store. Se le richieste in arrivo contengono il campo city ma lo Store non lo include, oppure è diverso, i dati della richiesta relativi a questo campo verranno scritti nello store.
5. 5.
   Utilizzare un profilo cliente completo per inviarlo al fornitore tramite una connessione server-to-server.

1. 1.
   Sito web. I due modi più diffusi per inviare dati dal sito web a sGTM sono la configurazione di GA4 server-side e il Data Tag.
2. 2.
   Webhook del CRM (HubSpot, Salesforce, Jira, ecc.).
3. 3.
   CMS. È possibile utilizzare i plugin per il tracciamento server-side di Shopify, WordPress o Magento 2 Google Tag Manager per inviare webhook di rimborsi e acquisti a sGTM.
4. 4.
   SDK e applicazione mobile. Stape ha creato SDK per iOS, Android, PHP e Node.js.
5. 5.
   Elaboratori di pagamento (Stripe, Braintree, ecc.).

Il metodo di ricezione dei dati dipende dalla modalità con cui si inviano i dati a sGTM. Ecco i tre modi per ottenere i dati:

1. 1.
   Client GA4. Funziona se si utilizza GA4 per trasmettere i dati a sGTM.
2. 2.
   Client Measurement Protocol. Può essere utilizzato per controllare il tipo di richiesta inviata a sGTM e renderla conforme allo standard di Measurement Protocol. Di solito si tratta del codice dell'applicazione.
3. 3.
   Data Client. Può essere utilizzato quando non si ha il controllo sulle richieste in arrivo poiché, in Data Client, è possibile modificare il percorso della richiesta, ad esempio per un webhook di Stripe.

Questa è la parte più complessa e fondamentale. Per creare una CDP adeguata, è necessario disporre di dati precisi sugli utenti e sulle loro azioni con il brand. La CDP deve contenere informazioni aggiornate e dati chiari e non duplicati. Per costruire un simile sistema di profili utente, è necessario uno User ID appropriato. 

Per gli utenti identificati, è possibile utilizzare un'e-mail o un ID interno utilizzabile su diversi sistemi. Se un utente non è identificato, può trattarsi di uno Stape User ID composto da un hash di:

• IP del client (IPv4/IPv6)
• User-Agent del browser
• Impostazioni TLS del browser
• Hostname

Se il Suo brand gestisce diversi domini, può anche abilitare l'opzione Cross-domain ID nel power-up User ID. Questa genera un ID aggiuntivo (X-Stape-Cross-Domain-Id) a partire dagli stessi segnali ma senza hostname, in modo che lo stesso utente non identificato ottenga un unico ID su tutti i domini collegati al contenitore server. Ciò aiuta a evitare profili duplicati nella CDP.

Se, per motivi di conformità alla privacy, desidera rendere il Suo User ID ancora più univoco, può aggiungere una variabile dipendente. Può trattarsi di giorno, mese, settimana o anno. Tutto dipende dal livello di univocità richiesto per l'ID. 

Utilizzeremo la variabile reStore oppure il tag Stape Store Writer e Stape Store Lookup per unire e riconciliare i profili utente dalle richieste e dal database. Le copie di questi modelli sono disponibili anche su GitHub di Stape.

Il tag writer e le variabili di ricerca sono piuttosto intuitivi. Questi due modelli consentono di scrivere e leggere dati da Data Store. 

La variabile reStore identificherà innanzitutto se l'utente esiste nel database. In primo luogo, la variabile recupera tutti gli identificatori utente dal nostro evento (e-mail, telefono o client ID). Quindi, invia una query allo Store per selezionare i clienti che possiedono uno di questi identificatori. Se nel database sono presenti informazioni sul cliente, restituirà i dati relativi a tale cliente.

Quando una variabile riceve la risposta dallo Store, la unisce alla richiesta in arrivo. Ad esempio, se non esiste alcun campo city, verrà utilizzato questo campo dello Store. Se le richieste in arrivo contengono un campo city ma lo Store non lo include, oppure è diverso, i dati della richiesta per questo campo verranno scritti nello store. Questa variabile crea una nuova entità se un cliente viene trovato solo parzialmente nello store.

Una volta elaborati e formattati nel formato di sGTM, i dati possono essere utilizzati per l'invio a qualsiasi fornitore desiderato, come Meta, TikTok, Google Ads o Analytics. Presti attenzione ai dati utente inviati nelle richieste. 

Il debug in sGTM è complesso, ma gli eventi offline possono essere ancora più insidiosi. Esamineremo come utilizzare quanto segue:

• Debugger di sGTM
• Log di Access/Request/Response di Stape
• Tag Logger
• Preview Header di sGTM

Presenterò due casi d'uso per dimostrare come utilizzare Data Store. Abbiamo riscontrato che questi sono gli scenari più diffusi per i clienti di Stape.

1. Configurare lo User ID. Utilizzerò il power-up User ID di Stape che aiuterà a unire gli utenti ai clienti.

a. Acceda al Suo account Stape e attivi il power-up. A tale scopo, apra il container sGTM, faccia clic sulla scheda Power up, apra lo User ID, attivi l'interruttore e salvi.

b. Nel container Server GTM, crei una variabile che recuperi lo User ID dalle intestazioni della richiesta nel server.

2. Scrivere i dati nel database in corrispondenza dell'evento purchase. Si assicuri di aggiungere lo User ID di Stape ai dati dell'evento. 

a. Aggiunga un tag Stape store writer alla galleria dei template di sGTM (lo scarichi da GitHub e lo importi nella sezione dei template di tag di sGTM) e crei un tag per scrivere i dati dell'evento in corrispondenza di un evento purchase. Scriverò tutti i dati dell'evento e aggiungerò uno User ID di Stape al record dello store. Ne avremo bisogno per unire gli utenti in corrispondenza di un evento pageview.

b. Se il tag ha funzionato correttamente, vedrà nel Suo database un record simile allo screenshot riportato di seguito.

3. Arricchisca i dati dell'evento pageview con i dati archiviati nel Data Store.

a. Per associare gli utenti dell'evento page view a quello che memorizziamo nel database, utilizzeremo nuovamente lo User ID di Stape e la variabile Stape Store Lookup in grado di recuperare i dati dallo store. Aggiunga la variabile Stape Store Lookup alla galleria dei template di variabili di sGTM. Per scaricare il template da GitHub, vada alla sezione dei template di sGTM. Faccia clic su Nuovo nella sezione delle variabili, quindi su Importa.

b. Crei una variabile Stape Store Lookup per i parametri che desidera ripristinare: ad document path e path name. 

c. Aggiunga una variabile Lookup al tag pageview. 

4. Testi la configurazione. Dovrebbe visualizzare i dati utente arricchiti nel tag attivato nel container sGTM. 

In questo caso d'uso desidero inviare dati di eventi offline a una rete pubblicitaria. Quando si inviano dati di conversione alla piattaforma pubblicitaria, l'elemento fondamentale è l'invio di un click ID. Il click ID è un identificatore aggiunto all'URL o ai cookie quando l'utente fa clic sul link pubblicitario. Con l'aiuto del click ID, la rete pubblicitaria può attribuire facilmente la conversione alla campagna pubblicitaria. 

I Click ID sono disponibili per tutti gli eventi web, ma se desidera utilizzare i dati di conversione del CRM o del CMS da inviare alla rete pubblicitaria, nella maggior parte dei casi i click ID non sono disponibili.

Per configurare questa opzione, utilizzerò la variabile di ripristino di Stape per scrivere i dati nel Data Store su pageview e ripristinarli sugli eventi purchase. Oltre a ciò, avrò bisogno di una trasformazione nel contenitore sGTM per arricchire l'evento inviato a Facebook. Un altro elemento critico è la corrispondenza tra gli utenti negli eventi pageview e gli utenti nei webhook di acquisto offline. A tale scopo, è necessario utilizzare un identificatore utente che rimanga lo stesso sia negli eventi pageview sul web sia negli acquisti offline. 

Con i CMS standard, questo risultato è facile da ottenere poiché di solito presentano questo tipo di identificatore nei cookie. Per i siti web personalizzati, sarà necessario chiedere agli sviluppatori di aggiungere questi parametri. La mia configurazione è realizzata su un sito WordPress. Il plugin WordPress di Stape invia un User ID univoco negli eventi web e lo aggiunge al webhook. Utilizzando questo User ID, posso associare gli utenti tra un evento pageview e i webhook di acquisto nel database. 

1. Ricevere il webhook di acquisto dalla sorgente dati offline all'interno di sGTM. 

a. Invii un webhook dal CRM. Utilizzerò l'app WordPress di Stape a questo scopo. Acceda alla scheda Webhooks e aggiunga l'URL del contenitore Server GTM. Questo è il dominio utilizzato per il Suo contenitore GTM server-side. Consigliamo di configurare un dominio personalizzato all'interno del dominio del Suo sito web, poiché consentirà di impostare cookie di prima parte. Non dimentichi di selezionare le caselle di controllo. 

b. Aggiunga il Data Client ai template dei client di sGTM e lo configuri per recuperare i webhook inviati dal CRM. A tale scopo, crei un template di Data Client e aggiunga un percorso Webhook.

c. Configuri il power-up Preview Header config di sGTM su Stape per eseguire il debug dei webhook in entrata in sGTM. Vada all'anteprima di sGTM, faccia clic sui tre puntini nell'angolo in alto a destra e selezioni "Send requests manually". Copi l'intestazione HTTP X-Gtm-Server-Preview e la incolli nel power-up Preview Header config di sGTM.

d. Apra il debugger di sGTM e verifichi che abbia ricevuto i webhook. Una volta attivato il webhook, dovrebbe vedere la richiesta in arrivo all'interno di sGTM e constatare che il client dati ha preso in carico tale richiesta.

2. Scriva i parametri fbc, fbp e client ID dell'evento pageview nel database.

In questo passaggio, Le mostrerò come scrivere i parametri fbc e fbp nel database utilizzando la variabile reStore. Per farlo, utilizzeremo un tag Facebook pageview per attivare gli eventi pageview e una trasformazione che scriverà i dati nello store tramite la variabile restore.

a. Aggiunga una variabile restore alle variabili di sGTM utilizzando questo link. Dovrà scaricarla da GitHub, creare un nuovo modello di variabile in sGTM e fare clic su Import.

b. Configuri la variabile restore. Dovrà utilizzare uno User ID di WordPress e un identificatore e scrivere fbp, fbc e lo User ID di WordPress nello store.

c. Crei una trasformazione che arricchisca i dati degli eventi sugli eventi pageview di Facebook utilizzando la variabile restore e aggiunga questa trasformazione al Suo tag FB pageview.

d. Testi la configurazione. Se tutto è configurato correttamente, dovrebbe vedere i dati registrati nel Data Store. 

e. Configuri un evento purchase di Facebook che si attivi ogni volta che viene ricevuto un webhook. Per arricchire questo evento con i dati del Data Store, dovremo utilizzare una trasformazione e la stessa variabile di ripristino impiegata per la trasformazione su un evento pageview di FB. Ciò consentirà di estrarre il parametro richiesto su un evento purchase. Tuttavia, per inviare i dati nel formato riconosciuto da Facebook, dovremo utilizzare una variabile Object Extractor che estrae l'oggetto richiesto dalla variabile di ripristino.

f. Testi la configurazione. Se tutto funziona correttamente, dovrebbe vedere che i parametri fbc e fbp sono stati inviati con successo a Facebook o su un evento purchase offline.

Grazie a Data Store, è possibile creare un database clienti o una CDP. Questo strumento offre un modo semplice per raccogliere e archiviare tutte le informazioni ottenibili dai clienti, utili per creare moduli di analisi migliori o incrementare i risultati delle campagne a pagamento. Potenziare e arricchire i dati dei clienti consente di ottenere informazioni approfondite sul loro comportamento e sulle loro preferenze, aiutando a sua volta a perfezionare le strategie di marketing.