Achille Baudino

Il sito era costruito per generare lead, ma non tutte le pagine avevano la stessa funzione.
Alcune pagine servivano a raccontare l’azienda, altre a spiegare casi applicativi, altre ancora a intercettare utenti in fase informativa tramite contenuti editoriali. Le pagine prodotto, pur non appartenendo a un ecommerce, avevano invece un ruolo diverso: aiutare l’utente a valutare una soluzione tecnica, consultare caratteristiche, scaricare documenti e arrivare eventualmente a una richiesta di contatto.
Leggere tutte queste pagine con le stesse metriche avrebbe prodotto una visione troppo generica.
Una visita su un articolo del blog può essere valutata soprattutto attraverso tempo attivo, profondità di lettura e coerenza rispetto alla lunghezza del contenuto. Su una scheda prodotto, invece, alcuni segnali hanno un peso diverso: il click sulla CTA, il download di un PDF, la consultazione delle specifiche tecniche o l’uso dell’indice interno possono indicare un interesse più concreto rispetto alla semplice lettura lineare della pagina.
Serviva quindi un sistema capace di misurare l’engagement reale, ma senza applicare lo stesso criterio a pagine che avevano obiettivi diversi.

Le metriche standard disponibili in GA4 non erano sufficienti per leggere correttamente questo scenario.
Il tempo medio di coinvolgimento, lo scroll e gli eventi raccolti in modo isolato possono dare indicazioni utili, ma non bastano per distinguere una visita realmente interessata da una navigazione superficiale. Il problema diventa ancora più evidente quando si confrontano pagine molto diverse tra loro.
Un articolo lungo, una pagina istituzionale, un case study e una scheda prodotto non richiedono lo stesso comportamento. Una lettura completa può essere importante per un contenuto editoriale, ma su una pagina prodotto l’utente potrebbe trovare valore anche consultando una sezione tecnica, scaricando una scheda PDF o cliccando sulla richiesta di contatto.
Per questo non era sufficiente misurare se l’utente fosse rimasto sulla pagina o quanto avesse scrollato. Bisognava capire che tipo di attenzione avesse espresso e leggere quel comportamento nel contesto corretto.
Il vincolo principale era quindi costruire una misurazione unica, distribuita tramite Google Tag Manager, ma abbastanza flessibile da adattarsi automaticamente al tipo di pagina visitata.

Ho progettato un sistema di Content Engagement Tracking distribuito tramite Google Tag Manager, pensato per misurare l’engagement su tutto il sito LeadGen.
Lo script rileva automaticamente la tipologia di pagina analizzando l’URL e applica criteri diversi in base al contesto. Le pagine vengono classificate in modo da distinguere contenuti generici, blog, case study e schede prodotto.
Per ogni pagina viene calcolata la quantità effettiva di testo utile, escludendo elementi non editoriali come header, footer, menu, form, shortcode e componenti di navigazione. Da questo valore viene stimato un tempo di lettura atteso, usato poi come riferimento per valutare se il comportamento dell’utente sia coerente con la lunghezza del contenuto.
Il sistema misura anche il tempo attivo, cioè il tempo in cui l’utente sta realmente interagendo con la pagina. I periodi di inattività prolungata e il tempo trascorso con la tab non visibile non vengono conteggiati come engagement.

Questi segnali non vengono sommati in modo automatico e indistinto. Il bonus comportamentale viene proporzionato alla profondità reale di consultazione della pagina, così un singolo click nella parte alta non può generare da solo un punteggio elevato.
In questo modo lo score finale non misura solo la presenza dell’utente sulla pagina, ma combina profondità, tempo attivo, coerenza di lettura e segnali specifici di interesse.

Il punto di partenza era una landing page di lead generation per una multinazionale operante nei settori di automazione industriale, energia e robotica (attività eseguita per conto di agenzia, la NDA impedisce la pubblicazione del nome del cliente finale).
L’obiettivo era tracciare correttamente per GA4 e piattaforme di advertising gli eventi di compilazione dei form legati a campagne di advertising in ambito robotica, e attribuire le conversioni alle rispettive sorgenti di traffico.

La landing era sviluppata su una piattaforma stand-alone gestita dall’agenzia, mentre il form era pubblicato direttamente da Salesforce.
Sulla landing e sulla Thank You Page era presente Google Tag Manager. Sulla pagina del form, invece, non era possibile installare il contenitore di tagging.
Il flusso si articolava quindi in questo modo:
- Landing con Tag Manager
- Form esterno su Salesforce
- Redirect verso Thank You Page sulla piattaforma originaria

