Consent Modecmpgdprlvcookiebot-migration

Migrācija no Cookiebot uz CookiePilot: praktisks pārejas ceļvedis

Marcin
2026. gada 1. augusts
15 min lasīšanas
Migrācija no Cookiebot uz CookiePilot: praktisks pārejas ceļvedis

Migrācija no Cookiebot uz CookiePilot parasti nav tikai sīkfailu banera nomaiņa. Tā ir pāreja uz citu kontroles slāni piekrišanām, skriptiem, pierādījumiem, Google piekrišanas signāliem un ikdienas darbam starp mārketingu, izstrādi, e-komerciju un juridisko pusi. Labi sagatavota migrācija palīdz sakārtot tagu pārvaldību un samazināt risku, ka reklāmas, analītikas vai veikala skripti darbojas citādi, nekā lietotājam ir paskaidrots.

Šis ceļvedis ir rakstīts Latvijas komandām, kas jau izmanto piekrišanu pārvaldības platformu un apsver pāreju no Cookiebot uz CookiePilot. Tajā ir praktisks migrācijas plāns: sākotnējais audits, konfigurācijas un pierādījumu saglabāšana, kategoriju un skriptu kartēšana, Google Consent Mode v2 pārbaude, Google Tag Manager validācija, WordPress un WooCommerce nianses, atkāpšanās plāns, testu matrica un kontroles saraksti. CookiePilot var palīdzēt ar piekrišanu pārvaldību un tehnisko ieviešanu, bet neviena platforma pati par sevi negarantē atbilstību. Atbilstība ir atkarīga no jūsu iestatījumiem, tekstiem, nolūkiem, pakalpojumu sniedzējiem un iekšējiem procesiem.

Pirms lēmuma pieņemšanas var noderēt lapa par Cookiebot alternatīvu, CookiePilot funkciju pārskats un cenu informācija. Latvijas kontekstā būtiski oficiālie avoti ir Datu valsts inspekcija un SPRK, bet Eiropas datu aizsardzības ietvaru palīdz saprast EDPB un Eiropas Komisijas datu aizsardzības portāls.

Kad pāreja no Cookiebot uz CookiePilot ir pamatota

Migrācijai ir jēga tad, ja esošā piekrišanu pārvaldība sāk traucēt ikdienas darbam vai vairs neatbilst komandas vajadzībām. Tipiski iemesli ir mājaslapas pārveide, jauns Google Tag Manager konteiners, Google Consent Mode v2 projekts, vairāku valodu ieviešana, e-veikala izaugsme vai vēlme labāk kontrolēt, kuri pakalpojumi tiek palaisti pirms un pēc lietotāja izvēles.

Labs migrācijas mērķis ir konkrēts. Piemēram: samazināt neskaidrību par tagu aktivizēšanos, vienkāršot WordPress uzturēšanu, sakārtot WooCommerce pirkuma ceļa mērījumus, uzlabot piekrišanas signālu kvalitāti Google Ads un GA4 vai izveidot skaidru procesu jaunu mārketinga rīku pievienošanai. Ja mērķis ir tikai "nomainīt baneri", pastāv risks, ka vecās problēmas paliks Google Tag Manager, tēmā vai spraudņos.

Vienlaikus ir jāpasaka, ko migrācija neatrisina. Tā automātiski nepārraksta privātuma politiku, nepārskata visus apstrādātājus, neizņem liekus pikseļus un nenosaka, kuri nolūki ir pieņemami jūsu biznesam. CookiePilot var atbalstīt tehnisko un operacionālo daļu, bet juridiskie lēmumi un faktiskais datu apstrādes modelis paliek jūsu organizācijas atbildībā.

Pirmsmigrācijas audits: vispirms saprast esošo vidi

Sāciet ar pilnu esošās Cookiebot ieviešanas auditu. Mērķis ir nevis uzminēt, kas ir vietnē, bet pierādīt, kas faktiski ielādējas lietotāja pārlūkā. Pārbaudiet, kur Cookiebot skripts ir ievietots: spraudnī, tēmā, lapas galvenē, pielāgotā koda rīkā, Google Tag Manager vai hostinga integrācijā. Pēc tam identificējiet visas vietas, kur tagi tiek kontrolēti atsevišķi.

