DEV Community: Mehwish Malik

Why Are My Consent Flags Correct in Tag Manager but Wrong in the CRM?

Mehwish Malik — Thu, 20 Aug 2026 06:37:39 +0000

Because you solved collection and skipped propagation. Most consent bugs aren't legal
problems. They're sync problems.

A user clicks reject. Your banner writes it locally. Your tag manager reads it. And
then nothing else in your stack ever hears about it again.

The four flags Google reads

ad_storage : may we set advertising cookies
analytics_storage : may we set measurement cookies
ad_user_data : may we send user data to Google for ads
ad_personalization : may we personalise ads

The last two arrived in November 2023. Since March 2024, Customer Match lists used in
the EEA need both set to GRANTED. Miss one and the list just doesn't serve. No warning,
no error.

Setting these is an afternoon's work. Keeping them honest is the part nobody owns.

Where it drifts

Your user changes their mind in the mobile app three weeks later.

Your web container never finds out. Neither does your CRM. Your email tool keeps
sending. The flags in your tag manager are still perfectly valid, and now they're also
wrong.

The bit that actually bites: identity

Here's the design decision that decides whether any of this works.

Consent keyed to a cookie is consent keyed to a browser. Same person on a phone and a
laptop gives you two records, and eventually two different answers.

Key it to a stable user identifier instead, and resolve the anonymous cookie to that
identifier the moment they log in. Otherwise universal consent quietly becomes
per-device consent with extra steps.

Build it as a service

Write once to a central store. Then push, don't poll. Webhooks out to your CRM, ESP,
warehouse and ad platforms.

Watch your propagation window. If your CRM syncs overnight, that's up to 24 hours of
processing you can't defend. Batch is fine for reporting and useless for revocation.

Stamp every write with a timestamp, the purpose, the channel and the rule that applied
at that moment. A year from now that stamp is the only thing standing between you and
"we think so".

And version your banner copy. Proving someone consented is easy. Proving what they were
looking at when they did it is what people forget to build.

The universal consent model
covers how offline and in-app consent joins the same record.

