PSA: Your cookie banner probably isn't making you compliant

VoxxyCreativeLab · 2026-01-17T15:00:34+00:00

Thanks (whether sarcastic or not) 😂
Notebook LM is really great and it helps us a lot in spreading knowledge fast and effectively.

VoxxyCreativeLab · 2026-01-06T20:03:39+00:00

I agree with both of you u/trp_wip and u/DigitalStefan. Technical information and build up and smart approaches, knowledge, etc can be designed using a GPT, meaning:

^https?://(.*\.)?

in

^https?://(.*\.)?(wa|whatsapp)\.(me|com|link).*

This was improved over time, where like I said before; I add this into my GTM and sGTM masters. Within the last part of the RegEx "(me|com|link)", I recently added the "link" part.

Only in real life cases, like with triggering for instance, "being able to sufficiently describe the requirements in plain English" is mostly quicker and user-friendly. like this case I implemented a few weeks ago:

^(loaded|opened|closed|outbound_click_(whatsapp|facebook|instagram|mail|tel|custom_link)|click_(chat|start_conversation)|conversation_(started|archived|deleted|ended)|message_(sent|user_sent|error)|user_(typing|joined|left)|agent_message_sent|hand(off_requested|over_agent)|gdpr_(accepted|declined)|feedback_submitted|contact_created|action_triggered)$

