Миграция от Cookiebot към CookiePilot: практически наръчник

Миграцията от Cookiebot към CookiePilot не е просто смяна на банер за бисквитки. За екипите, които управляват маркетинг тагове, аналитика, WooCommerce магазин или няколко езикови версии, това е преместване на контролната точка за съгласие, скриптове, доказателства и измерване. Добре планираният преход намалява риска от прекъсване на кампании, дублиране на тагове и загуба на доверие в данните.

Този наръчник е за компании в България, които обмислят преминаване от Cookiebot към CookiePilot и искат практичен план, а не общи обещания. CookiePilot може да помогне с управлението на съгласие, категоризацията и внедряването, но никоя CMP платформа сама по себе си не гарантира съответствие. Важни остават вашите текстове, доставчици, правни основания, настройки, процеси и локалните изисквания.

Ако все още сравнявате варианти, започнете с страницата за алтернативи на Cookiebot, вижте функциите на CookiePilot и прегледайте цените. След това използвайте този материал като работен план за одит, замяна, Google Consent Mode v2, Google Tag Manager, електронна търговия, rollback и наблюдение след пускане.

Кога има смисъл да преминете от Cookiebot към CookiePilot

Преминаването има най-голям смисъл, когато настоящата CMP конфигурация вече създава оперативно триене. Типични поводи са редизайн на сайта, смяна на тема в WordPress, нов GTM контейнер, проект за Google Consent Mode v2, разширяване към нови пазари или нужда маркетингът и разработчиците да работят с по-ясен модел за тагове.

Преди да смените платформата, формулирайте конкретната бизнес причина. Искате ли по-лесно управление на категории? По-добра видимост кои скриптове се зареждат преди и след съгласие? По-подреден процес за WooCommerce checkout? По-ясно подаване на сигнали към Google Ads и Google Analytics 4? Ако причината е само „да сменим банера“, има риск старите проблеми да бъдат пренесени в нова система.

Също толкова важно е да определите какво не е част от миграцията. CMP не премахва автоматично ненужни доставчици, не пренаписва политиката за поверителност и не решава спорни правни въпроси. CookiePilot може да поддържа техническия слой за съгласие, но организацията трябва да реши кои услуги са необходими, в кои категории попадат и как изборът на потребителя се отразява върху зареждането на тагове.

За официален контекст използвайте сайтовете на Комисията за защита на личните данни, Комисията за регулиране на съобщенията, Европейския комитет по защита на данните и документацията на Google за Consent Mode. Те не заменят правен съвет, но помагат екипът да работи с надеждни източници.

Предварителен одит: какво точно заменяте

Започнете с инвентаризация на текущото внедряване на Cookiebot. Опишете къде е поставен скриптът, дали се зарежда през WordPress плъгин, тема, Google Tag Manager, custom code snippet, хедър в CMS или външна интеграция. Проверете всички домейни, поддомейни, езикови версии, landing страници, продуктови страници, checkout, профилни страници и форми за lead generation.

Практичната таблица за одит трябва да съдържа домейн, тип страница, текущ CMP източник, GTM контейнер, GA4 property, Google Ads conversion тагове, Meta Pixel, LinkedIn Insight Tag, чат инструменти, heatmap инструменти, видео embeds, affiliate скриптове, payment и fraud услуги, както и бележка дали скриптът е необходим, аналитичен, функционален или маркетингов. Не разчитайте само на административния панел. Сравнете данните с browser developer tools, GTM Preview, crawler и ръчна проверка.

Тествайте поне четири сценария: първо посещение без съгласие, отказ на всички незадължителни категории, приемане на всички категории и промяна на избора след първоначално съгласие. Гледайте какви cookies се записват преди действие на потребителя, какви мрежови заявки тръгват, кои тагове се активират и дали отказът реално спира скриптовете, които трябва да бъдат спрени.

