[Stape webinar] Ask Stape anything: live Q&A about Stape platform and server-side tracking

Whether you’re already using Stape, planning to implement server-side tracking, or just starting to explore how it works, this is your place to get answers straight from our team. 

At Stape, we’ve built an all-in-one server-side tracking platform to help you capture complete data and boost marketing performance.

• Trusted by over 200,000 customers and 500+ agency partners worldwide
• Partnerships with Google, Meta, TikTok, and Snap for seamless integrations
• Active contribution to the web analytics community by creating GTM templates, open-source solutions, and free tools. 

And we love to share our expertise with you! Watch our live AMA-style session to dive deep into everything related to the Stape ecosystem and all things server-side tracking. 

Congratulations to the winners of our exclusive Stape T-shirts for the best questions!

Speaker: Dan Murov, Data Tracking Lead @ Stape

• Marketers, tracking specialists, and agencies exploring server-side tracking
• Current Stape users who want to better utilize platform
• Anyone curious about Stape’s features and how to integrate them efficiently

Why should I invest in a Stape account? What benefits does it bring?

A Stape account is essentially hosting for your tracking tools.

That “tool” can be:

• a server Google Tag Manager container,
• Meta/FB CAPI gateway,
• TikTok Events API gateway,
• Snap / Pinterest / other CAPI gateways, etc.

All of these help you:

• Prolong cookies and improve attribution windows.
• Bypass ad blockers more reliably by moving tracking server-side.
• Centralize and clean up your tracking so it’s easier, faster, cheaper, and more reliable than DIY hosting.

In other words, you’re not just buying “hosting”; you’re investing in infrastructure that makes tracking actually work under modern browser and privacy conditions.

We implemented Stape on our e-commerce site and since then we’ve seen more volatility and negative swings in Google Ads performance. Could our Stape integration be at fault?

Yes, it could.

Any time you change tracking infrastructure, you risk:

• mis-mapped events,
• broken or missing parameters,
• inconsistent event IDs,
• or logic errors in your container.

If performance dropped right after the migration, we would:

1. 1.
   Audit both containers (web + server):
2. 2.
   Use Preview / Debug mode to confirm events fire when you expect them to, with the correct values.
3. 3.
   Check any deduplication logic and event IDs.

If tracking is wrong or incomplete, Google Ads will optimize on bad data – and that absolutely can explain volatility and negative performance swings.

In Shopify, if the Stape app’s data layer is not used, will Cookie Keeper and Custom Loader still work? We found a workaround using the app’s custom pixel, but I’m not sure that’s the right approach.

Yes, Cookie Keeper and Custom Loader will still work, as long as they’re configured correctly.

• For Cookie Keeper, you must reference the correct cookies that Shopify uses (the ones we rely on in our app).
• For Custom Loader, you must embed it correctly in your theme / environment so it actually runs where it should.

Your workaround (using the app code as a custom pixel) is technically viable if it works consistently.

However, if you remove the app from the equation, you lose:

• ongoing maintenance,
• bug fixes,
• and the reliability that comes from us owning that code.

So: yes, it can work; but you’re trading off ease of maintenance and long-term reliability.

I’m sending an event_id to sGTM via the GA4 client, but the event ID on the server is different. I assumed sGTM accepts only 25 characters, trims the ID, and breaks deduplication. What’s really happening?

That assumption about a 25-character limit is wrong.

sGTM does not have a 25-character limit on event_id. If your IDs are getting trimmed or changed, it’s happening in your own implementation, not because of a hard limit in sGTM.

Likely causes:

• Tag sequencing or logic that regenerates event_id,
• A variable that resolves differently server-side than you expect.

Ensure that:

• The same event_id is generated client-side and passed unchanged to the server, and
• You’re not accidentally overwriting it or generating new IDs server-side.
• Tag sequencing is not used for tags that are relaying event_id

Deduplication requires identical IDs; as soon as they differ, dedupe fails.

I’m getting a 400 error from the Facebook Conversion API template in GTM, even though I followed your docs. All parameters seem correct. Any idea what could cause this?

The first thing we’d do is:

1. 1.
   Open GTM Preview / Debug and check the tag’s network request.
2. 2.
   Look at the full response body from Facebook in the debugger.

Facebook’s 400 responses almost always include an error explanation – invalid field, missing parameter, wrong value type, mismatched pixel, etc.

Common culprits:

• Missing or invalid event_name or value/currency

• Incorrect or expired access token or pixel ID

So the answer is: inspect the response body and follow what it tells you; 400s are almost always configuration errors, not platform bugs.

For the Conversion Linker, when used only on the web container, what options should I select? How do these settings affect the setup?