Inventārā iekļaujiet domēnus, apakšdomēnus, valodas, lapu tipus, GTM konteinera ID, analītiku, reklāmas pikseļus, video iegules, tērzēšanas rīkus, A/B testus, afiliātu skriptus, maksājumu un krāpšanas novēršanas pakalpojumus, atsauksmju logrīkus un katra rīka īpašnieku. E-komercijā pievienojiet produktu lapas, kategoriju lapas, meklēšanu, grozu, kuponus, reģistrāciju, piegādes izvēli, maksājumu novirzīšanu un pasūtījuma apstiprinājumu.

Neaprobežojieties ar CMP administrācijas skatu. Izmantojiet pārlūka izstrādātāja rīkus, tīkla pieprasījumu žurnālus, sīkfailu sarakstu, GTM priekšskatījumu un manuālus scenārijus. Testējiet pirmo apmeklējumu, visu noraidīšanu, visu pieņemšanu, tikai analītikas pieņemšanu, izvēles maiņu un atkārtotu apmeklējumu. Pierakstiet, kuri sīkfaili parādās pirms piekrišanas un kuri pieprasījumi turpinās pēc piekrišanas atsaukšanas.

Latvijas vietnēm bieži ir vairāki lietotāju ceļi, kurus sākotnējā auditā aizmirst: pieteikšanās konsultācijai, cenu pieprasījums, e-pasta jaunumu abonēšana, darba sludinājumi, partneru portāli, pasākumu reģistrācija un dokumentu lejupielāde. Šajās vietās var būt CRM formas, mārketinga automatizācija, kartes, video vai analītikas notikumi, kas netiek ielādēti sākumlapā. Ja uzņēmums darbojas arī Lietuvā, Igaunijā vai citos tirgos, pārbaudiet, vai katrai valodai ir savs teksts, savi pakalpojumu sniedzēji un atšķirīga tagu loģika.

Auditā iekļaujiet arī "nezināmo skriptu" sarakstu. Tie ir pieprasījumi, kurus redzat pārlūkā, bet komanda uzreiz neatpazīst. Tos nevajadzētu automātiski bloķēt, jo daži var būt saistīti ar drošību, maksājumiem vai hostingu. Tomēr tos nevajadzētu arī pasludināt par obligātiem tikai tāpēc, ka to izcelsme nav skaidra. Piešķiriet īpašnieku, pārbaudiet dokumentāciju un tikai tad izvēlieties kategoriju.

Eksporti, ekrānattēli un pierādījumu saglabāšana

Pirms vecās konfigurācijas noņemšanas saglabājiet visu, kas vēlāk var palīdzēt paskaidrot migrāciju. Eksportējiet vai arhivējiet banera tekstus, kategoriju aprakstus, pakalpojumu sniedzēju sarakstus, domēnu grupas, valodu versijas, skenēšanas pārskatus, piekrišanu žurnālus, ja tie ir pieejami, un ekrānattēlus no publiskās vietnes. Pievienojiet eksportēšanas datumu, atbildīgo personu un īsu piezīmi par testēto vietnes versiju.

Šie pierādījumi ir praktiski. Ja pēc palaišanas mainās piekrišanas īpatsvars, reklāmas platformu diagnostika vai pasūtījumu atribūcija, jums būs salīdzināšanas punkts. Tas palīdz arī iekšējās pārbaudēs un sarunās ar klientu atbalstu, ja lietotāji jautā, kāpēc pieredze ir mainījusies.

Vecās lietotāju izvēles nevajadzētu automātiski pārcelt uz jauno risinājumu. Ja mainās kategoriju nosaukumi, nolūki, sniedzēju loks, datu glabāšanas apraksti vai saskarnes formulējums, iepriekšējā izvēle var neatbilst jaunajam kontekstam. Šādu lēmumu vajadzētu pieņemt ar privātuma vai juridiskās atbildīgās personas iesaisti.

Kategoriju, skriptu un piekrišanas signālu kartēšana

