Monitoring & Performance of Your Server-Side Tracking

Your Server-Side migration is complete, but you’re unsure which indicators to monitor to ensure that your tracking remains 100% optimal in production?
No setup is future-proof, as modifications to your site or tracking can have negative consequences, such as:

• A drop in data volume (unintentional stoppage of adblocker bypass).
• Partial data being sent to your analytics or media platforms (requests with a success rate < 100%).
• Suboptimal media performance (algorithms poorly fed with user data).

Good news, your Addingwell container contains valuable information that allows you to easily verify:

• That the volume of your tracking requests aligns with your activity (and is therefore consistent with your website traffic).
• That the adblocker bypass is correctly implemented, ensuring you can collect incremental data.
• That your media partners receive all the conversion events configured on your server-side tags (with a 100% success rate for each provider).
• That you are feeding your media providers with high-quality data for their algorithms (user data is correctly transmitted from your GTM Web to your GTM Server).

In this article, discover the key screens of your Addingwell container and the essential indicators to monitor once your Server-Side migration is completed.

Consistent Request Volume & Effective Adblocker Bypass

Through your Dashboard, get a quick and effective overview of:

1. The volume of requests received by your server over the last 28 days. This provides an initial level of information, but you can see more details in the graphs below.
2. The graphs show detailed incoming requests to your server over the last 28 days. You can filter for a longer period (90 days, 365 days, or since your server-side setup began).

• In blue, tagging server requests represent events sent from your GTM Web to your GTM Server. This curve should reflect your website activity, and you can verify whether peaks/spikes in requests align with your traffic.
• In red, additional CDN requests appear if your adblocker bypass is set up and functioning properly. If you don’t see CDN requests, your adblocker bypass is either not working (or has been disabled due to changes on your site), and you simply need to implement the Addingwell alternative snippet.
• In green, additional Database requests appear if you use the Cookie Restore feature to maintain cookies beyond 7 days on Safari.

3. The tracking subdomains configured on your container. (Click on the “Domains” card to see the full list or add a new subdomain). If your subdomain is inactive, an error message will appear. In this case, check your DNS records with your hosting provider.
4. The number and location of deployed tracking servers.

By scrolling down on the Dashboard screen, you can view a map of where your traffic originates from over the last 28 days, helping you decide if adding a server in an additional region is necessary (extra charges apply for an additional zone).

5. The availability rate of your Addingwell servers over recent months. Our commitment is simple: to provide a high-performance infrastructure for your servers. This means we guarantee that 99.95% of the time, your servers are available to receive requests.

Tag Health: Monitor Your Server-Side Tags & Events

Tag Health is your real-time monitoring tool. It allows you to track the proper distribution of your events to various media and analytics partners. No more “black box” effect: you know in real-time what’s happening with every server-side tag. If an issue occurs, you can identify and fix it immediately.

Easily verify with Tag Health that data is being sent properly, with a 100% success rate, for each tag configured on your GTM Server. Click on a tag in the Tag Health tab to view details of each event sent, its success/error rate, and volume.

For example, if you want to verify that data is successfully sent to Meta, you can :

1. Select a specific period using the time filter in the top-right corner.
2. Check that your requests to Meta were sent successfully based on the success rate (in this case, we are close to 100% success, but we will check what is causing errors in some requests).
3. To see detailed events sent via your Meta tag, click on it. You will then access a list of all events sent to Meta.

Here, by hovering over the view_item event, 44 events are marked as “failed” and were therefore not successfully processed by Meta.

When you detect a tag or a specific event that requires correction, you can go further by consulting the associated logs to understand what needs to be fixed on your end.

Logs: Understanding Errors in Server Requests

Logs can be accessed at any time for each of your Server-Side tags, over a time period of your choice. These logs can help identify what needs to be corrected in your setup to prevent failed requests.

Continuing with the previous example of the Meta tag, which was not at 100% success, you can check the available error messages for your Meta tag in the Logs tab on the left of your Addingwell container by clicking on Logs.

A second screen with more details appears, where you can:

1. Filter by the time period that interests you (the period where you know your tags did not reach 100% success).
2. Check the number of failed requests (in this example, 55 errors with status 400).
3. View the most frequently returned error messages for your failed requests. In our example, the value associated with products on the site is invalid because it is not in the correct format (the “value” parameter must be a number, not a text string).

Data Monitoring: User Data Associated with Your Tracking Events

For optimal media campaign performance, you must be able to feed your partners’ algorithms with high-quality data. This means ensuring that user data is attached to the events you send them (for example, for advanced conversion tracking on Google or optimizing Meta’s Quality Match).

With Data Monitoring, you can check the presence of user data in the events sent from your GTM WEB to your GTM SERVER. The user data you can send includes, for example, the user’s email address, phone number, first name, last name, etc., and attach them to your tracking events.

To do this, click on the Data Monitoring tab to see the percentage of events containing each of your user-data parameters. In the example below, the email address is present in 61.4% of events.

Next, identify the list of events containing this user data. By clicking on Email Address (sha256), for example, the details of events containing a user email address will appear:

Don’t worry if the email address does not appear in 100% of your events. It is normal for some events, such as a page_view, to not contain user data (as the user is generally not logged in at this stage). However, a login or purchase event should logically contain the user’s email parameter at 100%.

Cookie Monitoring: Maintaining Cookies for More than 7 Days on Safari

With Safari’s stricter cookie restrictions, you can quickly check whether your current setup effectively bypasses Safari’s ITP limitations.

Our Cookie Monitoring tool allows you to verify that you can track Safari users when they return to your site, ensuring that you maintain cookies on Apple browsers beyond 7 days.

From the Cookie Monitoring tab, three cards allow you to compare traffic from the three environments: Apple, Chrome, and “other browsers” over the last 28 days.

You can check:

1. The number of visitors for each browser type over the last 28 days. In our example, there were 459K visitors from Safari, 211K of whom returned to the site.
2. The distribution of returning visitors (211K in this example):
   • 1 day after their last visit.
   • Between 2 and 7 days after their last visit.
   • Beyond 7 days after their last visit. This last percentage is what you need to monitor for Safari, comparing it with other environments (Chrome and other browsers). If the returning user rate beyond 7 days is roughly equivalent for Safari and other environments, your setup is functioning correctly, and your cookies are persisting properly on Safari.
3. That your configuration is resilient on Safari (indicated by the green symbol) if you have implemented the Cookie Restore solution.

Congratulations! 🎉

Great! You now know how to make the most of your Addingwell container for effective server-side monitoring. Feel free to explore these tools to ensure the longevity and performance of your setup. If you encounter any issues, contact the Addingwell support team.