After extensive experience using the Facebook Pixel Helper Chrome extension, it seems to rarely fail, but at times for various reasons, it may not detect events as expected in extreme edge-cases. Most of the time, the anomalies had to do with the browser or the environment running the Chrome extension.
For example, I had a ton of Chrome Tabs open in the browser and when I would debug a client’s site it simply wouldn’t fire as expected (i.e. produce no results or results that I knew were not sensible given the situation). After closing the browser and opening it again, it worked as expected.
The intention of this article is not to give IT Crowd advice (“have you turned it off an on again”), but to describe one of the most common scenarios and a sure-fire solution to completely isolate any sort of uncertainty.
Topics this will cover:
The most user-friendly way to check if your Facebook events are firing is to use the Facebook Pixel Helper Chrome extension; however, ensure the following ideas/steps are verified when checking your Facebook Events.
Auxiliary Reference: Pixel Helper Docs
The most common reason why the Facebook Pixel events were not firing (besides incorrect implementation) on clients’ site was because the person checking the events had an Ad Blocker extension running in their browser that was blocking the Facebook Pixel’s JS execution.
The box below should indicate whether you have an Ad Blocker running (refresh this page to update the results):
To resolve this, we need to turn the ad blocker software off or use a browser/computer that does not have this type of extension running.
If we are ever unsure of the Pixel Helper* or just want to see which events are firing in its raw format. Use the Chrome Developer Tools (press F12 on Windows and Command+Option+I on OSX).
Inspecting the above requests (and any sequence of requests before it – redirects, page navigation changes) should give a definitive view of what events are being fired/sent to Facebook.
Don’t forget to inspect the URL requested and the status within the “Headers” sub-panel:
Parsed Querystring (GET) parameters within the “Headers” sub-panel:
Pro Tip: Sometimes the Pixel fires events via the POST method. This happens when the payload (e.g. metadata/length of Query String parameters) exceeds 2048 characters in length in total. Whether the Pixel uses a POST or GET does not affect what shows up in the Pixel Helper results; however, how it appears in Chrome DevTools differs from what we expect in a GET request and we need to account for this accordingly. We just need to be aware that this can happen when debugging your events.
* There was an instance where the Pixel Helper was not recording the events on the front-end but we were able to see it propagating in Facebook’s back end. Surely enough though, when doing a screenshare with the client we were able to see it in Chrome Developer Tools (?). We did not debug this issue deeper, but we suspect it had to do with the complexity of the client’s implementation. All was OK in the very end.
As a caveat this is an **unofficial** way of achieving this as of this article's…
There are many benefits to verify your Business Manager on Facebook; however, it is not…
One issue when adding the Facebook pixel to a Google Tag Manager AMP container is…
When trying to run Puppeteer 1.0 within your Node.JS scripts on an Ubuntu 16.04 box and…
Off the back of this article, there could be some potential improvements to make the…
Before implementing the img tag, the previous article should be reviewed: it discusses some of…