Kartēšana ir vieta, kur migrācija kļūst precīza. Nepietiek pārnest kategoriju nosaukumus no vienas sistēmas uz otru. Katram skriptam jāzina nolūks, īpašnieks, ielādes vieta, piekrišanas nosacījums un pārbaudes veids. Viena pakalpojuma sniedzēja dažādi produkti var būt dažādās kategorijās, tāpēc nevajadzētu kartēt tikai pēc domēna vai zīmola nosaukuma.

Praktiski izmantojiet četras grupas: obligāti nepieciešamie, funkcionalitāte vai preferences, analītika vai statistika un mārketings vai reklāma. Vietnes valodā kategorijas var saukt citādi, taču lietotājam jāsaprot, kādam nolūkam tās tiek izmantotas. Maksājumu drošības skripts nav tas pats, kas remarketinga pikselis. Biznesam noderīga analītika arī nekļūst automātiski par obligāti nepieciešamu.

Izveidojiet tabulu ar šādiem laukiem: vecā Cookiebot kategorija, jaunā CookiePilot kategorija, skripta nosaukums, pakalpojuma sniedzējs, nolūks, īpašnieks, ielādes veids, piekrišanas nosacījums un tests. Šī tabula kļūs par darba dokumentu arī pēc migrācijas. Kad kampaņu laikā kāds vēlas pievienot jaunu pikseli, jūs varat prasīt kategoriju, īpašnieku un testu, nevis meklēt atbildes pēc tam.

Īpaši rūpīgi pārskatiet kategoriju tekstus latviešu valodā. Tie nedrīkst būt mehāniski tulkoti vai tik vispārīgi, ka lietotājs nesaprot izvēles sekas. Ja kategorija attiecas uz apmeklējuma mērīšanu, pasakiet to tieši. Ja kategorija attiecas uz personalizētām reklāmām vai atkārtotu uzrunāšanu citās platformās, arī tas jāapraksta saprotami. Tiem pašiem terminiem jāparādās banerī, sīkfailu informācijā un privātuma politikā, citādi rodas iespaids, ka dažādās vietās runa ir par atšķirīgiem procesiem.

Atsevišķi apskatiet formas un pārdošanas integrācijas. Viena pieteikuma forma var vienlaikus nosūtīt ziņu pārdošanas komandai, izveidot ierakstu CRM, aktivizēt e-pasta automatizāciju un nosūtīt reklāmguvuma notikumu analītikai. Migrācijas laikā šos nolūkus ir vērts atdalīt. Formas tehniskai nosūtīšanai var būt cita loma nekā kampaņas efektivitātes mērīšanai vai vēlākai auditoriju veidošanai.

Ja vietne izmanto Google Ads, GA4 vai citus Google tagus, Google Consent Mode v2 jābūt migrācijas centrā. Oficiālā atsauce ir Google dokumentācija par Consent Mode, bet praktiskai sagatavošanai noder arī CookiePilot ceļveži par Google Consent Mode v2 un Consent Mode v2 ar Google Tag Manager.

Svarīgākais ir secība. Noklusējuma piekrišanas stāvoklim jābūt iestatītam pirms tagiem, kuriem tas ir vajadzīgs. Pēc lietotāja izvēles CookiePilot konfigurācijai jānosūta atjauninājums. Parasti īpaši jāpārbauda ad_storage, analytics_storage, ad_user_data un ad_personalization. Atkarībā no vietnes var būt svarīgi arī funkcionalitātes, personalizācijas vai drošības glabāšanas signāli.

GTM priekšskatījumā pārbaudiet ne tikai to, vai tags ir palaists, bet arī ar kādu piekrišanas stāvokli tas ir palaists. GA4 lapas skatījums, Google Ads conversion linker, reklāmguvumu tags, remarketinga tags, Meta, LinkedIn, TikTok, e-pasta platformas un afiliātu rīki var prasīt atšķirīgu loģiku. Consent Mode palīdz Google tagiem pielāgot darbību, bet tas nav pilnīgs kontroles mehānisms visiem ārējiem pakalpojumiem.

Soli pa solim nomaiņas plāns

