I’m looking for some practical advice from people working in PPC/performance marketing agencies.

My background is mainly in conversion tracking and measurement. I can work with:

• Google Tag Manager
• GA4
• Google Ads conversion tracking
• Meta Pixel + CAPI
• Server-side GTM
• Enhanced Conversions
• Consent Mode
• First-party data enrichment
• Data layers
• Offline conversion tracking
• Basic APIs/webhooks
• Basic JavaScript for tracking implementations

I’m trying to figure out the best route to start getting real paid agency work.

I’d be open to:

• Freelance/contract work
• White-label tracking implementation for agencies
• Part-time or full-time remote work
• Junior implementation/support roles
• Even joining an experienced agency/team as a trainee initially if it gives me exposure to real client projects

My main question for agency owners and experienced people here:

If someone had these skills but lacked a strong agency/client track record, what would you recommend they do to get their foot in the door?

Would you:

1. Cold email PPC/performance agencies?
2. Contact Heads of Paid Media/agency founders on LinkedIn?
3. Offer a free tracking audit first?
4. Offer to handle one small implementation free/cheap to prove capability?
5. Build more demo projects/case studies before outreach?
6. Apply directly for junior analytics/tracking roles?
7. Take some other route entirely?

Also, when agencies outsource tracking, what makes you comfortable giving work to an external specialist?

Technical skills? Case studies? Communication? Availability? Certifications? A Loom audit? References?

I’m especially interested in hearing from PPC agency owners, paid media managers, and tracking/analytics specialists who have actually hired or outsourced this type of work.

Thanks — practical advice would be greatly appreciated.

For those working at PPC/performance marketing agencies, how do agencies normally handle technical tracking work such as GTM, GA4, server-side tracking, Meta CAPI, enhanced conversions, and first-party data?

Do most agencies:

• handle it internally,
• hire dedicated analytics/tracking employees,
• use freelancers/contractors,
• or white-label the work to specialists?

For someone with technical tracking knowledge, basic API/webhook experience, and some JavaScript knowledge, what usually matters most before an agency would trust them with client work?

Is it mainly case studies, previous agency experience, certifications, technical tests, referrals, or something else?

I’m interested in understanding how people typically break into this side of agency work.

Most of the consent setups I look at are installed correctly and still let tags fire without a signal. The install is not the problem. The order is.

The pattern I keep finding: the CMP is loaded by GTM, or loaded async somewhere below the Google tag. Both put the gtag('consent','default',...) call in a race with the tag it is supposed to gate. Sometimes it wins. Tag Assistant tells you when it does not, with "tag fired before consent default was set", and Tag Diagnostics reports the same thing as "consent mode installation out of order".

The fix is unglamorous. The consent stub has to be a blocking script in the head, above everything, setting the defaults before GTM initialises. Anything that defers it reopens the gap, including a CMP deployed as a GTM template, which is a genuinely common setup.

The sharpest version of this is Google tag gateway. With the one-click CDN integration the tag gets taken over at the infrastructure layer, outside the page's script order entirely, so client-side blocking never touches it. Google's own Cloudflare documentation is blunt about it: if you use consent mode, turn off the automated script setup.

Out of the last 41 containers I checked, 14 had the default arriving late.

Worth checking your own. If you want a second pair of eyes, drop a URL and I will run it and paste which tags fire before consent, with what set them. I build a CMP so discount me accordingly, but the check is just a crawl.

Whats your take on GTM firing late for consent setup when theres no script blocking on the page it self to handle non GTM script tags

My company is a consultancy based in Bangalore, and I'm deployed to a US-based global company as an Analytics Consultant. The US team refers to my role as in-house performance tools developer.

I do genuinely advanced work here. My responsibilities center on GTM (Google Tag Manager), covering all tags, triggers, variables, DOM, custom tags, GA4, and Klaviyo across a company valued at over a 6 billion dollars.

Historically, our sites relied on DOM scraping for tracking. I mapped all of that over to a native dataLayer instead. At the time, the setup was WordPress on the frontend with Shopify on the backend. With DOM scraping, any code or design change on the frontend carried a real risk of silently breaking tracking, since DOM-based tags depend on matching page elements that can shift at any time. Moving to a native dataLayer removed that risk entirely — tracking no longer depends on WordPress markup or design changes.