Отделете специално внимание на скриптове, които бизнесът нарича „важни“. Това не означава автоматично „строго необходими“. Плащане, сигурност, количка, избор на език и load balancing могат да имат различна логика от рекламни аудитории, аналитика, персонализация или социални плъгини. Когато има съмнение, включете правен консултант и не решавайте категорията само по маркетинг удобство.

За български сайтове често има и практически локални особености. Формите за контакт могат да са свързани с CRM или имейл маркетинг инструмент, онлайн магазинът може да използва куриерски модули, а счетоводни или ERP интеграции могат да добавят проследяващи пиксели в определени шаблони. Ако сайтът обслужва и клиенти извън България, проверете дали езиковите версии не имат различни тагове, например отделни рекламни акаунти за Румъния, Гърция или Германия. Одитът трябва да отразява реалната публикация на сайта, а не само централната тема или основната начална страница.

Запазване на експорти и доказателства

Преди да премахнете Cookiebot, архивирайте наличната конфигурация. Запазете текстове на банера, категории, списъци с доставчици, домейн групи, езикови варианти, scan reports, настройки за prior consent, screenshots от реалния интерфейс, GTM версии и налични consent logs, ако вашият договор и настройка дават достъп до такива данни.

Създайте папка за миграцията с дата, отговорник, версия на сайта и кратко описание защо се прави промяната. Това е полезно по две причини. Първо, дава техническа опора, ако след пускането видите различно поведение на тагове или спад в измерването. Второ, съхранява история на решенията. При въпроси от клиент, вътрешен одит или регулатор е много по-лесно да покажете какво е променено, кога и на каква база.

Не прехвърляйте стари избори за съгласие към нова платформа автоматично. Категории, цели, доставчици, периоди на съхранение и текстове могат да се различават. Ако CookiePilot задава на потребителя различен въпрос или групира услугите по друг начин, приемането, че старият избор остава валиден, може да е неподходящо. Решението трябва да бъде документирано, а не оставено като техническа догадка.

В документацията включете и „преди“ измерване. Запишете нормалните стойности за consent rate, conversion rate, checkout completion, page views, рекламни конверсии и основни funnel стъпки. Не защото след миграцията трябва да бъдат идентични, а защото екипът ще има база за разговор. Ако след launch видите спад, ще можете да различите технически проблем от сезонност, промяна в кампания или естествен ефект от по-точна consent конфигурация.

Картографиране на категории, скриптове и сигнали

Най-рисковата част на миграцията е mapping-ът. „Статистика“ в стара настройка може да не отговаря напълно на „аналитика“ в нова. YouTube embed може да бъде третиран различно от GA4. Един доставчик може да има няколко услуги с различни цели. Затова картографирайте по цел и поведение, а не само по име на доставчик.

Използвайте четири работни групи: строго необходими, функционални или предпочитания, статистика или аналитика, маркетинг или реклама. За всеки скрипт запишете собственик, цел, страници, условие за зареждане, категория в CookiePilot, GTM trigger, consent signal и метод за тест. Така маркетингът, разработчиците и правният екип говорят за един и същ обект.

При Google Consent Mode v2 обърнете внимание на ad_storage, analytics_storage, ad_user_data и ad_personalization. В зависимост от внедряването може да имате и други сигнали, свързани с функционалност, персонализация и сигурност. Важното е CookiePilot, GTM и отделните тагове да споделят една логика за default състояние и update след избор.

Default consent трябва да бъде зададен преди Google таговете, които зависят от него. След това при приемане, отказ или промяна на категории трябва да се изпрати актуализация. За по-подробна подготовка вижте Google Consent Mode v2 и практическото ръководство за Google Consent Mode v2 с Google Tag Manager.

Направете mapping таблицата достатъчно конкретна, за да може нов човек в екипа да я използва след шест месеца. Например „GA4 - analytics - всички страници - задейства се след analytics consent - проверка чрез DebugView“ е полезен запис. „Google“ не е полезен запис. Същото важи за рекламни пиксели, които имат различни събития: page view, add to cart, begin checkout и purchase може да имат различни условия и различни места на зареждане.

