Setting up the Facebook conversion API may be confusing. But after you did the tremendous job of moving FB tracking to the server and hope that everything is ok, you might log in to your events manager the next day and see red and yellow warnings for the events sent from the server.
I've faced this problem many times while setting up FB CAPI for clients. So I decided to create an article with some helpful tips. In this blog post, I will describe the most popular Facebook conversion API errors and warnings. Plus, share some tips on how to fix them.
Facebook's Events Testing Tool is a powerful new tool that allows you to debug and resolve issues with your FB pixels or server events. If there are errors, they will be displayed in the Diagnostics tab on the toolbar so you can review them more closely.
Errors marked red usually require a quick reaction and should be fixed right away. The yellow errors are non-critical warnings you should pay attention to and look into eventually.
Facebook allows to mark issues as resolved or ignore them. If you mark an error as resolved and this error repeats, Facebook will show it again in 3 days. In comparison, the ignored problems go to the Ignored section and stay there.
When you fix any issues with your FB tracking, I suggest marking them as resolved. This way, you will notify Facebook that the problems were fixed, and you will hear from the platform if these issues repeat.
You can see all domains that are sending data to your Facebook pixel. If FB notices traffic from a new subdomain or domain, the platform will send you this warning. You can whitelist or blacklist the domains. With the help of this feature, you can block traffic from your testing sites or technical URLs.
Most likely, you will also see the traffic from gtm-msr.appspot.com. It can happen when you run a debugging/publish container or users come to your site with disabled js (some bots).
To create the domain allow or block lists, open the events tool in the Business Manager -> Click settings -> Scroll down to Traffic Permissions.
That is the second most popular Facebook CAPI error from my experience. This error means that you are not sending some deduplication keys for your server events. Facebook uses these deduplication keys: event name, event ID, _fbp and external ID.
From my experience, Event ID parameters are causing this error 80% of the time. Check if you are sending an event ID for Facebook pixel and Facebook conversion API. This event ID should be the same for the browser and server event. In this case, FB will see the same event name and event ID and start deduplication.
For example, for the PageView events, send the same event ID and event name from Facebook pixel and FB CAPI.
To test event ID, open the Facebook event testing tool. If everything is correct, you should see something similar to the screenshot. That is how FB shows it recorded PageView events from both browser and server. These events had the same event ID. So they processed browser events and deduplicated server events.
But there might be another situation where you see browser and server events randomly triggered. In this case, check the FB event ID. Most likely, event IDs are not identical. Speaking of which, you can use our custom variable for the web container to set up Facebook event ID.
Sometimes this error can be caused when you did not remove Facebook test ID and publish FB CAPI tags to the production environment. I recommend setting up Test ID as a lookup table variable that works only when debug mode is true to fix this issue.
Here, Facebook wants to notify you that the values you are sending from the server are not unique or formatted correctly. For example, you can send user IP that includes symbols and not only numbers. Or maybe you’ve simply selected the wrong variable like sending a phone number in the email field.
To check what is wrong, open the preview mode of the Google Tag Manager server and web container (of course, if you used GTM to set up Facebook conversion API). You should see what user parameters were sent to Facebook and if they were formatted correctly. Test the event, click on the tag in the debug mode, and select values.
This error can also mean you might have forgotten to include a parameter or it is incorrectly formatted.
For example, I had a client who wanted to send the user country, city based on the IP address. Facebook expects to see actual user address details they enter on the site and not the ones you automatically extracted from the IP. This setup also sent an error about invalid key parameters.
Or maybe you tried to cheat and send the same username for all events to increase the quality.
This error usually relates to the browser events and means that Facebook detected user data in the URL. Some CMS and other tools like Calendly or PayPal send user details in the URL after they registered or made a purchase.
This error is hard to fix, and that is a task for your developers. They should improve the URL query parameters and remove all the user information from the URL. Alternatively, you can follow instructions from this GitHub post and try to fix the issue inside the GTM. Another way is to switch to server-side Facebook tracking only. This way you can modify the URL before sending it to Facebook.
For each server event that you send to FB, there will be the event match quality score. This score depends on the number of user data you send to FB.
If you use a custom subdomain for your tagging server, only User IP, browser ID, _fbp, and _fbc are sent to FB CAPI. If you send only these user parameters, the match quality will be around 4 out of 10.
How can you increase the event match quality score? The answer is simple: you need to send more user data. But the implementation remains a complex process. Here is how it works: I start by checking if the data layer is implemented on your site and whether it has all user data. For example, if the user can log in to your site, you need to check if user details are sent to the data layer when users are logged in.
If the data layer is not implemented, then assign a task of setting it up to your developers.
After that, make sure that you pass all user parameters from the web to the server container.
Another thing that will help you increase the match quality is a new feature from the Data Tag. We added the ability to store user data. For example, if the user submitted a contact form on the site, you can use the Data tag to store user data in the local storage and then use it on other pages. You can read more about this feature here.
If you are tracking Facebook events from both browser and server, then Facebook requires you to send a unique event ID for every event. For the matching events, Facebook pixel event name should be exact to the server events name. Same for the event ID, the same events from the FB pixel should match FB server events. This is when deduplication happens.
This error happens when you send the same event ID for many events. For example, a user landed on the product page. It means that two events should trigger on this page: PageView and ViewContent. You should send a unique event ID for each of the events. It means that FB events and eventIDs should look like:
FB browser: PageView, eventID: ‘69’ FB server: PageView, eventID: '69'
FB browser: ViewContent, eventID: '79' FB server: ViewContent, eventID: '79'
Even though these events trigger on the same page and might use the same trigger in the Google Tag Manager web and server container, you should send a unique event ID for both of them.
Same Event ID Received for Many Event Instances will occur if you’ll have this situation:
FB browser: PageView, eventID: ‘69’ FB server: PageView, eventID: '69'
FB browser: ViewContent, eventID: '69' FB server: ViewContent, eventID: '69'
In this example, we are sending eventID 69 for both PageView and ViewContent events. But Facebook expects to see a unique eventID for these two events.
Solution: add Facebook test ID, open the preview mode of web and server containers, and test the setup. After you find out when this error happens, we can do more to fix the issue.
We created a custom variable that generates a unique event ID. I suggest using this variable to set up FB event deduplication. You can add an event name to this variable to ensure that the eventID is unique. In this case, even if your events will use the same trigger, the eventID will be unique since it consists of event_name_eventID. You can read more about Facebook event deduplication in this article.
Setting up the Facebook conversion API may seem complicated and, at times, confusing. But it’s worth the time and effort. After you've done all that hard work of moving FB tracking to the server, the quality of tracking and audience will improve.
However, you might face some issues if there are errors within this new integration process. Simply put, you might see red and yellow warnings in the events manager.
The good news is most of these problems aren't as tricky as they might seem and not expensive to fix. I hope this article will help you deal with the most common Facebook conversion API errors and warnings.
By the end of 2024, Chrome and Chrome-based browsers will be done with third-party cookies. Safari and Firefox already implemented Intelligent Tracking Algorithms that can block trackers. That leads to the next point: digital advertising methods that rely on third-party cookies to target consumers might become ineffective or even stop working altogether. This change in how advertisers track users will hurt many publishers and ad networks that rely on these third-party companies to display ads and collect data from site visitors to understand their audience. In this blog post, I will explain what a third-party cookie is, why it matters, and how server-side tracking can help businesses transit to the world without third-party cookies.Aug 16, 2021
Using Facebook conversion API, you can send events from your server to the Facebook server. Server-side tracking with configured custom subdomain helps to bypass ad blockers, ITPs, and iOS 14 restrictions.