In genere, quando un team marketing viene da noi frustrato dai propri numeri di attribuzione, ci mostra una dashboard dove due chart sulla stessa pagina non concordano. Paid search è la fonte top su una card e la terza fonte su un'altra. Il team ha passato la mattina a litigare su quale chart sia giusto. Il chart non è il problema. La singola proprietà lead source che alimenta entrambi i chart è il problema, e fiddling a livello report non lo sistemerà. La soluzione vive un layer sotto, nell'architettura di proprietà sul record Contact.
Perché conta proprio adesso
I journey buyer B2B continuano a diventare più lunghi e rumorosi, i touch paid si accumulano sopra l'organico, la chat si sovrappone ai form fill, e un singolo Contact accumula dozzine di interazioni prima che l'SDR alzi il telefono. L'attribuzione last-click era la risposta facile, ma il last-click «travisa come la complessa combinazione di sforzi marketing di oggi influenzi gli outcome di acquisto», come Harvard Business Review ha messo nel suo pezzo sul perché le metriche marketing non tornano. (hbr.org) L'istinto è sistemare il report. La soluzione vera è smettere di lasciare che una proprietà porti il peso di tre domande diverse.
Perché una singola proprietà lead source perde sempre
A una singola proprietà lead source viene chiesto, ogni giorno, di rispondere ad almeno tre domande diverse, quale canale ha introdotto questo Contact a noi; quale canale li ha toccati per ultimo prima dell'attività di oggi; e quale canale era attivo nel momento in cui hanno alzato la mano. Sono tre lavori. Una singola proprietà può tenere solo un valore alla volta, quindi finisce per tenere qualunque segnale abbia vinto la race condition più recente, di solito l'ultimo form fill o l'ultimo click paid che sovrascrive qualunque cosa fosse lì.
Quindi per esempio: un Contact La scopre attraverso un blog post organico, ritorna due settimane dopo via un ad social paid, e infine converte su un form di webinar. La singola proprietà lead source legge «webinar», o «paid social», a seconda di quale workflow è scattato per ultimo. Il team contenuti pensa che il blog sia morto. Il team paid si prende il merito. Nessuno dei due team ha ragione, perché la proprietà non aveva mai avuto spazio per dire l'intera storia.
First-touch, last-touch, converting-touch, tre proprietà, tre lavori
La soluzione è smettere di trattare lead source come una proprietà e iniziare a trattarla come tre. Ognuna ha un lavoro chiaramente definito, una regola di scrittura chiaramente definita e un consumer chiaramente definito.
First-touch, write-once, set alla creazione del Contact
La proprietà first-touch risponde: quale canale ha introdotto questo Contact a noi. È impostata nel momento in cui il record Contact è creato e non viene mai sovrascritta: non da un workflow, non da un'integrazione, non da un form. La regola di scrittura è dura, settable solo al create, locked dopo. Questo è il campo che i team contenuti e SEO dovrebbero guardare, perché è l'unico che sopravvive all'intero lifecycle del Contact senza che attività paid o last-mile riscrivano la storia.
Last-touch, ultima interazione non-direct, aggiornabile
La proprietà last-touch risponde: quale canale ha toccato per ultimo questo Contact prima di qualunque cosa stiano facendo adesso. Si aggiorna ogni volta che un'interazione non-direct atterra, un click paid, un campaign tag, un referral. Il traffico direct non la sovrascrive (altrimenti ogni URL digitata cancella il segnale marketing reale). Questo è il campo che il team paid dovrebbe guardare, perché riflette se il budget sta ancora facendo il suo lavoro tardi nel ciclo.
Converting-touch, locked al momento della conversione
La proprietà converting-touch risponde: quale canale era attivo nel momento in cui questo Contact ha davvero convertito, submitted il form demo, raggiunto MQL, alzato la mano. È impostata all'evento di conversione e, come il first-touch, non è mai sovrascritta dopo. Questo è il campo che il sales handoff e il routing SDR dovrebbero guardare, perché cattura il canale di intent piuttosto che il canale di awareness o il canale dell'ultima esposizione di campaign.
Le regole di scrittura, quale sistema può toccare quale proprietà
Tre proprietà funzionano solo se le regole di scrittura sono ermetiche, applicate tra form, workflow e sync di integrazione. I form impostano first-touch al create e converting-touch al submit, punto, non scrivono mai last-touch. I workflow aggiornano last-touch quando una regola di attribuzione di campaign scatta, ma è loro proibito toccare first-touch o converting-touch dopo che sono impostati. Le integrazioni native ad e i feed reverse-ETL ottengono accesso in scrittura solo al last-touch. Se la superficie di scrittura di una proprietà non è vincolata, l'architettura collassa di nuovo nel pasticcio one-property entro un trimestre.
Un dettaglio pratico: blocchi i campi first-touch e converting-touch usando logica «set once» nei workflow che controllano se il campo è vuoto prima di scrivere. La piattaforma non applica write-once nativamente, quindi la disciplina vive al layer workflow. Questo va preso con un grano di sale, nessuna applicazione è perfetta, specialmente quando qualcuno importa un CSV, ma il pattern regge se i workflow sono nominati in modo consistente e revisionati trimestralmente.
Il layer di reporting, scelga una proprietà per report, mai mediarle
Tre proprietà significa tre report, non un report che media tra loro. La dashboard di attribuzione contenuti legge solo first-touch. La dashboard di efficienza paid legge solo last-touch. La dashboard di handoff MQL-to-SQL legge solo converting-touch. Ogni report nomina il campo nel suo titolo e nel sottotitolo del chart, così chiunque ci si avvicini capisce a quale domanda sta rispondendo. La tentazione di costruire un singolo report «lead source» che switcha tra i tre campi su un dropdown è reale, e va resistita, ogni team che usa il dropdown dimenticherà quale è attualmente selezionato e litigherà sul risultato.
Un problema gemello vale la pena segnalare, una volta che un Contact è noto, le UTM sulle sessioni successive smettono di essere catturate dal tracciamento di default, un failure mode separato da quello su cui verte questo post. L'architettura di proprietà qui presume che gli input siano puliti. Se lo stitching UTM è rotto a monte, il modello a tre proprietà registra fedelmente tre sapori di dati cattivi.
Pattern dal campo
Un team marketing B2B SaaS in DACH allo stadio late-Series-A è venuto da noi con esattamente questa contraddizione di dashboard. Il loro singolo campo «original source» veniva sovrascritto da un workflow paid social ogni volta che un Contact ri-engaged cliccava un ad, quindi il report mensile del loro team contenuti collassava continuamente mentre i Contact originalmente sourced dal blog venivano ri-attribuiti al paid mesi dopo. Il CFO ha chiesto, ragionevolmente, perché il budget contenuti esistesse. Abbiamo spezzato la proprietà in tre in un build di due settimane, first-touch come nuovo campo backfilled dallo snapshot di create-record storico, last-touch cablato al workflow paid esistente con la regola di scrittura ristretta, converting-touch impostato al submit del form e locked. Entro un mese il contributo del team contenuti ha smesso di sparire, il team paid ha tenuto il suo credito last-touch dove il budget davvero ri-engaged un Contact, e il sales handoff aveva un canale di intent stabile su cui instradare. Nessuno dei tre numeri si è mosso molto; era la stessa attività, finalmente separata.
Risoluzione, un playbook per installare il modello a tre proprietà
- Auditi la proprietà lead source esistente. Elenchi ogni workflow, integrazione e form che scrive su di essa. Sta cercando le race condition, i posti dove due sistemi si stanno sovrascrivendo. Questa lista di solito sorprende il team.
- Crei tre nuove proprietà. Un campo canale first-touch, un campo canale last-touch, un campo canale converting-touch. Non ri-utilizzi il campo lead source esistente al primo passaggio, lo lasci al posto suo così i report storici continuano a funzionare.
- Definisca i valori della picklist una volta, condivisi tra tutti e tre. Stessi valori, stesso casing, stesso ordine. I report collassano nel momento in cui un campo ha «paid social» e un altro ha «paid - social».
- Cabli le regole di scrittura. I form impostano first-touch (solo se vuoto) e converting-touch al submit. Le integrazioni paid scrivono solo last-touch. Ogni workflow che tocca questi campi riceve un prefisso di nome che segnala quale proprietà possiede.
- Backfilli first-touch dai timestamp di record-create. Per Contact esistenti, usi i dati original-source che la piattaforma già ritiene dove sopravvivono, e accetti un known-unknown per il resto. Documenti la data di cutoff.
- Ricostruisca i report contro i nuovi campi. Un report per proprietà. Titoli ognuno col nome della proprietà. Ritiri il vecchio report single-source o lo segni come deprecato così nessuno se ne fida.
- Riveda l'inventario workflow trimestralmente. L'architettura resta pulita solo se qualcuno possiede la review. La aggiunga all'agenda standing di marketing ops.
Dove entra in gioco Checkpoint
L'architettura di proprietà è il lavoro poco glamoroso dietro ogni dashboard HubSpot di cui qualcuno davvero si fida. È la maggior parte di ciò che facciamo sul lato marketing operations a Checkpoint. Se la Sua dashboard lead source si contraddice, o se contenuti, paid e vendite hanno smesso di concordare su cosa significhi «source», la soluzione è quasi sempre un layer sotto la dashboard. Ne parli con noi prima che la prossima review trimestrale forzi un'altra discussione su quale chart sia giusto.
Fonti
- Lindsay. «Why Your Marketing Metrics Don't Add Up». Harvard Business Review, 9 settembre 2014. hbr.org
- Hossain. «A Simple Framework for Unlocking Full-Funnel Marketing Attribution Intelligence». OpenView Labs. openviewpartners.com
Noah Charak