Learn best practices on how Stape can boost your server-side tracking setup!
00:00 - Intro
03:25 - GEO headers power-up
08:04 - sGTM Preview header config power-up
10:30 - Custom Loader power-up
16:02 - Cookie Keeper power-up
24:12 - Stape Store
32:51 - Logs
39:26 - Monitoring
42:06 - Stape Analytics
44:52 - Q&A session
By the end of this webinar, you will learn how to:
There’s no set average, but you should be tracking 90% or more of users who accept cookie consent — ideally close to 100%. Your current rates suggest there might be an issue with the implementation. Check that your consent setup is correctly configured and that consent signals are being captured at the right time. The significant difference between Google and Meta tracking likely points to a consent implementation issue.
Yes, absolutely. You must respect your users’ privacy choices at all times, whether you’re using a standard or custom loader, and regardless of whether the tracking is client-side or server-side.
Most likely not. Ad blockers typically block specific network calls with known patterns, but they generally don’t manipulate client ID values. If you’re seeing "not set," it’s likely due to other issues. We’ve written an article about the most common causes of "not set" traffic sources in GA4.
You can retrieve the fbclid value from the cookie and write it using the Stape Store Writer Tag. You can read more about our solution here.
However, you’ll need an identifier to associate the correct fbclid value with the right user, such as an email or user ID.
If you’re considering using Stape User ID for this purpose:
- It depends on when you plan to fetch data from the store.
- If you save the data on a website but need to retrieve it via a webhook, Stape User ID will not work in this scenario.
Ideally, using your own CDN or a same-origin setup is the best approach, as this allows you to proxy all traffic and match your website’s network address. This setup helps bypass Safari’s ITP cookie restrictions effectively.
Stape's CDN, however, offers the benefit of loading the container from a location closer to your users, which is particularly advantageous if your audience is spread across the globe. This can also have a positive impact on page speed.
You can find the detailed instructions in this guide.
Best practice is to use Server Managed cookies. This is one of the key benefits of server-side tracking, as it helps protect cookies from ITP restrictions.
However, if you're tracking GA4 eCommerce SST and notice many "Unassigned" placeholders in GA4 after selecting Server Managed cookies, it likely indicates an issue with your tag setup. Here's a guide to potential causes and fixes.
Our WordPress plugin sets a master cookie, which is a more reliable approach for cookie restoration than the Stape User ID power-Up. There’s no need to use both—simply use the Cookie Keeper based on the master cookie for the best results.
We’ve recently published a plugin for Prestashop! While it’s not yet visible in the Stape admin, you can find it on the Prestashop marketplace. Here's a guide on how to install and use it.
Alternatively, for any other platform, you can generate the loader code in the Stape admin and manually paste it into the section of your website. No additional configurations are required beyond this.
The cookie lifetime depends on the platform's recommendation. For example, Facebook's fbc (fbclid) cookie typically lasts 90 days.
However, with Stape’s setup, you can extend cookie lifetimes up to the maximum possible duration of 400 days, depending on your configuration.
Yes, the custom loader works in the sandbox environment, and you can verify this in your browser's network tab. However, Cookie Keeper will not work due to Shopify's restrictions.
Yes, absolutely! We even have a detailed guide on how to set it up.
While there’s no one-click solution or power-Up for this, it is possible. You can use a variable to read data from Google Sheets and a tag to write that data to the Stape Store. Both tools are available in the sGTM template gallery.
Yes, you can report to BigQuery directly from your sGTM, sending all would-be GA4 data to BigQuery without relying on the GA4 export feature. This approach is highly scalable and can handle high-traffic volumes effectively.
No, enabling logging in the tag does not add to the number of requests.
Yes, the Cookie Keeper will work as long as you correctly configure the master cookie and generate a custom loader with the correct master cookie name. Proper setup is essential for it to function properly.
The main benefit of Gateways is the simplicity—they require little to no configuration or implementation.
With sGTM, you can achieve everything (and more) that Gateways offer, but it requires manual setup and explicit configurations. Gateways, on the other hand, automate much of the process, saving time and effort while providing a more user-friendly solution.
Power-ups like Custom Loader, Cookie Keeper, Stape Store, and File Proxy generate additional requests.
Yes, this is normal. The purpose of the bypass is to mask GA4 requests from external observers. If you’re receiving those events in your server container, everything is working as expected.
Based on your description, this likely stems from issues with consent implementation, particularly during first-touch interactions.
Ad platforms, like Google Ads or Facebook, attribute events using click_id cookies (e.g., gclid, fbclid) or user data, which remain tied to the user even if source/medium data is unavailable.
GA4, on the other hand, relies on UTMs or the referrer from the first touch of the session for channel attribution. If the first-touch data is not being captured correctly - possibly due to how consent is configured - GA4 won't be able to attribute that session accurately.
Our recommendation is to run a thorough debug session to replicate first-touch scenarios, including initial interactions with the consent banner. Ensure that first-touch data (UTMs, referrer) is captured and stored when the user accepts tracking. This should help identify and resolve the issue.
Yes, the GA4 ad-block bypass encodes the payload. However, you don’t need to handle decryption yourself. Events will arrive at the server container in a readable format, ready for processing as usual.
We have an article that covers the most common causes and solutions in detail.
Yes, you can. However, keep in mind that the Stape User ID is persistent only as long as the user doesn’t switch devices, browsers, or networks.
These two serve different purposes and shouldn’t be directly compared. The Cookie Extender tag operates within the same cookie limitations as your other tags.
Cookie Keeper, on the other hand, is not a tag—it executes outside the container and is designed specifically to bypass Safari’s ITP restrictions. If your goal is to extend cookie lifetime on Safari, Cookie Keeper is the better option.
Webhooks are most commonly used for scenarios where online tracking isn’t possible, such as offline conversions, subscription payments, or other server-side actions.
For platforms like Meta, webhooks can still play a role in tracking and attribution. Attribution works effectively when user data (e.g., email, phone number) is included in the payload of the webhook events, allowing platforms to match conversions to the correct users and campaigns.
No, it is not possible. The Stape User ID power up is not consistent across different domains, as it is limited to first-party tracking.
We have an article that covers the most common issues related to (not set) source/medium in GA4. It includes potential causes and solutions to help you troubleshoot further.
No, you won’t be able to set a cookie in the sandbox (Shopify's customer events). For server-side tags to set cookies properly, the client-side GTM needs to run in the parent window, not in Shopify's sandbox.
Our advice is to use Stape's Shopify app, which embeds GTM in a way that creates a functional dataLayer and allows your cookies to be set as expected.
Yes, Cookie Keeper can be used with any ID, including logged-in User IDs, as long as the ID is exposed on the front end through a cookie, local storage, DOM element, or a JavaScript variable.
Yes, absolutely! This is a common and effective approach for managing multiple subdomains.
These serve different purposes and shouldn’t be directly compared. The Cookie Extender operates within the same cookie limitations as other tags in your container.
On the other hand, the Cookie Keeper is not a tag—it works outside the container and is specifically designed to bypass Safari’s ITP restrictions. If your goal is to extend cookie lifetime on Safari, the Cookie Keeper is the better option.
Yes, this approach is fine. As mentioned in the webinar, you just need to understand the nature of the Stape User-ID and the conditions under which it may change. Once you’re aware of its limitations, you can adapt and use it according to your needs.
No, they are standalone products. Using both is redundant, as either solution can independently handle Meta’s server-side tracking requirements.
Yes, it will work the same way as long as the code you’ve pasted is correct and properly configured.
Yes, using custom pixels on Shopify is one of the primary ways to implement a proper dataLayer. In fact, our app relies on the same approach. However, the exact setup may depend on your specific context and requirements.
Yes, this will work. Mapping destinations by hostname is one of the most straightforward and effective approaches for handling multiple domains in a single container.
Stape Global CDN allows the container to be downloaded from a location closer to the user's physical location, improving load times.
'Own CDN' is one method to ensure the server container and website share the same IP range, which can help bypass certain tracking restrictions, such as Safari's ITP.
Happy to hear that! Just click Try for free button and see all the options!