Migrāciju plānojiet kā nelielu relīzi, nevis kā vienu iestatījuma maiņu. Visdrošāk ir strādāt testa vidē. Ja tādas nav, izveidojiet īsu produkcijas testēšanas logu, skaidru atbildību un dokumentētu atkāpšanās plānu.

  1. Apturiet CMP, GTM un tēmas izmaiņas, kamēr tiek gatavota migrācija.
  2. Pabeidziet auditu, eksportus, ekrānattēlus un zināmo risku sarakstu.
  3. CookiePilot iestatiet domēnus, valodas, kategorijas, tekstus, sniedzējus un saites uz privātuma informāciju.
  4. Testa vidē pievienojiet CookiePilot un tajā pašā plūsmā izslēdziet Cookiebot ielādi.
  5. GTM sakārtojiet noklusējuma piekrišanu, atjauninājumus un tagu aktivizētājus.
  6. Pārbaudiet cieti ieliktos skriptus tēmā, spraudņos, CMS laukos un ārējos logrīkos.
  7. Testējiet pirmo apmeklējumu, noraidīšanu, pieņemšanu, daļēju izvēli, atsaukšanu un atgriešanos.
  8. Pierakstiet atkāpšanās darbības: kuru kodu atjaunot, kuru GTM versiju publicēt un kurš pieņem lēmumu.
  9. Palaišanu veiciet laikā, kad pieejama izstrāde, mārketings un vietnes īpašnieks.
  10. Pēc palaišanas sekojiet piekrišanām, tagiem, konversijām, kļūdām un atbalsta jautājumiem.

Lēmuma sagatavošanā var noderēt arī raksts par Cookiebot, CookieYes un CookiePilot salīdzinājumu un pārskats par CMP cenu veidošanos.

WordPress, WooCommerce un e-komercijas īpatnības

WordPress vidē vispirms noskaidrojiet, kur vecais Cookiebot tiek ielādēts. Tas var būt atsevišķs spraudnis, tēmas header, pielāgotu skriptu spraudnis, GTM tags vai hostinga iestatījums. Noņemiet tikai to ceļu, kas patiešām ielādē veco CMP. Ja Cookiebot un CookiePilot vienlaikus tiek rādīti parastiem lietotājiem, var rasties dubulti baneri, pretrunīgi piekrišanas signāli un neparedzēta tagu palaišana.

WooCommerce vietnēs testēšana jāveic daudz dziļāk nekā sākumlapā. Pārbaudiet produktu skatījumus, pievienošanu grozam, groza izmaiņas, kupona ievadi, pieteikšanos, konta izveidi, piegādes izvēli, maksājumu, atgriešanos no maksājumu vārtejas un pasūtījuma apstiprinājumu. Daudzi spraudņi ielādē skriptus tikai konkrētos soļos: atsauksmes, krāpšanas novēršana, sarakstes logrīki, personalizēti piedāvājumi vai pēcpirkuma analītika.

E-komercijas datos pēc migrācijas var būt redzamas izmaiņas. To var izraisīt atšķirīgs banera teksts, precīzāki tagu nosacījumi, pārlūku ierobežojumi, reklāmu bloķētāji vai Consent Mode modelēšana. Galvenais ir pārbaudīt, ka pirkuma ceļš nav bojāts, obligātie pakalpojumi darbojas un izvēles tagi ievēro lietotāja lēmumu. Papildu niansēm izmantojiet ceļvedi par sīkfailu baneri WooCommerce.

Testēšanas matrica pirms palaišanas

Bez strukturētas testēšanas migrācija bieži tiek apstiprināta pārāk ātri. Pielāgojiet šo matricu savai vietnei un pievienojiet savus biznesa kritiskos scenārijus.

JomaTestsSagaidāmais rezultātsPierādījums
Pirmais apmeklējumsAtvērt vietni tīrā pārlūka profilāCookiePilot parādās, noklusējuma stāvoklis iestatīts pirms tagiemEkrānattēls, dataLayer, tīkla žurnāls
Noraidīt visuNoraidīt izvēles kategorijasAnalītikas un mārketinga tagi nepalaižas bez atbilstoša pamataGTM preview, sīkfailu saraksts
Pieņemt visuPieņemt visas kategorijasAtļautie tagi palaižas vienreiz un saņem atjauninātu piekrišanuGTM preview, GA4 notikumi
Daļēja izvēleAtļaut tikai analītikuAnalītika darbojas, mārketings paliek bloķētsConsent tab, tagu žurnāls
AtsaukšanaMainīt izvēli iestatījumosTurpmākā ielāde ievēro jauno izvēliVideo, sīkfaili, lokālā glabātuve
E-veikalsVeikt testa pirkumuObligātās funkcijas darbojas, izvēles tagi seko piekrišanaiTesta pasūtījums, tīkla pieprasījumi
ValodasPārslēgt latviešu un citas valodasTeksti, pogas un saites ir lokalizētasEkrānattēli
Mobilais skatsTestēt mazu ekrānuBaneris ir salasāms, pogas sasniedzamasMobilais ekrānattēls
AtkāpšanāsTestā atjaunot iepriekšējo risinājumuKomanda zina, kā atgrieztiesPierakstīts process

