Analītika darbojas pirms piekrišanas: cēloņi un risinājumi
Pēdējās izmaiņas: 2026. gada 16. oktobris
Kāpēc baneris ir, bet analītikas pieprasījumi jau tiek sūtīti
Sīkdatņu banera esamība automātiski nemaina pārējo vietnes skriptu izpildes veidu. Ja skaitītājs pieslēgts ar parastu izpildāmu tagu, tas var palaisties neatkarīgi no apmeklētāja izvēles. Lai atrastu cēloni, jāizseko viss pieslēgšanas ceļš: no lapas veidnes līdz notikumam, kas palaiž integrāciju.
Vispirms nosakiet gaidāmo modeli. Ja uzdevums ir nesūtīt konkrētā analītikas pakalpojuma pieprasījumus pirms piekrišanas, pārbaudiet tieši šādu pieprasījumu neesamību. Ja tiek izmantots režīms ar ierobežotiem signāliem bez sīkdatnēm, kritērijs būs cits. Nejauciet šos variantus pieņemšanas laikā: vienāda vērtība „atteikums” saskarnē ne vienmēr nozīmē vienādu tīkla rezultātu.
1. cēlonis. Viens skaitītājs uzstādīts divreiz
Pārbaudiet vietnes veidni, CMS iestatījumus, analītikas spraudņus, tagu pārvaldnieku un patvaļīga HTML ievietojumus. Pēc migrācijas vai izpildītāja maiņas vecais pieslēgums bieži paliek ārpus jaunās pārvaldības shēmas. Pat pareizi iestatīta integrācija nekontrolē neatkarīgu skripta kopiju.
Salīdziniet skaitītāju identifikatorus un to uzstādīšanas vietas. Katram pakalpojumam izvēlieties vienu pārvaldāmu pieslēgšanas veidu. Pēc dublikāta atslēgšanas pārbaudiet ne tikai agro palaišanu, bet arī notikumu skaitu pēc piekrišanas: labojumam jāsaglabā vajadzīgā analītika bez atkārtotas sūtīšanas.
2. cēlonis. Tagu secība uzskatīta par bloķēšanu
Banera izvietošana HTML virs skaitītāja pati par sevi nenosaka atkarību „vispirms piekrišana, tad analītika”. Atribūts async arī nav piekrišanas pārvaldības mehānisms. Palaišanas nosacījums jāīsteno atsevišķi, un sākotnējais izpildāmais skripta eksemplārs jāizņem no neatkarīgā pieslēguma.
Cookiestack paredz to skriptu aktivizēšanu, kas atzīmēti ar type="text/plain" un data-cookie-category ar vajadzīgo kategoriju. Tas der atbalstītajam atliktās pieslēgšanas scenārijam, kas aprakstīts JavaScript API. Marķējums jāpiemēro reālajam palaišanas avotam; otras, pareizi marķētas kopijas pievienošana blakus parastajam skriptam problēmu neatrisinās.
3. cēlonis. Tagu pārvaldnieks palaiž integrāciju atsevišķi
Nodaliet konteinera ielādi un tagu izpildi tajā. Konteinera esamība kodā vēl nepaskaidro, kurš notikums palaida konkrēto skaitītāju. Pārbaudiet katra taga aktivizēšanas nosacījumus, sākotnējos piekrišanas iestatījumus un to atjaunināšanas apstrādi.
Atrodiet arī klikšķu, ritināšanas un logrīku atvēršanas apstrādātājus: tie var palaist analītiku vēlāk, kad pirmā pārbaude jau beigusies. Atkārtojiet diagnostiku pēc pārejas starp lapām. Vietnē ar klienta puses navigāciju maršruta maiņa var aktivizēt papildu integrāciju bez pilnas pārlādes.
4. cēlonis. Jūs redzat Google Consent Mode signālus
Google nošķir pamata un paplašināto piekrišanas režīmu. Pamata variantā Google tagi tiek bloķēti līdz mijiedarbībai ar piekrišanas mehānismu; paplašinātajā tie tiek ielādēti ar sākotnējiem iestatījumiem un atteikuma gadījumā var sūtīt signālus bez sīkdatnēm. Tāpēc Google pieprasījums Network jāsalīdzina ar izvēlēto arhitektūru, nevis automātiski jāuzskata par pierādījumu banera nepareizai darbībai.
Ja jūsu tehniskais mērķis ir pilnībā izslēgt šī pakalpojuma izsaukumus pirms piekrišanas, ar vienu glabāšanas aizlieguma iestatījumu nepietiek: nepieciešama atbilstoša ielādes bloķēšanas shēma. Salīdziniet īstenojumu ar Google dokumentāciju un atsevišķi pārbaudiet statusa atjaunināšanu pēc apmeklētāja izvēles.
Kā pārbaudīt labojumu
Atveriet Network pirms lapas ielādes, reproducējiet agro pieprasījumu un izpētiet tā iniciatoru. Pēc tam atrodiet pieslēgšanas vietu kodā vai vietnes iestatījumos. Mainiet vienu cēloni vienlaikus: tā vieglāk saprast, kas tieši novērsa nevēlamo darbību.
Atkārtojiet trīs scenārijus ar tīru stāvokli: pirms izvēles, pēc atteikuma un pēc vajadzīgās kategorijas atļaušanas. Pēc tam pārbaudiet atkārtotu apmeklējumu un iestatījumu maiņu. Pārbaudi veiciet lapās ar dažādām veidnēm un ārējiem logrīkiem, ne tikai sākumlapā.
Ar ko sākt iestatīšanu Cookiestack
Sastādiet pieslēgumu karti un salīdziniet to ar kategorijām domēna iestatījumos. Manuāliem skriptiem izmantojiet dokumentēto bloķēšanas mehānismu, integrācijām — atbilstošo instrukciju. Pēc uzstādīšanas veida maiņas noņemiet dublējošo palaišanas ceļu un veiciet kontroles testu.
Diagnostikas rezultātam jābūt pārbaudāmam: konkrētais pakalpojums palaižas vajadzīgajā stāvoklī, nesūta liekus notikumus un pareizi reaģē uz apmeklētāja turpmāko izvēli. Sāciet ar sīkdatņu un tīkla pieprasījumu auditu, pēc tam pārejiet pie iestatīšanas. Šāda secība palīdz novērst cēloni, nevis tikai noslēpt redzamo simptomu.
Ceļveži un nākamais solis
Pieslēgt Cookiestack savai vietnei →