Logs feature

The Logs feature provides real-time and historical records of the data flowing in and out of your server-side Google Tag Manager (sGTM) container. Logs make it straightforward to monitor and troubleshoot your server-side tracking setup so that any issues with your network or vendor don’t go unnoticed.

The Logs feature is available for Pro, Business, and Enterprise server-side GTM subscription users:

• Pro / Pro+ - last 3 days’ logs.
• Business / Business+ - last 10 days’ logs.
• Enterprise / Enterprise+ - last 10 days’ logs.

Optionally, you may also want to check out Stape’s Logger tag. This tag allows you to log the incoming request event data, request details, and custom information to stape.io, GCP, BigQuery, or other cloud platform logs.

How to use Logs

1. Log in to your stape.io account.

2. Select your sGTM container on the dashboard.

3. Open the Logs tab.

4. Configure your Logs request:

Type of requests:

• Incoming requests - these logs display the requests that your GTM server has received. Please note that they don’t contain cookies or personally identifiable information (PII).

• Outgoing requests - the requests that have been sent by the server GTM to Facebook, TikTok, and other platforms. They are only displayed if you enabled the toggle in the Outgoing requests tab. Since Outgoing requests may contain sensitive data, we need your consent to store the logs securely for a specific period of time (Pro plan users - 3 days, Business/Enterprise - 10 days).

• Date and time - select the time period for which you want to receive the logs.

• Request parameters - these allow you to filter your logs to find the ones you’re interested in. Different types of Logs offer different parameters, such as Status (the logs’ request code), Client (the logs’ origin), or Platform (that sent or received the logs).

After that, click Show logs. 

5. You will see the list of all logs that fit your request. You can download the data by clicking Download as CSV or clicking on any log record to expand to the Detailed view.

Testing the Logs feature

To verify that the Logs feature is working properly, perform actions on your website that are supposed to trigger your configured events and then check whether these events appear on the Logs dashboard.

Use cases of debugging with Logs

Incoming requests

Let’s use a common example like the Purchase event for GA4. You can compare several key numbers:

• Total number of Purchase events recorded in your backend.
• Number of Incoming requests received by the server container.
• Number of Purchase events recorded in your analytics platform.

By comparing these values, you can draw useful conclusions. For example, you can determine whether event over-reporting or under-reporting is happening. Next, you can review parameters related to the consent banner (whether consent was granted) and compare the transaction_id parameter in Incoming requests with the same parameter in your analytics platform.

From this data, you can identify patterns. For instance, you received 30 Incoming requests for Purchase events, but your analytics platform shows only 26 Purchase events for the same period. In this case, you can:

1. Find the 4 events in Incoming requests that are missing in analytics.
2. Check the gcs parameter, which indicates the consent banner status (accepted, rejected, or undefined).
3. If those 4 events contain a value like g100, it usually means that the user rejected the consent banner, which prevented the event from being registered in analytics.

Outgoing requests

The Outgoing requests logs allow you to see your server container’s interaction with external platforms, for example:

• You can view the full payload of the event being sent to Facebook or another platform and check that the event payload structure is correct.
• If the platform returned an error response, you can examine it here to figure out the problem (such as missing permissions, invalid parameters, or authentication issues).