План за замяна стъпка по стъпка

Третирайте миграцията като малък release, а не като бърза промяна в настройките. Най-добре е да работите първо в staging среда. Ако такава няма, използвайте ограничен прозорец за тест, ясна отговорност и готов rollback.

1. Замразете промени по стария CMP, GTM triggers и cookie категории.
2. Завършете одита и архивирайте експорти, screenshots и известни проблеми.
3. Конфигурирайте CookiePilot с домейни, езици, категории, текстове и поведение при избор.
4. Добавете CookiePilot в staging чрез препоръчания script, плъгин или интеграция.
5. Изключете Cookiebot в същата среда, за да няма две активни CMP системи.
6. Пренастройте GTM triggers, consent settings и hardcoded scripts.
7. Тествайте first load, reject all, accept all, granular choice, withdrawal и returning visitor.
8. Подгответе rollback: стара CMP версия, GTM workspace, CMS промени и отговорник.
9. Пуснете в период, в който разработчик, маркетинг и собственик на сайта могат да проверят заедно.
10. Наблюдавайте данни, тагове, checkout и сигнали от потребители през първата седмица.

За WordPress сайтове проверете дали старата CMP не се зарежда едновременно от плъгин и theme header. За магазини вижте и ръководството за cookie banner за WooCommerce, защото checkout и payment flow често имат отделни скриптове и различен ред на зареждане.

GTM и валидиране на Google Consent Mode v2

Google Tag Manager често е центърът на миграцията. Отворете GTM Preview в чист browser profile и проверете дали consent default се задава преди таговете, които го използват. След това тествайте всяко действие върху банера и вижте дали consent update пристига в правилния момент.

За GA4 проверете page_view, session_start, ecommerce events, custom events и cross-domain сценарии. За Google Ads проверете conversion linker, remarketing, conversion tags и enhanced conversions, ако ги използвате. За Meta, LinkedIn, TikTok, affiliate платформи, имейл automation и chat widgets Consent Mode не е универсална замяна на тригерите. Тези тагове трябва да имат собствен контрол според категорията.

В Chrome DevTools следете cookies, local storage, network requests и dataLayer. Проверете дали няма дублирани събития от паралелно зареждане на Cookiebot и CookiePilot. Нормалните потребители не трябва да виждат два банера или да получават два конфликтни consent update-а. Ако временно сравнявате двете системи в staging, изолирайте теста и го документирайте.

Добра техника е да създадете отделен GTM workspace само за миграцията. Така виждате ясно кои triggers, variables и tags са променени. Именувайте ги последователно, например с префикс CP или с описание на категорията. След launch публикувайте версия с разбираемо име и бележка какво съдържа. Това улеснява rollback и последваща поддръжка, особено ако по GTM работят външни агенции.

WordPress, WooCommerce и електронна търговия

В WordPress миграцията често се усложнява от плъгини за header scripts, кеширане, consent add-ons, page builders и theme hooks. Изчистете всички места, от които Cookiebot може да се зарежда. След това поставете CookiePilot по един контролиран начин и документирайте къде се намира.

WooCommerce изисква отделна матрица. Тествайте product view, add to cart, cart update, coupon, login, checkout, payment redirect, thank-you page, subscription renewal, review widgets и upsell инструменти. Някои плъгини зареждат скриптове само на checkout или order confirmation. Ако ги пропуснете в одита, може да откриете проблема чак след пускане.

При ecommerce измерване не очаквайте числата преди и след миграцията да съвпадат идеално. Изборът на потребителите, браузърите, ad blockers, Consent Mode моделиране и промени в тригерите влияят върху отчетите. Целта на launch проверката е да докаже, че таговете се активират когато трябва, остават спрени когато трябва и подават правилните consent сигнали.

