Zgoda na cookies dla Lovable,
jednym promptem

Domyślny projekt Lovable ustawia cookies analityczne i marketingowe, gdy tylko te skrypty zostaną dodane. To dokładnie to zachowanie, za które europejskie organy nakładają kary, a obowiązek prawny spoczywa na Tobie, operatorze, nie na narzędziu, które wygenerowało kod.

Zasada jest taka sama w całej UE i w Wielkiej Brytanii: bez zgody nie wolno zapisywać na urządzeniu odwiedzającego ani odczytywać z niego niczego poza tym, co ściśle niezbędne. To artykuł 5 ust. 3 dyrektywy ePrivacy, a zgoda musi spełniać definicję z RODO: dobrowolna, konkretna, świadoma i jednoznaczna, z odmową równie łatwą jak akceptacja. Wielka Brytania utrzymuje tę samą zasadę w PECR, z wąskimi wyjątkami dla statystyk niskiego ryzyka od 5 lutego 2026 r. Kalifornia i inne prawa stanowe USA działają odwrotnie: bez opt-in, ale z linkiem opt-out i obsługą sygnału Global Privacy Control.

Dla strony wynikają z tego trzy rzeczy. Skrypty analityczne, reklamowe i społecznościowe muszą poczekać na decyzję. Decyzję trzeba zapisać tak, aby dało się ją później pokazać, bo artykuł 7 ust. 1 przerzuca ciężar dowodu na Ciebie. A wycofanie zgody musi być równie łatwe jak jej udzielenie, co oznacza element na każdej stronie, który ponownie otwiera baner. Baner, który pokazuje dwa przyciski i mimo to ładuje Google Analytics, oblewa pierwszy test, i właśnie za to organy nadzoru nakładają kary, od decyzji CNIL wobec Google i SHEIN po kontrole organów holenderskiego i belgijskiego.

Lovable generuje aplikację React na Vite z Tailwind i shadcn/ui, zwykle z Supabase w tle, i publikuje ją na subdomenie lovable.app lub Twojej własnej domenie. Runtime zgody należy do jedynego pliku, który ma każda aplikacja Vite: index.html, jako pierwszy w head. Lovable edytuje ten plik, gdy o to poprosisz, i zachowuje zmianę przy kolejnych promptach.

Czego Lovable sam nie zrobi, to nie zablokuje niczego. Jeśli poprosisz o „baner cookies”, model napisze komponent pokazujący dwa przyciski i zapisujący wartość logiczną, podczas gdy dodany wcześniej snippet Google Analytics lub Meta Pixel dalej działa przy każdym załadowaniu. To gorsze niż brak banera: wygląda na zgodne, a nie jest. Poniższy prompt robi dwie rzeczy, które się liczą, we właściwej kolejności: najpierw runtime, potem każdy tracker zamieniony w skrypt wymagający zgody.

Potem przejmuje skaner. Ładuje Twoją opublikowaną aplikację w prawdziwej przeglądarce, w każdym stanie zgody, i wypisuje, co nadal odpala przed zgodą, jeśli cokolwiek. Ponieważ aplikacje Lovable to SPA, skan podąża za trasami po stronie klienta, które odkryje w wyrenderowanym DOM; dodaj w panelu adresy startowe dla tras, których nie osiągnie ze strony głównej. Dziennik zgód rejestruje każdy wybór od chwili, gdy baner jest na żywo.

Projekty Lovable z Google Ads lub GA4 dostają wartości domyślne Consent Mode z runtime przed załadowaniem tych tagów, więc pomiary dalej działają dla odwiedzających, którzy mówią tak.

Google Consent Mode v2 to warstwa sygnałów między banerem a tagami Google. Zanim uruchomi się jakikolwiek tag, siedem sygnałów (ad_storage, analytics_storage, ad_user_data, ad_personalization, functionality_storage, personalization_storage, security_storage) jest ustawianych na „denied” dla odwiedzających z EOG, Wielkiej Brytanii i Szwajcarii. Gdy tylko ktoś dokona wyboru, runtime je aktualizuje, a tagi Google się dostosowują. Od 15 czerwca 2026 r. Google używa ad_storage jako sygnału decydującego o danych Ads, więc właściwa wartość domyślna liczy się bardziej niż kiedyś.

CookieCrumbs ustawia wartości domyślne synchronicznie, przed jakimkolwiek menedżerem tagów, aktualizuje je przy każdej decyzji i dostarcza szablon Google Tag Manager, dzięki czemu wyzwalacze zgody istnieją bez ręcznie pisanych listenerów. W trybie zaawansowanym bezcookie’owe pingi Google utrzymują modelowane konwersje dla odwiedzających, którzy odmówili. Czego nie robi: nie udaje CMP certyfikowanego przez Google. Do AdSense, Ad Managera lub AdMob w EOG nadal potrzebujesz takiego z IAB TCF, a CookieCrumbs dziś nim nie jest.