Postback, pixel e image tag: solo uno di loro può reggere un pagamento
Tre meccanismi per segnalare una conversione, descritti in modo che li possa tenere in mano anche chi non è un ingegnere, più i sei modi in cui le integrazioni si rompono davvero. Scritto per operatori e affiliate manager tecnici che hanno già fatto debug di tutto questo alle undici di sera.
Una conversione si può segnalare in tre modi: un image tag, un pixel JavaScript o un postback server-to-server. Solo il postback regge abbastanza da poterci pagare sopra una commissione, perché non ha bisogno che il browser del giocatore collabori. La maggior parte delle integrazioni che «non tracciano» non sono affatto postback rotti: sono identificativi di clic mancanti sul record del giocatore.
La chiamata arriva sempre a un'ora sbagliata. Un affiliate manager ha un partner che minaccia di togliere il traffico, l'operatore giura che l'integrazione è attiva, e la dashboard dice zero. Qualcuno manda uno screenshot di un tag nel footer della pagina di deposito riuscito e chiede perché non funziona.
Non funziona perché è un tag nel footer di una pagina.
Segnalare una conversione è un piccolo problema con molti modi di sbagliarlo, e quei modi non sono cambiati granché in dieci anni. Quello che è cambiato è che due dei tre meccanismi hanno silenziosamente smesso di essere affidabili mentre tutti continuavano a spedirli lo stesso. Questo è il pezzo da passare al Suo ingegnere prima dell'integrazione, non dopo.
Tre modi per dire che un giocatore ha depositato
L'image tag. Il più vecchio. La Sua pagina include un'immagine da un pixel la cui sorgente è un URL che appartiene alla piattaforma di tracciamento. Il browser prova a caricare l'immagine, quella richiesta arriva alla piattaforma, e la richiesta stessa è il messaggio. Nessuna immagine serve davvero, il punto è la chiamata. Non richiede altro che HTML, ed è per questo che è sopravvissuto così a lungo nei sistemi a template dove nessuno voleva toccare JavaScript.
Il pixel JavaScript. Stessa idea con uno script invece di un'immagine. Uno snippet gira nella pagina, raccoglie un po' di contesto e invia la chiamata. È più flessibile: può leggere un valore che la pagina ha messo in una variabile, può aspettare che una conferma venga renderizzata, può passare un importo di deposito noto solo a runtime. È anche più fragile, perché dipende dal caricamento dello script, dall'esistenza della variabile e dal fatto che la pagina non abbia generato un errore più in alto.
Il postback server-to-server. Nessun browser. Quando il Suo backend registra l'evento che conta, effettua una richiesta HTTP verso un URL, portando l'identificativo che gli è stato consegnato quando il giocatore è arrivato la prima volta. Il Suo servizio di pagamento conferma un deposito, il Suo sistema scrive la transazione, e da qualche parte nello stesso percorso parte una richiesta che dice: questo giocatore, questo evento, questo importo, questa valuta.
È tutta qui l'idea. Sembra meno brillante delle altre due, ed è esattamente il motivo per cui regge.
Perché due dei tre hanno smesso di essere affidabili
Non c'è una causa sola. C'è una pila di cause, e ognuna presa da sola sarebbe sopportabile.
Safari e Firefox bloccano i cookie di terze parti per impostazione predefinita, e Firefox blocca anche le richieste verso i domini nella sua lista di tracker. Chrome consente ancora i cookie di terze parti, quindi su Chrome il blocco arriva dall'ad blocker e non dal browser. Safari limita inoltre quanto a lungo sopravvive lo storage scritto da script, in certi casi fino a pochi giorni, il che significa che qualsiasi cosa si appoggi a uno stato scritto al momento del clic e letto al momento del deposito ha una scadenza pari a una frazione di una normale finestra di valutazione. Sopra tutto questo stanno gli ad blocker, diffusi proprio nei pubblici che leggono contenuti comparativi prima di iscriversi. Nulla di tutto ciò si annuncia. Il Suo operatore vede la pagina renderizzarsi bene e conclude che l'integrazione funziona.
Poi c'è la parte che nessuna impostazione del browser può sistemare. Un giocatore clicca da desktop al lavoro, ci pensa su, e deposita la sera dal telefono. Oppure si registra sul web e deposita dentro l'app nativa, dove non c'è browser, non c'è pagina e non c'è tag da far partire. Nello sportsbook in particolare il deposito segue il calendario delle partite più che il clic, e lo segue dentro l'app. Se vuole vedere quanto diversamente si comportano quei due percorsi, il traffico casinò e quello sportsbook divergono esattamente su questo punto.
Un pixel non può partire da un posto che il browser non visita mai. Non c'è niente di sistemabile con un posizionamento migliore del tag.
| Quello che Le interessa | Image tag | Pixel JavaScript | Postback server-to-server |
|---|---|---|---|
| Parte da | Il browser del giocatore | Il browser del giocatore | Il Suo backend |
| Sopravvive agli ad blocker | Raramente | Raramente | Sì, non è coinvolto |
| Sopravvive al cross-device | No | No | Sì |
| Sopravvive a un deposito in-app | No | No | Sì |
| Può leggere lo stato della pagina a runtime | No | Sì | Non applicabile |
| Riporta un importo regolato | Solo quello che la pagina sa | Solo quello che la pagina sa | Sì, dal sistema di registrazione |
| Quando usarlo | Sistemi legacy che non può cambiare | Un segnale nella stessa sessione, come secondario | Qualsiasi cosa decida del denaro |
I modi di rompersi che vale la pena conoscere
Nessuno rompe un'integrazione in modo interessante. Gli stessi sei errori spiegano quasi tutto.
Far partire il tag al caricamento della pagina invece che sull'evento. Il tag vive sulla pagina di conferma del deposito, quindi parte ogni volta che quella pagina viene aperta. Un giocatore ricarica, torna indietro dalla cronologia, o ci atterra dopo un tentativo fallito, e ognuna di quelle volte è una conversione nel Suo reporting. Questo gonfia i numeri nella direzione che sembra buona, ed è per questo che sopravvive a lungo prima che qualcuno lo metta in discussione.
È davvero lato server? Un framework backend che renderizza un template sta comunque emettendo un tag che il browser deve eseguire. Se la richiesta parte dal dispositivo del giocatore, è lato browser, qualunque sia il file in cui è stata scritta. Il test dura un minuto: blocchi gli script nel Suo browser e veda se l'evento arriva lo stesso.
Poi c'è l'identificativo di clic, assente dal record del giocatore. È di gran lunga il guasto più comune e ha una sezione tutta sua qui sotto.
Il deposito viene segnalato prima che si regoli. Il pagamento è autorizzato, il postback parte, il pagamento poi fallisce o viene stornato. Ora c'è una commissione agganciata a soldi che non sono mai arrivati. Faccia partire l'evento sullo stato che il Suo reparto finance riconoscerebbe, non su quello che mostra la Sua pagina di checkout.
L'idempotenza, o la sua assenza. Le reti vanno in timeout. Un mittente ben costruito riprova, e fa bene. Se il lato ricevente non riesce a capire che il secondo tentativo è lo stesso evento del primo, il ritentativo diventa una seconda conversione. Ogni evento ha bisogno di un riferimento univoco e stabile dal Suo lato, lo stesso valore a ogni ritentativo, così un duplicato può essere riconosciuto e scartato invece che pagato due volte.
Gli eventi arrivano anche fuori ordine. Un deposito atterra prima della registrazione a cui appartiene, perché due servizi sono partiti in modo indipendente e uno è stato più veloce. Ordini gli eventi che dipendono l'uno dall'altro, oppure faccia in modo che ciascuno porti abbastanza contesto da reggersi da solo.
L'unica cosa che decide tutto
Ogni guasto qui sopra si ripara in un pomeriggio. Questo no.
Quando un giocatore arriva da un link di tracciamento, l'identificativo su quel link deve essere salvato sul record del giocatore al momento della registrazione. Non in una sessione. Non in un cookie. Sulla riga del Suo database che rappresenta quell'account, accanto all'indirizzo email, nella stessa transazione che la crea.
Se questo non succede, niente a valle può essere attribuito. Il giocatore deposita tre settimane dopo, il Suo backend fa partire un postback tecnicamente perfetto, e non porta alcun identificativo, perché non c'è niente da portare. Nessuna quantità di messa a punto del postback lo sistema. Non sta facendo debug di un problema di reporting, sta facendo debug di un problema di registrazione, e la correzione sta nel flusso di iscrizione.
Due abitudini collegate risparmiano molte discussioni. Conservi l'identificativo anche quando il valore sembra strano, perché sta salvando un token, non validandolo. E lo conservi per tutta la vita dell'account invece che per trenta giorni, perché un CPA che paga su un deposito qualificante ha bisogno che il collegamento esista ancora nel momento in cui il deposito qualifica, che può essere mesi dopo il clic. Se dalla Sua parte il vocabolario su depositi qualificanti e primi depositi è confuso, il glossario di FTD, NGR, CPA, CPL e CPR vale dieci minuti prima di scrivere lo schema.
Come testarlo prima di far girare traffico
Un test di integrazione corretto è noioso e dura circa un'ora.
- Clicchi un link di tracciamento reale e completi la registrazione come farebbe un giocatore normale. Poi guardi il record del giocatore nel Suo database e confermi che l'identificativo ci sia. Se non c'è, si fermi, perché tutto quello che viene dopo è teatro.
- Depositi denaro reale. Un importo piccolo va bene, 20 EUR bastano. I pagamenti in modalità test saltano spesso proprio il percorso di codice che fa partire l'evento, ed è così che le integrazioni passano in staging e falliscono il primo giorno.
- Verifichi che l'evento di deposito sia arrivato una volta sola, con l'importo e la valuta giusti, dopo che il pagamento si è regolato e non quando è stato inviato.
- Rimandi lo stesso evento di proposito. Deve essere riconosciuto come duplicato e non conteggiato due volte.
- Ripeta tutto da telefono, e ancora una volta con il deposito fatto nell'app invece che nel browser, se ne ha una.
Un'ora del tempo di un ingegnere e un deposito, contro un mese di riconciliazione con un affiliato già convinto che gli stiate tosando il traffico. La guida al QA di un link di tracciamento copre il lato affiliato dello stesso test, e farne girare i due capi insieme è il modo per trovare il disallineamento in un pomeriggio invece che in un trimestre.
Che cosa si aspetta AFFILIFY da un operatore
Il riferimento per l'integrazione sta su affilify.partners/docs, con l'endpoint, i nomi dei parametri e i tipi di evento accettati. Lo legga lì e non da un post di blog, perché quella pagina è quella che teniamo aggiornata.
La forma è piccola. Un nome di evento, l'identificativo che Le è stato consegnato al momento del clic, un importo e una valuta, più la Sua chiave. Registrazione, primo deposito, depositi successivi ed eventi di ricavo sono messaggi separati, perché il modello di commissione agganciato a un deal decide quali di essi contino, e un programma non può pagare RevShare su dati che non ha mai ricevuto. Se sta ancora scegliendo fra i modelli, CPA, RevShare e ibrido spiega che cosa serve a ciascuno dalla Sua parte.
Due cose vanno dette chiaramente. L'attribuzione dalla nostra parte ha meccanismi di fallback a più livelli. Sono un'assicurazione, non un piano. L'identificativo salvato in registrazione è la parte che controlla Lei, quindi lo mandi. E la qualità del traffico viene valutata di continuo, il che significa che alcune conversioni restano in verifica invece di essere accreditate all'arrivo. Non è un rifiuto, e l'affiliato ne vede lo stato invece di un vuoto silenzioso.
Un operatore che restituisce l'identificativo, riporta una sola volta gli eventi regolati e può essere testato con un deposito reale in un'ora non avrà mai la conversazione delle undici di sera. È tutta qui l'ambizione.
Domande frequenti
Qual è la differenza fra un postback e un pixel?
Un pixel viene fatto partire dal browser del giocatore mentre una pagina è aperta. Un postback viene fatto partire dal Suo backend quando l'evento viene registrato, senza alcun browser coinvolto. Quell'unica differenza decide tutto il resto: il postback non è toccato dagli ad blocker né dalla policy sui cookie del browser, funziona anche quando il giocatore si registra da laptop e deposita dal telefono, e funziona quando il deposito avviene dentro un'app nativa dove nessuna pagina viene mai caricata. Riporta inoltre l'importo che risulta al Suo sistema di registrazione, non quello che una pagina per caso conosceva.
Possiamo tenere un pixel come backup accanto al postback?
Può, ma sia chiaro su quanto vale. Un pixel confermerà solo gli eventi che riesce a vedere, cioè un sottoinsieme degli eventi realmente avvenuti, e la dimensione di quel sottoinsieme Le è invisibile. Lo tratti come un controllo di sanità nella stessa sessione durante lo sviluppo, non come una seconda fonte di verità, e non riconcili mai i pagamenti su di esso. Se entrambi partono per lo stesso evento, la Sua piattaforma ha bisogno di un riferimento univoco e stabile dalla Sua parte, così la coppia viene riconosciuta come una conversione e non come due.
I nostri postback partono ma non viene attribuito niente. Perché?
Quasi sempre perché l'identificativo di clic non è mai stato salvato sul record del giocatore in fase di registrazione. Il postback parte correttamente, in tempo, con una chiave valida, e non porta nulla su cui fare match. Controlli prima una riga di giocatore reale nel Suo database. Se lì l'identificativo manca, il bug è nel Suo flusso di iscrizione e non nel codice del postback, e nessuna logica di ritentativo o messa a punto dell'endpoint cambierà l'esito.
Come dovremmo testare un'integrazione postback prima di far girare traffico?
Clicchi un link di tracciamento reale, si registri come giocatore e confermi che l'identificativo sia atterrato sulla riga dell'account. Poi depositi denaro reale, perché i pagamenti in modalità test saltano spesso proprio il percorso di codice che fa partire l'evento. Confermi che il deposito sia arrivato una volta sola, con importo e valuta giusti, dopo che il pagamento si è regolato. Rimandi lo stesso evento di proposito e confermi che venga scartato come duplicato. Poi ripeta da telefono, e nell'app se ne ha una. Un'ora, e un piccolo deposito.
