Tracking
centralizzato
sui 4 siti
dell'ecosistema.

1. Una sola strategia, quattro implementazioni Sui quattro siti dell'ecosistema il tracking è costruito attorno a un singolo evento GA4 di conversione (generate_lead), declinato per canale via parametro lead_type: form, mail, phone, whatsapp (più calendly per LiveCoverage). La differenza tra un sito e l'altro non sta in cosa si traccia, ma in come i singoli eventi vengono catturati a livello tecnico, perché i CMS sono diversi (tre siti su Astro — Amedani, ContentLove, StudioUp — e LiveCoverage su WordPress).
2. Google Tag Manager come singolo punto di gestione Tutti i tag — Google Analytics 4, Meta Pixel, eventi conversione — vengono iniettati e governati dal container GTM. Il vantaggio operativo è che ogni modifica (un nuovo evento, un pixel di una nuova piattaforma, una modifica al consent mode) si fa in un solo posto e si propaga, senza interventi puntuali sul codice del sito.
3. LiveCoverage ha un'eccezione · in aggiunta, non in sostituzione LiveCoverage utilizza Calendly per la presa appuntamenti. Calendly offre un'integrazione nativa con Google Analytics 4 che traccia in modo affidabile selezione data, selezione orario, tipologia di form e page view del widget. La scelta è di usarla in aggiunta al GTM standard del sito — non al posto — per avere il dato Calendly pulito senza dipendere dal listening dell'iframe lato GTM.
4. Le form sui siti Astro richiedono un data layer custom Tre siti su quattro sono in Astro (Amedani, ContentLove, StudioUp). Il quarto è LiveCoverage, in WordPress + Elementor. Su Astro le form non passano da plugin standard che emettono già eventi: serve aggiungere al data layer un evento personalizzato dopo la validazione della form, in modo che GTM lo possa intercettare. Su WordPress il problema non si pone — esistono listener consolidati per Elementor/CF7 e simili. StudioUp oggi non ha form contatti attive sul sito, quindi è una partita che si affronterà al momento della loro reintroduzione.
5. Il consent database di Iubenda è il tassello in più Iubenda è installato su tutti e quattro i siti, e governa il cookie banner. Ma il consent database — la sezione che registra a database ogni invio form con il relativo consenso — non è oggi mappato. È il pezzo che, su richiesta di un utente, permette di documentare quali dati sono stati raccolti e di cancellarli in modo tracciato (diritto all'oblio). Va completato per allineare l'ecosistema alle disposizioni GDPR sulla gestione dei dati raccolti via form.

Modello eventi · tutte le conversioni convergono su generate_lead

La scelta di nomenclatura, già operativa sui siti dove i click events sono attivi, è di trattare ogni conversione come una variante dello stesso evento GA4 generate_lead, distinta solo dal parametro lead_type. Il vantaggio operativo è che CPL, ROAS e dashboard di conversione leggono un singolo evento, mentre la segmentazione per canale (form vs telefono vs WhatsApp vs mail) avviene via parametro. Il modello è quello standard raccomandato da Google per i siti lead-gen.

Eventi del set base (comune ai 4 siti)

I click events su mail / telefono / WhatsApp sono già configurati con questo schema sui siti che hanno il container GTM attivo. La parte da aggiungere è il lead_type: form al momento della submission delle form — quello che richiede la convenzione del data layer custom descritta nella sezione 04.

Eventi specifici di LiveCoverage · funnel Calendly

L'integrazione nativa di Calendly verso GA4 invia eventi con nomi propri (es. calendly_event_type_viewed, calendly_date_and_time_selected, calendly_event_scheduled). Su LiveCoverage manteniamo l'allineamento al modello dell'ecosistema rimappandoli in GTM verso lo stesso evento generate_lead sui passaggi che hanno valore di conversione, e tenendo i passaggi intermedi come eventi di funnel.

La ragione dell'eccezione Calendly

Sarebbe tecnicamente possibile catturare gli stessi passaggi tramite listening dell'iframe Calendly via GTM, ma l'integrazione nativa offerta da Calendly è più stabile e non dipende da modifiche al codice del widget. Va in aggiunta al container GTM, non al posto: GTM continua a gestire pixel, page view del sito e gli altri eventi standard, e in più rimappa la conferma appuntamento sul generate_lead standard dell'ecosistema.

Tracciamento multi-step

Allo stato attuale sui quattro siti non sono presenti form a step multipli. Se in futuro verranno introdotte (es. configuratori, preventivi personalizzati), la logica è già pronta: ogni avanzamento di step diventa un evento data layer FormStepAStudio con parametro form_step, e l'invio finale resta FormSubmitAStudio → generate_lead. Questo permette di leggere a funnel dove gli utenti abbandonano — informazione utile per UX e per profilare la qualità degli utenti per canale di arrivo.

Direzione di medio periodo · tracking server-side

Il tracking client-side (quello attuale, basato su tag JavaScript che il browser dell'utente carica) è oggi lo standard, ma è in via di erosione per via dei meccanismi che limitano i cookie di terze parti. Quando il dato raccolto inizierà a calare in modo significativo rispetto a quello effettivo, sarà utile valutare il passaggio a un'architettura server-side (es. Conversion API di Meta, GTM server-side): i tag non vengono più caricati nel browser dell'utente ma sul server, e il dato viaggia tra server senza dipendere dai cookie. È un'evoluzione che richiede infrastruttura dedicata e va valutata quando il dato perso supera l'80% di copertura del traffico effettivo. Per ora l'attenzione resta sull'implementazione client-side ben fatta.

Il pattern "data layer custom"

Su WordPress, plugin come Elementor o WPForms emettono già di loro un evento al momento dell'invio form, ed è sufficiente che GTM lo ascolti — è il caso di LiveCoverage per le form Elementor del sito. Sui siti in Astro (Amedani, ContentLove, StudioUp) non c'è un plugin che faccia da tramite: la form è codice direttamente nel sito. Per renderla osservabile a GTM, basta che il codice della form, dopo aver verificato che l'invio sia andato a buon fine (la cosiddetta "post-validation"), aggiunga un evento al data layer della pagina. GTM lo intercetta e fa partire tutto il resto: l'evento su Google Analytics, l'evento su Meta Pixel, e qualunque altra integrazione successiva.

Forma dell'evento data layer

Il nome dell'evento da emettere nel data layer è stato concordato come FormSubmitAStudio — standardizzato e univoco sui quattro siti dell'ecosistema, sufficientemente "unique" da non rischiare di collidere con eventi emessi da librerie di terze parti o da CMS futuri. GTM lo intercetta come trigger e fa partire la chiamata GA4 (generate_lead con lead_type: form) e Meta.

Cosa succede dopo · trasformazione in evento GA4

Compilazione del consent nello stesso momento

Lo stesso punto del codice — la post-validation della form — è il momento giusto per fare anche la chiamata al consent database di Iubenda. È un punto di integrazione: una sola modifica lato form, due benefici (tracking + adempimento legale). I dettagli del consent database stanno nella sezione successiva.

Tracciamento click su mail, telefono, WhatsApp

I click su mailto:, tel: e su link WhatsApp si tracciano da GTM senza interventi sul codice del sito — sono trigger automatici, e sui siti con container GTM già attivo sono già configurati con lo schema generate_lead + lead_type (rispettivamente mail, phone, whatsapp). L'attivazione dei click events sui siti dove il container è da configurare ricalca lo stesso schema.

Cosa serve fare · 3 passaggi

Cosa cambia una volta attivo

Ogni invio form genera un record nel consent database di Iubenda con: dati raccolti, timestamp, IP, fingerprint del consenso prestato. La dashboard di Iubenda permette di cercare un utente per email/telefono, vedere lo storico dei consensi prestati, e — su richiesta — cancellare in modo tracciato i suoi dati. È lo strumento che permette di dare risposta documentata a una richiesta GDPR di diritto all'oblio.

Costo e capacità

Il consent database di Iubenda è incluso fino a 20.000 azioni al mese sulla soglia gratuita. Considerando il volume contatti attuale dei quattro siti, il costo aggiuntivo a regime è zero.

Possibile evoluzione forced consent mode

Esiste una configurazione alternativa in cui il consenso viene gestito interamente dal container GTM, e Iubenda viene iniettato dopo aver letto la scelta dell'utente direttamente dal GTM. È un'architettura più "GTM-centrica" e permette in alcuni casi di recuperare dati che andrebbero persi con il blocco automatico. Non è da attivare ora: ha senso solo se nei prossimi mesi si osserva che il dato di Google Analytics 4 scende sotto l'80% del volume reale rilevato dal team. Per il momento la configurazione standard di Iubenda va bene.

• Setup eventi conversione su Amedani e StudioUp I container GTM sono già attivi su entrambi i siti e gli accessi ci sono. Si possono attivare gli eventi click standard (mail, telefono, WhatsApp) e consolidare il GA4 di destinazione. Su Amedani resta da configurare la form contatti, che richiede la convenzione del data layer custom della sezione 04. Su StudioUp le form non sono oggi attive sul sito: il setup avverrà nel momento in cui verranno reintrodotte, applicando la stessa convenzione del data layer custom degli altri siti Astro (sezione 04).
  SitoAmedani · StudioUpTipoSetup GTM
• Abilitazione accessi container ContentLove Il container GTM è presente ma non ancora accessibile dal mio account. Una volta abilitato l'accesso, si fa la stessa attività di setup eventi standard del punto precedente. ContentLove è in Astro: sulla parte form si applica la stessa convenzione del data layer custom prevista per gli altri siti Astro (Amedani, StudioUp), sezione 04.
  SitoContentLoveTipoAccesso + setup
• Creazione container GTM su LiveCoverage Oggi il sito ha solo il tag GA4 caricato direttamente. Si crea un nuovo container GTM, ci si sposta dentro l'attuale GA4, si configura il set eventi standard. In parallelo si attiva l'integrazione nativa Calendly→GA4 (con verifica della Content Security Policy, perché l'integrazione richiede di permettere alcuni domini Calendly). Il container GTM e l'integrazione Calendly convivono — non si esclude uno con l'altro.
  SitoLiveCoverageTipoNuovo container + Calendly
• Data layer custom per le form Astro Sui tre siti Astro (Amedani, ContentLove, StudioUp) serve definire la convenzione del data layer post-validation. È un piccolo lavoro condiviso tra sviluppo e tracking: si concorda la struttura dell'evento (sezione 04), si applica una sola volta nel codice della form, da quel momento ogni nuova form segue lo stesso pattern.
  SitoAstro (3 siti)TipoConvenzione codice
• Setup consent database Iubenda Inserimento dell'API key Iubenda nel head dei siti che hanno form attive (Amedani, ContentLove, LiveCoverage). Mapping dei campi delle form sulle convenzioni Iubenda. Helper JavaScript condiviso per la chiamata al consent database al momento della submission. Va affrontato in parallelo al data layer custom (sezione 04) perché è lo stesso punto del codice — un solo intervento, due benefici. La sequenza ottimale è: prima si definisce la convenzione del data layer, poi si aggancia anche la chiamata Iubenda al momento dell'invio. StudioUp si allinea quando reintroduce le form sul sito.
  SitoAmedani · ContentLove · LiveCoverageTipoLegale + tracking
• Allineamento con il team social sui pixel Dopo il setup base degli eventi standard, è utile un confronto con il team che gestisce le campagne social per capire come vengono oggi configurate le conversioni Meta (ipotizzo via thank-you page, ma può essere diverso). L'obiettivo è far convergere il dato pixel sui nuovi eventi conversione di GA4, in modo che CPL e ROAS delle campagne leggano lo stesso evento che leggiamo noi su Analytics — meno disallineamenti, dati più paragonabili.
  SitoTuttiTipoAllineamento
• Review periodica qualità del dato Una volta che il tracking è attivo, ha senso una verifica mensile della copertura del dato: confrontare gli eventi conversione registrati su GA4 con i contatti effettivi arrivati al team commerciale, e capire se siamo sopra l'80% di match. Se il dato perso supera quella soglia, è il momento di valutare il passaggio a server-side (Conversion API + GTM server-side) — è la direzione di medio periodo descritta nella sezione 02.
  SitoTuttiTipoReview continuativa

1. Setup eventi standard · siti GTM-ready Amedani e StudioUp hanno già i container e gli accessi. Attivazione click events (mail, telefono, WhatsApp) e verifica posizione Meta Pixel. primo step
2. Definizione convenzione data layer · form Astro Allineamento tra sviluppo e tracking sulla struttura dell'evento data layer FormSubmitAStudio e sulla sua rimappatura in GA4 come generate_lead con lead_type: form. Sezione 04 di questo documento è la base. in parallelo
3. Implementazione form events · Amedani Prima applicazione della convenzione data layer sulle form di Amedani. Diventa template per gli altri siti Astro. a seguire
4. Container GTM · LiveCoverage Creazione nuovo container, migrazione GA4 dentro al container, attivazione integrazione Calendly→GA4 nativa. a seguire
5. Accesso e setup · ContentLove Abilitazione accesso al container esistente, setup eventi standard, applicazione della convenzione data layer alle form (stesso pattern degli altri Astro). a seguire
6. Consent database Iubenda In parallelo all'implementazione form events: API key in head + mapping campi + helper di submission. Stesso intervento codice usato per entrambi. in parallelo
7. Allineamento con il team social Confronto sulla configurazione pixel attuale e convergenza sui nuovi eventi conversione di GA4. fase successiva
8. Review periodica qualità del dato Verifica mensile della copertura. Quando il dato perso supera il 20%, valutazione del passaggio a server-side. continuativo