Mārketinga un analītikas rīki
GA4 iestatījums, kas izdarīts pareizi: e-komercijas notikumu izsekošana, kas atbilst tam, ka kase patiešām pabeidzas, Consent Mode v2 konfigurēts tā, lai ES apmeklētāji neizpostītu jūsu datus, un server-side tagging, kad client-side bloķētāji sāk maksāt skaitļos. Bieža situācija: GA4 konts, kas darbojies sešus mēnešus, kuram pietrūkst puses transakciju ad-blocker zaudējumu dēļ, un kuram vajadzīga server-side migrācija plus Consent Mode v2 savienošana.
Kāpēc klienti pie mums nāk ar šādām lietām
Pirmais scenārijs, ko visbiežāk redzam, ir GA4 konts, kas darbojies sešus līdz divpadsmit mēnešus, un e-komercijas skaitļi neatbilst pasūtījumu pārvaldības sistēmai. Par 15% nogāzti, par 30% nogāzti, dažreiz par pusi nogāzti. Iemesls gandrīz vienmēr ir viens no trim: ad-blocker zaudējumi klienta pusē, Consent Mode v2 nepareizi konfigurēts tā, ka noliegtas piekrišanas trafika netiek modelēta, vai purchase notikumi, kas nostrādā uz pateicības lapas, ko daži lietotāji izlaiž caur maksājumu pāradresāciju. Pirmajā nedēļā saprotam, kurš no trim.
Otrais ir tirgotājs, kas tūlīt sāks maksas piesaistīšanu (Google Ads, Meta, TikTok) un saprot, ka konversijas signāls ir neuzticams, un jebkura optimizācija, ko platformas dara uz šī signāla pamata, optimizēs nepareizo lietu. Tērēt 3000 EUR mēnesī Google Ads ar salauztu konversiju izsekošanu ir sliktāk nekā tērēt nulli, jo algoritms aktīvi mācās atrast nepareizos klientus. Mēs ienākam, pirms kampaņas paātrinās, ne pēc.
Trešais ir atbilstības spiediens. Tirgotājs saņēmis vēstuli no Latvijas, Igaunijas vai Vācijas datu aizsardzības iestādes par sīkdatņu piekrišanu vai analītiku bez piekrišanas, un viņiem vajag būt uz Consent Mode v2 ar pareizi konfigurētu CMP jau vakar. Esam to darījuši pietiekami daudz reižu, lai mums būtu 48 stundu labošanas komplekts: Cookiebot vai Iubenda konfigurācija, GTM piekrišanas trigeri, GA4 server-side tagging tur, kur tas dod jēgu, un rakstīts audita dokuments, ko nododam, lai klientam ir kaut kas, ko nosūtīt atpakaļ regulatoram.
Posmi un termiņi
Klasisks analītikas iesaistījums ilgst četras līdz sešas nedēļas. Pirmā nedēļa ir audits. Saņemam tikai-lasīt piekļuvi GA4, Google Tag Manager, CMP, Search Console un pasūtījumu pārvaldības sistēmai, ko tirgotājs izmanto kā patiesības avotu ieņēmumu skaitlim. Salīdzinām trīs logus: GA4 ziņotie ieņēmumi, GTM nostrādājušie notikumi un faktiskie pasūtījumi. Atstarpe starp šiem trim ir projekts. Pirmās nedēļas piektdienā mums ir rakstīts dokuments, kas saka, kur katrs no salauztajiem gabaliņiem atrodas.
Otrā un trešā nedēļa ir pārbūve. Tag Manager pārrakstām ar tīru struktūru (viens konteiners, nosaukti trigeri, nekādu palicis tagu no iepriekšējās aģentūras), Consent Mode v2 ievelkam caur CMP ar pareiziem update izsaukumiem, un e-komercijas notikumus iestatām atbilstoši faktiskajai GA4 shēmai. Ja dati nopludinās tā, ka client-side tagging tos neatgūs, uzstādām server-side GTM uz gtm.merchant.com apakšdomēna. Tas ir aptuveni 20 EUR/mēnesī Google Cloud Run rēķins plus vienreizēja iestatīšanas maksa, un tas parasti atgūst 15 līdz 25% no zaudētajiem datiem.
Ceturtā nedēļa ir verifikācija. Veicam reālus testa pirkumus caur kasi, salīdzinām GA4 pret OMS par to dienu un noregulējam, līdz atstarpe ir mazāka par 5%. Piegādājam Looker Studio paneli, ko klients patiešām var lasīt (nevis GA4 noklusējuma atskaites, kurām neviens netic), rakstītu runbook gadījumiem, kad kaut kas atkal salūst, un 30 dienu pēc-palaišanas pārbaudi, kur datus apskatām vēlreiz un apstiprinām, ka nekas nav pasliktinājies.
Ir projekts, ko vajag sakārtot?
Pastāstiet, kas nestrādā, un mēs pateiksim, vai varam palīdzēt.