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.
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
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:
All of these help you:
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:
If performance dropped right after the migration, we would:
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.
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:
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:
Ensure that:
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:
Facebook’s 400 responses almost always include an error explanation – invalid field, missing parameter, wrong value type, mismatched pixel, etc.
Common culprits:
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.
So:
Are the Data Client and Data Tag in GTM important? Why?
They’re tools, not magic.
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:
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:
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”:
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:
So you get:
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:
Most of the rest:
…are handled by Stape.
We also provide:
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:
Stape helps by:
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:
…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:
Best practices:
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:
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:
Native apps often:
On the flip side: Stape works fine for niche e-commerce platforms and unusual business models too.
As long as:
…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:
We only have a small number of core products (roughly five), and which ones you need depends on:
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:
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:
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:
Best practices:
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.”
For other platforms:
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.
When they are correctly attached:
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:
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:
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.
However, my personal stance is:
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”.
That said, it can be beneficial to:
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.
Can you clarify “once per page” vs “once per event” in GTM, and when to use each?
Roughly:
In most setups:
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:
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:
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:
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:
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:
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.
Comments