La tua proprietà GA4 segnala 4,180 acquisti il mese scorso. La tua tabella degli ordini ne indica 4,690. Alla domanda su quale sia il dato corretto, la risposta onesta è nessuno dei due, finché non sarai in grado di spiegare dove sono finiti i 510 ordini mancanti. Non si tratta di un problema di ordine. Ogni risultato di un esperimento e ogni punteggio di priorità che produci sono calcolati su un numero che presenta un errore di entità e direzione ignote.
Google considera normale una grande porzione non misurata: la modellazione comportamentale per la modalità di consenso non si attiva finché una proprietà non registra almeno 1,000 eventi al giorno con analytics_storage='denied' per almeno 7 giorniAl di sotto di tale soglia, i dati mancanti rimangono mancanti.
Questo corso è pensato per chi si occupa di analisi dati o CRO (Conversion Rate Optimization) in un team di e-commerce. Al termine, avrete a disposizione una tabella di riconciliazione, una scomposizione del divario in cause specifiche con un test per ciascuna, e un valore di tolleranza che potrete giustificare.
Cosa misura effettivamente una riconciliazione degli acquisti
Una riconciliazione non significa "far coincidere i numeri". Non coincideranno mai, e un team che cerca di forzarli di solito ha fatto qualcosa di peggio che lasciare la discrepanza così com'è. Risponde a tre domande: quanto è grande la discrepanza, quali meccanismi specifici la generano e quanto è recuperabile a quale costo. La eseguiamo prima di qualsiasi attività di sperimentazione, perché un test misurato su un evento di conversione che scarta silenziosamente una quota sconosciuta di ordini non è un esperimento.
Passaggio 1: estrarre due tabelle che possono essere unite tramite l'ID dell'ordine
È necessaria una riga per ordine, da entrambi i sistemi, per lo stesso intervallo di calendario, con una chiave presente su entrambi i lati.
- backend: ID ordine, data e ora di creazione nel fuso orario di reporting della struttura, valore dell'ordine sulla stessa base di tassazione e spedizione configurata in GA4, metodo di pagamento, dispositivo, paese, stato.
- GA4: l'esportazione di BigQuery, non l'interfaccia utente. Query
purchaseeventi conecommerce.transaction_id,event_timestamp,ecommerce.purchase_revenuecategoria del dispositivo e sorgente di traffico.
Utilizzare BigQuery con cognizione di causa. I dati modellati dalla modalità di consenso appaiono nei report standard GA4 e in alcune esplorazioni, ma Google dichiara che è non è un Nell'esportazione BigQuery, sono presenti segmenti di pubblico, esploratori utenti, esplorazioni di coorti o di fidelizzazione, oppure metriche predittive. Confrontando l'interfaccia utente con la tabella degli ordini, si confronta una stima con un dato certo.
Quindi un full outer join sull'ID dell'ordine. Ora hai tre bucket: in entrambi, solo backend, solo GA4. Il terzo è più piccolo ma il più diagnostico.
Passaggio 2: esprimere il divario in tre modi, non in uno
Una singola percentuale mensile nasconde tutto. Calcola tutte e tre:
- Differenza nel numero di ordini: (ordini di backend meno acquisti GA4 corrispondenti) / ordini di backend. Questo isola la perdita di tracciamento.
- Divario di fatturato: Lo stesso calcolo vale per il valore. Se la differenza di conteggio è del 3% e la differenza di fatturato è dell'11%, non si tratta di un problema di tracciamento, bensì di un problema di definizione del valore (tasse, spedizione, sconti, valuta, carte regalo).
- Varianza giornaliera del divario: Traccia il divario tra il numero di ordini giornalieri e il totale. Una linea piatta indica una causa strutturale, come problemi di consenso o blocchi. I picchi indicano implementazioni, picchi di campagne o un problema con il fornitore di servizi di pagamento.
Fase 3: scomporre il divario in cause specifiche
Esaminate attentamente questa tabella. Per ogni causa è disponibile un test che può confermarla o escluderla in meno di un'ora.
| Causare | Come provarlo | Firma nei dati |
|---|---|---|
| Consenso negato, il tag non si attiva | Confronta il registro dello stato di consenso del tuo CMP con le sessioni GA4 per lo stesso periodo | Percentuale giornaliera stabile; traffico concentrato nell'UE e in Turchia. |
| Blocco di annunci e tracker | Conta le richieste nei log del server per l'URL di conferma e confrontale con gli eventi di acquisto GA4 su tale URL. | Distorsione per desktop, Firefox e browser incentrati sulla privacy; stabile nel tempo |
| La pagina di conferma non si carica mai. | Conteggio degli ordini solo backend per i quali non è mai stato richiesto l'URL di conferma nei log del server | Specializzato in metodi di pagamento con reindirizzamento bancario e 3DS. |
| Eventi di acquisto duplicati | Conteggio degli eventi di acquisto GA4 per transaction_id | GA4 sovraccarica il backend in alcuni giorni; pagine con frequenti aggiornamenti e utilizzo del pulsante Indietro. |
| Collegamento tra domini interrotti | Controllare se _gl sopravvive al viaggio di ritorno dal fornitore di servizi di pagamento | Gli acquisti vengono inseriti in nuove sessioni attribuite al dominio di pagamento come referral |
| Reimposta la durata dei cookie | Tasso di nuovi utenti segmentati per browser | Aumento gonfiato dei nuovi utenti e del traffico diretto su Safari e iOS |
| Modellato rispetto al grezzo | Confronta i totali dell'interfaccia utente di GA4 con quelli di BigQuery per lo stesso intervallo di date. | I due numeri di Google non coincidono ancora prima di aprire la tabella degli ordini. |
| Definizione del valore | Ricalcola i ricavi del back-end con e senza tasse, spese di spedizione e sconti. | I conti corrispondono, le entrate no |
| confine del fuso orario | Riaggregare a settimane intere | Il divario si riduce fino a zero con una granularità settimanale. |
Due meritano un'attenzione particolare. transaction_id La deduplicazione funziona solo sui flussi web, non sui flussi delle app, e Google avverte che l'invio di una stringa vuota fa sì che Analytics non esegua la deduplicazione. ogni acquisto evento trasporto transaction_id=''Quel singolo bug può rovinare quasi un'intera giornata. Inoltre, l'elenco dei referral indesiderati è limitato a 50 domini per flusso di dati, il che rappresenta un problema se si utilizzano diversi acquirenti, portafogli e pagine bancarie.
[DATI INTERNI NECESSARI: la distribuzione osservata di queste nove cause negli incontri di riconciliazione di Switas, in modo che i lettori possano vedere quali sono solitamente predominanti.]
Passo 4: impostare una tolleranza che si possa difendere
Google non pubblica alcuna percentuale di discrepanza accettabile e la citazione frequente "il 5% va bene" non compare in nessuna documentazione di Google che siamo riusciti a trovare. Impostate la vostra percentuale, basandovi sulla scomposizione piuttosto che sul solo valore numerico.
| Divario nel numero di ordini mensili | Lettura | Action |
|---|---|---|
| Fino all'2% | bordi del fuso orario e deduplicazione normale | Registra le cause, ricontrolla trimestralmente |
| 2% a% 5 | Accettabile solo se ogni punto è attribuito a una causa specifica | Documentare, quindi procedere alla sperimentazione |
| 5% a% 10 | Almeno una causa strutturale non è stata risolta | Correggi prima di fidarti dei numeri di conversione assoluti |
| Sopra 10% | Non adatto alla sperimentazione | Smetti di usare gli acquisti GA4 come metrica principale dell'esperimento finché non viene risolto |
Queste sono le nostre soglie operative, non uno standard di settore. Il punto è proprio questo: un 3% di anomalie non spiegate è peggio di un 8% di anomalie spiegate.
Passaggio 5: correggere nell'ordine che recupera il maggior numero di ordini per ora di lavoro
- Definizione del valore e fuso orario. Configurazione, non ingegneria, e di solito richiede un pomeriggio.
- ID di transazione duplicati e vuoti. Una correzione per il livello dati.
- Referral indesiderati e cross-domain. Configura entrambi, quindi esegui nuovamente il test del percorso di ritorno del pagamento reale, non di quello di staging.
- Evento di acquisto lato server. Invia l'acquisto dal tuo sistema di ordini con il Protocollo di Misurazione, utilizzando il
client_idIl tuo tag web è stato generato. Google richiede che questi eventi si verifichino entro 48 ore dal timestamp originale dell'evento lato client, altrimenti l'attribuzione potrebbe non essere elaborata come previsto. Questo è ciò che recupera gli ordini persi a causa dei blocchi e delle pagine di conferma che non sono mai state visualizzate. - Architettura del consenso. Il più lento e il più politicizzato. Considerate la parte restante come una lacuna nota, di dimensioni definite e documentata.
Cosa cambia se vendi in Turchia o nell'UE?
Due fattori regionali influenzano i numeri.
Anche in Turchia il consenso è facoltativo, ma senza la rete di sicurezza offerta da Google. L'autorità turca per la protezione dei dati ha multato un gestore di siti web di 300,000 lire turche con la decisione 2022/1358 (23 dicembre 2022) per l'utilizzo di cookie pubblicitari e di marketing senza una base giuridica, e ha richiesto il consenso esplicito per i cookie non essenziali. Molti siti turchi hanno risposto con un banner che blocca completamente il tag di Google invece di uno che invia segnali di consenso. Questa distinzione è costosa: la modellazione richiede analytics_storage='denied' eventi da creare. Un banner che non genera nulla non fornisce a Google alcun elemento su cui basare il modello, quindi i dati vengono persi anziché essere stimati.
I flussi 3DS turchi restituiscono l'acquirente tramite POST. Con iyzico, il commerciante visualizza una pagina 3DS decodificata e, dopo la conferma dell'OTP, iyzico reindirizza al sito del commerciante. callbackUrl con status, paymentId and mdStatus. Un ritorno guidato da POST è esattamente ciò che Google chiama rottura della misurazione cross-domain, poiché i reindirizzamenti possono rimuovere _gl prima che la destinazione venga caricata. Se la differenza si riscontra nei pagamenti con carta ed è quasi nulla per il pagamento in contrassegno, ecco il motivo.
Due affermazioni ampiamente ripetute che non siamo stati in grado di verificare
Safari limita la durata di conservazione dei cookie proprietari a 7 giorni. Impreciso. La documentazione di WebKit afferma che ITP elimina i cookie JavaScript e altri dati di archiviazione scrivibili dagli script dopo 7 giorni di nessuna interazione con l'utentee, separatamente, limita i cookie JavaScript a 24 ore quando la landing page è stata raggiunta tramite un link proveniente da un dominio classificato. I test di Simo Ahava hanno rilevato che il conteggio si basa sui giorni di utilizzo del browser, non sui giorni di calendario, quindi un cliente abituale può conservare un identificativo ben oltre una settimana.
"Una discrepanza del 5% è accettabile." Non abbiamo trovato alcuna fonte su Google per questa cifra. Circola tramite blog di fornitori e risposte sui forum. Consideratela come una fonte popolare, non come un valore di riferimento.
Dove questo metodo fallisce
Non copre i flussi di app, dove transaction_id La deduplicazione non è applicabile, così come i modelli di abbonamento e spedizione parziale, in cui "un ordine" non rappresenta un singolo evento. Non è in grado di recuperare l'identità di un utente a cui è stato negato il consenso, ma solo di stimarne il volume. Non risolve il problema dell'attribuzione del canale, un problema separato e più complesso. Inoltre, presuppone che la tabella degli ordini sia pulita: se gli ordini annullati e bloccati per frode vengono conteggiati in modo incoerente sui due lati, si finirà per cercare una lacuna che esiste solo nella query.
Domande frequenti
Con quale frequenza dovremmo eseguire questa operazione? Completamente una volta, poi un grafico di gap giornaliero. Esegui nuovamente la scomposizione completa dopo ogni modifica al checkout, al CMP, al fornitore di pagamento o al gestore dei tag.
Perché non utilizzare l'interfaccia GA4 invece di BigQuery? L'interfaccia può includere utenti e sessioni modellati che l'esportazione non include, quindi i due dati di Google non coincidono. Confrontandoli con una stima, la differenza diventa impossibile da quantificare.
L'etichettatura lato server colmerà completamente questo divario? No. Recupera gli ordini persi a causa dei blocchi e delle pagine di conferma che non sono mai state visualizzate. Non recupera gli utenti che hanno negato il consenso.
GA4 è superiore al nostro backend. È possibile? Sì. Solitamente si tratta di eventi di acquisto duplicati derivanti da aggiornamenti di pagina, da un elemento vuoto o riutilizzato. transaction_id, o ordini di messa in scena per sparare nella proprietà di produzione.
La modalità di consenso risolve il problema del consenso in Turchia? In parte. I segnali bloccati rendono possibile la modellazione, nel rispetto delle soglie di volume di Google. Non sostituiscono un banner legale ai sensi delle normative turche.
Cosa si intende per un intervallo adeguato? Un sistema in cui ogni punto percentuale ha un nome. Un 8% documentato è meglio di un 3% inspiegabile.
Dovremmo riformulare i resoconti storici dopo aver risolto questo problema? No. Annota la data fissa e tratta i periodi come serie separate. Ripetere le conversioni tracciate distrugge la traccia di controllo.
Possiamo eseguire test A/B se il divario è superiore al 10%? Eseguite i test su metriche relative misurate all'interno dello strumento di test, ma non comunicate l'impatto assoluto sui ricavi derivante da GA4 finché il divario non sarà stato scomposto.
Esegui questa riconciliazione sul tuo negozio questo mese, oppure Fai eseguire il test al nostro team di analisi. e consegnarti la scomposizione, la tolleranza e l'ordine fisso.
fonti
- [GA4] Modellazione comportamentale per la modalità di consenso, Guida di Google Analytics
- [GA4] Ridurre al minimo gli eventi chiave duplicati con gli ID di transazione, Guida di Google Analytics
- [GA4] Segnalazioni indesiderate, Guida di Google Analytics
- [GA4] Misurazione cross-domain, Guida di Google Analytics
- Invia gli eventi del protocollo di misurazione a Google Analytics e Google per sviluppatori.
- Parametri della modalità di consenso, documentazione di Google Tag Platform
- Prevenzione del tracciamento in WebKit
- Rimozione del limite di scadenza dai cookie JavaScript nei browser WebKit, Simo Ahava
- KVKK Kurul karari 2022/1358, 23 dicembre 2022
- Implementazione 3DS, documentazione per sviluppatori iyzico
