Update (June 2021)
It appears that Shopify is releasing a completely new version of the Conversions API integration (available June 30th). This version handles all standard events (excluding Page View) for fuller coverage of user interactions. From our tests, it appears that this version handles the events much better so you can expect an uplift of 5-25% in the number of events tracked on Facebook.
Kudos to the Shopify Engineering team for following through with this feature.
Over the past year, and with an increased rate with the recent changes, we’ve seen Facebook reps push Shopify merchants to use the Conversions API as their reporting method.
This is a good practice, as it removes the dependency that stores have on the Facebook Pixel being able to load, primarily due to ad blockers installed on the shopper’s browser. When looking at the data, with over 25% of US consumers using some ad blocker, this recommendation makes perfect sense.
Shopify, which usually has fantastic built-in integrations for marketing channels (in my opinion, one of the features that sets them apart from other platforms) has somehow dropped the ball on this one. I can’t tell if this is sloppy engineering or some legal limitations, but in either case, the result is sub-par.
A quick recap on Conversions API
The Conversions API, aka CAPI, is a method of sending the user interactions without relying on the Facebook Pixel, which is often blocked by the user’s browser.
To connect between the anonymous user or identified user on the site and the user’s Facebook profile (to attribute ad activity etc.), an identifier needs to be passed back to Facebook.
There are several identifiers available that can be used. The more identifiers used, the higher the chances of that user being matched with a Facebook user for attribution purposes.
Generally, these identifiers are split across two groups: Anonymous and Personal Information.
- FBP – A value set by the Facebook Pixel (if exists and loads)
- FBCLID – Short for “Facebook Click ID”. A value appended to any URL a user clicks out of the Facebook ecosystem (app or browser)
- IP Address
- User Agent
- Birth date
- Address – e.g. City, Country & ZIP
With this data, the interaction that happened on the site can be reported back to Facebook and properly attributed.
The Shopify approach
Shopify offers merchants to implement the Facebook Pixel with click using the built-in Facebook Sales Channel integration. When setting up the channel, you can select the Data Sharing option, which is powers the the Facebook data integration.
The Standard option sets up a standard pixel to send browser side events back to Facebook on all standard user actions – e.g. Viewed a Product, Added to Cart or completed a Purchase.
The Enhanced option adds personal information (when available, i.e. a user is logged in) to the pixel events. This makes Facebook’s matching significantly more accurate, as the user can be matched with an email or phone number, that Facebook probably match in their records.
Both option above rely on the Facebook Pixel being loaded on the site. If the Facebook Pixel fails to load, due to an ad blocker or a slow connection, the data will not be sent.
When selecting the Maximum option, the data is sent in parallel via the pixel in the browser (which can get blocked) as well as via Shopify’s API, which in turn forwards the data to Facebook’s Conversions API.
That’s good isn’t it?
We went exploring
To try and understand how this was working in practice, we set out to dissect the Shopify tracking mechanism.
Shopify uses a unified tracking mechanism called Trekkie which handles the dispatching of events to the various ad platforms a store works with.
To drill down specifically into the Conversions API feature, we scanned the code to find this bit:
This is the trigger that operates the Conversions API feature in the Trekkie script. The basic gist is that it collect certain data on the browser and sends it back to a dedicated Shopify server, which probably the sends it to Facebook. So far so good.
We the examined the payload sent to the server, to see what data points are being used.
The issue with Shopify’s approach
While the general approach to sending events via the server, there are several caveats to Shopify’s implementation.
Reliance on Personal Information
In order for an event to be sent, the user’s personal information must be available. If now such data exists (e.g .an express checkout) the CAPI event won’t be sent.
Enforcing this reliance on such events is wrong, as some sites will have legal restrictions on sending this information to a third party (i.e. Facebook) and the other anonymous methods (e.g. FBP, FBCLID etc.) can be used regardless of the personal information.
Only Purchase events are tracked
When we examined the triggers, we’ve see that only Purchase events are being sent (which somewhat explains their reliance on personal information). This is literally hardcoded into the event, meaning no other events are available to be sent this way.
From our tests we’ve seen that measuring other events (e.g. View Content or Add to Cart) can lead to 5-10% increase in the sum of events reported in Facebook. Some clients of ours have even seen 25% increase. That’s a major chunk of users they can engage with.
No real reason not to apply this to other events too.
Not a true Server Side solution
I know this, because I have built one myself in under an hour’s work. I’m pretty sure the Shopify team can code better than me, so why settle for this?
Implementing a true server-side solution, that grabs the FBCLID parameter from URLs visited on the backend, will be able to drive true value for overcoming ad blocking and proving accurate attribution. Heck, it can also use the user’s personal information for improved matching (as Facebook’s Offline Conversions API suggests.)
What about Google Analytics?
This last rant is unrelated to Facebook Ads, but really upsets me as well. As a long time analyst working with Google Analytics on dozens of ecommerce stores, I’ve migrated many of them to use the Measurement Protocol.
This protocol is essentially a simple API that accepts Google Analytics hits. This protocol increases measurement accuracy ten fold, and is a standard for any serious ecommerce business. Shopify could have easily integrated this into their server-side API alongside the Facebook events, as the data is quite identical.
I like Shopify. It’s my go-to platform for ecommerce and there’s plenty of clients I’ve personally recommended they migrate from whatever platform they’re on to Shopify. Because it’s so simple to use and all the pixel hassle is non-existent in Shopify.
But they could have gone the extra mile, bringing more value to their clients and keeping them (and themselves) ahead of the curve when it comes to tracking.