Biežākās kļūdas migrācijas laikā

Pirmā kļūda ir redzamā banera nomaiņa, atstājot veco loģiku GTM vai vietnes kodā. Vietne izskatās migrēta, bet tagi joprojām gaida vecos notikumus, kategorijas vai datu slāņa vērtības. Pirms palaišanas meklējiet vecās atsauces GTM, spraudņos, tēmā, koda fragmentos un dokumentācijā.

Otra kļūda ir pierādījumu nesaglabāšana. Kad vecā konfigurācija ir dzēsta, to atjaunot no atmiņas ir grūti. Trešā kļūda ir paļaušanās tikai uz automātisku skenēšanu. Skenēšana ir noderīga, bet tā var nepamanīt skriptus, kas parādās tikai pēc pieteikšanās, groza izmaiņām, maksājuma vai konkrēta lietotāja segmenta.

Ceturtā kļūda ir pārāk plaša palaišana. Ja vienā relīzē maināt CMP, analītiku, dizainu, checkout un reklāmas kontus, vēlāk būs grūti saprast, kas izraisīja kļūdu. Piektā kļūda ir mehāniski tulkots baneris. Latvijas lietotājiem tekstam jābūt skaidram un dabiskam, nevis juridiski smagam vai acīmredzami pārnestam no citas valodas.

Sestā kļūda ir neskaidra atbildība. Mārketings zina kampaņas, izstrāde redz kodu, e-komercija redz pasūtījumus, bet juridiskā puse vērtē nolūkus. Migrācijai vajag vienu atbildīgo īpašnieku un skaidrus pārskatītājus.

Palaišanas kontrolsaraksts

Pirms palaišanas pārbaudiet:

  • CookiePilot ir iestatīts visiem aktīvajiem domēniem, apakšdomēniem un valodām.
  • Vecais Cookiebot produkcijā vairs netiek ielādēts.
  • Banera teksti, pogas un kategorijas ir pārskatītas latviski.
  • Privātuma politika un sīkfailu informācija ir aktuāla.
  • GTM noklusējuma piekrišana tiek iestatīta pirms atkarīgajiem tagiem.
  • Google Consent Mode v2 ir pārbaudīts GA4 un Google Ads tagiem.
  • Ne-Google tagiem ir skaidri aktivizēšanas nosacījumi.
  • WordPress tēma, spraudņi un WooCommerce paplašinājumi ir pārbaudīti.
  • Testēta pieņemšana, noraidīšana, daļēja izvēle, atsaukšana un atgriešanās.
  • Atkāpšanās plāns ir pierakstīts, pārbaudīts un piešķirts konkrētai personai.
  • Testu pierādījumi ir saglabāti koplietojamā vietā.

Palaišanas brīdī turiet izmaiņas pēc iespējas šauras. Publicējiet CookiePilot konfigurāciju, vietnes izmaiņas un GTM versiju saskaņotā secībā. Uzreiz pēc tam pārbaudiet sākumlapu, galvenās kategorijas, produkta lapu, grozu, checkout un pasūtījuma apstiprinājumu.

Pirms publiskas palaišanas sagatavojiet īsu saziņas pierakstu iekšējai komandai. Tajā norādiet, kas mainās, kad tas notiek, kurš pārbauda mārketinga tagus, kurš pārbauda veikala plūsmu un kurš pieņem lēmumu par atkāpšanos. Šāds pieraksts ir īpaši noderīgs mazākām komandām, kur viena persona pārvalda gan reklāmu kontus, gan tīmekļa saturu. Ja kaut kas nedarbojas, laiks netiek tērēts, meklējot pareizo atbildīgo.

