When should I use the Facebook img tag over the Facebook Pixel JS Code to fire my Facebook Events?

An img tag (html tag) can be used to fire Facebook Pixel events on your site. This is a not a well-known feature and for a good reason, as it is really only appropriate to implement in very specific situations. We will go over some of the scenarios where this approach may be applicable in this article:


Preamble:

Though the above may outline some rare cases where the img tag may be a candidate approach, my general recommendation is to avoid this if possible. I would only recommend using img tags if you are absolutely sure you know what the advantages, drawbacks and repercussions are.

Some general drawbacks are that the img tag is:

  • more onerous to maintain (e.g. the complexity is higher to maintain all the parameters and proper encoding in the img tag as opposed to more simple JS calls)
  • prone to human error (e.g. when creating the codes the format is more difficult to comprehend and easy to go wrong)
  • you are willing to eschew any new functionality that Facebook may implement via the JavaScript code: this is not an idle warning, as I believe in the near future, new functionality will take advantage of the power of JavaScript to execute tasks that the img tag will simply not be able to do and your marketing signals may suffer as a result.

OK, fair enough, beyond that…


From a practical standpoint, what do I lose/gain from using the img tag?

As of the date of this article’s publication, there is not a whole lot that is functionally different – though this can obviously change in an instant as Facebook is constantly rolling out new features in the pixel. Nevertheless, there is nothing really significant at the moment that the img tag prevents you from executing your marketing on the platform.

There are minor differences though how the Event would pass in the referrer URL(the URL that it thinks the pixel is fired from)- I have not tested this out thoroughly in all scenarios though (troubles can be circumvented by using/creating Custom Conversions based on Events as opposed to URLs)- and also helper functions to hash your Advanced Matching would also be lost. This does not prevent you from using the Advanced Matching feature: you just need to hash the data manually (pre-hash it on your website on the server/client-side) before passing it into the img tag.


Some potential scenarios where the img tag may be appropriate:

No 3rd Party JavaScript is allowed for Security Reasons

The img tag may be a viable approach if your organization has stringent security protocols (e.g. a Bank or other privacy-sensitive organizations) for:

  1. Avoiding any loading of 3rd-party hosted JS to avoid compromises/security breaches/infection of its customers when used on the organization’s public site. (e.g. remember the massive DDoS AWS/Github had to endure after Baidu’s CDN was compromised – these are legitimate concerns for some organizations)
  2. Requires any 3rd-party JS to be audited when it is changed (e.g. Facebook report to your IT team and notify them of any Pixel code changes for them to audit – this isn’t practical/realistic)

JavaScript is simply not an option for technical reasons

If there is some “rare” CMS or e-Comm system that was limited or has restrictions imposed (e.g. no Tag Manager, modern way to insert Javascript or IT simply won’t allow you to modify the site in a certain way) the img tag could be an option.

Performance Concerns

This is a really controversial point as it is easy to simply say/dismiss using any JS code as it adds to the page load. This is partially true but does not tell the whole performance story and the ultimate effect on the User Experience (when they load the site). A healthy discussion on the merit of this claim is encouraged around this.

The FB JS tag implements web best-practices (async) to load the JS code requirements. The sheer number of calls doesn’t tell the full performance story (and also what a user ultimately sees) as the pixel is loaded in an Asynchronous way to avoid blocking page rendering. This greatly improves performance and does not block DOM construction on the page, which reduces the impact that it has on what the users sees despite the fact that it makes multiple calls to download JS.

Barring the above, if a bare-bones approach to using the img tag may be warranted. I would strongly review the preamble and balance/understand the tradeoffs before opting for the img tag.

Full Control of event firing is needed

This is also a controversial point. In the past, there were shortcoming around how you could fire multiple pixels, some misunderstandings on how to tag Single-Page Applications and misconceptions about the AutoConfig feature (SubscribedButtonClick and MicroData events). Ensure that the following articles are understood before opting to use the img tag.

I have written extensively on these topics on how to mitigate or control all these aspects as one would need. At the moment of publishing this article, there is functionality that will allow an implementor to control the important aspects/timing of the JS pixel code:


When deciding to use the img tag, be very careful and understand all the implications. I personally do not recommend going down this route for the variety of reasons stated above; however, there are some legitimate cases where this approach is needed

My next blog post will go into more detail on how to implement this and also provide some easy-to-use tools to get this done accurately.

Leave a Reply

Your email address will not be published.