If you’ve ever tried to set up Facebook tracking by hand, then you’ve no doubt encountered an endless litany of red and yellow Facebook errors. Deviate Tracking helps stem the onslaught, but any off-the-shelf solution can only do so much. As the saying goes: patch one error and two more shall take its place.

After reading your tenth cryptic error message, you might be left with the urge to close the Diagnostics tab and never look at it again. We can’t blame you — debugging Facebook tracking can be a nightmare. It’s worth it in the end, though. The time spent fixing errors now will be repaid tenfold in your marketing return on investment. That’s why we’ve collected a list of the top four Facebook errors. Each error has an explanation of what it means, why it’s happening, and instructions on how to fix it.

Potentially Violating Data Sent to Facebook

Potentially violating data has been detected. This data may not comply with Facebook’s terms and policies. To help protect Facebook users’ privacy, this information was blocked and you will not be able to view or use it.

This is one of the most ominous errors to receive. The good news is that Facebook probably won’t take action against your account. It’s not worth it, especially since you’re a paying customer. The bad news is that “potentially violating data” is an arbitrary category. Sometimes Facebook will flag your data for legal reasons (such as compliance with health data regulations). Other times, Facebook’s decisions feel a lot like random whim.

Until this error is fixed, Facebook will ignore the flagged events. Depending on how your tracking is configured, this could be almost all your data. To maximize your marketing ROI, we recommend tackling this error as quickly as possible.

The first step is to identify which pieces of data Facebook is flagging. To do so, open Events Manager and go to the Diagnostics tab. Scroll down to the Potentially Violating Data error and click on the link that says Learn where violations are occurring. This should reveal a list of flagged data sources. You will need to go through them one by one, track down where they are being sent from, and remove them.

One common source of this error is IP tracking. Facebook forbids the use of IP addresses in most regions and business verticals. Deviate Tracking has this feature disabled by default, but you may have turned it on by accident. The switch is at the bottom of the User Parameters section in each Deviate Tracking tag. Unless you are certain that you need IP tracking, we recommend disabling it.

Another frequent cause of the error is the query string. A query string is the part of the URL that comes after the question mark.

Deviate Tracking sends the entire URL (including the query string) to Facebook. This can cause issues if the query string contains violating data. Even if your URLs don’t normally contain violating data, many ad platforms such as Google Ads will add extra parameters. These can contain anything from the user’s IP address to their device type. Depending on the exact parameter name used, your region, and your business vertical, Facebook may flag the resulting URL.

Deviate Tracking currently can’t exclude the query string, but this feature is on our roadmap. As a temporary measure, we recommend removing the violating data from the URL. This may be as simple as editing a link, or it may involve configuring a third-party ad system.

Missing Purchase Currency and Value Parameters

One or more of your Purchase events is missing a value and currency parameter. This may affect your return on ad spend calculation.

The value and currency parameters must be sent with all your Purchase events. This is required by Facebook. You can find both of these inside the Object Properties section of Deviate Tracking.

The value parameter represents the dollar price of the purchased item, and should be in the form X.XX. Do not add the dollar sign (so, $5.22 would be invalid but 5.22 would not be). You do not need to pad the zeroes ($5.00 can be input as either 5.0 or 5).

If you are running a large ecommerce store with hundreds or thousands of products, it may seem daunting to manually provide a price for each of them. We recommend using a GTM variable that uses Javascript to extract the price when the page loads. The coding involved in this is minimal and any competent web developer should be able to manage it without issue.

The currency parameter represents the units that the price is in, such as USD, Euros, or Chinese Yuan. Deviate Tracking defaults to USD, but supports over fifty other currencies.

Event Timestamp Invalid

The timestamp for the PageView events sent from your server is in the future. Timestamps are metadata sent alongside each event you send from your server and they represent the time of day when an event actually occurred. For example: the time that a customer made a purchase on your website. All timestamps should represent a point in time that occurred within the last 7 days.

Events being sent from the future? Spooky.

Time travel is impossible, but misconfigured clocks are not. Deviate Tracking timestamps events based on the user’s system time. If their clock is ahead of the true time, then Deviate Tracking will appear to be sending events from the future. Events can also be sent from the “past”, which results in an Event Delay from Server error:

Your server is sending PageView events more than two hours after the actual PageView has occurred. Events should be sent from your server as close to real time as possible to avoid issues with attribution or ads delivery optimization.

These errors are unfixable but not a significant problem since most users will have accurate clocks. If there are only a few errors, we recommend marking them as Ignored.

If you see a large quantity of errors over a period of several hours, consider submitting a support ticket. There may be an issue with the Deviate Tracking API.

New Domains Sending Data

Your pixel recently started sending events from these domains:

example1.com

example2.com

This is generally not a significant issue but you should review the list of domains and make sure they are all legitimate. If you don’t recognize a domain, ask your dev team. Engineers often install pixels on other sites for testing purposes and it’s easy to forget about them. It’s also common for events sent from third-party embeds to show up as coming from a foreign domain.

If, after asking around, you’re unable to find anyone who can explain the domain, then you might have a security leak on your hands. Anyone who visits your website can, if they know how, steal your pixel information and spoof fake events to it. This rarely happens because there’s no real benefit — the attacker can’t steal your data or gain access to your pixel. It’s digital vandalism: petty, pointless, and wasteful.

Fortunately, Facebook allows you to block domains. We recommend banning malicious attackers as soon as possible to stop their fake data from contaminating your real data.

1. Go to the Settings tab in Events Manager
2. Scroll down to the Traffic Permissions section at the bottom
3. Create either a block list or allow list

A block list rejects all domains that are on it, while an allow list rejects all domains that are not on it. Block lists are easier to set up, but also easy to circumvent (the attacker can lie about their domain). Therefore, we recommend using an allow list. Don’t forget to include any testing domains that your engineering team uses.

Closing Notes

As with the hydra of ancient myth, the important thing when debugging is persistence. If your error wasn’t listed above, submit a ticket and our technical support team will reach out to you. Don’t give up — your marketing budget will thank you in the end.