Multi-touch attribution custom su BigQuery: un modello tuo, non una black box

Il problema

Sommi le conversioni che dichiarano Google Ads e Meta e ottieni più ordini di quanti ne hai fatti davvero. Non è un bug, e nessuna delle due piattaforme sta mentendo: è il modo in cui sono costruite.

Ogni piattaforma misura con il proprio pixel e si auto-attribuisce qualunque conversione preceduta da un click (o da una impression, nel caso di Meta) dentro la propria finestra di attribuzione — di default 7 giorni click / 1 giorno view per Meta, 30 giorni click per Google Ads. Se un utente clicca un’ad Meta lunedì, un annuncio Google mercoledì e compra giovedì, entrambe le piattaforme rivendicano quella conversione al 100%. Nessuna delle due vede l’altra.

“Ma GA4 ha il data-driven attribution”. Vero, ed è meglio di niente, ma ha limiti strutturali:

• È una black box: non puoi ispezionare i pesi, non puoi modificare la logica, non puoi sapere perché un canale è stato premiato.
• Vede solo i click: le impression di Meta, che Meta usa per attribuirsi conversioni view-through, per GA4 non esistono.
• Sotto certe soglie di dati il modello degrada silenziosamente verso regole più semplici.
• Nella UI lavori su aggregati: non hai accesso ai path utente, quindi non puoi verificare niente.
• Con Consent Mode attivo una parte delle conversioni è modellata, non osservata — e non sai quale.

Un’alternativa esiste: costruire il modello sui tuoi dati grezzi in BigQuery, dove ogni touchpoint è una riga che puoi interrogare, e ogni regola di attribuzione è SQL che puoi leggere.

A chi serve davvero — e a chi no. Un modello custom ha senso se spendi un budget pubblicitario significativo distribuito su più canali e prendi decisioni di allocazione ogni mese. Se spendi su un solo canale, o se le conversioni mensili si contano in poche decine, non te lo consiglio: il rumore statistico mangia il segnale, e il last non-direct click di GA4 letto con criterio ti basta. Se è il tuo caso te lo dico alla prima call, e ti propongo qualcosa di più piccolo (o niente).

Come lavoro

1. Audit di fattibilità

Prima di scrivere una riga di SQL verifico che il modello regga: volumi di conversione, canali attivi, qualità della UTM governance, stato del tracking (click ID persi, redirect che sporcano i referrer, eventi duplicati). Se i dati non reggono un modello multi-touch, ti fermo qui — meglio un audit da pochi giorni che una pipeline costruita su dati rotti.

2. Touchpoint e identità

Attivo (o verifico) l’export GA4 → BigQuery con gli eventi grezzi. Costruisco la logica di identità: user_pseudo_id per il device, user_id dove c’è login per il cross-device, gclid/fbclid/UTM per agganciare i click alle campagne. Se emergono buchi nel tracking, li sistemo adesso: ogni touchpoint perso qui è un’attribuzione sbagliata dopo.

3. Pipeline BigQuery

Sessionizzazione dei dati grezzi, tabella touchpoint ordinata nel tempo per utente, journey table conversione per conversione. Tutto alimentato da una pipeline MERGE incrementale schedulata (giornaliera o settimanale), con tabelle partizionate per tenere i costi di query vicini allo zero.

4. Modelli e confronto

Implemento più modelli in parallelo sulla stessa journey table: first click, last non-direct click, lineare, position-based, time-decay — e, se i volumi lo giustificano, un data-driven custom basato su removal effect (catene di Markov). Il punto non è eleggere “il modello giusto”: è vedere quali canali risultano sistematicamente sopra o sottovalutati in tutti i modelli. Quella è informazione su cui puoi spostare budget.

5. Dashboard e reconciliation

Dashboard Looker Studio con confronto multi-modello e drill-down per canale e campagna. E un documento di reconciliation: perché Google Ads, Meta e GA4 ti mostrano numeri diversi tra loro e diversi dal modello, e quale numero usare per quale decisione. Senza questa parte, la dashboard diventa l’ennesima fonte di confusione.

Cosa ricevi a fine progetto

• Dataset BigQuery di tua proprietà con pipeline incrementale schedulata e versionata.
• Tabelle touchpoint e journey interrogabili in SQL, documentate campo per campo.
• Dashboard Looker Studio con confronto multi-modello per canale e campagna.
• Documento di metodologia: definizione di touchpoint, finestre di attribuzione scelte, logica di ogni modello, limiti noti (consenso, cross-device, traffico dark).
• QA report: validazione della pipeline contro GA4 e contro le piattaforme, con le discrepanze attese spiegate.
• Sessione di handover su come leggere i dati e usarli nelle decisioni di budget.
• 30 giorni di supporto post-release inclusi.

Tempi e costi

• Durata: 4–8 settimane. Se l’export BigQuery non era attivo, parte del tempo è accumulo storico: la pipeline si costruisce intanto, il modello si valida quando i dati bastano.
• Range prezzo: da 4.000€. Fa variare il prezzo: il numero di canali da riconciliare, lo stato del tracking esistente (se va sistemato prima, è lavoro in più), e se serve il modello data-driven custom oltre ai modelli rule-based.
• Costi ricorrenti BigQuery (non inclusi): per volumi tipici, tra zero e poche decine di euro al mese.
• Pagamento: 50% all’avvio, 50% alla consegna.