Meta Pixel без съгласие: защо CAPI не те спасява

На 4 юли 2025 г. съд в Лайпциг присъди 5 000 евро на един-единствен човек, не заради теч на данни, не заради хакерска атака, а само защото данните му са тръгнали към Meta, без той да е казал „да“. И това решение не е изолирано: към края на юли 2025 г. подобните дела срещу Meta са около 500, с обезщетения между 1 000 и 10 000 евро на човек.

Тук идва въпросът, който чувам най-често от собственици на онлайн магазини: „Добре, ама ние минахме на Conversions API. То е server-side, значи бисквитките вече не важат за нас.“ Важат. И то по два независими начина, всеки от които сам по себе си стига, за да ти спре кампанията.

Тази статия е за това защо съгласието за Meta Pixel не е формалност, която отмяташ с банер, а условие, без което нямаш право да пращаш нищо. Ще ти покажа откъде идва митът за server-side, какво казват европейският регулатор, съдът и българският закон, и накрая какво реално работи, когато човекът натисне „не“.

Накратко

• Conversions API не е извън закона. Полетата, които го правят полезен (хеширан имейл, IP, _fbp, _fbc), са същите, които го вкарват в обхвата на изискването за съгласие;
• Законът не е за бисквитките, а за устройството. Европейският комитет по защита на данните затвори тази врата с Насоки 2/2023: важно е откъде идват данните, не кой сървър ги праща;
• Легитимен интерес не работи за реклама. Съдът на ЕС отряза това основание дори за самата Meta;
• Отговорността е твоя. Като оператор на сайта си съвместен администратор за момента, в който данните тръгват, а договорът ти с Meta изрично изисква „проверимо“ съгласие;
• Има законни алтернативи. Моделирани конверсии от съгласилата се група, собствена first-party аналитика и по-висок процент на съгласие ти дават реална картина, без да пращаш човек на трето лице.

„Ама Conversions API е server-side“: откъде тръгна митът?

За да разберем защо митът е толкова устойчив, трябва да си спомним защо всички изобщо минаха на CAPI. Safari блокира third-party бисквитките през 2017 г., Firefox го последва през 2019 г., а iOS 14.5 и App Tracking Transparency през 2021 г. довършиха работата. Пикселът започна да губи голяма част от събитията и рекламодателите останаха да оптимизират почти на сляпо.

Тогава Meta пусна Conversions API, интерфейс, през който твоят сървър праща събитията директно към Meta, вместо браузърът на клиента. Логиката изглежда желязна: щом сървърът праща, а не браузърът, значи няма бисквитка, а щом няма бисквитка, няма „бисквитен закон“. Проблемът е, че този закон никога не е бил за бисквитките.

Погледни какво реално отива към Meta при едно Purchase събитие с приличен Event Match Quality! Ако вече си минавал през нашето ръководство за интеграция на Meta Pixel, Google Tag Manager и Google Analytics, знаеш кои полета се пълнят:

• _fbp — бисквитка, която пикселът е записал в браузъра на клиента;
• _fbc — идва от параметъра fbclid в линка на рекламата;
• client_ip_address — IP адресът на клиента;
• client_user_agent — браузърът и операционната система;
• em, ph, external_id — хешираните имейл, телефон и потребителско ID.

Сега си представи, че махнеш всичките! Какво остава? Събитие „някой купи нещо за 89 €“ без нито един идентификатор. Meta не може да го свърже с човек, Event Match Quality пада към нулата и оптимизацията спира да работи. Ето го неудобното: полетата, които правят CAPI полезен, са точно същите полета, които го вкарват в обхвата на закона. Няма версия, в която едновременно да е полезен и да е извън обхвата.

Законът не е за бисквитките, а за устройството

Чл. 5(3) от Директива 2002/58 (ePrivacy, европейските правила за неприкосновеност в електронните комуникации) не съдържа думата „бисквитка“. Той говори за съхраняване или получаване на достъп до информация в крайното устройство. Информация, не лични данни, а това е далеч по-широко понятие.

През октомври 2024 г. Европейският комитет по защита на данните прие в окончателен вид Насоки 2/2023 относно техническия обхват на чл. 5(3). Писани са точно заради новите методи за проследяване, които заместиха бисквитките. Два от изводите те засягат пряко.

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

Второ, хешираният имейл също е вътре. Насоките описват „уникални идентификатори“, извлечени от постоянни лични данни (име, имейл, телефон), хеширани на устройството на потребителя и споделяни между няколко администратора, за да идентифицират еднозначно едно лице. Прочети това и го сравни с Advanced Matching: това е същото нещо, описано с други думи. Комитетът дори разглежда проследяване само по IP адрес и стига до извода, че чл. 5(3) може да се приложи и там.

Изводът е сух: инструктирането на браузъра да изпрати информацията вече е „получаване на достъп“ и задейства разпоредбата. Каналът е без значение.

