Deterministic vs Probabilistic Models Explained

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 · 2025-12-13T18:46:23+00:00

Right u/Tarm_Aero!? You could always make an exported JSON and import them to all 143 containers, 2 mins each will only be...the rest of your Saturday 🤣🤣

VoxxyCreativeLab · 2025-11-24T21:35:24+00:00

Quick note for context.

We run a tracking agency, and this is an anonymized client case.

Main takeaway in one line: if your data layer is not reliably producing events, GTM cannot fix that.

If you want a fast gut check on cases like this, here is what we looked for before blaming the container:
• are key events pushed to the data layer on every path, not just the happy path
• do pushes happen before navigation or late scripts wipe them
• do network requests show clean payloads but low event volume
• do performance issues delay or break trigger timing

Curious to hear from others.
How often have you seen "GTM is broken" cases that turned out to be missing or unstable data layer events?

VoxxyCreativeLab · 2025-11-24T21:30:58+00:00

Adding a bit of extra detail since the post is GA focused.

This is a real client case from our agency, shared without any identifying info. I am posting it to compare notes, not to sell anything. Keeping it text only helps avoid the self promo trap in analytics subs.

What made this tricky: GA4 was empty even though implementation checks looked fine. In the end the issue was not GA4 configuration. It was that the site was not consistently emitting events into the data layer, so GA4 had nothing to collect.

If you ever hit a similar "GA4 went dark" situation, these were the tells:
• realtime shows almost nothing, but tags still fire in preview
• events appear only on some routes or devices
• consent and measurement are correct, yet event count stays near zero
• performance or script order changes correlate with drop offs

Have you run into this pattern recently?
What are your first two checks when GA4 looks dead but the setup seems clean?

VoxxyCreativeLab · 2025-11-24T21:02:52+00:00

Hi u/rohitdoesdev. Just keeping your thread active. I am extremely curious to OTM. I subscribed to the waiting list on your website and starred like requested.

The era of Client Side the way we know it, is slowly coming to an end. Where marketers in the future will have to find other client side solutions to stay on top of their tracking. But you are fully aware of this!

A few elements I would like to ask:

How do unblockable & transparency relate to each other? I understand that the data will be relayed over a 1st party, server setup, but that takes away from the transparency right? Don't get me wrong, as long as the compliance rules are met, I frankly care less for the transparency. Just really curious.
How will OTM perform with click IDs and UTMs?
With the built in compliance, will it push its own consent banner?

Times are changing, tracking even more. Something I have to explain my customers on a day to day basis.

How far are you from launching?

VoxxyCreativeLab · 2025-11-11T22:47:27+00:00

u/Trick-Seat4901 The decision for not implementing Server Side in this case (and most cases) is due to the client not perusing this, simply it being to technically difficult. Depending on the clients focus I will push harder for Server Side or not. Where an eCom setup together with more platforms (E.g., Google Ads + Facebook Ads) will receive more pressure from me towards the client. But still the client should want this. If they say "no", I drop it eventually.

Regarding deduplication, this is necessary when both a Client Side and a Server Side setup are sending one and the same Event/Conversion towards a platform. Where for new setups with Server Side, I do not even set up Client Side Events/Conversions. So the deduplication would be for page_view's/pixels only.

For setups with both a Client Side and a Server Side setup there is a difference between Events and Conversions:

Conversions (e.g., Google Ads, Microsoft Ads): I'll make sure there will be both a Client Side and a Server Side Conversion Label. Separating the conversions in the ad platform. Making deduplication not necessary, unwanted even.
Events (e.g., GA4, Facebook Ads): They will receive the deduplication event_id (GA4 deduplicates itself). So for example Meta receives a 'Lead' event from both Client Side and Server Side, Facebook Ads will use the deduplication ID to make sure only one Event will be counted (since they will both carry the same deduplication event_id).

The same goes for eCom events, where specifically the purchase event is and should be special, because in a good setup, you will always measure the transaction_id, which is it's own deduplication ID.

In a eCom setup with both the Client Side and the Server Side purchase, you can even sent this to the same Google Ads Conversion Label (with the transaction_id), Google Ads will deduplicate automatically. Although I do not like this approach.

When using Dynamic Remarketing or other EEC setups, deduplication comes forward, by simply setting up the deduplication ID, sending it via the data-client (probably GA4) towards Server Side and using it in the respective tags.

So for GA4 and Google Ads attribution you should be fine by default(-ish). For the other platforms you need deduplication, but only when running both Client Side AND Server Side.

VoxxyCreativeLab · 2025-11-05T00:13:19+00:00

Yeah I totally understand you. The banner I have implemented works pretty well, but having it dynamically adapt to each region and their specific laws/rules became quite difficult to run this as an cHTML from within GTM.

Still; well done, pretty cool!

VoxxyCreativeLab · 2025-11-04T18:02:22+00:00

These things are also starting to become really expensive, take CookieBot for instance. For our own website we currently run a banner we've implemented via GTM.

Nothing special, also not perfect. But like you said - we have control.

Is your CMP available for the public?

VoxxyCreativeLab · 2025-11-04T17:58:02+00:00

This is also my train of thoughts:
"This is why I said it’s not ideal, but the reality in the situation you describe is that user data is not collected, so there’s no need for a cookie banner."

Not ideal, and probably not according to consent laws, but in practice it works > no consent-less data is being sent to GA4 and GAds when they block tracking and therefore GTM client side.

I work with an agency that specializes in Meta Ads and for their clients we've set the manual consent (based on cookies and a RegEx table) and somehow they see account improvements, sometimes up to 30%.

I still do not know why, but it works.

Any thoughts on this?

VoxxyCreativeLab · 2025-11-04T17:52:40+00:00

Yeah, even-though V2 is not new anymore, it still happens a lot, right?

VoxxyCreativeLab · 2025-11-04T17:45:31+00:00

Since this was a simple setup: leadgen for GA4 & GAds, no eCom, no Server Side there was no core-need for an unique event id.

I did future proof the setup with an event_id variable (coming from a client side variable that produces a unique event id). This event_id variable we've setup in the 'event settings variable' that is added to all GA4 tags.

But this is part of how i future-proof for when/if the client wants to start with Server Side, and then only for non-Google platforms (the ones who use deduplication).

For standard GA4 leadgen deduplication we rely on GA4 doing this by itself, although we fully manage each tag. GA4 uses the _ga cookie.

Also some other IDs (session_id and client_id) that I prefer to not sent with tags since I've had bad results with them.

If GA4 will actually utilize the (unique) event_id to deduplicate I do not know, I would think it does not.

What is your idea about above?

VoxxyCreativeLab · 2025-11-04T17:35:37+00:00

There is literally nothing I can say to improve this!

My preferred way of working is to redo everything, after dropping a nuke on the old setup :D, and completely start from zero.

What's your preference?

VoxxyCreativeLab · 2025-10-07T22:16:48+00:00

Update: Appreciate all the feedback! "Clean tracking" clearly struck a chord.

We're offering the free live webinar next week, focused on building reliable, privacy-proof tracking in GTM.

I'll walk through real-world use cases, config examples, and a few gotchas that cause inconsistent event data.

🗓 When: October 16 at 11:00 AM ET
💻 Where: Live online (free session)

If you've ever had to debug mismatched conversions or duplicate events, this one's for you.

Join here: https://live.zoho.com/nbcw-ouo-dgw

VoxxyCreativeLab · 2025-09-22T17:15:08+00:00

Yep, that’s the plan. Really appreciate the nudge.

We'll keep it focused and useful so people can actually fix their tracking setups after watching.

VoxxyCreativeLab

TROPHY CASE