Actionable tips to improve Facebook conversion attribution

Proper Facebook conversion attribution is essential for businesses that want the full advantage of paid advertising. While some companies still rely on browser tracking, switching to server-side tracking can provide more accurate data. Server-side tagging enables direct communication with your server and Facebook server, delivering quality first-party data and using first-party cookies. 

This blog post will provide actionable tips to help you improve your Facebook conversion attribution using server-side tagging.

How server-side tagging can help with Facebook attributionCopy link to this section

One of the main advantages of s2s tagging is that it provides improved accuracy over client-side tracking methods. This is because server-to-server tagging can't be blocked since the communication takes on the server level. Tools like AdBlocker or other tracking prevention mechanisms can’t access data sent through the server. 

When you enable FB s2s integration, your server communicates directly with the Facebook servers. It sends reliable data about events and users who visited your website that help FB attribute your users to their FB profiles in accurate way - meaning quality reporting and higher chance of successful targeting.

The most popular way of server-to-server Facebook tracking is setting Facebook conversion API with the help of server Google Tag Manager container. But there are several approaches to setting up FB CAPI in sGTM. In this guide, I want to describe different methods of setting up FB CAPI, how each way impacts FB attribution, and how to improve attribution. 

These suggestions are based on stape's experience and stape customers' feedback. 

Facebook conversion API (browser+server)Copy link to this section

Facebook recommends setting up CAPI using the browser+server method. When browser tracking is blocked, server tracking will still send user data to Facebook. When both browser and server tracking is triggered, FB uses the event name and event ID for event deduplication. It discards one event and keep another to prevent overreporting.

We have a blog post that describes how to set up Facebook CAPI using server GTM. 

FB gives higher priority to browser events. When they see both browser and server events, their deduplication algorithm will likely discard server events and record browser events. So if you send more data with a server event, FB won’t be able to read this data. They also do not combine web and server event parameters. 

An essential aspect of setting up FB CAPI using hybrid methods via Google Tag Manager pops up when you use GA4 (or any other GTM tag) to deliver data from the web to server GTM. In cases when AdBlocker blocks GA4, it does not provide data to sGTM, meaning FB CAPI tags also do not trigger. So in this scenario, browser events do not trigger, as well as server tags. 

To solve this problem, stape created Custom Loader power-up. This power-up makes your GTM and GA4 script resistant to AdBlockers. So when AdBlocker uses its maximum capacity and blocks gtm.js or collect requests, Custom Loader hides them and prevents them from being blocked. This way, when the FB pixel is not working, your GA4 tag will still deliver data to the sGTM container, and sGTM will send FB CAPI events to Facebook, meaning user action is tracked.

Check this article to learn more about Custom Loader power-up and how you can make Web GTM and Google Analytics 4 resistant to AdBlockers. 

Advantages:

• FB recommends setting up the browser+server method.

Disadvantages:

• Server tracking can be blocked unless you use stape Custom Loader power-up (the use case is described earlier in the blog post).
• More comprehensive implementation if you do not use web GTM for setting up FB pixels.
• When a user on an iOS device opts out of tracking, both web and server events won’t be sent. (I will talk about it late in the blog post).

Facebook conversion API (server only)Copy link to this section

Though sending only server events is not recommended by Facebook, it is a good solution if you have more user or event data in server Google Tag Manager container than in web one. Or use any technique to enrich your server data. We already have two blog posts on how you can enhance sGTM data with the help of Firestore or Google Sheets.

I recommend sending server-only events in such a situation. The main reason is that by using the web+server method, FB will prefer web events and skip all user and event parameters sent from the server. It means that valuable data that can help with conversion attribution will be lost, and FB will have less accuracy when attributing events to campaigns. 

FB conversion attribution of iOS users who opted out of tracking is another lengthy and controversial discussion. In the official documentation, FB says that FB CAPI does not help track users who opted out of tracking. Though some case studies and our experiment show that one of the ways to track people who opted out of tracking on iOS is by sending only server events through FB CAPI. 

This theory is based on the logic that with web+server tracking FB sees the device ID using pixel and does not collect all events for this device ID. But when sending events through the server, FB only has access to data you configure and does not know the device ID or if the user opted out of tracking. 

Advantages:

• Improve conversion attribution in case you have more data in sGTM.
• It takes less time to implement since there is no need to set FB pixel and event deduplication.
• You can track users who opted out of tracking.

Disadvantages:

• FB does not recommend this method.
• You will need to manually send fbp since the browser ID won’t be generated by FB pixel. If you use the FB CAPI tag, you can easily enable this option. 

Facebook conversion API through webhooksCopy link to this section

Setting up FB CAPI through webhooks is similar to sending FB events only through the server. The only difference is how you deliver data from server Google Tag Manager. In method #2 (server-only tracking), you send data from web GTM to sGTM using GA4, UA, or Data Tag. With this method, you can trigger FB CAPI events based on the data you send via Webhooks. 

The most popular CMSes have functionality that allows configuring webhooks easily. With stape Preview Header power-up, you can debug incoming webhooks in sGTM. We already have a blog post on how to send webhooks to sGTM.

Webhooks can be an excellent data source for sGTM since it carries complete information about orders and users. 

The main benefit of using webhooks to send FB CAPI events is that these events can’t be blocked. Some clients prefer to test sending the same event via browser+server vs. webhook (server only). This way, they can split test and compare which method has a higher match rate and better impact on conversion attribution.

Advantages:

• Improve conversion attribution since Webhooks include valuable data about user and order
• You can track users who opted out of tracking on iOS devices.
• Gives an excellent opportunity for split testing web+server tracking vs. server through the web GTM vs. server through the webhooks.

Disadvantages:

• It might take longer to set up since you will need to configure webhooks.

Facebook offline conversions using sGTMCopy link to this section

The Stape team created a new sGTM tag designed explicitly for sending FB offline conversion from sGTM. Using this tag, you can automatically send FB offline conversion events to FB. Previously you either had to build a custom integration or upload offline manually via CSV. 

The main benefit of FB offline events is that they can be measured in parallel with FB pixel and FB CAPI events. You can split test if web+server, server only, or FB offline conversion events work more accurately in terms of attribution.

Besides that, our experiments showed that by using webhooks as a data source for FB offline conversions, FB can track people who opted out of tracking on iOS devices. The main reason that offline conversion is considered first-party data that you share with FB. 

Another considerable benefit is the increased attribution window of FB offline events. It has a 28-day click attribution window compared to 7 day maximum for FB CAPI or pixel. 

We’ve recently started recommending stape clients set up FB Offline conversion in parallel with FB CAPI tracking. The main reason is that it gives you more information for evaluating campaigns performance, and setting up FB Offline conversion won’t take long if you have already implemented FB CAPI. 

Advantages:

• It can track campaign performance in parallel with FB pixel or CAPI. All you need to do is customize columns in Ads manager.
• FB offline conversions have a 28-day attribution window.
• High chance that it will track users who opted out of tracking on iOS 14/15 devices.

Disadvantages:

• It takes additional time to set up.

Conclusion:Copy link to this section

Thanks for sticking with me till the end of this blog post. Now that you know what tips we are using to  improve stape clients FB campaign's conversion attribution with the help of server-side tagging, it’s time to put this knowledge into practice. 

Remember that no solution fits all websites since technologies and conversion funnels are different. Try to experiment and find a method that works best for you. 

We are here to help if you need assistance setting up your tracking or troubleshooting any issues. Our team of experts is always happy to help new users get started with tracking and answer any questions. And be sure to check back regularly as we will continue to update our blog with the latest news and insights in digital marketing. Until next time!