E’ passata circa una settimana dal Measurecamp London e finalmente ho trovato il tempo per scrivere nuovamente un articolo nel blog.. ormai mi ero dato per disperso 😀

Scherzi a parte, il Measurecamp di Londra è stato un’ottima occasione per rivedere vecchi amici e conoscerne di nuovi, ma soprattutto di poter discutere alcuni temi “caldi” sul fronte dell’Analytics e soprattutto di GA4.

La mia sessione ha vinto l’award come “Best Presentation of the Conference” ed era intitolata: “Tales from GA4: The F***ing (not set)” ed era basata su Magic The Gathering dove le soluzioni proposte avvenivano sotto forma di carta giocata (alla fine dell’articolo un esempio).

Oltre alla mia presentazione, la sessione è stata molto interessante in quanto si è creata una discussione attorno ai bug di GA4 e tutti hanno suggerito test da effettuare, condiviso frustrazioni, ecc.

Visto che il 3 settembre Google ha dichiarato di aver fixato una parte di questi (not set), visto il momento delicato che stanno attraversando le attribuzioni in GA4 stesso e visto soprattutto l’avvicinarsi dell’Analytics Academy (posti ancora disponibili) dove parleremo in dettaglio di questo e molto altro, ho deciso di condividere la presentazione soprattutto per avere vostri feedback ed integrazioni su questa “non feature” di GA4.

Attribuzione Revenue a (not set)

In alcuni clienti, e solo per certe property, abbiamo riscontrato un volume molto importante di revenue attribuita al (not set).

Le caratteristiche delle properties colpite erano:

• Full CoMo V2
• Blended Report Identity

Intuizione: se si switcha tra Blended e Device Based nel report identity, l’attribuzione viene armonizzata tra source / medium portando il (not set) sotto il 3%.

Grazie a questa intuizione abbiamo scoperto che il problema è relativo alla gestione della user_id da parte di Google e non è relativo né al tracking né ai modeled data.

Soluzione:

• Mantenere il Blended Report Identity
• Eliminare user_id dai parametri di configurazione
• Settare la user_id come user property sotto altra nomenclatura

Con questa soluzione abbiamo portato tra il 3-5% dell’attribuzione della revenue nel (not set).

(not set) in Google Ads Campaigns

Per questa casistica ho letto di cure miracolose, script magici e molto altro… Scherzi a parte, per questo WTF ed il successivo, le soluzioni devono essere deliverate in primis da Google stesso: noi addetti ai lavori possiamo fornire workaround per analizzare i dati degli account colpiti.

Problema:

• (not set) nel session campaigns
• Attribuzioni settate in modo errato tra le sorgenti di GA4

Soluzione:

• Utilizzare gli UTM assieme all’auto-tagging delle campagne di Google Ads

Sì, vero, tutto corretto ma spesso non viene specificato che*:

• Se ad_user_data = granted, vince l’auto-tagging e tutti i dati di costo fluiscono all’interno di GA4 e si possono creare i report di cpc, impressions, ecc
• Se ad_user_data = denied, vince l’UTM ma nessun dato di costo viene importato in GA4, quindi il report di Google Ads in GA4 perde di consistenza

Come si può vedere, quindi, anche in questo caso il problema deve essere risolto a monte e non valle, direttamente da Google Analytics.

*(potresti aver sentito qualcuno parlarne dopo il mio webinar di lunedì scorso)

Esiste anche una Soluzione 2, ovvero:

• Set UTM e gclid (o altro parametro adv) all’interno del local storage tramite custom dimensions e inviarli ad ogni chiamata
• Inviare i dati in BigQuery
• Analizzare i dati ricavati direttamente in BigQuery

Ovviamente qui dobbiamo essere in grado di utilizzare BigQuery e quindi conoscere SQL e user interface di BQ.

(not set) in dataLayer pre-GTM

In questo caso il problema è relativo all’invio di dati tramite un dataLayer preGTM (es. login_status).

A volte vengono rilevati picchi di (not set) per queste variabili in relazione soprattutto alle views o alle sessions.

Soluzione:

• Settare un tag sequence in Google Tag
• Il tag sequence prevede l’invio del tag page_view dopo il Google Tag
• Eliminare tutti i trigger di attivazione dal tag di page_view

(not set) in Measurement Protocol

Questa casistica è spesso la meno esplorata in quanto il measurement protocol è uno strumento che viene utilizzato in pochi casi, anche a causa del diverso funzionamento rispetto a GA3.

L’esempio più banale è passare le info di bonifico avvenuto tramite Measurement Protocol seguendo le guide di Google e ritrovarsi una buona fetta di sessioni cadere sotto (not set), assieme al purchase.

Questo perchè in GA4 è necessario passare una serie di parametri per cercare di unificare la sessione di provenienza dell’utente, altrimenti l’utilizzo dell’MP genera una hit che non ha nessuna tipologia di provenienza.

Soluzione:

• Settare tutti i parametri richiesti con particolare attenzione verso client_id, session_id e user_id
• Pregare

Scherzi a parte, da qualche settimana GA4 ha lanciato una news in cui afferma di aver apportato un netto miglioramento a questa tipologia di invio dati, riuscendo ad attribuire tutta la journey al corretto clienti o user id

(not set) Altri casi

Beh ora tocca a te farmi sapere in quali altre “non-feature” GA4 ha rilasciato dei bug nei not set e soprattutto mi piacerebbe conoscere come hai fixato la situazione per mantenere una sana data collection and storage!

Ti ricordo che all’Analytics Academy parleremo in modo approfondito anche di queste tematiche, quindi non farti scappare il biglietto!

Esempio di carta Magic GA4 che abbiamo creato 🙂