In una configurazione di questo tipo, il passaggio centrale rompeva la continuità del dato. Quando l’utente arrivava alla Thank You Page, la conversione era visibile, ma mancavano le informazioni necessarie per ricostruire bene la provenienza del traffico.
Questo rendeva più debole la lettura delle performance e meno affidabile l’attribuzione.

La prima esigenza era conservare le informazioni di sorgente lungo un percorso che, di fatto, le disperdeva.
Ho quindi strutturato un flusso di misurazione che partiva dalla landing, raccoglieva i dati utili alla lettura della visita (campagna, medium, parametri UTM) e li rendeva nuovamente disponibili all’apertura della Thank You Page.
In questo modo è stato possibile inviare a GA4 un evento di conversione più completo, anche sotto il profilo attributivo.
Questa prima configurazione ha permesso di recuperare continuità nel tracciamento senza intervenire direttamente sul form Salesforce.

Successivamente il progetto è cambiato, perché non bastava più ricostruire la lettura della conversione dentro GA4. Serviva anche rendere quei dati utilizzabili per le piattaforme advertising attraverso le Conversioni Avanzate.
A quel punto la soluzione iniziale non era più sufficiente e il flusso è stato esteso.
Nel form su Salesforce è stato possibile inserire un codice JavaScript che si attiva al momento della “submit” del form ed invia i dati di compilazione a un’API dedicata che ho sviluppato. L’API riceve le informazioni e le salva in una tabella BigQuery con trattamento cifrato, in modo da poter poi avere anche informazioni sulla qualifica del lead. Successivamente si occupa di inviare i dati necessari alle Enhanced Conversion ad un contenitore GTM Server Side, che li trasmette alle piattaforme di advertising e analytics.
Con questa evoluzione il sistema non si limita più a registrare una conversione. Rende disponibile un dato più solido, più riutilizzabile e più adatto sia alla misurazione sia all’ottimizzazione delle campagne.

L’intervento ha rimesso in continuità tre passaggi che prima erano separati: origine della visita, compilazione del form e conversione.
Questo ha migliorato la qualità del dato disponibile per l’analisi e ha reso più leggibile il contributo delle campagne.
Con l’attivazione delle Conversioni Avanzate, il flusso si è evoluto ulteriormente e ha iniziato a restituire valore anche alle piattaforme media, che hanno potuto lavorare su segnali più utili e meglio strutturati.
Dopo l’implementazione delle Conversioni Avanzate, le performance delle campagne sono cresciute del 26% in termini di lead generati e di chiusura delle trattative.

Il progetto riguarda un hotel con spa in Umbria. Il sito consente la vendita diretta dell’ospitalità, ed è seguito da una consulente SEO per l’ottimizzazione organica.
Il sistema di raccolta dati era basato sulle piattaforme standard (Google Search Console e GA4), senza una struttura centrale che garantisse continuità storica e integrazione tra fonti.

Il sistema presentava fragilità strutturali che impedivano di costruire un’infrastruttura decisionale solida nel medio periodo:
- le piattaforme utilizzate imponevano limiti temporali che rendevano impossibile mantenere uno storico dati completo
non esisteva un repository centrale indipendente dai vincoli delle singole fonti
- i dati SEO, di comportamento e di vendita non erano integrati in una struttura coerente
- i report erano costruiti sulle piattaforme native, adattando l’analisi ai limiti tecnici invece di superarli

Il problema in questo caso derivava dall’assenza di un’architettura capace di superare i vincoli imposti dagli strumenti, sia in termini di durata dei dati disponibili, sia in termini di integrazione dei dati necessaria per una serie di analisi statistiche.

L’intervento è stato orientato alla progettazione di una struttura dati indipendente dai limiti tecnici delle piattaforme utilizzate.

Sono stati progettati:
- un sistema di raccolta e conservazione dati in BigQuery per garantire continuità storica oltre i limiti temporali di Google Search Console e GA4
- un’integrazione strutturata tra GSC, GA4 e CMS, per rendere coerenti le diverse fonti informative
- un framework di KPI differenziato per livello operativo e direzionale
- un sistema di reporting in Looker Studio costruito sopra l’architettura centrale, non vincolato alle interfacce native

L’obiettivo non era adattare l’analisi ai limiti delle piattaforme, ma progettare una soluzione che li superasse strutturalmente.

Il sistema è passato da un insieme di strumenti con limiti strutturali a un’infrastruttura dati progettata per essere indipendente dai vincoli delle piattaforme.
La continuità storica è stata garantita, le fonti sono diventate coerenti tra loro e l’analisi non è più stata condizionata dai limiti tecnici degli strumenti utilizzati.
Il risultato non è solo un miglioramento operativo, ma la costruzione di una base dati stabile, interrogabile e governabile nel tempo, su cui costruire analisi evolutive e decisioni consapevoli.