Tracciamento delle conversioni sui link brevi: identificatori di clic, finestre ed eventi server

Ogni report sui link ha un punto naturale in cui si ferma, e per la maggior parte dei team quel punto è il clic. La dashboard dice che un link è stato aperto quattromila volte il mese scorso, ripartito per paese, dispositivo, browser e sorgente, ed è lì che l'analisi finisce. Ma quattromila clic descrivono quello che hai speso, non quello che hai guadagnato. È la metà economica del funnel, ed è la metà che viene meglio in uno screenshot.

Il tracciamento delle conversioni chiude quel divario portando un identificatore dal momento del reindirizzamento fino al sistema che alla fine registra l'ordine, per poi rimandarlo indietro. L'idea è facile da descrivere e facile da sbagliare in modi che emergono solo mesi dopo, sotto forma di report sui ricavi che non quadrano con le fatture. Questo articolo copre l'identificatore, la finestra di attribuzione e perché sia una decisione di business, la differenza tra un evento lato server e un evento lato browser, perché il denaro è un intero, come vengono gestiti i duplicati e che cosa fare quando la conversione avviene in un sistema che non controlli.

Un clic è un costo, non un risultato

La reportistica che si ferma ai clic sopravvive perché il clic è la misurazione facile. Il reindirizzamento avviene su infrastruttura che controlli, quindi contarlo non richiede la collaborazione di nessuno, mentre tutto quello che viene dopo succede da un'altra parte. La nostra guida a come si tracciano davvero i clic sui link racconta che cosa può contenere un singolo evento di clic, e la versione breve è che sa che il clic è avvenuto e nulla di quello che è seguito.

Quel limite ha conseguenze concrete. Due posizionamenti possono produrre volumi di clic identici mentre uno porta acquirenti e l'altro porta persone che rimbalzano in tre secondi. Una ripartizione per paese che sui clic sembra eccellente può ribaltarsi sui ricavi. Gli split test decisi sul tasso di clic scelgono regolarmente la variante con il titolo più aggressivo e il checkout peggiore. Finché i ricavi non sono agganciati alle stesse ripartizioni, ognuno di quei giudizi è una supposizione travestita da metrica.

Per agganciarli serve una cosa sola: un valore che sopravviva al viaggio dal reindirizzamento all'ordine.

L'identificatore è tutto il progetto

A ogni reindirizzamento il worker emette un token e ne fa due cose. Lo aggiunge all'indirizzo di destinazione sotto un nome di parametro che scegli tu, lp_cid per impostazione predefinita, e scrive lo stesso valore in un cookie di prima parte sul tuo dominio di reindirizzamento, valido per 90 giorni.

Le copie sono due perché ognuna delle due può perdersi. Le destinazioni rimuovono i parametri di query, a volte di proposito per avere URL puliti, a volte come effetto collaterale di un reindirizzamento dalla loro parte. Nel frattempo un visitatore che clicca oggi e torna tre giorni dopo digitando l'indirizzo non ha più alcun parametro, ma porta ancora il cookie. Nessuna delle due copie è affidabile da sola; insieme coprono la maggior parte dei percorsi realistici verso un acquisto.

Che il cookie sia di prima parte non è un tecnicismo. Lo imposta il tuo dominio di reindirizzamento, quello su cui il visitatore è davvero passato, ed è esattamente la categoria di cookie che i browser non stanno rimuovendo. È per questo che un dominio personalizzato smette di essere una preferenza di branding e diventa infrastruttura di misurazione: su un dominio condiviso del fornitore il cookie appartiene al fornitore.

Che cosa trasporta il token

Il token è firmato, e la firma copre più del clic. Gli identificatori di area di lavoro e di partner fanno parte del payload firmato, quindi un token emesso sul link di un cliente viene rifiutato nell'area di lavoro di un altro esattamente come un falso. Per chi gestisce link per più clienti, questo tiene i ricavi di un cliente fuori dal report di un altro per costruzione, e non grazie a un filtro che qualcuno si è ricordato di applicare.

