WIWOTW: Troubleshooting Numerous Tag Issues After Site Migration
TL;DR: IP Address solution for Facebook CAPI LDU issues and tag sequencing to solve data layer race conditions.
Welcome to the second installment of What I Worked on this Week! I work at a digital marketing agency and with all of our different clients, I get to work on large variety of different tasks. This week I got to help put out some fires that popped up on a client account after a site migration. This was a particularly challenging task as the changes I made did not result in immediate results. However, it was a great learning opportunity. With that, let’s jump in to what happened.
What Happened?
One of our clients went through a site migration, which required moving all of their current tags in Google Tag Manager (GTM) to another container. Usually site migrations are a great time for a fresh start when it comes to the tags on your website, so it was no surprise the client went with this option.
The only downside is that the container that housed their previous tag implementation was pretty large and housed 200+ tags. Naturally, anytime you have to move that many tags, there are bound to be issues.
The first issue that popped up was a complete drop off of Facebook Conversion API events. After some QA we were able to verify that both the server and browser events had matching ID’s and were successfully being sent in the network calls. Because this was happening on a Thursday and the GTM container had just been published, we decided to give it some time.
Monday morning rolled around and I got a notification that not only were the server events still not coming in, but now there was a whole slew of other issues. Conversions for multiple channels reduced drastically AND enhanced conversions for Google Ads were missing the user data variable on every single conversion.
Upon learning about all of these issues I knew it was time to put on my detective hat and take a deep dive into what was going on.
Solutions
The first thing I needed to do was to make sure that all the tags were firing like they were supposed. This meant having to do a test transaction and buy a product on the client’s website. For this process, I opened up the website in GTM’s preview mode, along with Omnibug in the chrome developer tools, with the network calls being the final source of truth.
After I went through the website’s flow I immediately found something interesting in the data layer. On the thank you page after the transaction I saw that there was a race condition happening with certain events. This means that the purchase event that was firing all of the transaction tags, was actually firing before the container loaded event in GTM.
Issue #1: Event Race Condition
In this case the tags were being passed all of the correct information, but because a majority of the tags were firing before their configuration tags, the conversions weren’t being correctly attributed to the accounts they were supposed to.
The best solution in this case would be for the client to make some changes on their back end so that the purchase event get’s pushed to the data layer after the container loaded event. Unfortunately, changes like that can take some time, which means that I had to do a quick fix to account for the race condition.
The fix was pretty straightforward and just included setting some tag sequencing up for the various channels. I set the configuration tags to fire once per page, and to always fire before the purchase tags. By doing this, I was able to ensure that regardless of what order the events came in, the configuration tags would fire before the purchase.
Issue #2: Facebook Server Events
The next step was to figure out what was going on with our server events. Our company has our own solution when it comes to server events so my first stop was to look at what the logs were saying for our server endpoint.
As I stated previously I was able to verify that they were successfully being sent to our server, which meant something was going on with our endpoint sending the events to Facebook.
After combing through the event logs I was able to see that the our endpoint was receiving a 400 status code from the Facebook servers. The error message pointed to how our LDU options were being sent. It specifically said we needed to either add in a country/state code OR pass a valid IP address.
This was extremely confusing because as I compared the LDU options in the current tag setup to the previous setup there was no difference. However, after digging further I was able to see that the IP address variable was referencing a session storage variable that was never being set. Luckily the account manager had done some QA of their own and verified that the IP address was undefined. We were also able to see that the tag that originally set the IP address was paused.
I was able to unpause the tag that sets the IP address and also adjust the variable that that referenced the session storage value so that it passes a default value.
Results
As I stated at the beginning of the article the results were not immediate. The next day it appeared that none of the changes had an effect on anything. I ended up getting another team member to double check what I was seeing and they were able to confirm that I was not crazy, and that everything looked to be set up correctly.
Luckily the next day is when the results finally started coming in. I got an update that the conversions were back to normal and that the server events were finally starting to come in.
What I learned?
After this project I learned quite a bit about the LDU options for Facebook server events. If you are sending server events to Facebook CAPI, and you are sending LDU options with your events, you either need to pass a country/state code with the options, or pass a valid IP address so that Facebook can geolocate the user. If you don’t, there is a high chance that your events will not be accepted by the Facebook servers.
I also learned to always keep track of the events you are pushing into the data layer. More than once, I have run across a race condition where events are being passed into the data layer before other key events have a chance to fire. This can cause many issues, and is especially hard to see when it doesn’t happen every time.
Conclusion
This task was another great learning opportunity for Facebook CAPI troubleshooting and what to look for when diagnosing other issues that pop up in a site migration.
As always if you have any questions about what I went over in this article feel free to reach out to me on LinkedIn. Also if you have any recommendations on how to handle these issues, or just want to talk about times you have faced similar situations, I am always looking to learn more things.