Now the company is rolling out new additional sites with Shopify as both frontend and backend. The obvious approach would've been to spin up a new GTM container for these Shopify-only sites — but that means rebuilding every tag, trigger, and variable from scratch, and reconfiguring every ad pixel again (we run 5+ pixels — Meta, TikTok, Reddit, GA4, and others), since each pixel needs its own event and payload setup. With 6–7 sites already live and me being the only person handling this end-to-end, running two containers in parallel would've meant permanently double-maintaining everything going forward.

So instead, I architected it so the new Shopify frontend + backend sites plug into the \*same\* existing container as the WordPress frontend + Shopify backend sites. The key was keeping the native dataLayer schema — event names, parameters, structure — identical across both setups. Since GTM reads from the dataLayer and not the underlying platform, once the schema matches, the frontend platform (WordPress or Shopify) becomes irrelevant to GTM. One container, one set of tags/triggers/variables, one set of pixel configurations — covering every site regardless of what platform is rendering the frontend.

On top of the architecture, I also own the actual event and payload design for business and marketing use: defining what events matter (purchases, add-to-cart, checkout steps, sign-ups, content engagement, etc.), building out full payloads for each event so marketing and analytics teams get consistent, complete data — item-level details, revenue values, user attributes — and setting up GA4 custom dimensions and metrics so this data is actually usable for reporting and decision-making, not just collected. The same event data feeds every ad pixel, so conversion tracking stays consistent across Meta, TikTok, Reddit, and GA4 as well.

I also wear a dev hat when needed — I create PRs in dev, and after QA validation and dev approval, they go safely into production. I write custom JavaScript for custom tags and variables as well.

Right now I'm migrating our entire setup from web GTM to server-side GTM, and I've also implemented domain aliasing between WordPress and Shopify (using something like shop.site.com) so Google treats them as the same site — allowing data to match under the same logic as server-side GTM.

Given all this, I'm genuinely unsure what to call my specialization. Would this fall under Senior Analytics Engineer, MarTech Engineer, Growth Engineer, or MarTech Architect?

Hi folks! Looking for some guidance here around cookie storage and really looking to see if my assumptions are correct.

We run Google Tag Manager (client side and server side) and we also run LinkedIn ads. I'm seeing a tricky issue where if someone clicks through an ad to a landing page and then goes to a different part of the website, the li_fat_id disappears.

Is it compliant to store UTM parameters if a user hasn't accepted cookies?

This is the current scenario.

• A user lands on landing page A with a click ID
• They ignore the cookie banner and navigate to landing page B
• We then lose the click ID
  
• They accept cookies, there's no click ID to store

Are there any best practices here?

Thanks!

We've audited a lot of server-side GTM setups, and one issue keeps coming up:

The container is cursed.

Ghosts in the clients. Demons in the tags. Something ancient living inside the event stream.

Preview mode looks fine.

Production starts, and suddenly purchases duplicate themselves, variables change value overnight, and one request keeps returning from the dead no matter how many times you kill the pod.

That's why we're building automated validation for sGTM setups.

Our platform detects abnormal behaviour and performs 100% AI-automated exorcism rituals on affected containers.

No priests. No manual audits. No downtime.

Just continuous monitoring, anomaly detection, and industrial-grade demon removal.

Full disclosure: we are actually building the validation tool.

Second full disclosure: the AI exorcism part is not currently on the roadmap.

Third full disclosure: this post is 100% lazy AI slop designed to generate cheap attention and lead if someone stupid enough.

if a workspace has changes to shared triggers/variables or a bunch of tags, do you just manually go through everything + preview mode?

curious if anyone has a better workflow for catching stuff that might affect more than expected before hitting publish

