The Magento and Facebook Conversion API Conundrum

Recently Apple has shaken things up for marketers with new privacy focused policies introduced in iOS 14. One significant impact that has prompted many discussions with our clients is around Facebook pixel tracking.

The Message Marketers Received from Facebook

Earlier in the year, marketers advertising on Facebook received the following email from Facebook:

Subject:

Changes to Apple’s iOS 14 are coming soon.

Body:

Apple has announced changes that will adversely affect the way our ad systems work and may impact your ability to reach people with personalized ads. These changes are expected to be introduced with an update to iOS 14 in early 2021. This disruption may significantly affect advertisers using pixels, as well as iOS 14 app developers and publishers. 

To help you prepare, we have added a Resource Center with updates and tasks in Ads Manager. We also recommend reviewing resources in the Facebook Business Help Center with your marketing team. We know these changes may have a significant impact on your business, and we remain committed to providing updates and additional resources as they become available.

They were directed at an article titled: “Facebook Pixel Updates for Apple's iOS 14 Requirements” in the Facebook Business Help Center with specific steps recommended in response to these iOS 14 changes.

In this post we will talk about one step which is not directly recommended in the “Facebook Pixel Updates for Apple's iOS 14 Requirements” article, but repeatedly came up in conversations with our clients...implementing server-side tracking via the Facebook Conversions API. We will be taking a technical deep dive specifically considering its implementation of the Magento Commerce platform. Buckle up.

A Typical Client-Side Tracking Implementation on Magento

Historically, on a Magento site we have always implemented Facebook tracking via client-side tags. We prefer to implement them via a Tag Manager such as Google Tag Manager. This allows us to set up all the tracking we need without even involving a developer.

At minimum we typically report back to Facebook the following eCommerce funnel steps:

1. View Content – The user has viewed a product page.

2. AddToCart – The user has added a product to their shopping cart.

3. Initiate Checkout – The user has visited the checkout page.

4. Purchase – The user has placed an order.

Facebook provides many more standard events that can be tracked, and it is even possible to track custom events. All this works great with client-side tracking. In a server-side tracking world, however, this is not so easy as we will see shortly.

The Page Cache Problem

A fundamental feature of Magento and many ecommerce platforms is page caching. In the Magento world, a CDN (typically Fastly if using Magento Commerce Cloud) sits in front of Magento. Magento leverages Fastly not only to serve “static assets” such as CSS or JavaScript, but in fact also to serve HTML for pages that are considered “cacheable.” These are typically CMS pages (e.g., the home page), and category or product pages.

Looking back up at our typical client-side tracking implementation, you can see that we report the View Content event back to Facebook when the user views a category page. This works fine with client-side tracking as the client (browser) is consuming the HTML for every page the user views and will always execute the tracking code. But in a server-side tracking world, how can we report this event to Facebook if the server does not even know that it happened (as the response is coming from the CDN)? We cannot!

There may be a technical solution to this such as streaming logs from your CDN and reporting that info to Facebook, but this would require a separate custom application (not Magento) adding extensive additional complexity.

Our engineering team reviewed the official Facebook / Magento connector, which, in addition to View Content tracks View Category, and found that it has not addressed the page cache problem and simply is not able to report these events properly.

The Stability Concern

So, we have seen the issues of server-side tracking with cacheable pages. What if we were willing to live without tracking on cacheable pages and only track uncacheable events. That would still catch the majority of the metrics we outlined initially (AddToCart, Initiate Checkout and Purchase could still be tracked).

While it is possible to track these events, it needs to be done very carefully.

Generally speaking, we recommend limiting your application’s backend external dependencies as much as possible. Depending on how the server-side tracking is implemented, it may put your website in a position where a service interruption with the Facebook API causes your entire website to crash.

We would recommend implementing a feature like this in the most asynchronous fashion possible...in the Magento world the most architecturally sound approach is to use a message queue.

Unfortunately, another thing we found while reviewing the Facebook connector is that while it does use an asynchronous Guzzle request overall, communication with Facebook is not queued and happens in real time when the user completes the action to be tracked. Without a tight timeout on requests (which it does not look to use) the dependency concern is very real.

This is Bigger Than Facebook

While conversations around client-side vs. server-side tracking have largely been regarding Facebook, it is also important to understand that the discussion is actually not rooted in Facebook, but rather in Apple’s iOS 14 updates. This means that Facebook is not the only platform where the discussion about client-side vs server-side tracking is relevant. This then raises an even larger engineering stability concern. What it your application needed to report server-side events not only to Facebook, but all your marketing partners? Now your application backend stability is dependent on all your marketing partners. If this discussion is about moving to server-side tracking, we must consider this concern. Another way to look at this...you are taking all the processing work for user tracking that had historically been distributed across your user’s devices (in their browser) and putting it all onto your own backend infrastructure.

Our Conclusion

Based on several discussions involving engineering and marketing leadership our conclusion is that a move from client-side tracking to server-side tracking is not the appropriate step to take in response to recent privacy updates. We are viewing these updates in a larger shift in the tracking landscape that will play out over the coming years. Our guess is that marketing teams' tracking capabilities will be more limited than they have been historically, and they will have to adjust.

In the end, we should look at this through the eyes of the consumer. Many would agree that the level of tracking on the web these days has gone too far. Taking that viewpoint, we can see this as a step in the right direction.