Iesaistiet arī ārējos partnerus. Daudzām Latvijas vietnēm reklāmas kontus pārvalda aģentūra, tehnisko uzturēšanu veic izstrādātājs, bet saturu ievieto uzņēmuma komanda. Ja šie cilvēki nezina, ka CMP loģika ir mainīta, viņi var nejauši publicēt vecu GTM versiju, atjaunot Cookiebot spraudni vai pievienot jaunu pikseli bez piekrišanas nosacījumiem. Pirms palaišanas pārliecinieties, ka visiem ir zināms jaunais process un ka piekļuves tiesības nav plašākas, nekā nepieciešams.

Uzraudzība pēc palaišanas

Pirmajās 24 stundās sekojiet banera attēlošanai, pārlūka konsoles kļūdām, sīkfailiem, GTM priekšskatījumam, GA4 reāllaika pārskatiem, reklāmas platformu diagnostikai, reklāmguvumu notikumiem un klientu atbalsta ziņām. E-veikalā īpaši pārbaudiet maksājumu plūsmu un pasūtījuma apstiprinājuma lapu, jo tur bieži sakrīt obligātās funkcijas un mērījumu tagi.

Pirmajā nedēļā skatieties tendences, nevis vienu izolētu rādītāju. Piekrišanas īpatsvars var mainīties, jo lietotāji redz citu formulējumu vai skaidrākas kategorijas. Analītikas dati var mainīties, jo tagi tagad precīzāk ievēro piekrišanu. Tas ne vienmēr nozīmē kļūdu, bet komandai vajag pierakstītu skaidrojumu.

Pēc vienas vai divām nedēļām ieplānojiet īsu pārskatu. Pārbaudiet, vai inventārs ir atjaunināts, vai jauni tagi tiek pievienoti tikai caur saskaņotu procesu un vai katram pakalpojumam ir īpašnieks. Migrācija ir vērtīga tad, ja tā uzlabo ikdienas pārvaldību arī pēc palaišanas dienas.

Vēlams ieviest regulāru mini auditu reizi mēnesī vai ceturksnī. Pārskatiet jaunos spraudņus, kampaņu pikseļus, formas, iegultos video un galvenās veikala lapas. Salīdziniet aktīvos tagus ar apstiprināto inventāru un pierakstiet izmaiņas. Tas neprasa lielu projektu, bet palīdz novērst situāciju, kur pēc sakārtotas migrācijas vietnē pakāpeniski atkal parādās rīki bez īpašnieka un bez skaidras kategorijas.

Ja mārketings regulāri pievieno jaunas kampaņu platformas, izveidojiet vienkāršu ievades kārtību: pirms taga publicēšanas jābūt zināmam nolūkam, datu saņēmējam, kategorijai, lapām, kur tas ielādēsies, un testam pēc pieņemšanas un noraidīšanas. Šī kārtība padara CookiePilot ieviešanu ilgtspējīgu, nevis tikai vienreizēju nomaiņu.

Uzraudzībā iekļaujiet arī klientu pieredzi. Ja baneris aizsedz svarīgu pogu mobilajā skatā, ja grozā pazūd maksājuma iespēja vai ja lietotājs nevar viegli mainīt izvēli, tas ir jālabo neatkarīgi no tā, ka tehniskie signāli izskatās pareizi. Piekrišanas slānim jābūt saprotamam un lietojamam, jo citādi tas rada gan reputācijas, gan komerciālu problēmu.

Latvijā lietotāji bieži salīdzina pieredzi latviešu, krievu un angļu valodas versijās, pat ja uzņēmuma galvenā valoda ir latviešu. Ja vietnē ir vairākas valodas, pēc palaišanas pārbaudiet, vai preferences poga, privātuma saites un kategoriju apraksti nav palikuši tikai vienā valodā. Nekvalitatīva lokalizācija var mazināt uzticēšanos tieši tajā brīdī, kad lietotājs pieņem lēmumu par datu izmantošanu.