Quello che il token contiene è deliberatamente ristretto: il momento del clic, il link, la variante dello split test, il paese, la classe di dispositivo, la sorgente di traffico e un flag per il traffico sospetto. Nessun dato personale. Quell'elenco è anche ciò che rende utile la colonna dei ricavi, perché ognuno di quei campi diventa una dimensione per cui ripartire i ricavi in analytics senza una seconda unione con nient'altro.

Il nome del parametro e l'interruttore di attivazione stanno nelle impostazioni dell'area di lavoro, e cambiare l'uno o l'altro riscrive subito la configurazione in cache di ogni link. Una conseguenza da mettere in conto: quando un piano non include le conversioni il redirector smette del tutto di emettere identificatori, e attivarle in seguito non crea retroattivamente gli identificatori dei clic già avvenuti.

La finestra di attribuzione è una decisione di business

La finestra è l'età massima di un clic che può ancora essere accreditato per una conversione. È un'impostazione per area di lavoro, ed è l'unico numero di tutta questa storia su cui vale la pena discutere invece di accettarlo come valore predefinito.

Impostala troppo corta e butti via ricavi che hai prodotto davvero. Impostala molto troppo lunga e accrediti ai link acquisti che sarebbero avvenuti comunque, il che è peggio che inutile perché è sbagliato con sicurezza. Scegli misurando l'intervallo tra primo contatto e acquisto sugli ordini che già riesci a tracciare: un acquisto d'impulso si chiude in minuti, un acquisto consumer ponderato richiede giorni, un acquisto aziendale con un passaggio di approvazione richiede settimane.

Il modo di fallire che questo progetto evita è il rifiuto silenzioso. Una conversione che arriva oltre la finestra viene respinta con attribution_expired, un codice distinto da invalid_click_id. Quelle due condizioni richiedono correzioni completamente diverse, e un'integrazione che riceve un unico errore generico per entrambe passerà una settimana a cercare il problema sbagliato. Registra il codice, conta le due cose separatamente e tratta un tasso di attribution_expired in crescita come il segnale che la tua finestra non corrisponde più al tuo ciclo di vendita.

Anche le due strade di ingresso hanno tetti diversi. Il cookie vive 90 giorni, quindi un report lato browser che ne dipende non può andare oltre. Un report lato server conserva l'identificatore stesso ed è limitato soltanto dalla finestra dell'area di lavoro.

Due strade di ingresso, un solo insieme di regole

Entrambi i percorsi passano dallo stesso servizio, quindi la finestra di attribuzione, la deduplicazione e la consegna verso l'esterno si comportano in modo identico. Quello che cambia è a che cosa sopravvive ciascun percorso e che cosa chiede a te.

L'evento lato server

Il tuo backend invia l'identificatore con un obiettivo, un identificatore di ordine, un importo e una valuta.

curl -X POST https://api.linkprofit.com/v1/conversions \
  -H "Authorization: Bearer lp_live_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-10241" \
  -d '{
    "click_id": "1.eyJ1aWQiOiJ...",
    "goal": "purchase",
    "order_id": "10241",
    "amount_cents": 4999,
    "currency": "usd"
  }'

La chiave deve avere lo scope conversions:write, il che significa che questa strada ti costa qualcosa che quella lato browser non chiede: una credenziale da emettere, custodire e ruotare. Vedi l'autenticazione API per capire come si gestiscono le chiavi con scope, e tieni questa chiave su un server — una chiave con accesso in scrittura ai dati sui tuoi ricavi non ha posto dentro una pagina.

Quello che ottieni in cambio è un report che nessun blocco della pubblicità, blocco degli script, impostazione di protezione dal tracciamento o errore JavaScript può sopprimere. Parte dalla tua infrastruttura nel momento in cui il tuo sistema riconosce che un ordine esiste, quindi riflette la verità dopo i controlli antifrode e non l'istante ottimistico in cui è stato premuto un pulsante.

L'evento lato browser

Il worker serve un piccolo script dal tuo dominio di reindirizzamento, e la pagina di ringraziamento lo richiama.

<script src="https://go.example.com/cv.js" defer></script>
<script>
  window.lpConversion({ goal: 'purchase', orderId: '10241', amountCents: 4999, currency: 'usd' });
</script>

Lo script legge l'identificatore dall'URL o dal cookie di prima parte, quindi non c'è nulla da passargli a mano. In tutta la catena non compare alcun host di terze parti, e questo conta due volte: è una proprietà di privacy ed è una proprietà white-label, perché la pagina del tuo cliente non carica nulla che nomini la piattaforma sottostante.

Il costo è il solito costo della misurazione lato client. Blocker, modalità privacy, caricamenti di script falliti e un visitatore che chiude la scheda mezzo secondo troppo presto tolgono tutti degli eventi, e la perdita non è uniforme. I pubblici tecnici e attenti alla privacy ne sopprimono molto più di quelli consumer, quindi una configurazione solo browser non si limita a sottostimare: sottostima in modo diseguale da segmento a segmento.

Come scegliere tra le due

Usa la strada lato server ovunque ci sia un server che sa dell'ordine, cioè praticamente ovunque passi del denaro. Usa la strada lato browser per gli esiti che esistono solo nel browser, o dove non puoi aggiungere codice lato server: una pagina che puoi modificare solo attraverso un tag manager, un'iscrizione su una piattaforma ospitata, la landing page di un cliente che non ti appartiene.

Far girare entrambe le strade per lo stesso esito è sicuro grazie alla deduplicazione, ma solo se entrambe inviano lo stesso order_id. Senza quello non stai aggiungendo copertura: stai contando due volte gli stessi ricavi.

Gli obiettivi in sé sono leggeri. Un obiettivo è un esito con un nome, come purchase, signup o trial, può portare un valore e una valuta predefiniti per le conversioni che arrivano senza importo, e un obiettivo richiamato prima di esistere viene creato al primo utilizzo.

Il denaro è un intero

Gli importi sono unità minime intere. 4999 significa 49.99 in una valuta a due decimali, e un importo di 49.99 viene rifiutato indicando il campo invece di essere arrotondato in silenzio.

La cosa infastidisce per circa un giorno e poi salva per anni. La virgola mobile binaria non rappresenta esattamente la maggior parte delle frazioni decimali, quindi la classica dimostrazione in cui sommando due importi ne esce un terzo con una cifra finale inattesa non è una curiosità: è quello che succede a ogni somma di una colonna dei ricavi su larga scala. E le valute senza decimali rompono qualunque assunto secondo cui dividere per cento sia sempre corretto.

Rifiutare i decimali al confine spinge l'unica conversione onesta, quella dal prezzo leggibile da una persona alle unità minime, in un solo punto: il tuo codice, una volta sola, dove puoi metterla sotto test.

Dei duplicati si occupa il database

La deduplicazione avviene come singolo inserimento atomico, non come una lettura seguita da una scrittura. Consegne ripetute dello stesso order_id creano una sola conversione e la restituiscono marcata come duplicato.

La distinzione sembra accademica e non lo è. Un controllo seguito da un inserimento lascia uno spazio tra le due operazioni, e un webhook ritentato da un mittente impaziente fa cadere due chiamate dentro quello spazio. Entrambe non vedono alcun record esistente ed entrambe ne scrivono uno. È così che un report sui ricavi mette su un dieci per cento fantasma che nessuno riesce più a localizzare, perché ogni singolo record sembra perfettamente legittimo.

La regola pratica è scegliere un identificatore di ordine stabile e unico nel tuo sistema, e poi non cambiare mai il modo in cui lo ricavi. Il tuo numero d'ordine di solito va bene; una marca temporale o qualsiasi cosa venga rigenerata al ritentativo è esattamente sbagliata. Abbinaci un header Idempotency-Key, come nella richiesta qui sopra, e una chiamata fallita diventa qualcosa da ripetere invece che da indagare.

Il traffico sospetto viene etichettato, non nascosto. Il verdetto del classificatore viaggia dentro il token, quindi una conversione attribuita a un data center o a un proxy viene marcata come sospetta nel momento in cui viene registrata e compare nei report come segmento a sé. Duecento conversioni, e duecento conversioni di cui quaranta da un solo intervallo di hosting in un'ora, sono fatti diversi, e solo uno dei due vale la pena pagarlo. È lì che i dati sulle conversioni e le regole di filtro del traffico smettono di essere funzionalità separate.

