Facebook Conversion API errors and how to fix it

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. 

How to check if there are any Facebook pixel or Conversion API errors

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. 

What are the most popular Facebook pixel and conversion API errors, and how to fix them?

1. New Domains Sending Data

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. 

2. Event Missing Some Deduplication Parameters

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.  

We also have an article on how to set up Facebook event deduplication. 

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. 

3. Server Sending Invalid Match Key Parameters for PageView Event

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.

4. Potentially Violating Personal Data Sent to Facebook

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.

5. Increase event match Quality

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. 

To have high quality score, it is pretty important to send as many parameters as possible. FB uses these data to match users on your site to the ones in their database. But before doing it, you should check if sending user data to FB complies with the privacy policy rules indicated on your site and other regulations first. But technically, it’s good to send more parameters. It means that the audience and conversion data will be more accurate, Facebook algorithms will have more specific data about your users, and campaigns will perform better. 

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.

6. Same Event ID Received for Many Event Instances

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:

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:

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.  

Conclusion

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.