Il pixel installato nel browser vede ormai solo una parte delle vostre conversioni. Blocchi pubblicitari, rifiuto del consenso, restrizioni dei browser sui cookie di terze parti: la perdita è strutturale e peggiora. L’API Conversioni esiste per compensarla, a condizione di configurarla correttamente.
I due canali
Il pixel del browser si esegue sul dispositivo del visitatore. Cattura il contesto completo: identificativi pubblicitari, cookie, comportamento di navigazione. Viene bloccato non appena intervengono un blocco, un’estensione o un rifiuto del consenso.
L’API Conversioni invia l’evento dal vostro server alla piattaforma, senza passare dal browser. Non viene bloccata, ma dispone solo di ciò che le trasmettete, ed è cieca rispetto al percorso di navigazione.
I due non sono alternativi. La configurazione raccomandata li fa funzionare insieme sugli stessi eventi, con un meccanismo di deduplicazione.
La deduplicazione
È il punto tecnico centrale, e quello che le implementazioni sbagliano più spesso.
Se un acquisto viene inviato dal pixel e dall’API senza meccanismo di riconciliazione, la piattaforma conta due conversioni. I vostri report mostrano il doppio del volume, il costo per acquisizione appare dimezzato, e le vostre decisioni pubblicitarie poggiano su cifre false.
La riconciliazione si basa su due valori, che devono essere strettamente identici nei due invii: il nome dell’evento e un identificativo unico generato per quell’occorrenza.
Tre regole pratiche. L’identificativo va generato lato server e poi trasmesso al pixel, non il contrario. Deve essere stabile se la pagina viene ricaricata, il che esclude un’estrazione casuale a ogni visualizzazione: il riferimento d’ordine è il miglior candidato per l’acquisto. E deve essere unico per occorrenza, non per prodotto né per sessione.
Facebook Dynamic Ads + Pixel PRO — Feed prodotti, Pixel e API Conversions (PrestaShop 8 e 9)Vendi i tuoi prodotti su Facebook e Instagram e misura ogni conversione€89.00
Cosa si aspetta l’API
A differenza del pixel, che deduce molto, l’API conosce solo ciò che le inviate. Tre famiglie di informazioni.
I dati di corrispondenza cliente. Email, telefono, nome, cognome, città, CAP, paese. Servono a collegare la conversione a un utente della piattaforma. Vanno normalizzati e poi sottoposti ad hash prima dell’invio, mai trasmessi in chiaro.
I dati di evento. Nome, marca temporale, valore, valuta, contenuto dell’ordine con gli identificativi prodotto.
I dati di contesto. Indirizzo IP e user agent del visitatore, più gli identificativi di clic pubblicitario se presenti nell’URL di arrivo. Questi ultimi due migliorano nettamente la corrispondenza e vengono spesso dimenticati.
La qualità di corrispondenza
La piattaforma calcola un punteggio che misura la sua capacità di collegare i vostri eventi a utenti. Quel punteggio condiziona direttamente la performance delle vostre campagne, ed è molto più determinante del volume di eventi inviati.
Tre leve per migliorarlo. Inviare più parametri di corrispondenza: ogni campo aggiuntivo aumenta la probabilità di collegamento. Normalizzare correttamente prima dell’hash: minuscole, rimozione degli spazi, formato internazionale per i telefoni. E trasmettere gli identificativi di clic, che sono i segnali più affidabili.
Un punteggio basso non si vede nei report di conversione, si vede nella performance delle campagne. È ciò che lo rende difficile da diagnosticare.
Il consenso
Punto da trattare seriamente, perché l’invio server non esonera da nulla.
Il fatto che l’evento parta dal vostro server invece che dal browser non ne cambia la natura giuridica. Se il visitatore ha rifiutato i tracciatori pubblicitari, non dovete trasmettere i suoi dati a una piattaforma pubblicitaria, qualunque sia il canale tecnico.
L’API Conversioni compensa la perdita dovuta ai blocchi e ai limiti tecnici dei browser, non quella dovuta al rifiuto del consenso. Sostenere il contrario è una lettura errata molto diffusa.
In concreto, la vostra implementazione server deve conoscere lo stato del consenso del visitatore e condizionare l’invio.
Gli eventi da coprire
Cinque bastano per governare campagne e-commerce: visualizzazione contenuto, aggiunta al carrello, avvio del pagamento, acquisto e iscrizione se vi serve.
L’acquisto è l’unico che deve tassativamente passare da entrambi i canali con deduplicazione. Gli altri possono accontentarsi del pixel in un primo tempo, con la copertura server a seguire.
Un punto di coerenza da sorvegliare: gli identificativi prodotto inviati negli eventi devono corrispondere esattamente a quelli del vostro feed prodotti. Una divergenza impedisce il funzionamento delle campagne dinamiche, che poggiano su quella corrispondenza.
Verificare
Tre controlli, in quest’ordine.
Lo strumento di test della piattaforma, che mostra gli eventi ricevuti in tempo reale con la loro sorgente. Effettuate un ordine completo e verificate che l’acquisto compaia una volta sola, con la dicitura che indica che c’è stata deduplicazione.
Il punteggio di qualità di corrispondenza, da rilevare dopo qualche giorno di attività e da confrontare con i riferimenti della piattaforma.
La riconciliazione con il vostro back office, su una settimana. Uno scarto del 10 al 20 % in meno resta normale. Uno scarto positivo, con la piattaforma che conta più acquisti di quanti ne avete registrati, segnala un fallimento della deduplicazione.
Il modulo Facebook Dynamic Ads e Pixel PRO per PrestaShop mette in opera questa doppia copertura su PrestaShop 8 e 9: pixel del browser e API Conversioni con deduplicazione per identificativo di evento, hash dei dati di corrispondenza, considerazione del consenso e generazione del feed prodotti per le campagne dinamiche.