Iscriviti alla nostra newsletter Tea O'Clock!
Il punto più importante e più critico nella migrazione tra i due strumenti è la costruzione dei tag e-commerce, che comprendono informazioni sul tipo di prodotto.
In effetti, in GA4, si trovano più prodotti inviati tramite un oggetto javascript - l'oggetto "items" - per un solo evento di e-commerce.
A Piano, i prodotti vengono inviati "a piatto" all'interno dello stesso oggetto javascript che contiene le proprietà* di un evento. Si hanno quindi più eventi che prodotti presenti nel Data Layer. "Conosciamo bene il punto dolente dell'integrazione della nostra soluzione di e-commerce. Lavoreremo per semplificare questo aspetto molto presto...", assicura Benjamin Diolez, Product Owner di Piano.
Si noti inoltre che il nome delle variabili è diverso tra GA4 e Piano.
Inoltre, esistono differenze a livello di eventi "view_promotion" e "select_promotion" di GA4, che possono essere denominati rispettivamente "publisher_impression" e "publisher_click" o "self_promotion.impression" e "self_promotion.click". In effetti, dal lato Piano, gli eventi di tipo "publisher" e gli eventi di tipo "self_promotion" possono essere utilizzati in modo intercambiabile. Di conseguenza, si parla semplicemente di "editore".
Inoltre, al centro di questi eventi, si riscontra un'altra importante differenza a livello di costruzione dell'oggetto "items": in GA4, è in un oggetto javascript (con tutti i prodotti interessati nell'oggetto), mentre in Piano non è previsto, in quanto questi punti di misura non sono considerati come e-commerce in modalità nativa.
Inoltre, i parametri standard utilizzati per il Piano non sono identici a quelli utilizzati per il GA4.
Inoltre, se esistono altre differenze di eventi e di parametri tra le due piattaforme, la flessibilità di Piano permette di creare tutti gli eventi personalizzati che si desiderano e offre fino a 1000 proprietà personalizzate per rispondere in modo adeguato a ogni caso.
Per affrontare nel modo più efficace possibile le differenze di struttura tra le due piattaforme, Piano ha creato e messo a disposizione un modello di tag e di variabile; questo permette di semplificare enormemente il lavoro di lettura della struttura di tipo GA4 inserita nel Data Layer rispetto a quella che i tag di Piano richiedono.
Realizzati da Piano e migliorati e testati in collaborazione con fifty-five, questi template consentono una migrazione fluida tra le due piattaforme e assicurano che gli eventi più importanti della raccolta siano disponibili nell'interfaccia di Piano Analytics senza alcuno sforzo. "La nostra collaborazione continua con fifty-five ci ha permesso di creare un template di tag robusto che fa parte di tutta la flessibilità che offre Piano Analytics e il suo modello di dati. Viene già utilizzato dai consulenti di Piano Analytics per diversi progetti con operatori dell'e-commerce e della vendita al dettaglio in tutto il mondo", afferma Charles Dieppois, Product Manager di Piano.
Che cosa fa il template?
Oltre a queste funzioni di migrazione, il modello propone diverse azioni per procedere alla migrazione semplice e migliorare la raccolta:
Inoltre, la migrazione tra i due strumenti è molto semplificata. I modelli offrono un notevole guadagno di tempo ed evitano il coinvolgimento di altre squadre nel processo di migrazione della raccolta. Per Benjamin Diolez, il successo deriva dallo sforzo collaborativo che ne è all'origine: "Abbiamo lavorato main dans la main con gli esperti cinquantacinque, per essere certi di rispondere alle esigenze e alle attese dei nostri clienti e partner, combinando la loro conoscenza del business con la nostra competenza sul prodotto".
Piano Analytics offre maggiori capacità di misurazione e di analisi, in particolare grazie all'applicazione dell'esenzione ePrivacy. In termini di analisi, Piano propone analisi e-commerce native avanzate, tra cui l'analisi del ciclo di vita del pannello, non disponibile in GA4. Per poter usufruire di queste analisi, è necessario inserire un "cart_id" (identificativo del carrello) e aggiungerlo a ogni evento e-commerce interessato. Si noti che, per Piano, il "cart_id" è un parametro obbligatorio per il corretto trattamento della maggior parte degli eventi e-commerce. Se questa informazione non è disponibile nel vostro dataLayer GA4 (in quanto non standard in GA4), è necessario richiederne l'implementazione all'équipe IT (soluzione privata) o, in alternativa, assegnare un valore unico e preciso alla giornata in questo parametro obbligatorio. Le analisi del ciclo di vita del pannello sono alimentate parzialmente e questo assicura che gli eventi di e-commerce raccolti siano trattati correttamente. (Ad esempio, una soluzione comunemente utilizzata per generare un ID univoco consiste nell'accoppiare il valore dell'ID del cookie visitatore alla data del giorno, al fine di ottenere un'analisi alla data del giorno).
Un altro punto cruciale da tenere in considerazione: la gestione degli UTM. In effetti, una lettura esatta delle performance di acquisizione del traffico è spesso un elemento essenziale della digital analytics. Anche la migrazione deve essere preparata su questo punto. Per questo, Piano ha introdotto un parametro di configurazione (il "campaignPrefix") che consente di leggere gli UTM (oltre ai cliché di Piano "at_").
È quindi molto semplice adattare il tracciamento degli UTM e il tracciamento dei link di campagna non deve essere modificato. Questo parametro di configurazione può essere aggiunto direttamente nel modello di variabile a disposizione.
In realtà, è importante tenere conto di una differenza tra le due piattaforme. In GA4, gli UTM obbligatori sono 'utm_source' e 'utm_medium'. Oppure, per Piano, i parametri di campagna obbligatori sono "at_medium" e "at_campaign". A tal fine, se un visitatore arriva sul vostro sito tramite il link tracciato qui di seguito:
>> https://monsite.com/?utm_medium=mon-medium&utm_source=ma-source
Piano ne pourra pas lire correctement la source marketing du visiteur, car aucun 'utm_campaign' ne sera attribué à un 'src_campaign'**, et la correspondance suivante s'effectuera :
Una volta che l'hit è arrivato all'elaborazione, non c'è più nessun 'src_campaign' da tenere in considerazione e la fonte della visita viene ignorata dal punto di vista del marketing.
È quindi necessario aggiungere una regola all'implementazione per avere sempre un valore associato all'UTM "utm_campaign" (tramite una variabile javascript o una tabella di ricerca, a seconda delle vostre esigenze e necessità).
Una volta presi in considerazione questi elementi importanti nella vostra migrazione, questa avverrà in modo più semplice ed efficace. Se avete domande sulla migrazione, non esitate a contattarmi: sebastien.roberto@fifty-five.com.
L'équipe fifty-five ringrazia Charles Dieppois e Benjamin Diolez per la loro collaborazione nell'ottimizzazione dei modelli di tag e variabili per GTM e per la loro partecipazione alla stesura di questo articolo.
* Une propriété chez Piano Analytics, est l'équivalent d'une dimension chez Google Analytics. Allo stesso modo in cui esistono dimensioni personalizzate in Google Analytics, esistono anche proprietà personalizzate in Piano Analytics.
** Il parametro " src_campaign " corrisponde al parametro di hit che viene creato quando un parametro di link di campagna " at_campaign " o " utm_campaign " viene inserito nell'URL.
Scoprite tutte le ultime notizie, articoli, repliche di webinar e cinquantacinque eventi nella nostra newsletter mensile, Tea O'Clock.