Дори без бисквитки остава GDPR

Да речем, че си инат и махнеш всичко от устройството: _fbp, _fbc, IP адреса, user-agent-а. Оставяш само хеширан имейл, който клиентът сам е написал във формата за поръчка на твоя сайт. Пак не си чист, само че вече по друга причина.

SHA-256 хешът на имейл е псевдонимизация, не анонимизация: данните си остават лични. Ето най-простия тест: ако хешираният имейл беше анонимен, CAPI нямаше да работи. Цялата идея е Meta да вземе твоя хеш, да го сравни със своя хеш на същия имейл и да намери профила. Не можеш да твърдиш едновременно „това идентифицира клиента ми в Meta“ и „това не са лични данни“. Избери едно!

А ако разчиташ на легитимен интерес, за да не искаш съгласие, тук е доказателството, което слага край на дискусията. На 4 юли 2023 г. Съдът на Европейския съюз се произнесе по дело C-252/21, Meta срещу Bundeskartellamt и постанови, че персонализираната реклама, с която Facebook финансира дейността си, не може да се обоснове като легитимен интерес при липса на съгласие.

Спри се тук за момент: ако самата Meta, чийто цял бизнес модел е точно това, няма легитимен интерес да обработва данните за реклама, ти като рекламодател, който ѝ ги подаваш, откъде ще го извадиш?

Същото решение затваря и последната вратичка: „клиентът купи от мен, значи имам договор“. Съдът казва, че договорът оправдава обработването само ако то е обективно необходимо, така че основният предмет на договора да не може да се постигне без него. Ти продаваш продукт, клиентът плаща, ти доставяш. Изпращането на конверсия към Facebook няма нищо общо с доставката: договорът се изпълнява идеално и без нея.

Какво казва българският закон?

Чл. 5(3) е транспониран у нас чрез чл. 4а от Закона за електронната търговия и тук има уловка, за която повечето български сайтове не подозират. Текстът позволява съхраняване и достъп, при условие че на получателя е предоставена възможност да откаже, тоест opt-out, а не предварително съгласие.

Това е дефектна транспозиция: България така и не отрази изменението от 2009 г., което въведе изискването за предварително съгласие. Ако четеш само буквата на българския закон, изглежда, че банер с „продължавайки, приемаш“ минава. Не разчитай на това и ето три причини.

1. КЗЛД казва обратното. В собствените си насоки Комисията за защита на личните данни изисква предварително съгласие, изрично съгласие за рекламните бисквитки, банер без предварително маркирани категории и отказ, който е също толкова лесен, колкото приемането;
2. Съдът на ЕС вече се произнесе. По дело C-673/17 (Planet49) съдът отсече, че се изисква активно предварително съгласие: предварително маркирано чекче не върши работа;
3. GDPR е регламент. Действа пряко и не зависи от това как България си е написала закона. А доказването на основанието по чл. 6 е твое задължение, не на потребителя.

Колко струва грешката?

Дотук говорихме за теория. Ето цената в реални числа.

Германия. Решението на съда в Лайпциг от 4 юли 2025 г. по дело 05 O 2351/23 е важно с това, че съдът разгледа именно Conversions API, не само пиксела. От мотивите личи, че CAPI получава server-side данните, нужни за разпознаване на устройството, както и „аналогови“ лични данни като име в хеширана форма, без потребителят да може да проследи или предотврати това. Обезщетението е 5 000 евро на един човек, без доказана имуществена вреда; достатъчно е усещането за загуба на контрол.

По данни на Stiftung Warentest от 31 юли 2025 г. такива решения има около 500, с обезщетения между 1 000 и 10 000 евро. Честно е да се знае и че нито едно още не е влязло в сила: Meta обжалва редовно.

А защо това е твой проблем, а не на Meta? Защото решението по дело C-40/17 (Fashion ID) установи, че операторът на сайт, който вгражда инструмент на Facebook, е съвместен администратор за събирането и предаването на данните. Не за това какво Meta прави с тях после, но за момента, в който данните тръгват от твоя сайт, отговаряш ти. Ти си сложил пиксела, ти си свързал CAPI, ти си определил целта, оттам нататък „ама Meta го направи“ не работи.

Швеция. Регулаторът IMY глоби аптечните вериги Apoteket и Apohem съответно с 37 и 8 милиона крони заради предаване на чувствителни данни към Meta през пиксела. Причината е банална: включена подфункция (Advanced Matching), данни, които текат над две години, а никой отвътре не ги забелязва, докато не дойде сигнал отвън. Засегнати са до 930 000 души.

И договорът ти с Meta. Това е точката, която почти всички пропускат. Meta Business Tools Terms изрично изброяват Conversions API като Business Tool и изискват в ЕС да гарантираш по проверим начин, че потребителят е дал всички необходими съгласия. По проверим начин, не „предполагаме, че е ок“. А собствената документация на Meta за GDPR не предлага никакво изключение за CAPI.

