Setting up server-side tagging can be an uphill battle. Except for configuring a tagging server for your sGTM, there are so many different clients, tags, variables, and triggers that need tweaking to work seamlessly.
In this blog post, I want to talk about server GTM logs and how logs help diagnose problems with server-side tagging.
Logs is an essential tool to use when setting up server-side tagging. It can help you troubleshoot any problems with requests, missing data, or even determine how the vendor processed a request.
Stape offers several types of logs for users to view:
Stape's paid plan users get access to logs for free! We keep them only 3 days before they're purged. Each type of log has its own filter options like date range or client name, which will help ensure specific events don't get lost among others - perfect when you need quick troubleshooting. Downloading those requests onto CVS is also possible.
We'll look at each type of log and see how they might help set up server-side tagging. I'm also going to show some examples of ss tracking problems that logs can help with so that everything makes sense together in no time flat.
To see logs, log in to your stape.io account, open the sGTM container, and go to the Logs tab.
Access Logs - shows requests received by server GTM. It’s possible to filter access logs by date, client name, event name, status code, and request URL.
In the screenshot below, I filtered requests claimed by the UA client. To see a more detailed description of this log, click on the right side of the request.
If you expand request details and scroll down, you’ll see associated requests. For example, when using the UA client to trigger FB CAPI and click on the UA access log, you will see associated request and response logs from FB CAPI. Request and response logs are only available for stape tags when you enable this option in tag settings.
Request Logs - show requests that have been sent by server GTM to the Facebook, TikTok, etc., platforms. This only works if you use Stape tags. To enable this type of log, go to server GTM, open tag, scroll down to Logs Settings, and select Always log to console.
Response Logs - show responses received from 3rd party platforms like Facebook, TikTok, etc., and only work if you use Stape tags.
Response logs are beneficial when troubleshooting ss tagging. For example, you can filter all responses received from Facebook and see if all have 200 response codes, meaning they were processed correctly. When the event was not successfully processed, you can check request details and troubleshoot what caused an error.
Other Logs - logs that we can't categorize as access, request, or response. Use it to see requests sent by the logger tag. Logger tag is available in the server Google Tag Manager template gallery and is extremely helpful to test POST requests in sGTM. I will show how to use the logger tag in this blog post.
There are countless situations when server Google Tag Manager logs can help troubleshoot server-side tagging setup. Here are just four of the many ways that it will help you out.
1. Fewer purchases in the analytics platform than in the CRM.
Let’s say you’ve set up FB CAPI but see fewer purchases in the Facebook events manager than you have in the CRM. To troubleshoot this issue, you can go to logs and filter all Facebook response logs and see if all purchase events were processed successfully (status 200). If you see any request with another response code, open request data and check what caused this issue; for example, check if all necessary parameters were sent.
2. Suspect that Facebook ads manager attribution doesn’t work correctly.
Facebook attributes events to campaigns by checking the fbc (click ID) parameter. If you think that FB attribution doesn’t work correctly, the first thing that you would want to verify is if Facebook CAPI sends fbc and fbp parameters. Just check request details and see the number of purchases with fbc parameters.
3. Event is missing parameter.
You’ve noticed that some purchases in Google Analytics miss purchase value. In this case, the Logger tag can help to troubleshoot this error. I will show how to use the Logger tag later in this blog post. But the main idea is that you set up a tag in sGTM that triggers the purchase event when the purchase value is 0. You can add a custom name to this event and later check it inside the stape logs section.
4. Logging POST requests body.
Server GTM logs have two request types POST and GET. POST request body is not available by default in Google Cloud or Stape logs. If you need to see more details about POST requests, use Logger Tag and enable Log Request Body in the tag settings.
1. Download Logger tag from GitHub -> Open templates sections in the server Google Tag Manager container -> Click New.
2. Click three dots in the top right corner -> Click Import -> Select Logger tag template you’ve recently downloaded from GitHub -> Click save.
3. Create a new tag in sGTM -> Tag type Logger Tag -> Select if you want to log events only while debugging or always -> Select what information you want to add to logs -> add event name. You can use either static or dynamic name -> add custom data if needed -> add a trigger.
4. Launch sGTM debugger and test Logger tag. Once the tag is triggered go to your sGTM Container -> click logs -> other logs -> add event name -> apply filter.
You will see information about requests and can troubleshoot any issues.
Server GTM Logs is a powerful tool when setting up, testing, and debugging server-side tagging. The best thing about stape logs is that it's free for paid plan users. Unlike Google Cloud, where you need to pay an additional charge for logs..
If you use stape's tags, you can also check response logs and clearly understand whether the platform successfully received and processed requests or encouraged some errors.
If you want to test a specific situation, the logger tag for sGTM can be helpful.
All it takes is a few simple questions. Click Get A Quote, fill-up the form, and we will send you a quote.