Проверете и българските специфики на checkout процеса: наложен платеж, плащане с карта, банков превод, куриерски офис, автоматично попълване на адрес и интеграции за фактуриране. Не всички тези услуги са свързани с marketing consent, но някои плъгини добавят външни скриптове, които трябва да се разберат. Ако услугата е нужна за изпълнение на поръчката, документирайте защо. Ако служи за анализ или реклама, поставете я в подходяща категория и я тествайте като такава.

Сравнителна тестова матрица

Област	Преди миграция	След CookiePilot	Какво да проверите
Банер и предпочитания	Текстове, категории, езици в Cookiebot	Локализирани текстове и категории в CookiePilot	Ясен избор, отказ, запазване, повторно отваряне
GTM	Стари triggers и consent checks	Нови triggers и consent states	Preview mode, consent tab, липса на дублиране
Google Consent Mode v2	Default и update сигнали	ad_storage, analytics_storage, ad_user_data, ad_personalization	Default преди таговете, update след избор
Analytics	GA4 events и cookies	GA4 поведение според категорията	Page view, ecommerce, reject и accept сценарии
Реклама	Google Ads, Meta, affiliate тагове	Контрол според маркетинг съгласие	Конверсии, remarketing, network requests
WooCommerce	Checkout и плащания	Същият поток без блокиране на нужни услуги	Add to cart, плащане, thank-you page
Доказателства	Експорти и screenshots	Нови настройки и launch запис	Дата, отговорник, резултати от тестове

Чести грешки

• Оставяне на Cookiebot и CookiePilot активни едновременно в production.
• Картографиране по име на доставчик вместо по реална цел на скрипта.
• Забравени hardcoded scripts в theme header, footer или page builder.
• Default consent, който се задава след Google таговете.
• Непроверени checkout, payment и account страници.
• Липса на архив на старата конфигурация и GTM версия.
• Прекалено общи текстове, които не описват конкретните цели на сайта.
• Приемане, че CMP инструментът сам гарантира съответствие.

Launch checklist

• Одитът е завършен и покрива основните шаблони, checkout и ключови landing pages.
• Cookiebot конфигурацията, screenshots и scan reports са архивирани.
• CookiePilot е конфигуриран с домейни, езици, категории и локални текстове.
• Вътрешните собственици на тагове са потвърдили category mapping.
• GTM workspace е прегледан и готов за публикуване.
• Consent Mode v2 default и update са валидирани.
• WordPress кеш, CDN и plugin conflicts са проверени.
• Rollback планът е описан с конкретни стъпки и отговорник.
• Маркетинг, разработчици и site owner имат общ launch прозорец.
• След пускане има план за мониторинг поне седем дни.

Вътрешна отговорност и комуникация

Миграцията върви по-добре, когато има един технически owner и ясни участници от маркетинг, правен екип и ecommerce. Техническият owner не трябва сам да решава правната категория на всеки доставчик, а правният екип не трябва да бъде оставен без информация как реално се зареждат скриптовете. Използвайте одитната таблица като общ документ, в който всеки запис има собственик и статус.

Преди launch изпратете кратко вътрешно съобщение до support, sales и хората, които следят кампании. Обяснете кога ще има промяна, какво може да се наблюдава и към кого да се ескалира. Ако клиент съобщи, че вижда банер повече от веднъж, че предпочитанията не се запазват или че checkout изглежда различно, support трябва да знае дали това е очаквано поведение, кеш проблем или сигнал за rollback.

Rollback план

Rollback не е признание за провал, а част от контролирана миграция. Преди launch запазете стара GTM версия, CMS промени, Cookiebot script location и списък със стъпки за възстановяване. Определете кой може да върне GTM контейнера, кой може да промени WordPress или deployment конфигурацията и кой решава дали проблемът е достатъчно сериозен за rollback.

