Generalmente, quando un marketing leader si rivolge a noi frustrato sull'attribution, la conversazione parte dalle dashboard. La dashboard Looker dice che l'inbound è arrivato da organico. La dashboard HubSpot dice che l'inbound è arrivato da referral. Entrambe sono tecnicamente corrette ai rispettivi layer, e il fatto che disaccordino non è un problema di tooling, è un problema di session-stitching. Gli UTM vivono su sessioni anonime, i contact vivono in HubSpot, e nessuno è owner del join nel mezzo. È il gap di cui parla questo articolo.
Perché conta proprio adesso
Sales e marketing operano ancora su dati disconnessi nella maggior parte delle organizzazioni B2B SaaS, ed è il failure mode sotto a quasi ogni discussione su attribution. Il pezzo di Harvard Business Review sul collegare sales e marketing lo diceva direttamente: le aziende sono inibite da dati di customer in silos, e un digital customer hub, un identificatore, un record, un journey, è la soluzione strutturale (hbr.org). Per i team SaaS che fanno girare un warehouse insieme a HubSpot, il cucitura session-to-contact è dove quell'hub o regge o smette silenziosamente di essere affidabile.
Perché la cattura UTM al form-fill non basta
Il pattern standard è catturare gli ultimi parametri UTM al submit del form e scriverli su campi nascosti del contact: utm_source, utm_medium, utm_campaign. HubSpot lo fa nativamente, e funziona per il caso più semplice, un visitatore atterra su un URL UTM-taggato, clicca una CTA, compila un form, diventa un contact. Una sessione, un contact, un set di UTM.
Il caso che quasi mai regge, un visitatore apre l'email UTM-taggata il giorno uno, naviga tre pagine, esce. Due giorni dopo torna via ricerca Google, legge il pricing, esce di nuovo. Due giorni dopo ancora incolla l'URL della homepage in un browser e compila il form demo. La cattura UTM al form-fill scrive direct / none sul contact. La session table del warehouse, intanto, ha tutte e tre le sessioni e l'UTM email-source che ha guidato davvero il journey. Due sistemi, due verità, e quella che vince è quella della dashboard che il CFO apre per prima.
Il pattern session-token property
La soluzione non è un tool di attribution più grosso. È una singola proprietà sul record del contact, la chiami session_token, che tiene lo stesso identificatore che il front-end scrive sul proprio session log. Al primo page load, il front-end genera il token (un UUID, un cookie hashato, qualunque cosa stabile fra le sessioni), lo droppa in un cookie first-party, e tagga ogni page event con esso. Quando il visitatore compila un form, lo stesso token scrive su un campo nascosto e atterra sul contact.
Da lì, l'attribution smette di essere una congettura e diventa un join. Il contact ha un token; la session table ha la storia UTM completa keyed su quel token, incluse tutte le sessioni anonime precedenti dello stesso browser. Le proprietà UTM a livello contact in HubSpot diventano il riassunto; il join sul warehouse è la fonte di verità.
Cosa vive dove
Sul contact, session_token, first_session_utm_source, first_session_utm_medium, first_session_utm_campaign, last_session_utm_source. Sono campi di riassunto, popolati dal workflow al submit del form, così l'SDR può leggere la card del contact senza aprire il warehouse.
Dentro il warehouse, la session table piena, keyed su session_token, una riga per page view con contesto UTM completo. Il record del contact punta alla session table; la session table non ha bisogno di sapere del contact finché non gira il join.
Workflow di backfill, matchare sessioni anonime a contact convertiti
Il form fill cattura il session token corrente. Non cattura, da sé, le sessioni anonime precedenti dello stesso browser. È a questo che serve il workflow di backfill.
Il cookie first-party che tiene il token persiste tra le sessioni, stesso UUID a ogni visita finché il cookie non scade o l'utente non lo cancella. La session table del warehouse eredita quel token, quindi tutte le sessioni anonime di quel browser sono già keyed su un identificatore. Il record del contact apprende il token solo al momento del form-fill. Il backfill è il momento in cui Lei cammina quel token all'indietro nella session table e tira ogni sessione precedente dentro la vista di attribution del contact.
In pratica è un job schedulato, non un workflow real-time. Ogni notte, una query Looker trova nuovi contact creati nelle ultime 24 ore, fa il join su session_token, e scrive i first-touch e converting-touch UTM aggregati di nuovo in HubSpot via API. Il real-time è un nice-to-have; il notturno è la versione che spedisce davvero e resta in piedi.
Il problema dei domini email gratuiti
Circa il 40% dei contact inbound sui siti B2B SaaS che vediamo arriva da un dominio email gratuito, gmail, outlook, yahoo. Alcuni sono buyer veri che usano un indirizzo personale; molti sono rumore. In ogni caso, un contact su un'email personale è più difficile da risolvere a una company, e il session token aiuta solo se lo stesso browser-and-cookie è stato davvero del buyer. Laptop condiviso, cookie cancellati, form fill in incognito, qualsiasi di queste rompe la catena del token e il backfill produce un quadro parziale.
Non c'è una soluzione pulita a livello contact. Quel che funziona è accettare la verità direzionale, i contact con dominio email gratuito si risolvono pulitamente nel 60% dei casi circa, quelli con dominio email business più verso il 90%, e il report aggregato resta onesto se segmenta per tipo di email. La dashboard che finge che ogni contact abbia attribution piena è la dashboard che mente silenziosamente al CMO.
Da un lato, dall'altro
Da un lato, il join via session-token dà credito alla campagna email che ha effettivamente guidato il journey, anche quando il form fill di conversione dice direct / none. Dall'altro, va presa con le pinze a livello contact, soprattutto sul bordo dei domini email gratuiti. Direzionalmente, il join è la soluzione che il tool di attribution più grosso doveva essere. A livello del singolo contact, è un segnale tra molti. Entrambe le cose possono essere vere.
Schema dal campo
Un team B2B SaaS dell'area DACH in Series A si è rivolto a noi lo scorso trimestre con un lamento familiare: la dashboard del warehouse diceva che il paid social era il loro miglior canale inbound, la dashboard contact-level di HubSpot diceva che il paid social registrava a malapena. Il team aveva discusso per due mesi su quale numero mettere nel board deck. Il vero problema era che il front-end scriveva un session ID nel warehouse ma mai sul contact, quindi HubSpot vedeva sempre solo gli UTM della sessione di conversione: che, dato il tipico journey read-then-return del buyer, atterravano quasi sempre su direct o organico. Abbiamo aggiunto una proprietà session_token, cablato il form per catturarla, fatto girare un backfill notturno contro la storia di sessione esistente, e in tre settimane le dashboard hanno cominciato a raccontare la stessa storia, il paid social guidava la discovery, il direct chiudeva.
Risoluzione, il playbook session-stitch
- Generi un session token stabile sul front-end. Un UUID per browser, persistito in un cookie first-party, attaccato a ogni page event che fluisce in Looker.
- Aggiunga una proprietà contact
session_tokenin HubSpot. Single-line text, nascosta dalla card del contact se preferisce, ma popolata a ogni form fill via campo nascosto. - Scriva il token sul form. Il campo nascosto del form legge dal cookie al momento del submit e scrive il token sul record del contact. È l'unico pezzo che deve essere real-time.
- Costruisca la query di backfill notturna. Un job Looker che fa il join dei nuovi contact su session_token, aggrega first-touch e converting-touch UTM dalla session table, e spinge il risultato di nuovo in HubSpot via API.
- Segmenti il reporting per tipo di email. I contact con dominio email gratuito ottengono una tab separata nella dashboard di attribution. L'aggregato è onesto solo se lascia visibilmente rumoroso il segmento rumoroso.
- Riconcili le due dashboard mensilmente. Looker e HubSpot non combaceranno esattamente, stanno riassumendo cose diverse, ma la storia direzionale dovrebbe concordare. Quando non lo fa, la session-stitch è rotta prima dei dati.
- Documenti il join. Una nota di una pagina su quale proprietà vive dove, quale job gira quando, e cosa controllare per primo quando un numero sembra sbagliato. Il pattern session-token è il tipo di idraulica che si rompe silenziosamente se nessuno sa che esiste.
Dove entra in gioco Checkpoint
La maggior parte del lavoro di attribution che facciamo in Checkpoint non è costruire un nuovo modello, è sistemare la session-stitch che il modello precedente assumeva ci fosse. Se il Suo team di marketing operations sta combattendo con due dashboard che disaccordano, il join è quasi sempre il layer rotto, e una proprietà più una query notturna è quasi sempre la soluzione. Lo accoppiamo al lavoro più ampio di revenue operations su a cosa serve davvero l'attribution nel Suo funnel, e al lavoro di HubSpot implementation che cabla proprietà, form e workflow perché la cucitura sopravviva al prossimo cambio di portale. Per questo il posto giusto da cui partire non è il tool di attribution, è il record del contact.