Analītika un CRM

GA4 pirkumu dublēšanās: pārbaudiet sūtītājus un pasūtījumu ID

GA4 uzrāda pārāk daudz pirkumu? Pārbaudiet notikumu sūtītājus, transaction_id un atkārtotus pieprasījumus ar praktisku testu tabulu e-veikaliem Latvijā.

Vladlens Kecko · 2026-10-21 · 7 minūtes

Ja GA4 rāda vairāk pirkumu nekā veikala sistēma, sāciet ar viena pasūtījuma notikumu ceļu. Atskaites filtrs neizlabos divas integrācijas, kas nosūta vienu pārdošanu. Savukārt jauns nejaušs darījuma ID katrā lapas pārlādē var vienu pasūtījumu pārvērst vairākos šķietamos pirkumos.

Šis ceļvedis ir par pirkumu uzskaiti vietnes GA4 tīmekļa datu straumē. Visai konfigurācijai izmantojiet GA4 audita sarakstu. Ja pirkumu skaits ir pareizs, bet maksājumu pakalpojums parādās kā klientu avots, izmantojiet atsevišķo maksājumu novirzījumu ceļvedi.

1. Noskaidrojiet, vai tiešām ir dublēšanās

Pierakstiet GA4 īpašumu, datu straumi, atskaiti, rādītāju, periodu un laika joslu. Salīdziniet vienādas pasūtījumu grupas: apmaksātus vai izveidotus pasūtījumus, bruto vai neto ieņēmumus, atmaksas, nodokļus un piegādi. Notikumu skaits nav automātiski unikālu pasūtījumu skaits.

Atlasiet nelielu pasūtījumu piemēru kopu ar identifikatoriem bez personas datiem. Katram pierakstiet laiku, summu un valūtu, tad pārbaudiet nosūtītos datus. Trūkstoši un dublēti pirkumi var pastāvēt vienlaikus; vienāda kopsumma vēl nepierāda pareizu uzskaiti.

2. Apziniet visus pirkuma notikumu sūtītājus

Sarakstā iekļaujiet e-komercijas platformas integrāciju, vietnes kodu, GTM tagus un servera integrāciju. Katram norādiet atbildīgo, aktivizēšanas nosacījumu, mērījuma ID un pasūtījuma ID avotu. Divi konteineri ir norāde pārbaudei, nevis pierādījums: noskaidrojiet, ko katrs faktiski nosūta.

Izmantojiet Google ieviešanas diagnostikas rīkus apstiprinātā testa vidē. DebugView izvēlieties savu testa ierīci un apskatiet purchase parametrus. Tagu priekšskatījums un integrācijas žurnāli palīdz noteikt konkrēto sūtītāju; DebugView viens pats to ne vienmēr parāda.

Ievērojiet lietotāja piekrišanas izvēli. Ja tās ierobežojumu dēļ notikums nav redzams, neieslēdziet izsekošanu piespiedu kārtā. Ja iespējams, izmantojiet testa īpašumu un dokumentējiet, kā testa darbības tiek nodalītas no uzņēmuma atskaitēm.

3. Piesaistiet transaction_id pasūtījumam

Google darījuma ID dokumentācija apraksta dublikātu novēršanu tīmekļa straumēs, nevis lietotņu straumēs. Viena lietotāja atkārtoti pirkuma notikumi ar vienādu ID var tikt deduplicēti. Tā nav universāla garantija visām identitātēm un integrācijām.

Vienojieties par pasūtījuma līmeņa noteikumiem:

• Pabeigtam pasūtījumam ir stabils ID no pasūtījumu sistēmas, bez personas datiem.
• Atkārtota nosūtīšana saglabā šī pasūtījuma ID; jaunam pasūtījumam ir cits ID.
• Nesūtiet nemainīgu vērtību vai tukšu virkni un neatkārtojiet ID nesaistītiem pasūtījumiem vai lietotājiem.
• Identifikatorā neiekļaujiet vārdu, e-pastu vai citu personisku informāciju.

Tukšs transaction_id var izraisīt nepietiekamu uzskaiti. Nedodiet visiem pirkumiem vienādu ID, lai slēptu dublikātus. Ja divas integrācijas dublē vienu pienākumu, izvēlieties galveno sūtītāju un pēc testēšanas noņemiet lieko ceļu, saglabājot atjaunošanas iespēju. Pirms atslēgšanas pārbaudiet pārlūka un servera integrāciju paredzētās lomas.

4. Izpildiet atkārtojamu testu tabulu

Šis ir hipotētisks piemērs, nevis klienta rezultāts. Testa pasūtījumā TEST-A ir divas preces pa €40: preču vērtība ir €80. Nodokļus un piegādi pierakstiet atsevišķi. Google e-komercijas ieviešanas ceļvedī aprakstīti parametri un vērtības aprēķins.

Saglabājiet paredzēto un novēroto rezultātu, sūtītāja pierādījumus, versiju un atbildīgo. Veiksmīgs tīkla pieprasījums pierāda nosūtīšanu, nevis pareizus ieņēmumus vai atribūciju. Izlabojiet konkrēto kļūmi un atkārtojiet testus, nemainot vairākus iestatījumus vienlaikus.

5. Salīdziniet jaunus, apstrādātus datus

Pirms jauno pasūtījumu salīdzināšanas nogaidiet atskaišu apstrādi. Google diagnostikas ceļvedis standarta atskaitēm iesaka atvēlēt 24–48 stundas. Izmantojiet vienādas datumu un laika joslu robežas, izskaidrojot piekrišanas, atmaksu un datu vākšanas atšķirības.

Izlabots tags nepārraksta vēsturi. Saglabājiet izmaiņas datumu savā atskaišu žurnālā. Ja pirkumu uzskaite ir pareiza, bet GA4 un Google Ads joprojām atšķiras, pārbaudiet definīcijas un tvērumu konversiju atšķirību ceļvedī.

Pirkumu uzskaites izlaišanas pārbaude

• Pirms izmaiņām izsekojiet viena pasūtījuma notikumiem.
• Nosakiet atbildīgo un galveno purchase sūtītāju.
• Pārbaudiet stabilus ID un atšķirīgu otrā pasūtījuma ID bez personas datiem.
• Testējiet pārlādi, atkārtojumus, atcelšanu, atmaksas un piekrišanas ietekmi.
• Saglabājiet iepriekšējo ieviešanu un labojuma aprakstu.
• Pārbaudiet apstrādātos pasūtījumus un ieņēmumus, ne tikai notikumu piegādi.

Vajag palīdzību nošķirt datu vākšanas, atribūcijas un atskaišu problēmu? Mūsu izsekošanas, atribūcijas un CRM pakalpojums sasaista pārbaudes ar biznesa lēmumiem. Piesakiet bezmaksas 30 minūšu izaugsmes pārskatu ar dibinātājiem un saņemiet īsu rakstisku plānu ar trim prioritātēm. Nav pienākuma nolīgt CPCInsider; ieviešanas apjomu saskaņojam atsevišķi.