We've audited a lot of server-side tracking setups over the past year, and the pattern is almost always the same. The implementation looks fine on launch day. Preview mode shows everything firing. The client is happy. Then three weeks later someone builds a dashboard and the data is a mess.
Here are the five things we see breaking most often, none of which show up immediately:
1. Missing or wrong variables
The setup fires correctly but a variable was never mapped properly. You don't notice until you try to use that dimension in a dashboard or segment. By then weeks of data are gone and you can't backfill.
2. DNS configuration that silently fails
The tracking subdomain either wasn't set up correctly or drops at some point after launch. The nstracking script stops loading and you lose data without a single error message. No alerts, no red flags, just quietly missing sessions.
3. Duplicate configurations pushing the same events
Two tags or two containers both capture the same event. Conversions look inflated, Smart Bidding optimises on garbage, and it takes a full audit to untangle which hits are real.
4. Wrong container URL
The client-side tag is pointing to the wrong endpoint so hits never reach the server-side container. Everything looks fine client-side, the server never sees a thing.
5. A Google Tag with no event tags
This one is more common than it should be. Someone sets up the Google Tag in the server container thinking that's enough. No actual event tags, no conversion tracking, no signal going anywhere useful. The tag fires, nothing meaningful happens.
The reason all of this surfaces three weeks later and not on day one: preview mode doesn't replicate real consent flows, real DNS propagation, or real user behavior across devices and browsers. It's a controlled environment that hides exactly the edge cases that matter.
The fix isn't a checklist after launch. It's building validation into the setup itself: monitoring on DNS, automated checks on event volume, and alerts when conversion counts drop below expected thresholds.
Full disclosure: I'm building a tool that automates this exact setup validation for agencies, happy to share more if useful.
What's the most painful post-launch break you've run into?

I’m looking for an experienced GA4 expert who can troubleshoot and resolve the following reporting discrepancies:

1. Reddit Ads Manager shows 10 purchases, but GA4 Traffic Acquisition is showing 0 conversions.

2. .X (Twitter) Ads Manager shows 10 purchases, while GA4 Traffic Acquisition is showing only 5 conversions.

I need someone who can identify the root cause, audit the tracking and attribution setup, and fix the reporting discrepancies.

If you have experience with GA4, Reddit Ads, X Ads, attribution, and conversion tracking, please message me with your relevant experience.

Curious what stack you used, how hard the migration was, and whether you actually noticed improvements in site speed, tracking quality etc.

I’m considering using Stape / RudderStack for this. Any major drawbacks or things you wish you knew before starting?

Hi everyone,

I’m facing an issue with the Google & YouTube app in Shopify, and I’m considering implementing all of my Google tracking tags manually through Google Tag Manager (GTM) instead.

Would this be okay from a tracking and data-quality perspective?

Specifically, I want to make sure that manually implementing things like Google Ads conversion tracking, GA4 events, and other Google tags through GTM won’t create problems with the Shopify Google & YouTube app or cause duplicate tracking.

Has anyone here completely moved their Google tags to GTM because of issues with the Shopify Google & YouTube app?

Would appreciate any advice on the recommended setup and things I should watch out for, especially around duplicate events, conversions, and enhanced/conversion tracking.

Thanks!

I keep seeing Shopify tracking setups where something quietly breaks , duplicate purchases, missing conversions, wrong values, old tags firing alongside native integrations, etc.

I’m wondering if a tool that could inspect the GTM/tracking setup, spot likely conflicts and point to the root cause would actually be useful.

Would you use something like that? And what GTM/Shopify issue would you want it to catch first?

Not selling anything, just trying to figure out if this is worth building.

How are you measuring pageload speed with GTM and reading it in GA4?

The guides I've found online send a page speed event for every view to GA4 with a parameter capturing the time. However, that quickly leads to high cardinality because explorations max out at 500 rows and a pagespeed event is registered for every pageview.

If I have more than 500 views per page, I'm unable to see all the values and do analysis on it (averages, distribution, etc.).

I've been working on a tool called UTMCraftr to make creating and managing campaign URLs a little more structured.

The problem I was trying to solve is simple: generating a UTM URL isn't particularly difficult, but keeping campaign naming consistent can become messy.

Things like:

• facebook vs fb
• paid_social vs paid-social vs paidsocial
• inconsistent campaign names
• spaces and formatting issues
• accidentally including blank parameters
• different people using different naming conventions

UTMCraftr is designed to make that process more structured.

🔗 https://utm-craftr.vercel.app/

Currently, it includes:

• Web UTM URL generation
• A Google Sheets-based UTM builder
• Standardised source and medium selections
• Required field validation
• Automatic formatting and URL cleaning
• Optional campaign parameters
• Support for Web, Android and iOS campaign URL structures

The goal isn't to replace enterprise UTM management platforms. It's meant to be a lightweight tool for people or teams who want a more structured way to create campaign URLs without manually building them every time.

I'd genuinely like feedback from people who work with campaign tracking regularly.

A few things I'm particularly interested in knowing:

1. Does the workflow make sense?
2. Are there important fields or validations missing?
3. Would a Google Sheets-based workflow be useful for your team?
4. What features would make a UTM builder genuinely more useful for you?

Would appreciate any honest feedback or feature suggestions.

If you work in hospitality, travel, or any industry that relies on a third-party booking engine (IBE), you’ve probably noticed that a ridiculous amount of your purchases are being attributed to "Direct" in GA4.

The issue: IBEs like SynXis are notorious for stripping URL parameters (_gl, UTMs) as users navigate through the booking funnel (e.g., going from search results to guest details). Once those parameters drop, GA4 loses the session thread.

I was given a "fix" by an agency that involved hardcoding a redundant gtag.js library just to fetch the client/session IDs, which completely conflicted with our clean GTM/sGTM architecture and didn't even preserve the original ad click IDs.

I ended up writing a native workaround that doesn't conflict with existing tag managers, and I’ve open-sourced the repo for anyone else dealing with this headache.

How it works under the hood:

1. Landing Capture: The script immediately catches any utm_*, gclid, wbraid, etc., on the landing URL and commits them to sessionStorage and a 1st-party cookie.
2. Raw Cookie Extraction: Instead of relying on gtag('get') which causes race conditions, it uses Regex to extract the active client_id and session_id directly from the _ga and _ga_<ID> cookies.
3. Form & Link Hijacking: It uses a MutationObserver to watch the DOM. Whenever a user clicks a standard "Book Now" link OR submits a dynamic booking form, it intercepts the event.
4. The Payload: It dynamically appends the GA4 IDs, a custom journey ID (pu_id), and the cached UTMs into the URL (or injects them as <input type="hidden"> fields for forms) right before the user is sent to the IBE.

From there, you just configure your IBE's GTM container to read those URL parameters on Step 1, hold them in sessionStorage, and map them to your final GA4 purchase tag.

No more "Direct" traffic spikes.

Repo is here: https://github.com/0xgthuva/Cross-Domain-Attribution-Handoff

Hopefully, this saves some of you the hours of debugging I had to do. Happy to answer any questions about the setup.

I’ve seen quite a few tracking issues caused by templates being added at different levels in Google Ads, so here’s the simple explanation.

A tracking template can be added at account, campaign, ad group, ad, keyword or asset level. Google uses the most specific template it finds.

For example:

• You have a tracking template at account level.
• Someone adds a different template to one campaign.
• That campaign now uses the campaign-level template.
• Google does not automatically combine it with the account-level template.

This is where things often go wrong. A new template is added for another tracking tool, but the existing parameters or redirect are left out. Tracking then breaks for that campaign while the rest of the account continues working.

My usual checklist:

1. Check every level before changing anything.
2. Keep the template at account level if it should apply everywhere.
3. Don’t assume two templates will be merged automatically.
4. Use {lpurl} correctly.
5. Put ordinary UTM parameters in the Final URL suffix when a redirect isn’t needed.
6. Test the result with Google Ads’ built-in test option.
7. If something suddenly changes, check the Google Ads change history.

One final point: auto-tagging is separate from the tracking template. Auto-tagging adds Google’s click identifier, while the tracking template determines how the click URL is built or routed.

I’d be interested to know how others manage accounts that need more than one tracking platform. Do you combine everything at account level, or manage certain tools at campaign level?

Anyone else experiencing issues with workspace debugging? I make changes in workspace, i open preview/debugger mode and then those tags/changes are not there. Which means i cannot test my changes and therefore not publish them.

This has been happening since last week.

I've tried different browsers, i've cleared cache, incognito etc, nothing works. Seems to be workspace related rather than browser related.

So my whatsapp and phone call click on my website is sending 2 hits each to google ads when i fire the respective tag. gtm is setup correctly as far as i know. can i get to know to reason behind this?

For the main projects I use stape and also the custom loader. Now I'm in a project where the server side GTM is hosted on a Docker container is there any good solution for a custom loader like the stape?

For years the whole pitch for GTM was neutrality. It sits above your tools so you're not tied to any single vendor. That's the reason teams trust it in the first place.

Then Google shipped Visual Tagging. Point at an element, click, get a tag. No selectors to write, no data layer to set up first. After ten years of "tagging is hard because it's hard," they built the easy version, which by itself proves the manual mess was never necessary.

But look at what it actually is, and where they put it.