(If you'd rather not build the identity layer, propagation queue and audit log
yourself, Seers AI ships it: https://seers.ai/)

Four questions stall enterprise deals. Most teams cannot answer one of them.

Mehwish Malik — Tue, 18 Aug 2026 12:51:58 +0000

Ask your team which EU AI Act article your production model triggers.

Most cannot answer. Since 2 August 2026, somebody can ask officially.

What landed on that date

The AI Office and national authorities took on supervision and enforcement.

Their powers are concrete:

Send a formal request for information.
Run their own evaluation of your model.
Demand access to a general-purpose model.
Interview staff and inspect provider premises.
Order a provider to restrict a model's public availability. None of that starts in a courtroom.

Five artefacts, and when to build them

Evidence, not intent. That means:

A register with a named owner per model, including third-party APIs and bundled vendor features.
Data lineage per dataset. Source, licence, and whether personal data sits inside it.
Model cards and version history, so you can say which version decided what, and when.
Input and output logs for anything touching a person's job, credit, health or education.
A human review path that somebody actually staffs. Build it into the pipeline. Reconstructing it after an incident does not work.

Teams already running consent tooling from Seers hold half of this. Disclosure evidence and data maps overlap heavily with AI documentation.

One deadline moved. One did not.

Annex III high-risk duties now apply from 2 December 2027. High-risk AI inside regulated products gets until 2 August 2028.

That is real breathing room.

GDPR did not move. Articles 13 and 14 already require you to tell people how automated processing works on their data.

Why the business cares

A register with owners, versions and logs answers a customer security questionnaire in a day.

Without one it takes a month. Enterprise deals stall on that gap more often than on price.

The comparison of AI governance and AI compliance is worth reading before your next release.

Seers AI Governance scans a live site and maps each system it finds to the articles that system triggers.

Your Hashed User IDs Are Still Personal Data Under GDPR

Mehwish Malik — Tue, 18 Aug 2026 06:36:44 +0000

Plenty of engineering teams believe that hashing an email or swapping a real user ID for a random token takes a table out of GDPR scope. It does not, and the wording of the law is the reason.

Article 4(5) defines pseudonymisation as processing personal data so that it "can no longer be attributed to a specific data subject without the use of additional information".

The ICO reads that exactly as written: pseudonymisation is "effectively only a security measure. It does not change the status of the data as personal data".

So if a salt, a key vault entry, a lookup table or a join key exists anywhere in your estate, the hashed table is personal data. Retention limits, breach reporting and subject access requests all still apply to it.

What actually leaves scope

Only irreversible anonymisation. If any reasonable means could relink a row to a person, you are still inside GDPR.

Where this bites in real stacks

Client-side tags firing before the consent state resolves.
Web servers keeping full IP addresses in default log config.
Error monitoring attaching session and device IDs to stack traces.
Mobile SDKs reading the advertising identifier on app launch. Each of those touches something on the regulator list of what counts as personal data under GDPR, so each one needs a lawful basis before it runs.

Why the business cares

Article 83 puts the upper tier at 20 million euros or 4% of global annual turnover. A logging default is a cheap fix. An enforcement action is not.

Fix it at the edge, not in twelve codebases

Chasing consent logic through every SDK is work you will repeat forever. Move collection behind server side tagging and you get one control point instead of twelve.

Seers.AI sits there and decides, per visitor, per identifier, what is allowed to leave. The AI learns your tag landscape as it changes, so a new script added by the marketing team does not quietly become your next incident. Give the boring part to a system that never forgets to check.

fbq('consent','revoke') Before init: The One Line Most Meta Pixel Setups Are Missing

Mehwish Malik — Thu, 06 Aug 2026 07:47:24 +0000

Most Meta Pixel installs are compliant in intention and leaking in practice. The reason is sequencing.

The default snippet Meta gives you calls fbq('init', ...) and then fbq('track', 'PageView'). Both sit high in the so the Pixel loads fast. Your consent banner is a separate script that loads later. For the window between them, the Pixel has already sent a PageView with no consent recorded anywhere.

Meta's own GDPR implementation docs cover the fix. The Pixel has a consent state, and you set it before you initialise:

`js fbq('consent', 'revoke'); // must run before init fbq('init', 'YOUR_PIXEL_ID'); fbq('track', 'PageView');

Then, in your banner's accept handler:

js fbq('consent', 'grant');

While revoked, the Pixel loads but holds back tracking data. That is the state you want by default for EU and UK traffic.

The part that catches teams out

The Conversions API does not inherit this. It runs server side, so your revoke call has no reach over it. If you are gating the Pixel and firing CAPI events for everyone, you have gated the visible half of your setup and left the other half open. The route changed. The legal basis did not.

Second trap: if the Pixel and CAPI both report the same purchase, you double count it. Meta deduplicates when both events carry the same event_id and event_name`. Generate the ID once per event, pass it to both, and your numbers stop inflating.

One more that has quietly changed: the Advertiser Tracking Enabled parameter is no longer required for Facebook SDK for iOS 17.0.0 and later. If your mobile setup still hardcodes it, review it.

The full sequence, including the GTM variant, is in this walkthrough of facebook ads consent tracking.

Where a CMP earns its place

Wiring this by hand across Meta, Google Consent Mode v2 and Microsoft means three separate signal paths to keep in sync, and every deploy is a chance to break one. A consent platform with native Meta integration emits all three from one source, so the banner state and the tag state cannot drift apart. That is the reason to use one, rather than the banner itself.

Manifest vs Latent Disclosure: What SB 942 Actually Makes You Build

Mehwish Malik — Thu, 30 Jul 2026 07:27:31 +0000

California's AI Transparency Act started on 2 August 2026. If your AI tool makes images, video or sound, has over a million users a month, and works in California, you have three things to build. Here is the full duty list.

1. A label people can see

A watermark on images. An overlay on video. A spoken tag on audio.

It has to be easy to notice. Small grey text in the corner will not pass. Build it as a real feature with a toggle, because users must be able to switch it on.

2. A tag people cannot see

A signed note inside the file that says what made it and when. It has to be very hard to strip out. The standard used here is C2PA.

One warning. Re-encoding kills these tags. Convert a PNG to JPEG in your export pipeline and the tag can disappear. Test every export path before you ship.

3. A free public checker

Anyone sends you a file. You say whether your AI made it, and return any origin info you find. Public endpoint, rate limited, no login, no fee.

Text-only output is not covered. Images, video and sound only.

What to build and what not to build

Build the watermarking. It touches your models and your pipeline.

Do not build a law tracker. That means someone reading bills, someone updating config, and someone remembering that AB 853 moved this date by seven months. Forever.

What Seers AI covers instead

150+ privacy laws, updating themselves when a law changes
Cookie and script scanning, blocked until a visitor agrees
Consent records and analytics, which is your proof if anyone asks
Google Consent Mode v2, Microsoft Consent Mode, IAB TCF v2.2, Global Privacy Control
One click install on WordPress, Shopify, Magento and Joomla
28+ languages, support at any hour

Check the Seers AI feature list and count how many of those you were about to build. 50,000+ sites already run it.

Free for 14 days.

How Geo-Targeted Cookie Banners Work (and Why One Global Banner Fails)

Mehwish Malik — Wed, 29 Jul 2026 07:48:39 +0000

If you serve traffic across regions, one cookie banner is a bug, not a feature. GDPR needs opt-in before non-essential cookies fire. CCPA is opt-out. LGPD wants consent per purpose. Hard-code one banner for all three and you either block scripts you did not need to or fire scripts you should have blocked. Both cause problems.

How it works

On page load, the consent script reads the visitor's IP and checks it against a geolocation database to resolve a region. That region maps to a config: which banner to show, which cookie categories to block by default, and which legal basis applies.

An EU visitor keeps non-essential tags blocked until they opt in. A California visitor can load tags with a Do Not Sell or Share control. A low-regulation region can get a light notice.

Worth getting right

Resolve the region before rendering tags, so blocking happens on first paint.
Default to deny for unknown IPs, then relax per region.
Log every consent event with region, banner version and timestamp for your audit trail.
VPN traffic resolves to the server's location. Most teams accept this.

The business payoff

Tags load where the law allows, so your data is fuller in relaxed regions and clean in strict ones. Local banners lift opt-in rates. Fewer scripts in low-regulation regions help Core Web Vitals. And the cost of getting it wrong is steep, with GDPR fines reaching €20 million or 4% of global turnover.

Building and maintaining the geolocation, blocking and logging layer yourself is a lot of upkeep. Seers does all of it: region detection, the right banner per law (GDPR, CCPA, LGPD and US state laws), cookie blocking before consent, and per-region consent logs for your audit trail.

You set the rules once, drop in a single script, and it updates as laws change, with plugins for WordPress, Shopify, Magento and Drupal. You can start with Seers free. If you want the full case first, here are the benefits of geo-targeted cookie banners.

How Geo-Targeted Cookie Banners Work (and Why They Beat One Global Banner)

Mehwish Malik — Wed, 29 Jul 2026 07:26:40 +0000

If you serve traffic across regions, a single cookie banner creates a technical and legal mismatch. GDPR needs opt-in before non-essential cookies fire. CCPA is opt-out. LGPD wants consent per purpose. Hard-coding one banner for all of them means you either block scripts you did not need to, or fire scripts you should have blocked.

How it works

When a page loads, the consent script reads the visitor's IP and checks it against a geolocation database to resolve a country or region. That region maps to a consent configuration: which banner layout to show, which cookie categories to block by default, and which legal basis applies. For an EU visitor, non-essential tags stay blocked until an explicit opt-in event. For a California visitor, tags may load with a Do Not Sell or Share control available. For a low-regulation region, you can serve a minimal notice.

Implementation notes

Resolve the region before rendering tags, so blocking happens on first paint rather than after.
Keep a default deny state for unknown or ambiguous IPs, then relax per region.
Log each consent event with the region, banner version, and timestamp for your audit trail.
Expect VPN traffic to resolve to the server's location, not the user's. Most teams accept this as standard.

Business value

Region-aware blocking means analytics and marketing tags load where the law allows, so your data is fuller in relaxed regions and clean in strict ones. Contextual banners lift consent rates. Fewer scripts in low-regulation regions also help Core Web Vitals.

Rather than maintaining this logic by hand, a consent management platform such as Seers automates location detection, banner display, cookie blocking, and logging across GDPR, CCPA, LGPD and US state laws, so you can ship region-based consent without writing the geolocation layer yourself. For the full rationale, this breakdown of geo-targeted cookie banner benefits walks through the eight main gains.

Why server-side tagging is becoming standard for data teams

Mehwish Malik — Tue, 28 Jul 2026 07:47:37 +0000

Client-side tracking has a growing reliability problem. Tracking scripts run in the visitor's browser, and modern browsers keep restricting that. Apple's Intelligent Tracking Prevention, Chrome's Privacy Sandbox changes, and common ad blockers all interrupt or drop these scripts. When that happens, conversion and engagement events never reach your analytics. Some UK analytics studies report client-side data loss above 30%.

How server-side tagging works

Instead of firing tags directly from the browser, you send a single stream of events to a server-side container that you host, usually a Google Tag Manager server container running on your own subdomain. That container receives the raw event, then decides which platforms should get which data.

Because the request goes to your own domain, it reads as first-party traffic. That is the main reason it survives ad blockers and tracking prevention that target third-party calls.

From there, the server forwards clean events to destinations through server-to-server APIs, such as the Meta Conversions API and Google's server-side endpoints. Both platforms recommend server-side integrations because the event data is more complete.

The business value

More complete data, so attribution models get consistent inputs.
Faster pages, because fewer scripts run in the browser.
Real control over data. You choose which fields leave your server, which supports GDPR and CCPA data-minimisation.
Better paid media signals, which often improves return on ad spend.

This is the change behind why CMOs are moving to server-side tagging. It has shifted from a technical extra to a measurement foundation.

Getting started without the heavy lift

You can build a server container yourself, but consent handling and privacy filtering add complexity. If you want the benefits without the build, Seers AI sets up server-side tagging with consent built in, so your events stay accurate and compliant from day one. You can start free and skip the heavy engineering project. Want to see it first? Watch a quick demo.

How to Build a Cookie Banner That Speaks Every Visitor's Language

Mehwish Malik — Wed, 22 Jul 2026 10:30:14 +0000

A cookie banner is the first thing many users see on your site. If it loads in a language they cannot read, they close it or leave. That hurts your numbers and your consent quality. Here is how to fix it, step by step.

Step 1: Detect the language.
There are two common ways. You can read the browser language setting (navigator.language). Or you can use the visitor's location from their IP address. Some setups use both for a better guess. Once you know the language, load the matching text.

Step 2: Keep a clean set of translations.
Store each language in its own small file or object. Load only the language you need, not all of them at once. This keeps the banner fast and light.

Step 3: Handle legal words with care.
Machine translation is fine for normal text. But legal terms need a human check. A phrase like "legitimate interest" has a set meaning under GDPR Article 6(1)(f). A loose translation can weaken your consent. Get a native speaker to review your main markets.

Step 4: Support right-to-left languages.
Arabic, Hebrew, Persian, and Urdu read from right to left. You must flip the whole layout, not just the words. Move buttons, fix text alignment, and set dir="rtl". A banner that is only translated but not mirrored looks broken.

Step 5: Always keep a fallback.
If you cannot match the visitor's language, fall back to a default like English.

Why bother? The law asks for it. GDPR Article 12(1) says information must be in clear, plain language. In 2021 the Dutch privacy watchdog fined TikTok for showing its privacy notice only in English to Dutch users. A multi-language cookie banner solves both the legal and the user side.

If you would rather not build and maintain this yourself, Seers does the detection and translation for you.

Why You Should Check Your Cookie Duration Regularly

Mehwish Malik — Wed, 22 Jul 2026 06:47:42 +0000

Cookie duration is easy to set and easy to forget. You pick a value once during the build. Then it sits there for years. That gap causes bugs in your data and risks in your consent.

Here is what the setting does. A cookie is a small file in the browser. Its life comes from the Max-Age or Expires value in the code. A session cookie ends when the browser closes. A persistent cookie stays for a set time, from hours to years.

The rules are clear on this. The ePrivacy Directive says most cookies should not last more than 12 months. The EDPB treats a life over 13 months as a problem unless you can justify it. Many bodies also say you should ask for consent again every 6 to 12 months.

Now the technical side. Browsers can override your value. Safari caps first-party cookies at 7 days. Cross-site cookies drop to 24 hours. So a 90-day setting means little for a large part of your users. Third-party scripts add their own cookies too, and some run for two years. If your policy says 90 days but a tag sets 730 days, your own site breaks its own rule.

This is why teams should review cookie duration on a plan. A simple flow works well. Scan every cookie and list its name, source, and life. Match each life to its purpose. Cross-check against your consent records. Fix and write down what you changed.

The business value is real. Old cookies add fake returning visitors and count the wrong sales. France's data body gave over €486M in cookie fines in 2025. Clean settings protect both your numbers and your budget.

Seers AI helps you scan and manage cookie duration across every page, so you stay in line with GDPR and CCPA without manual work.

How to make the Meta Pixel wait for consent before it fires

Mehwish Malik — Wed, 15 Jul 2026 06:48:16 +0000

If you have ever shipped a Meta Pixel, you know it usually fires on page load. That default is the exact behaviour privacy law tells you to avoid.

Under GDPR and the ePrivacy Directive, non-essential tracking has to wait for consent. So the engineering problem is not "add the pixel", it is "make the pixel obey a consent state".

There are two channels to think about. The client-side Meta Pixel runs in the browser. The Conversions API (CAPI) runs server-side.

Teams often protect one and forget the other, which leaves a compliance hole and inconsistent data. A proper setup routes the same consent signal to both, so a visitor's choice is respected whether the event fires from the browser or your server.

The logic is straightforward:

Visitor accepts cookies → consent signal is granted → Pixel and CAPI track in full.
Visitor declines → signal is denied → cookie-based tracking pauses and Meta switches to conversion modelling, estimating outcomes from aggregated, anonymised patterns instead of dropping the event.

The business case for getting this right is measurement. When declined visitors simply vanish, Meta's algorithm optimises on partial data, which raises cost per acquisition and thins out retargeting and lookalike pools.

Modelled conversions keep enough signal flowing to optimise properly while staying inside the rules.

You can build this by hand with the Pixel's consent API and custom tag logic, but the wiring, the load order (your consent banner must initialise before the pixel, or the signal lands too late), the edge cases, and the CAPI parity are where time disappears. A consent platform abstracts it.

With Seers you add the domain, drop one script in the header, and toggle the framework on. No tag manager rules, no changes to your existing pixel code, and the signal reaches both channels automatically.

Full walkthrough here: Meta Consent Mode integration.

EU AI Act for Developers: Which Risk Tier Is Your System In?

Mehwish Malik — Wed, 08 Jul 2026 11:03:52 +0000

If you build or deploy AI systems that touch EU users, the EU AI Act now shapes your technical roadmap. The regulation is in force, several deadlines have passed, and fines scale to 7% of global turnover. Here is what matters for engineering teams.

Four risk tiers decide your workload

Every AI system falls into one of four categories. Prohibited systems, such as emotion recognition at work or social scoring, have been banned since 2 February 2025. High-risk systems, including AI used in hiring, credit scoring and biometric identification, need conformity assessments, technical documentation, logging, and human oversight controls. Limited-risk systems like chatbots carry transparency duties: users must know they are talking to a machine, and AI-generated content needs labels. Minimal-risk systems such as spam filters have no mandatory obligations.

GPAI rules are already live

Since 2 August 2025, providers of general-purpose AI models must document architecture, training data, compute used, and intended use cases. Models trained above 10^25 FLOPs are presumed to carry systemic risk and face adversarial testing, cybersecurity duties, and incident reporting to the European AI Office.

The deadline everyone gets wrong

Many teams still plan around August 2026 for high-risk compliance. That date moved. Under the Digital Omnibus package approved by the European Parliament in June 2026, stand-alone high-risk systems now have until 2 December 2027, because the harmonised standards from CEN-CENELEC were not ready. The full breakdown of the updated EU AI Act timeline explains each phase: https://seers.ai/blogs/https-seers-ai-blogs-eu-ai-act-business-compliance/

Where to start

Inventory every model and system you run, tag each with a risk tier, and get your documentation pipeline in order. Compliance also depends on how your product collects and handles user data. Tools like Seers AI handle the consent management layer, so your team can focus on the model side.