If you don’t know exactly what a particular option does, leave everything at defaults.

• In a standard setup, the default Conversion Linker tag is enough.
• You can override cookie values or pass custom attributes, but we don’t recommend touching those unless you have a very specific use case and know precisely why.

So:

• Default settings → good for almost everyone.
• Advanced options → only if you have a clear, thought-through reason.

Are the Data Client and Data Tag in GTM important? Why?

They’re tools, not magic.

• A Data Tag / Data Client pair gives you a vendor-agnostic data stream that you can forward from web → server.
• It lets you send data in any shape you want and then use the Data Tag to build the HTTP request to your destination (Meta, TIkTok, etc).
• That request pattern is often less likely to be blocked by ad blockers because it’s not a known “tracker” URL.

Are they “important”? They’re important if you use them. You can absolutely run a simpler setup on GA4 & Meta without them, but if you want maximum flexibility and vendor-neutral data stream , they’re very powerful.

Can Stape be a solution for websites in the health category that are prevented from installing pixel events by Meta’s rules or meta tags?

Yes and no.

If Meta classifies your business as a restricted category, that classification and its limitations still apply regardless of Stape:

• It doesn’t matter whether you send events via browser pixel, Conversion API, or Stape –
• You’re still bound by Meta’s policies and legal restrictions.

If Meta literally prevents you from installing pixel events via meta tags / enforcement, Stape will not “bypass” that. We’re not in the business of circumventing platform legal rules.

Why do we need server-side tracking at all?

Three main reasons:

1. 1.
   Signal loss in the browser
2. 2.
   Short-lived cookies in client-only setups
3. 3.
   More data sources

Without server-side, you’re simply leaving data – and performance – on the table.

Does server-side tracking automatically fix “(not set)” and “unknown” issues in GA4?

No, not by itself.

“(not set)” or “unknown” in GA4 is almost always configuration, not “no server-side”:

• Missing parameters,
• Misconfigured tags,
• Consent issues,
• Incorrect routing/sequencing of events.

Server-side tracking gives you more control and better tools to fix the problem, but you still need to configure it correctly.

There’s a lot of material from both Google and us on this; search for “not set” if you’re deep in that problem.

Why is server-side tracking considered more accurate than client-side tracking?

Two main reasons:

1. 1.
   More signal
2. 2.
   Longer-lived identifiers

So you get:

• More events,
• More complete user journeys,
• More consistent identifiers over time.

That naturally makes the resulting data more accurate and useful than purely client-side tracking.

If we implement SST, are there a lot of technical processes involved? How does Stape help with them?

We’ve tried hard to take most of the technical pain away.

The most “technical” bits left for you are:

1. 1.
   Setting up DNS and creating a tracking subdomain (to keep it first-party).
2. 2.
   Connecting your GTM server container to that subdomain.

Most of the rest:

• Container updates,
• Auto-scaling,
• Infrastructure configuration,

…are handled by Stape.

We also provide:

• Setup Assistant for many platforms (especially e-commerce),
• Apps and templates that give you a working skeleton.

So yes, there’s still some technical work, but we’ve removed most of the heavy lifting.

Purchases in my Shopify store vs Meta vs Google Ads look completely different. Will Stape help improve accuracy and campaign optimization?

Indirectly, yes.

Here’s what’s going on:

• Shopify shows all orders (online, offline, drafts, etc.).
• Meta and Google Ads only show purchases that were:

Stape helps by:

• Improving event delivery (fewer losses due to ad blockers / browser limits).
• Sending cleaner, better-attributed events to the platforms.

That means your campaigns receive better, more complete data, and the algorithm can optimize more effectively.

But Stape doesn’t “force” Shopify and Meta to show the same numbers; they measure different things by design.

Is Stape only useful for the EU region?

No – Stape is useful anywhere there is internet.

The EU has extra wrinkles (e.g. data residency) that we support and comply with, but all the core benefits of server-side tracking:

• better attribution,
• more stable data,
• better signal for ML,

…are just as relevant in the US, APAC, LATAM, anywhere.

In my GA setup using GTM server-side, only 40–50% of users are tracked. What are best practices to maximize the percentage tracked?

First, figure out where the loss comes from:

1. 1.
   Consent
2. 2.
   Implementation errors

Best practices:

• Audit both containers thoroughly.
• Make sure consent logic is correctly implemented and that events are still sent for consented users.
• With a proper setup, you can expect ~90%+ of consented users to land in your analytics property.

My site moved to Shopify. Do I still need Stape?

If you still care about high-quality tracking, then yes.

Moving to Shopify doesn’t magically solve tracking:

• Your needs – reliable attribution, server-side delivery, flexibility – don’t disappear.
• Shopify’s native apps are fine for simple setups, but they don’t give you the same control, flexibility, and extensibility.

So if you needed Stape before, you most likely still need it now.

Can I just use Shopify’s native tracking apps instead of Stape?

What if I use a very niche e-commerce platform or business model?

You can rely on Shopify’s native apps, but we generally advise against it if:

• You want control over the exact events and payloads,
• You anticipate future changes (e.g. new events, new platforms),
• You care about having a single, consistent tracking stack.

Native apps often:

• Hide implementation details,
• Limit what you can customize,
• Make it harder to evolve your tracking later.

On the flip side: Stape works fine for niche e-commerce platforms and unusual business models too.

As long as:

• You can inject some code onto the site, and
• You can get hold of the basic data (IDs, value, currency, etc.),

…you can use Stape. Data can even come from outside the website entirely (API / backend), it’s not limited to the front end.

I’m confused about the different Stape products. Which ones do I need? What’s the best solution for my server-side tracking?

A quick way to think about it:

• If you only use one ad platform (e.g. just Facebook), you can sometimes get by with a very minimal setup, such as Gateway products would provide

• As soon as you use more than one (e.g. Meta + Google + TikTok), server-side GTM becomes much more valuable.

We only have a small number of core products (roughly five), and which ones you need depends on:

• How many platforms you send data to,
• Whether you need gateways for specific APIs,
• Whether you want extras like Stape Store, Delay Events, etc.

If in doubt, talk to support or your account manager; we can map product choices to your use case very quickly.

Do you support or recommend anything for DSP (demand-side platform) tracking?

Our exposure to DSPs is limited, but in most cases we've seen you can:

• Use their own native interfaces and pixels plus first-party data,
• Combine them with your server container via postback function they normally provide

We don’t have a special DSP-specific solution today, but many DSP scenarios can be handled with the existing GTM + Stape setup. If you have a specific DSP in mind, I’d recommend opening a ticket so we can look at that particular integration.

Can we also use Stape for a Google Ads CAPI–style setup?

Google doesn’t literally call it “Conversion API” the way Meta does.

They’re rolling out Google Data Manager API capabilities which are effectively Google’s server-side / API-based conversions.

Yes, you can absolutely use that with Stape:

• We already support it.
• We’ve built tools to make it easier than doing everything manually.

So while it’s not called “CAPI” on Google’s side, their server-side offering works fine on top of Stape.

What are best practices for SPA (single-page application) sites with user ID and CMP to avoid too many “new users”?

On an SPA, the browser doesn’t reload between views, so:

• Your “page view” equivalents should be history change events, not literal page loads.
• In GTM, you typically switch to using History Change / custom events instead of traditional Page View for virtual pageviews.

Best practices:

• Treat your SPA as one page load with many virtual page views.
• Make sure your CMP/consent logic is still evaluated correctly on each view.
• The SPA itself shouldn’t inherently create “new users”, so if you see a ton of them, check your identifier logic and consent handling.

Can I send only certain events (like purchase) server-side and leave basic events like add-to-cart on client-side to reduce costs?

Technically yes, strategically “usually no.”

• You can choose which events go where.
• But for GA4, mixing client-side and server-side for the same property tends to break your data, because:

For other platforms:

• It’s technically viable, but you might be hurting your optimization, because platforms like Meta use all events (not just purchases) to train their models.

So while you can route only some events server-side, in many cases you’re better off pushing as much as possible through server-side for consistency and better ML training.

I want to know more about external IDs and cookie values like fbp / fbc. What happens if they’re ignored or not attached to events? What should happen if they are attached?

In most cases, you don’t have to handle them manually.

• Our Meta / TikTok / Snap / Pinterest templates automatically pick up fbp / fbc and other cookie data from the request headers.
• If they’re “ignored” in your own custom mapping but still present in cookies, templates will still attach them.

When they are correctly attached:

• You get better attribution,
• Better matching between web and CAPI events,
• And improved deduplication and performance.

So 99% of the time, just use the templates and let them handle cookies automatically.

Can I send Google Sheets data to sGTM via Stape?

Yes.

You can:

• Use scripts in Google Sheets to call yoursGTM endpoints,
• Push data (e.g., lookups, enrichment tables) into your server-side setup.

As long as you can make an HTTP request from Sheets (Apps Script), you can push that data into Stape / sGTM.

Can I add, update, or delete Google Sheet data inside Stape Store using the Stape API and keep them in sync automatically?

Yes.

We provide an API for Stape Store, the same one our tags and variables use. Using that, you can:

• Add entries,
• Update them,
• Delete them,

from external systems, including Google Sheets scripts.

