Asi to poznáte. Revenue v administrácii e-shopu vôbec nesedí s tým, čo vidíte v Google Analytics. 😬
Okrem bežných dôvodov ako chýbajúci consent alebo agresívne ad-blockery môže byť príčina aj v duplicitných objednávkach.
Počkať, nemal by toto riešiť Google Analytics automaticky? ❓ Áno aj nie. 🤷🏻♂️
Google Analytics by mal deduplikovať transakcie s rovnakým Transaction ID, ak tieto eventy (purchase) patria rovnakému používateľovi (User).
Takto je to uvedené v dokumentácii. V praxi to ale nie vždy funguje.
✳️ Aké možnosti na riešenie duplicitných objednávok existujú?
V prvom rade odporúčam eliminovať samotnú príčinu. Tou býva dosť často technický problém, napríklad viacnásobné odosielanie purchase eventu pri refreshi stránky.
Problémy môže spôsobovať aj nesprávne nastavené User ID, duplicitné dataLayer.push-e a milión ďalších vecí. ❗
Ak môžete liečiť iba symptómy, existujú dve relatívne jednoduché riešenia:
1️⃣ Ukladanie Transaction ID do cookie alebo localStorage
Pred odoslaním purchase eventu si skontrolujete, či je parameter transaction_id odlišný od uloženej hodnoty (a ide teda o novú objednávku).
Výhody: Rýchle, dostupné Nevýhody: Krehké a nespoľahlivé 😅
2️⃣ Server-side GTM
Toto riešenie viete využiť iba v prípade, ak už využívate server-side GTM (sGTM). Princíp je rovnaký – porovnávate, či objednávka s daným Transaction ID už existuje.
Rozdiel je v tom, že netreba nič ukladať na zariadení používateľa a referenčný zoznam objednávok môže byť uložený napríklad vo Firebase alebo v BigQuery. 🤔
Výhody: Elegantné, spoľahlivé Nevýhody: Náročnejšie na nastavenie 💡
Dokáže Google Analytics zamedziť vzniku duplicitných objednávok?
transaction_id, ak patria tomu istému užívateľovi. V praxi to však nie vždy funguje — najmä ak sú purchase eventy odoslané z odlišných zariadení alebo s rôznymi hodnotami client_id a user_id. Aké sú najčastejšie príčiny vzniku duplicitných objednávok v Google Analytics?
purchase eventu — typicky kvôli duplicitným dataLayer.push volaniam alebo pri opakovanom načítaní „thank you“ stránky. Ako zabrániť vzniku duplicitných objednávok cez server-side GTM?
purchase event nachádza na zozname už spracovaných objednávok (napríklad vo Firebase alebo v BigQuery). Všetko prebieha mimo prehliadača zákazníka, čo z riešenia robí elegantnú a spoľahlivú metódu. Aké sú výhody a nevýhody server-side deduplikácie?
Ako zabrániť vzniku duplicít ak nemám sGTM?
cookie alebo localStorage. Pred odoslaním purchase eventu musíte potom skontrolovať, či sa údaje z objednávky zhodujú s uloženými údajmi. Ak áno, event sa neodošle. Riešenie je rýchle a ľahko nasaditeľné, no relatívne krehké – používateľ ho môže obísť napríklad vymazaním cookies.