Quando la conversione avviene da un'altra parte

In pratica la difficoltà maggiore non sta nell'API. Sta nel fatto che il momento che vale la pena misurare avviene dentro uno store ospitato, un CRM o un fornitore di fatturazione, e il tuo compito è portare una sola stringa dal clic dentro quel sistema e poi farla uscire di nuovo.

Store ospitati. Se la piattaforma ammette attributi d'ordine o metadati personalizzati, quella è la strada pulita: leggi l'identificatore quando il visitatore arriva, portalo attraverso il checkout in un campo nascosto, salvalo sull'ordine e invia la conversione dal tuo server quando l'ordine è confermato, non quando viene premuto il pulsante. Se la piattaforma non ammette campi personalizzati ma consente uno script sulla pagina di conferma, usa invece la strada lato browser. La nostra pagina delle soluzioni per l'ecommerce entra più nel dettaglio in queste scelte.

CRM e trattative seguite da venditori. Cattura l'identificatore come campo nascosto sul modulo di contatto e salvalo sul record, poi invia la conversione quando la trattativa viene segnata come vinta. La trappola qui è il tempo: una trattativa che si chiude in sette settimane ha bisogno di una finestra che regga sette settimane, e se il tuo CRM è l'unico posto che conosce l'identificatore, la sua conservazione e il suo comportamento in esportazione diventano parte della tua architettura di attribuzione. Valuta di inviare un obiettivo signup alla raccolta del contatto e un obiettivo purchase alla chiusura, così la cima del funnel viene misurata anche quando il fondo richiede un trimestre.

Fatturazione e abbonamenti. Lascia che sia il webhook del fornitore di fatturazione a fare da innesco. Quando una fattura viene pagata, il tuo server recupera l'identificatore salvato su quel cliente e invia una conversione usando l'identificatore della fattura come identificatore di ordine. Gli addebiti ricorrenti arrivano allora in modo naturale come conversioni separate, e i primi pagamenti restano distinguibili dai rinnovi attraverso l'obiettivo.

In tutte e tre le forme lo schema è identico: il sistema esterno non ha bisogno di sapere nulla dei link. Custodisce una stringa opaca e te la restituisce.

Dove viaggiano i numeri dopo è deliberatamente convenzionale. Un evento conversion.created firmato viene emesso attraverso la normale macchina dei webhook, e le integrazioni pubblicitarie configurate ricevono la conversione tramite una coda di consegna con un'attesa crescente documentata e un marcatore di resa invece di ritentativi infiniti. I piani possono anche limitare le conversioni accettate per mese di calendario, contate in UTC, e superare quel tetto risponde quota_exceeded e non una restrizione di piano, così «non è nel tuo piano» e «l'hai esaurito questo mese» restano distinguibili senza aprire un ticket.

Farlo bene la prima volta

1. Attiva le conversioni prima della campagna, non dopo. Gli identificatori vengono emessi al momento del reindirizzamento e non si possono creare retroattivamente.
2. Fai girare i link sul tuo dominio, così il cookie di prima parte appartiene a te.
3. Imposta la finestra a partire dal ciclo di acquisto che hai misurato, poi rivedila quando il tasso di attribution_expired si muove.
4. Preferisci la strada lato server ovunque ci sia un server che sa dell'ordine.
5. Converti i prezzi in unità minime intere in un solo punto del tuo codice.
6. Usa il tuo numero d'ordine reale come identificatore di ordine, e invialo identico da ogni strada.
7. Registra i codici di rifiuto separatamente, poi riconcilia con la fatturazione una volta per periodo e indaga lo scarto invece di smussarlo in una media.

Il riferimento completo dei campi sta nella documentazione sulle conversioni, e la pagina della funzionalità di tracciamento delle conversioni racconta come si comporta la colonna dei ricavi nei report che già leggi. Niente di tutto questo sostituisce la contabilità. Risponde a una domanda più stretta a cui la contabilità non può rispondere: quale link, quale paese, quale destinazione e quale sorgente di traffico hanno prodotto il denaro.