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:
- Ad Blocker(s): Likely the #1 Culprit in interfering with the Facebook Pixel JS code (firing)
- Google Chrome Developer Tools: The definitive answer/tool as to what is going on in Chrome and how we can verify Pixel fires within this tool
Intro:
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
Ad Blockers
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.
Using Google Chrome Developer Tools to Detect Pixel Events
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).
- Navigate to the “Network Panel”
- Check the “Preserve log” checkbox: (this ensure the logs do not get lost when a page redirects – good for detecting unexpected behaviour)
- Add a “tr/” filter to limit the requests (also ensure that “All” options is selected)
- The requests that are initiated by Facebook, contains the “tr/” URL and are of status “200” (i.e. successfully completed) should be the events that are fired on the page.
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.