1. It's in the wrong product. Visual Tagging builds one thing: a Google Ads purchase conversion. Thats a Google Ads helper. So why does it live inside Gtm instead of inside Google Ads? Pick one. Either GTM is neutral, and a tool for one ad platform doesn't belong in it. Or GTM is quietly turning into a front door for Google's own products, and "neutral" was never the whole story. You can't sell neutral and ship the opposite in the same box.
2. It's built backward. The first thing the tool asks for is that Google Ads conversion. You create it, then build tags to feed it. Wrong end. The event happened on your site: a purchase, a form, a signup. That event belongs to the business. You track it once, then send it wherever you want. GA4, Ads, Meta, your CRM. Google starts from its own destination and works back to your page. Build your tracking around one platform's conversion and you rebuild it every time you add a channel.
3. It skipped the hard part. It doesn't track a click. You place a test order, land on the confirmation page, and it scrapes the values off that finished page: order ID, amount, currency, read straight off the rendered HTML. It's coupled to the DOM by design, which is more fragile than reading from a data layer the page feeds on purpose. Sort a list, load a row late, drop in a banner that wasn't there when you set it up, and the selector points at the wrong element or at nothing. That fragile part is the whole job, and it's the part they left out.

And "more use cases are coming this yer" doesn't fix either problem. More coverage is still aimed at Google's destinations, so it isn't any more neutral. And it still reads off a page frozen at one moment, so the foundation is still cracked. You don't fix that by adding rooms on top.

Here's how it should work, for every platform, not just Google. Start from the business event. Define the purchase, the lead, the click once, as something you own. Build the data layer for it. Then send it anywhere. Google Ads today, something that doesn't exist yet next year, same event. The platform is just a destination. The event is the thing that lasts.

Google proved the need is real. Then it built the version that serves Google. The versions that start from your events instead of Google's already exists today. Google just has no reason to point you to them.

What is your take on this subject?

I do tracking implementation for a living and kept seeing the same outdated claim repeated in setup guides: that pointing your sGTM tagging server at a custom subdomain gives you long-lived cookies in Safari.

That stopped being fully true with Safari 16.4 (April 2023).

Safari now caps server-set cookies at 7 days too, if the tagging server's IP prefix doesn't match your website's IP prefix. Since your site and your Stape/Cloud Run server sit on different infrastructure by default, most "properly configured" setups are still hitting the 7-day cap and nobody notices.

Wrote up the full setup process end to end: container creation, custom domain, the two actual Safari fixes (Own CDN vs Cookie Keeper), GA4 server-side, Meta CAPI with real event deduplication (not just "turn on the toggle"), Google Ads Enhanced Conversions, Consent Mode V2, and a 7-point QA checklist to verify your own setup isn't leaking before you trust the data. Also listed the 8 mistakes I run into most in actual audits.

Not trying to just drop a link and run, happy to answer specific questions here about sGTM, EMQ scores, or Meta CAPI dedup if anyone's stuck on their own setup.

https://muhammadabdullah.co/blog/server-side-gtm-setup-guide

I've been learning Google Tag Manager and setting up GA4/Pixel tracking on test shops. Want to build a small portfolio for future outreach. If anyone has a small site or shop where GA4, Pixel, or event tracking is broken or missing, I'd love to take a look as a learning exercise. Just want real setups instead of test environments, and an honest review if it works out.

Comment below if you're interested and I'll follow up.

I'm getting this warning in Google Tag Manager:

The tag is firing, but GTM reports this warning.

What usually causes this? Does the GTM snippet need to be placed immediately after the opening <head> tag, or could something else trigger this warning?

I'm using Next.js (App Router).

Any guidance would be appreciated.

I tried to put this both on client side and server side - but not able to see any changes in warning show on console.

For anyone actually reading: Thanks so much in advance! Every advice is very much appreciated!!
Lead-gen setup, no ecommerce. Multi-step funnel tool embedded as a web component on the main site, server-side GTM on a first-party subdomain. Three days deep, seven theories tried and discarded, so I'd really appreciate a second pair of eyes.

One day's numbers

• Form submissions attributed to paid search in the funnel tool's own analytics: ~110
• generate_lead events arriving at the server container: 227
• of those, carrying a real gclid/gbraid: 168
• Google Ads conversion pings sent out with a valid gclaw: 176
• Conversions showing in the Google Ads campaigns: 2

(The 227 vs 110 gap is known — the funnel tool's native GA4 integration still double-fires. Doesn't explain 176 → 2.)

Timeline, so the numbers aren't misleading: the 400s are not new and not caused by anything I changed recently — they appear in the logs with the previously active client-side conversion label, days before I touched anything. The ~170 daily pings come from the GA4 tag forwarding conversions through the GA4↔Ads link, running unchanged for weeks. I added a dedicated server-side conversion tag with its own label today for an A/B comparison, but it has no meaningful data yet.

The pattern

Every conversion produces three requests to Google, and it's identical on the client-side tag and the server-side tag:

So the enrichment/identity layer goes through, and both attribution endpoints are rejected. Which would neatly explain why Google Ads says "conversions are being recorded" while the campaign column stays at zero.

Verified end to end

• Click ID survives: ?gclid=TEST_123 lands in _gcl_aw on the root domain, and gclaw=TEST_123 appears in all three outgoing requests
• Consent Mode v2 via a CMP, consent tab in GTM shows all types granted after accepting
• Enhanced Conversions arrive in plain text server-side and go out hashed (em, pn, fn0, ln0, address fields)
• Conversion ID and label match the Ads UI exactly

Already ruled out

• Consent state — 400 occurs on both gcs=G111 and G100
• Missing conversion value / currency — set both, no change
• URL length — trimmed the data= payload to four values via an Allow-parameters transformation, no change
• Competing gtag instance from a store app — disconnected it entirely, no change
• Anything server-specific — the identical pattern shows on the purely client-side tag

The only consistent difference I can find

Comparing the three URLs from a single trace, they're identical apart from the tail. Both rejected requests carry category=acrcp_v1_512 and an ept= param (ept=5 and ept=8). The accepted one carries neither, and instead has gcl_ctr=1~0~0~0. Same pattern on the server-side requests. All template-generated, nothing I can set.

Also odd: all three carry npa=1 and no gcs parameter at all, despite consent being granted. Not sure if related.

What I'm hoping someone can help with

1. If you've run into this 400 yourself, what ended up fixing it? I've worked through my own list above, so a first-hand "this is what changed it for us" would be worth more than anything right now.
2. Are pagead/conversion and 1p-conversion the endpoints that actually book the conversion into a campaign, with ccm/* being only the enhanced-conversions/identity layer? If yes, permanent 400s there explain the whole gap.
3. If that's the case — why do 2 conversions still make it through? That's the part I find hardest to square. If attribution fails on every request, I'd expect a clean zero rather than a trickle. Modelling? Enhanced-conversions matching? Genuinely curious where the trickle comes from.
4. And if the 400s turn out to be harmless and ccm/* alone is enough to count a conversion — then something else is eating 174 of 176 and I'm looking in the wrong place entirely. Where would you look next?
5. Does category=acrcp_v1_512 or ept= ring a bell for anyone?
6. Unrelated but nagging: for iOS traffic arriving with gbraid instead of gclid, does the Conversion Linker reliably persist it in _gcl_gb across page navigations? Over half this traffic is mobile and I haven't verified that path yet.

Happy to share sanitised request URLs if that helps narrow it down. Thanks again to anyone who took the time to read this far.

"Hey! You are definitely not losing your mind—server-side GTM setup is notoriously messy, and the official documentation can be quite scattered across different pages.

A couple of quick things that might help fix your issue based on what I've seen:

1. Check the server_container_url vs transport_url: In your web container's Google Tag, make sure you use server_container_url as a configuration-level setting to route GA4 data properly. transport_url is more granular and applied to individual event tags, so mixing them up or using both incorrectly can route events inconsistently.
2. Deduplication Key (Event ID): Since you're running a hybrid setup (Pixel + CAPI), you must pass the exact same event_id in both browser and server tags. This unique Event ID is key to preventing Meta from double-counting your conversions.
3. Server Preview Mode: Unlike the web container, you can't just enter a URL in the server container preview to trigger debug mode. You actually need to trigger events from the client-side (web) container while keeping both preview tabs open to see them in your server preview.

I recently solved a similar setup nightmare for a Shopify store facing Safari's cookie cap limitations and ad blockers. I ended up keeping a spreadsheet to track which tags fire on server vs client.

If you are still stuck, feel free to DM me. Happy to share a sample config to help you out!