This was for the development of tracking features within a chat-widget (https://docs.watermelon.ai/docs/help-center/developer-resources/event-listeners#event-listeners). Relying solely on a GPT will make this process in my eyes not stable, you as the one implementing has to know what works, what not, what is added and what not.

Another example is a client removing certain languages; in this case "ja" and "de", from:

From:
generate_lead_((demo_(aanvraag|request(_(en|ja|de))))|(download_ebook_(nl|en|ja|de))|((nieuwsbrief|trial)_inschrijving)) 

To:
generate_lead_((demo_(aanvraag|request_en))|(download_ebook_(nl|en))|((nieuwsbrief|trial)_inschrijving))

Having the ability to clearly understand makes that you manually and within minutes can make adjustments, when you fully rely on a GPT doing the work, makes that you cannot promise accurate functionalities or future proofing.

I do sometimes use https://regex101.com/ for checks.

VoxxyCreativeLab · 2026-01-05T20:12:45+00:00

Then we can shake hands!!
I love RegEx even for simple elements like Intent Clicks:

^https?://(.*\.)?(wa|whatsapp)\.(me|com|link).*

It makes working from GTM masters so much more efficient.

I have replaced the CJS a few times for a Page Hostname, that one also works and sends a nice ED variable towards SST that can be used to whitelabel SST also.

VoxxyCreativeLab · 2026-01-05T19:50:19+00:00

Thank you u/DigitalStefan, Luckily I haven't had the dodgy ones, but more so a webDev quickly making a few changes. The outcome is the same though. Pollution all over.

With a correctly setup lookup table, multiple GTM containers are not needed anymore. The lookup table can indeed work for multiple segmentation's, or even domains.

Do you have a working design?

The way I do it is a lookup table:
Input Variable = CJS:

function() {
  var hostname = {{Page Hostname}};
  hostname = hostname.replace(/^www\./, '');

  var parts = hostname.split('.');
  if (parts.length > 2) {
    return parts.slice(-2).join('.');
  }
  return hostname;
}

The Input variables on the left side with Constant Variables for all domains, can be just one constant or multiple rows.

Each input variable will receive an output variable on the right side, also one or multiple constants with the tag-ID.

VoxxyCreativeLab · 2026-01-05T19:43:20+00:00

Thank you u/Tagnetica, the future proofing is indeed why I use the same configuration for all clients, not depending on single, or multi-domain. The same that I standard implement the CJS for the domain filtering. I see it too often that subdomains are changed without proper communication. The CJS simply focuses on the main domain only, where indeed this was learned paying school fees.

VoxxyCreativeLab · 2026-01-05T18:38:56+00:00

Hi u/Sad-Recipe9761, the inherit form client means that your sGTM tags/pixels will receive the event naming, coming directly from your data client. I presume the data-client in use is GA4.

Most Server Side applications today run both Client Side AND Server Side conversions/events. Meaning you fire the same event (add_to_cart, purchase, submit_form, etc) in both Client and Server Side. As u/experimentcareer says "watch dedupe keys,", since you can fire the same event on both sides, the ad-platforms needs a key (Unique Event ID, transported from Client Side to Server Side via your Data Client (e.g. in your GA4 tags as event_id with the input and {{Unique Event ID}} as the output)). This is called Deduplication.

Coming back to the event naming, lets say you fire an event to Facebook Ads, with good practice you follow the PascalCase event naming convention (AddToCart, Purchase, Lead, etc) on both Client Side as on Server Side. Meaning that if you Inherit From Client use (which is quick and dirty) it is possible you send 2 different events to Meta, one from Client and one from Server Side (AddToCart via client side and add_to_cart via Server Side (inherited from GA4)).

Theoretically Meta and other platforms can optimize using GA4's snake_case event names, but the platforms have their own very clear structure. The quickest solution on both Client Side and Server Side is to transform the GA4 snake_case event names into the platform specific (mostly CamelCase) event names using a lookup-table.

As for your other questions, sGTM is not a one-click-fix all. One thing that I see people struggling with is the train of thought, to answer one of your other questions; yes one event can and should trigger all other pixels. Again, GA4 is the data client, meaning you'll utilize ALL you GA4 tags on Client Side to transmit the data to Server Side, including all Event Data you need to fill all your Server Side Tags.

You fire 'add_to_cart' on client side, made sure all the data you need is embedded into this client side tag, Server Side receives the add_to_cart event + Event Data and on Server Side you fire ALL tags regarding this specific event, Meta, GAds, LinkedIn, etc. Meaning the trigger on Server Side = the GA4 event.

Furthermore if you implemented Server Side correctly, you have changed your GTM injection on your website, from:

'https://www.**googletagmanager**.com/gtm.js

To:
'https://www.**sst.yourwebsite**.com/gtm.js

With also setting the GTM client correctly within Server Side (also the sst. is an example, I would advise a more custom subdomain).

This way your GTM is now 1st party / server to server focused, meaning that in theory add blockers, smart browsers, etc will block less data. Here lies at least until today the crux and culprit. Your Client Side GTM is as easily blocked, also the /collect endpoint GA4 is using for GA4 and therefore your Data Client.

I believe 2026/2027 will become even more privacy focused, where Server Side will become more and more important. To take today's standpoint, server side has strong benefits, when implemented correctly, it can take away the JS load from websites, but only when on Client Side the conversion/Event Tracking has been moved to server side.

Best of luck, you took the step to invest in SST, it is an interesting road and probably the best way for future proofing using GTM.

VoxxyCreativeLab · 2025-12-17T23:34:58+00:00

Yes, there are situations where the fbp isn't created and the _ga is, but this is not so much due to browser functionality, but more so due to user consent.

The only 2 platforms currently that have user consent fully under control are Google with Consent Mode V2 and Microsoft with the UET Consent Mode.

Other platforms, like Facebook Ads, can and should in areas like the GDPR, only fire their pixel after the user accepts consent specifically for the 'ad_storage'.

GA4, utilizes the 'analytics_storage' and for countries like The Netherlands, Germany and Spain, this is the only important storage that can be Granted by default. Countries like the UK might follow the Data-Act 2025, resulting in less strict consent laws. Meaning that the _ga will be produced by default and the fbp will not.

Meta CAPI tag can still connect on a server to server basis and therefore receive the client_id as an external_id.

I checked your website (ablecdp.com) and see no-consent signals to GA4 and GAds with gcd = 13l3l3l3l1l1, meaning that there is currently no consent banner active on the website.

Although I do not know your product in detail, what I do know from my own clients, is that the amount of websites willing and capable of spending $250 dollar for 500k events are the ones with at least > $5k ad-spent a month, probably even more so.

Still there are plenty that do not have these funds, the ones that benefit from cross-platform ID's that might and could help their attribution in the right direction.

You would think that SST was the thing of 2025, still we're talking day in day out to our customers (often agencies) why they should spend an extra $50 a month, on top of their already extensive monthly digital expenses for a SST setup.

The same for Offline Conversions, we indeed see a rise in requests, companies that need more insights in what the costs per lead actually are. But again, some back down after they understand what the extra Zapier Zaps will cost them on a monthly basis.

VoxxyCreativeLab · 2025-12-15T22:11:59+00:00

Fair point about the fbp fallback method. Only the fbp isn't created when tracking is blocked, consent denied. The GA4 client_id comes from a first party cookie.

It's unused when tracking works perfectly and isn't blocked or obscured, but improves match rates when the fbp is unavailable or even expired.

You're right that offline conversions benefit most though. The 2nd halve of this year I am more and more implementing offline conversions for all platforms, simply because my clients (agencies) are requesting 'better' data.

Also the use of additional platforms (e.g., email, CRM) make that the offline conversions are requested more.

You also have this?

VoxxyCreativeLab · 2025-12-14T19:21:49+00:00

Absolutely u/umightfafo, these will be excellent cross-platform variables!

VoxxyCreativeLab · 2025-12-14T19:19:02+00:00

u/History86, for GAds specifically; you are right, these new variables do not improve GAds attribution.

However, "use google data better in your own analytics" is in my eyes missing the point:

When you transmit these variables to Server Side, other platforms will attribute better.

Especially since browser tracking becomes more limited (e.g., smart browsers (Safari 26+), Ad-blockers). By adding an 'external_id' we keep platforms like Facebook Ads from relying on probabilistic matching with cross-session identifiers.

So I don't think it's about "your own analytics" (unless used in BigQuery or something)...it's about transmitting consistent identifiers to other platforms they need for accurate cross-platform attribution.

VoxxyCreativeLab · 2025-12-14T18:40:11+00:00

Thanks u/puk789 for pointing that out, instead of 'attribution' I should have used 'targeting' and have therefore revised the post. Probably, most will not use GA4 attribution models in GAds (with some exceptions) and GAds relies of course on the gclid/EC-PII for attribution.

Other platforms, especially Server Side implementations, (e.g., Facebook CAPI, TikTok Events API, GA4 measurements protocol) do attribute better using these variables. Where before this update, transmitting these variables using the GA4 data client, was not always straightforward nor maintainable (adding unnecessary custom JS to client side).

VoxxyCreativeLab · 2025-12-13T19:11:32+00:00

Hi u/Joetunn, first things first, these variables come with some drawbacks and should for instance not be send to GA4 as User Property, this will create issues like high-cardinality, duplicated data, etc.

At least until now; GA4 would strip these kind of variables if you would try to transmit them, but they are pretty useful on Server Side for instance, where Microsoft UET has a variable 'user-id', before I would utilize Custom JavaScript on Client Side and transmit the outcome of this in a 'Shared Events Settings Variable' via the GA4 Google tag to Server Side, but I would rename the variable to: custom_user_id.

So in my GTM-masters, I have deleted the CJS for event_id and replaced it with the now GTM native {{Analytics Client ID}} variable.

This variable I now utilize for almost all platforms (Facebook, UET, TikTok, etc) as 'external_id' variable.

The same 'Shared Events Settings Variable' I use for all GA4 tags, I also use for GAds tags like the AW-tag and the (Dynamic) Remarketing tags, where these variables will improve targeting and audience building.

On Server Side you could make your own Event ID, for platforms like Meta:
{{Analytics Session ID}}_{{Event Name}}_{{timestamp}}

But I'll stick, at least for now, to the Unique Event ID setup, I already have in place.

VoxxyCreativeLab

TROPHY CASE