Задайте критерии предварително: липсващ банер, блокиран checkout, дублирани конверсии, липса на consent updates, критичен спад в плащанията или явна грешка в локализацията. Ако критерият се активира, върнете системата по описания ред, запазете evidence от проблема и анализирайте причината в staging.

Наблюдение след пускане

През първите дни след преминаването следете consent rates, GA4 real-time, Google Ads conversions, GTM debug reports, checkout completion, bounce rate на ключови страници и съобщения до support. Не правете прибързани изводи от един ден данни. Сравнявайте с подобни дни, кампании и сезонност.

Добра практика е да направите кратък review след една седмица. Проверете дали всички известни проблеми са затворени, дали нови тагове се добавят през правилния процес и дали текстовете в банера отговарят на реалните услуги. За допълнителна ориентация може да видите и материала за ценообразуване на CMP решения или да се свържете с екипа чрез контакт.

След първия review определете постоянен процес. Когато маркетингът добавя нов pixel, когато ecommerce екипът инсталира нов payment или review плъгин, или когато разработчиците добавят embed, промяната трябва да минава през consent оценка. Това предпазва новата CookiePilot конфигурация от постепенно замърсяване със скриптове, които никой не е категоризирал.

Как да вземете решение

Ако имате малък сайт с няколко основни тагa, решението може да бъде сравнително бързо: одит, конфигурация, тест и пускане. Ако управлявате ecommerce, няколко пазара, множество рекламни канали и сложен GTM, планирайте миграцията като координиран проект. CookiePilot е най-полезен, когато искате по-ясен consent workflow и по-подредено управление на скриптове, а не когато търсите магическо решение без вътрешна дисциплина.

Изберете момент, в който не върви критична кампания, не се прави голяма промяна по checkout и имате наличен екип за проверка. Най-добрият преход от Cookiebot към CookiePilot е този, който потребителят почти не забелязва, но вашият екип усеща като по-чист и по-управляем процес.

Ако решението все още не е ясно, оценете три въпроса. Първо, колко време губите с настоящата настройка при всяка промяна на тагове? Второ, можете ли уверено да обясните кои скриптове се зареждат при отказ и при приемане? Трето, имате ли доказателства и тестове, които показват как работи consent layer-ът днес? Ако отговорите са неясни, миграцията е възможност не само да смените инструмент, а да подредите процеса.

Често задавани въпроси

Колко време отнема миграцията от Cookiebot към CookiePilot?

За малък сайт може да отнеме няколко работни дни, ако таговете са подредени. За WooCommerce магазин, многоезичен сайт или сложен GTM контейнер планирайте повече време за одит, mapping, тестове и наблюдение.

Мога ли да запазя старите съгласия?

Не трябва да приемате това автоматично. Старите избори може да са свързани с различни категории, текстове или доставчици. Решението трябва да бъде проверено технически и правно.

Трябва ли да премахна Cookiebot напълно?

Да, за production потребители трябва да има една активна CMP логика. Две платформи могат да създадат конфликтни сигнали, дублирани банери и неправилно поведение на тагове.

CookiePilot гарантира ли съответствие с GDPR?

Не. CookiePilot може да помогне с управлението на съгласие и техническата конфигурация, но съответствието зависи от вашите практики, текстове, доставчици и правни решения.

Какво е най-важно за Google Consent Mode v2?

Default consent трябва да се зададе преди релевантните Google тагове, а update да се изпрати след избора на потребителя. След това проверете поведението в GTM Preview и browser developer tools.

Какво да тествам в WooCommerce?

Тествайте product view, add to cart, cart, coupon, checkout, payment redirect, thank-you page, account login и всички плъгини, които добавят скриптове само в магазина.

Какво да направя след първия месец?

Направете повторен scan, прегледайте GTM промените след launch, сравнете основните метрики и проверете дали нови доставчици са добавени през правилния процес. Така миграцията остава работеща практика, а не еднократен проект.