Il pixel browser è la parte dell'attribuzione che si rompe per prima. L'Intelligent Tracking Prevention di Apple limita i cookie di terze parti e degrada il referrer; i blocchi pubblicitari eliminano la chiamata di rete del pixel prima che lasci la pagina; la App Tracking Transparency di iOS 14.5 ha ridotto la qualità del segnale di Meta sul traffico iPhone al punto che Meta stessa tratta ormai il pixel browser come un ripiego.
Il tracciamento delle conversioni server-side è la risposta su cui tutti concordano. L'implementazione è ciò che le persone sbagliano. Questo articolo illustra l'architettura così come si concretizza quando uno URL shortener possiede il click_id - cosa fa lo shortener, cosa fa il tuo back-end, cosa si aspettano le piattaforme pubblicitarie dalla loro parte, e la struttura di deduplicazione che impedisce il doppio conteggio quando sia gli eventi browser che quelli server vengono inviati.
Le tre piattaforme verso cui la maggior parte dei team effettua l'inoltro: Meta CAPI, GA4 Measurement Protocol, TikTok Events API. Mixpanel, Klaviyo e Pinterest accettano la stessa struttura con nomi di campo specifici per ciascun vendor. Sarò precisa su Meta e GA4 perché sono quelle che guidano la maggior parte del budget; le altre seguono lo stesso schema.
Perché server-side#
La versione breve: il browser non è più una fonte di segnale affidabile. La versione più lunga vale la pena capirla perché determina come si configura la deduplicazione.
Tre fattori degradano le conversioni lato browser:
Partizionamento e limiti di durata dei cookie. ITP di Safari partiziona i cookie per sito di primo livello e limita a 7 giorni i cookie di prima parte impostati da script (24 ore se viene rilevato un cross-site tracker noto). La Total Cookie Protection di Firefox applica un partizionamento simile. Brave e la coorte delle estensioni privacy vanno ancora oltre. Il flusso di attribuzione tramite cookie di prima parte che funzionava nel 2018 non funziona nel 2026.
Blocchi pubblicitari. uBlock Origin, AdBlock Plus, Pi-hole, NextDNS e i blocchi a livello di rete spediscono regole predefinite per connect.facebook.net, googletagmanager.com, analytics.tiktok.com e l'intera superficie dei tag di marketing. Il pixel non si attiva mai; la conversione non viene mai registrata.
App Tracking Transparency di iOS e le modifiche al link tracking di iOS 17. ATT ha ridotto la qualità del segnale di Meta. La Link Tracking Protection di iOS 17 ha esteso questo ambito ai parametri di query nella navigazione privata e in Mail, rimuovendo fbclid, gclid e altri prima che il link venga aperto.
L'effetto cumulativo su un tipico negozio Shopify con traffico iOS elevato: il 25-40% delle conversioni viene perso dai pixel lato browser. Il numero esatto dipende dal mix di traffico; i brand di bellezza e abbigliamento con forte presenza iOS si collocano nella fascia alta. L'aritmetica del fatturato recuperato giustifica il lavoro di ingegneria - per un negozio con €10M/anno di fatturato e un gap di attribuzione pixel del 30%, recuperare anche solo la metà equivale a €1,5M di fatturato attribuibile reindirizzato verso le piattaforme che l'hanno generato.
Il tracciamento delle conversioni server-side colma gran parte del gap. Non lo colma completamente - ci sono conversioni in cui il click_id non è mai stato catturato (organico, diretto, brand search) che nessun CAPI potrà recuperare - ma chiude il gap derivante dal blocco lato browser.
L'architettura#
Il flusso dei dati si sviluppa in quattro passaggi: annuncio → short link → sito → inoltro server-side.
Piattaforma pubblicitaria → short link. La destinazione del creatività Meta o Google Ads è un short link. L'utente clicca; il gestore edge dello short link cattura l'evento di clic e reindirizza all'URL di destinazione con un click_id aggiunto.
Short link → sito. L'URL di destinazione ha ?elido_click=<id> aggiunto (configurabile per workspace). Il tag manager o il codice tema del sito lo legge e lo scrive in un cookie di prima parte o, ancora meglio, negli attributi personalizzati del carrello o dell'ordine.
Sito → ordine. Quando l'utente finalizza un ordine (carrello Shopify inviato, ordine WooCommerce creato, carrello headless convertito), il click_id è negli attributi/metadati dell'ordine. Questo è il punto di trasferimento duraturo - una volta che il click_id è sull'ordine, non è soggetto a scadenza dei cookie o alla durata della sessione browser.
Ordine → inoltro server-side. Il webhook order-paid viene attivato dalla tua piattaforma di commercio. Il tuo back-end (o Elido, se hai delegato a lui) legge il click_id, recupera le credenziali di inoltro delle conversioni e invia la conversione a POST verso ciascuna piattaforma pubblicitaria collegata. Le piattaforme ricevono la conversione e attribuiscono il merito alla campagna di origine.
Il ruolo dello shortener è il click_id al passaggio 2 e l'orchestrazione al passaggio 4. Il primo è diretto; il secondo è dove l'integrazione dimostra il suo valore.
Deduplicazione: la cosa che nessuno menziona fino alla produzione#
L'incidente di produzione più frequente che riscontro è il doppio conteggio. Il pixel lato browser è ancora sulla pagina (il team non l'ha disabilitato perché voleva il fallback browser per il traffico non-Safari), e anche l'inoltro server-side si attiva. Meta acquisisce entrambi gli eventi. La conversione viene contata due volte, il budget allocator sovrastima, e alla successiva revisione del budget della campagna qualcuno nota "aspetta, perché il nostro ROAS riportato è 3× il fatturato?".
La correzione è l'identificatore di deduplicazione. Meta CAPI accetta un event_id. GA4 Measurement Protocol accetta un client_id e un transaction_id. TikTok Events accetta un event_id. Se sia il browser che il server inviano lo stesso evento con lo stesso ID di dedup, la piattaforma accredita uno e ignora il secondo.
L'ID di dedup deve essere lo stesso valore su entrambi i lati. L'ID dell'ordine funziona per gli eventi di acquisto - sia il pixel lato browser che l'inoltro server-side lo vedono. Il click_id funziona per gli eventi a monte (lead, add-to-cart, view-content) dove l'ordine non esiste ancora.
La documentazione sulla deduplicazione di Meta illustra la finestra di corrispondenza: gli eventi ricevuti entro 48 ore l'uno dall'altro con lo stesso event_id sono trattati come duplicati. La deduplicazione basata su client_id di GA4 è simile nel principio, sebbene meno documentata.
La regola operativa: ogni conversione server-side deve portare l'ID di dedup, e l'ID di dedup deve essere lo stesso emesso dal pixel lato browser. Saltare questo passaggio è la differenza tra un'integrazione CAPI funzionante e una che silenziosamente gonfia i tuoi numeri riportati per tre mesi finché qualcuno non se ne accorge.
Requisiti di hashing#
Sia Meta CAPI che TikTok Events richiedono che gli identificatori email e telefono vengano sottoposti a hash SHA-256 prima della trasmissione. GA4 non lo richiede strettamente ma lo accetta. L'hashing riguarda gli identificatori cliente - em (email), ph (telefono), fn (nome), ln (cognome), ge (genere), db (data di nascita), ct (città), st (stato), zp (CAP), country (paese) - non i metadati dell'evento.
Due problemi da tenere a mente. Prima di tutto, il formato deve essere normalizzato prima dell'hashing - tutto minuscolo, senza spazi iniziali o finali, prefisso internazionale rimosso dal telefono, trattini eliminati. Fare l'hashing di [email protected] produce un valore diverso dall'hash di [email protected]; le piattaforme si aspettano il secondo. La pagina dei requisiti dei parametri di Meta elenca le regole di normalizzazione per campo.
Secondo, l'hash deve essere esadecimale minuscolo senza spazi. SHA256("[email protected]") produce a3b6...; l'API si aspetta a3b6..., non A3B6... e nemmeno \xa3\xb6.... La maggior parte degli SDK dei linguaggi restituisce esadecimale maiuscolo per default; devi convertire il risultato in minuscolo.
Se stai instradando tramite l'endpoint POST /v1/conversions di Elido, l'hashing viene gestito lato piattaforma - tu invii email/telefono grezzi, Elido esegue la normalizzazione e l'hashing in base ai requisiti di ogni piattaforma e inoltra. Il vantaggio è un unico set di regole di normalizzazione da mantenere nel tuo back-end invece di tre. Il costo è che ti fidi di Elido con i dati PII grezzi al momento dell'inoltro; la richiesta è crittografata in transito e non viene persistita lato server, ma il modello di fiducia vale la pena comprendere prima di effettuare il collegamento.
Un POST Meta CAPI di esempio#
Cosa vuole effettivamente la piattaforma. L'endpoint è POST https://graph.facebook.com/v21.0/{pixel_id}/events. Il corpo è JSON.
{
"data": [
{
"event_name": "Purchase",
"event_time": 1716480000,
"event_id": "order-acme-2026-05-23-001847",
"action_source": "website",
"event_source_url": "https://acme.example/checkout/thanks?order=001847",
"user_data": {
"em": ["a3b6...sha256 of email"],
"ph": ["c4d7...sha256 of phone"],
"client_user_agent": "Mozilla/5.0 ...",
"client_ip_address": "203.0.113.42",
"fbc": "fb.1.1716470000.AbCdEf",
"fbp": "fb.1.1716470000.987654321"
},
"custom_data": {
"currency": "EUR",
"value": 89.5,
"content_ids": ["sku-spring-jeans-32-blue"],
"content_type": "product",
"num_items": 1
}
}
],
"test_event_code": "TEST12345",
"access_token": "EAAxxxxxxx"
}
Tre aspetti degni di nota:
L'event_id è la chiave di dedup. Impostalo sull'ID ordine; il pixel Purchase lato browser imposta lo stesso valore. Meta deduplicates entro la finestra di corrispondenza di 48 ore.
fbc e fbp sono gli identificatori cookie di Meta. fbc è l'identificatore del clic (fbclid dall'URL di atterraggio, con prefisso); fbp è l'identificatore del browser dal cookie _fbp. Entrambi sono di prima parte dal punto di vista del tuo dominio e possono essere catturati lato server una volta che li hai persistiti dalla landing page. Se non li hai, il tasso di corrispondenza di Meta scende; se li hai, il tasso di corrispondenza è eccellente.
test_event_code ti consente di inviare eventi di test che non vengono conteggiati nel reporting di produzione. Configuralo sempre per primo; verifica in Test Events di Events Manager prima di abilitare il traffico di produzione.
L'equivalente nell'API Elido: POST /v1/conversions con {click_id, event_name: "Purchase", value, currency, order_id, customer: {email, phone}}. Elido normalizza e fa l'hashing secondo le specifiche di Meta, recupera fbc/fbp del workspace dall'evento di clic e costruisce il payload CAPI.
Un POST GA4 Measurement Protocol di esempio#
Il formato wire di GA4 è simile nella struttura, ma i nomi dei campi differiscono. Endpoint: POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXX&api_secret=xxx.
{
"client_id": "click-id-as-fallback-if-no-ga4-cookie",
"user_id": "user-acme-12847",
"events": [
{
"name": "purchase",
"params": {
"transaction_id": "order-acme-2026-05-23-001847",
"value": 89.5,
"currency": "EUR",
"items": [
{
"item_id": "sku-spring-jeans-32-blue",
"item_name": "Spring Jeans 32 Blue",
"quantity": 1,
"price": 89.5
}
],
"engagement_time_msec": 1
}
}
]
}
Note:
client_id è il valore _ga del cookie GA4 se presente; in caso contrario, il click_id costituisce un utile fallback (perché GA4 creerà una sessione contro di esso).
transaction_id è la chiave di dedup - impostalo sull'ID ordine, lo stesso valore dell'evento purchase di gtag lato browser; GA4 deduplica all'interno della propria finestra di sessione.
engagement_time_msec deve essere presente e positivo affinché l'evento venga conteggiato nell'attribuzione; impostarlo a 1 soddisfa il requisito.
api_secret è a livello workspace. La documentazione GA4 MP illustra la configurazione delle credenziali.
Semantica dei retry#
Le piattaforme accettano i retry; quello che non puoi fare è eseguire i retry alla cieca. Tre pattern resistono alla prova del tempo.
Idempotenza sull'ID di dedup. Se l'event_id / transaction_id della piattaforma è l'ID ordine, e riprovi lo stesso payload, la piattaforma deduplica - il secondo invio viene silenziosamente ignorato. Sicuro.
Backoff esponenziale su 5xx. Sia Meta che GA4 restituiscono occasionalmente 5xx. Riprova con backoff (1s, 2s, 4s, 8s fino a 60s, poi rinuncia). I retry devono preservare lo stesso event_id affinché la piattaforma deduplichi eventuali casi di successo parziale.
Non eseguire retry su 4xx. Una risposta 4xx significa che il payload è malformato o le credenziali sono errate. I retry non risolveranno il problema; il retry consuma solo il budget del rate limit. Registra il problema, avvisa, correggi il problema a monte.
Se stai instradando tramite Elido, il retry/backoff è gestito - POST /v1/conversions ritorna immediatamente e il fan-out verso le piattaforme avviene in background, con lo stato dei retry osservabile tramite GET /v1/conversions/{id}. Se gestisci tutto da solo, il livello di coda (RabbitMQ, Kafka, AWS SQS) è dove risiede la struttura dei retry.
Modalità test e dry-run#
Il singolo errore più grande che i team commettono è saltare il dry-run.
Meta ha i Test Events. Imposti test_event_code sul payload, gli eventi appaiono nel pannello Test Events in pochi secondi, verifichi la struttura e la deduplicazione. Gli eventi di produzione passano attraverso lo stesso endpoint ma senza il test_event_code.
GA4 ha la DebugView. Imposti debug_mode: 1 sui parametri dell'evento, gli eventi appaiono in DebugView, verifichi prima di abilitare il traffico di produzione.
TikTok dispone di una modalità test simile nell'interfaccia Events Manager.
La checklist di verifica è breve. Effettua un ordine di test, osserva il webhook order-paid, osserva l'attivazione dell'inoltro della conversione, osservala atterrare nel pannello di test della piattaforma. Verifica che l'event_id corrisponda al valore emesso dal pixel lato browser. Verifica che il valore, la valuta e i content_ids siano corretti. Quindi disabilita la modalità test e osserva i primi dieci ordini di produzione.
Se salti questo passaggio, scopri che l'integrazione è rotta tre giorni dopo quando i report sono piatti. Saltare il dry-run è il singolo modo di fallimento più comune che riscontro.
Modalità di fallimento comuni#
Click_id mancante sull'ordine. Il più comune. Già trattato nel cornerstone sull'ecommerce; la correzione consiste nel portare il click_id attraverso il carrello fino all'ordine.
Mismatch di hash. [email protected] sottoposto a hash senza normalizzazione produce un valore diverso da [email protected]. Le piattaforme rifiutano la corrispondenza, la conversione viene registrata senza corrispondenza di identificatori, e il reporting di Meta la attribuisce a "unmatched". La correzione è nelle regole di normalizzazione nella documentazione parametri CAPI di Meta; la soluzione più pulita è delegare l'hashing allo shortener in modo che le regole risiedano in un unico posto.
fbc non catturato. Quando l'utente arriva da un annuncio Meta, l'URL contiene fbclid; la pagina deve catturarlo e persistirlo (tipicamente in un cookie di prima parte o nell'attributo del carrello). Senza fbc, il tasso di corrispondenza di Meta scende significativamente. La correzione è il passaggio tag manager sulla landing page che scrive fbc in un cookie di prima parte o nell'attributo del carrello.
ID di dedup inconsistente. Il pixel lato browser usa l'ID ordine; il lato server usa un UUID generato al momento dell'inoltro. Entrambi gli eventi vengono acquisiti, nessuno viene deduplicato. La correzione è assicurarsi che l'inoltro server-side utilizzi lo stesso valore event_id emesso dal pixel lato browser - l'ID ordine per gli acquisti è la risposta standard.
Mismatch di valuta. Il browser invia USD (perché la configurazione gtag ha USD come default); il server invia EUR (perché l'ordine è in EUR). GA4 e Meta trattano entrambi la valuta come parte della firma dell'evento in alcuni contesti di corrispondenza, e le conversioni vengono registrate ma non si aggregano in modo pulito. La correzione è derivare la valuta dall'ordine, non dalla configurazione a livello di pagina.
Dove si colloca nel data plane#
L'inoltro delle conversioni è un pezzo della più ampia pipeline di attribuzione. Il cornerstone per la pipeline circostante è Come tracciare le campagne UTM end-to-end senza un CDP - quell'articolo tratta in dettaglio il template UTM del workspace, gli override a livello di campagna, l'importazione in blocco e il passaggio di verifica dry-run. Questo articolo è l'approfondimento del fan-out server-side che chiude il cerchio.
Per la guida operativa, la documentazione sul conversion forwarding è il passaggio per passaggio. Per i dettagli architetturali su come Elido effettua il fan-out senza superare i rate limit delle piattaforme, il post sull'architettura di click ingestion illustra la pipeline fire-and-forget.
Leggi il cluster#
Articoli correlati nel cluster features: Smart links spiegati (il cornerstone), Webhook per eventi su link (la struttura più ampia degli eventi), e Inoltro conversioni a Meta CAPI (l'approfondimento più specifico su Meta). Per la versione rivolta alla persona, solutions/marketers è la pagina; la pagina della funzionalità conversion-tracking è la superficie del prodotto.
Correlato sul blog#
Prova Elido
Incolla un URL, ottieni un link breve
Senza registrazione. Il link vive 30 giorni. Iscriviti per conservarlo.
Gratis, nessuna registrazione richiesta · 2 al giorno