From a design perspective, I’d still ask: why keep two sources (Sheets + Store) in sync instead of having Stape Store as your single source of truth. But technically, yes, you can sync them; the answer is “yes” to both adding and updating via API.

For our iOS mobile app, when the user does not accept ATT, can we track by using fbclid from the mobile app site and then send CAPI events?

Technically, what you’re describing is doable.

• You can capture a click ID (fbclid) on a web page,
• Store it on your server, and
• Use that ID later when sending Conversion API events.

However, my personal stance is:

• If the user explicitly says “no” (ATT opt-out), the spirit of that is that you should not track them, whether or not it’s “PII” technically.
• We cannot give you legal advice. If your legal team signs off on your approach, the implementation is straightforward and you essentially already outlined it.

So: technically yes, legally - I suggest talking to your DPO.

We’re considering implementing a CDP (e.g. RudderStack) together with Stape. In what order should we implement them? How do they work together?

There’s no strict “right order”.

• A CDP + server container (Stape) combination gives you much broader capabilities than either alone.
• There’s no hard requirement that one must precede the other.

That said, it can be beneficial to:

1. 1.
   Stand up server-side tracking first (so you have a clean pipeline),
2. 2.
   Then connect the CDP to enrich and redistribute that data.

But again, it depends on your architecture; there’s no technical restriction that forces one specific order.

Are there extra cookie settings needed to set up server-side tracking on Shopify?

If you use our Setup Assistant and provided templates, then no extra cookie settings are required.

• The template containers (web + server) already include what’s needed for cookie handling.

Can you clarify “once per page” vs “once per event” in GTM, and when to use each?

Roughly:

• Once per page
• Once per event

In most setups:

• You don’t need to touch these at all.
• Default behavior is fine unless you have a very specific reason to constrain firing.

On SPAs, avoid using “once per page” for view events; instead treat history changes as “page views” and let tags fire accordingly.

A merchant reports huge data inaccuracies using GA4. Stape seems like a good solution to get a better handle on the data. If a merchant is on Magento and installs the plugin, how involved is getting up and running?

If you’re on Magento, the Stape plugin itself is very quick to set up – configuration is just a few clicks.

The important nuance is what the plugin actually does. Its main purpose is to implement:

• the data layer,
• Custom Loader, and
• Cookie Keeper.

You can also use Stape Setup Assistant, because it is one of the platforms we have an app for and everything is supported. 

That gives you a solid technical foundation, but it’s not the full GA4 setup by itself. You will still need to:

• Configure your GA4 tags in Google Tag Manager,
• Map the data layer variables to GA4 parameters, and
• Make sure the events are delivered correctly into your GA4 property.

So: plugin setup is easy, but you still need to do proper GTM + GA4 configuration on top to really fix data accuracy.

I’m just getting started with your product. I’m in healthcare in the US. Can you give me a 10,000-foot overview of what to consider when using your product?

This is a pretty broad question, but there are a few key points I’d highlight.

First, from an infrastructure perspective, our setup is HIPAA-compliant. That’s the baseline.

However, the critical decisions are on your side:

• You must decide what data you send and what you do not send,
• based on your internal policies, your legal counsel, and your interpretation of HIPAA and other regulations.

Because you’re in healthcare, the amount and type of personal / sensitive data you’re allowed to send may be severely restricted. So even though the infrastructure can handle it securely, you still need to be very deliberate about:

• which identifiers you pass,
• what content ends up in events, and
• how you use that data downstream.

In Stape Analytics I see about 13% of our data still affected by tracking prevention, especially 0% recovered from ad blockers. We don’t use the Stape WordPress plugin to inject the GTM snippet; it’s injected by another plugin. If we switch to the Stape plugin, will that help recover that data? Is the Stape plugin what removes the “GTM” label and helps with ad-blocked traffic?

What you need here is the Custom GTM Loader.

You have two options:

1. 1.
   Use the Stape WordPress plugin – this is the easiest, it will insert the custom loader for you in just a couple of clicks.
2. 2.
   Generate the custom loader in Stape admin and insert it manually into your theme’s header (or wherever your GTM snippet lives).

We’d strongly recommend option 1 (via the Stape plugin) because it’s faster and less error-prone.

The key point: You must replace the standard GTM loader snippet on your site with the custom one.

Simply enabling the power-up in the Stape interface is not enough. Until the regular GTM snippet on the page is replaced, ad blockers will still recognize and block it, and you won’t see the recovery you’re expecting.

• Server-side tracking benefits: what it is and why it matters in 2025
• How to set up server-side tracking with Stape
• Latest webinar recording and text version of Q&A
• Stape’s Setup Assistant for Google Tag Manager
• Stape's Website Tracking Checker - free tool