Какво реално можеш да правиш без съгласие?

Дотук беше лошата новина. Сега полезната част, защото „не пращай нищо“ не значи „остани сляп“.

Агрегираното измерване не е GDPR вратичка. Ще чуеш, че Aggregated Event Measurement е „съвместимата с поверителност алтернатива“, но не е, поне не за този проблем. AEM е отговорът на Meta на Apple ATT, не на GDPR, и е слой за обработка върху събитията, които вече си изпратил. Не пуснеш ли нищо, няма какво да агрегира. А лимитът от „8 приоритизирани събития“ отпадна през юни 2025 г..

„Meta Consent Mode“ не съществува. Ще срещнеш десетки статии на доставчици на банери, според които при отказ пикселът пращал анонимни cookieless пингове, точно като Google Consent Mode v2, който поддържаме в платформата. Прочети ги внимателно и ще видиш, че си противоречат: изразът „cookieless pings“ е дословно от документацията на Google, а в тази на Meta го няма. fbq('consent', 'revoke') е локална ключалка, която спира пиксела, не канал за сигнал.

Моделираните конверсии са добрата новина. За да ги получиш, не ти трябва да пращаш нищо за отказалите се: Meta моделира от съгласилата се група, като гледа как се държат хората, за които има данни, и оценява останалите. Чистите събития за казалите „да“ вече ти дават моделирането, а мълчанието за останалите не ти струва нищо отгоре.

Собствена аналитика, независима от Meta. UTM параметрите не идентифицират човек, казват ти само от коя кампания идва трафикът. Комбинирани със собствена server-side статистика, при която ти си администраторът и няма предаване към трето лице, ти дават реална картина, без да зависят от това дали някой е натиснал „приемам“. Точно това прави нашата вградена услуга анализ и статистики: следиш кои реклами носят продажби, без да пращаш клиента си на Meta. Няма да ти каже кой точно е купил след коя реклама, но за решенията, които реално взимаш, второто е достатъчно.

Истинският лост е процентът на съгласие. Ето числото, което променя всичко: разликата между 35 % и 65 % съгласие ти носи повече данни, отколкото каквото и да е заобикаляне и е напълно законна. Банер, който не мами, отказ, който е също толкова лесен, колкото приемането, и едно изречение защо ти трябва. Хората не са глупави и когато им кажеш честно, голяма част казват „да“.

Накрая

Три неща за запомняне. Server-side не е правна стратегия: данните, които правят CAPI полезен, идват от устройството на клиента, а европейският регулатор затвори тази врата през 2024 г. Легитимният интерес не работи за реклама: Съдът на ЕС го отряза дори за самата Meta. А договорът ти с Meta изисква проверимо съгласие, независимо какво мислиш за закона.

Добрата новина е, че съответствието и резултатите не са в конфликт. Честният банер, чистата настройка и бързият сайт носят повече от всеки трик и не те държат буден нощем. Ако не си сигурен какво точно гърми на сайта ти, преди клиентът да натисне „приемам“, одитът на сайт го показва черно на бяло; повечето хора се изненадват какво са пуснали, без да знаят. При Creativiso Xpress Google Consent Mode v2, гейтването на Meta Pixel зад банера и собствената аналитика са част от платформата, не отделен проект за програмист.

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

Източници

1. Европейски комитет по защита на данните — Насоки 2/2023 относно техническия обхват на чл. 5(3) от ePrivacy, окончателна версия, октомври 2024 г.
2. Съд на ЕС — дело C-252/21, Meta срещу Bundeskartellamt, решение от 4 юли 2023 г.
3. Съд на ЕС — дело C-40/17, Fashion ID, решение от 29 юли 2019 г.
4. Landgericht Leipzig — дело 05 O 2351/23, решение от 4 юли 2025 г.
5. Stiftung Warentest, преглед на германската практика — около 500 решения, 31 юли 2025 г.
6. Integritetsskyddsmyndigheten (Швеция) — глоби срещу Apoteket и Apohem.
7. Meta Business Tools Terms и документация на Meta за GDPR.
8. Закон за електронната търговия, чл. 4а — транспониране на чл. 5(3) от ePrivacy.
9. Помощна страница на Meta за Aggregated Event Measurement — AEM е рамкиран около Apple ATT и iOS 14.5+, не около GDPR.
10. Документация за параметрите на Conversions API — CAPI изисква поне един идентификатор в user_data; събитие само с value и currency не е валидно.
11. Промяната в AEM от юни 2025 г. — премахнат лимитът от 8 събития и ръчното приоритизиране.
12. Противоречията около „Meta Consent Mode“ — пикселът на Meta няма еквивалент на cookieless пинговете на Google.

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