Svarīgi ir arī saglabāt lēmumu vēsturi. Pierakstiet, kāpēc konkrēts pakalpojums ir iekļauts noteiktā kategorijā, kurš to apstiprināja un kāds tests pierāda vēlamo uzvedību. Šāda dokumentācija nav jāpadara sarežģīta: pietiek ar koplietotu tabulu, datumiem un saitēm uz ekrānattēliem. Kad pēc dažiem mēnešiem mainās aģentūra, darbinieks vai spraudnis, šis pieraksts ļauj turpināt darbu bez minējumiem.

Tas ir īpaši vērtīgi sezonālās kampaņās, kad lēmumi par jauniem tagiem bieži tiek pieņemti ātri un bez pilna projekta ritma.

Lēmums: pāriet tagad vai pagaidīt

Pāriet tagad ir saprātīgi, ja jums ir skaidrs biznesa iemesls, zināms tagu inventārs, pieejams testēšanas logs, atbildīgais īpašnieks un komanda, kas var pārbaudīt tehniskās, mārketinga un juridiskās sekas. Labi iemesli ir Consent Mode v2 sagatavošana, WooCommerce pārveide, vairāku valodu ieviešana, labāka piegādātāju pārvaldība vai vēlme vienkāršot CMP ikdienas darbu.

Pagaidiet, ja neviens nevar nosaukt aktīvos tagus, ja vietne pašlaik piedzīvo nestabilu lielu relīzi vai ja nav panākta vienošanās par kategorijām. Tad vispirms sagatavojiet inventāru un lēmuma pierakstu. Kad pamats ir skaidrs, nākamais solis var būt CookiePilot funkciju pārskats, cenu izvērtēšana vai saziņa caur kontaktu lapu ar informāciju par domēniem, CMS, GTM, e-komerciju un vēlamo termiņu.

Biežāk uzdotie jautājumi

Vai varam pārcelt vecās piekrišanas no Cookiebot uz CookiePilot?

Vispirms eksportējiet un saglabājiet pieejamos ierakstus. To izmantošana jaunā vidē ir atkarīga no kategorijām, tekstiem, nolūkiem, sniedzējiem un jūsu juridiskā vērtējuma. Automātisku pārnesi nevajadzētu pieņemt kā pašsaprotamu.

Vai migrācijā jāmaina Google Tag Manager?

Parasti jā. Pat ja lietotājam redzamā izmaiņa ir baneris, GTM aktivizētāji un piekrišanas iestatījumi bieži ir piesaistīti vecajai ieviešanai. Pārbaudiet tos priekšskatījumā pirms palaišanas.

Vai CookiePilot pats nodrošina GDPR vai sīkfailu noteikumu ievērošanu?

Nē. CookiePilot var palīdzēt ar piekrišanu pārvaldību, konfigurāciju un pierādījumu uzturēšanu, bet atbilstība ir atkarīga no jūsu izvēlēm, tekstiem, pakalpojumiem, nolūkiem un procesiem.

Cik ilgi aizņem pāreja no Cookiebot uz CookiePilot?

Vienkāršu informatīvu vietni var sagatavot ātrāk nekā daudzvalodu e-veikalu ar daudziem tagiem. Visvairāk laika parasti aizņem audits, kartēšana un testēšana.

Ko noteikti testēt pirms palaišanas?

Testējiet pirmo apmeklējumu, visu pieņemšanu, visu noraidīšanu, daļēju izvēli, piekrišanas atsaukšanu, atgriešanos, GTM piekrišanas stāvokļus un galvenos e-komercijas soļus.

Vai migrāciju labāk veikt kopā ar mājaslapas pārveidi?

Tas var būt efektīvi, jo tajā pašā laikā mainās veidnes, skripti un analītika. Tomēr vajadzīgs atsevišķs testēšanas plāns, lai CMP problēmas varētu nošķirt no dizaina vai checkout izmaiņām.

Ar ko sākt, ja pašreizējā ieviešana ir haotiska?

Sāciet ar inventāru. Pierakstiet katru skriptu, nolūku, īpašnieku, ielādes vietu, kategoriju un testu. Tikai pēc tam konfigurējiet jauno risinājumu.

Autors

Marcin

Zespół CookiePilot dzieli się wiedzą o RODO, PKE i zarządzaniu cookies.

Kopīgojiet šo rakstu: