Let’s get one thing straight right out of the gate, The results of your Meta ad campaigns will never match 1-1 with what is actually happening in your cart. The sooner you can get over that, the sooner you can start making decision about your business that will actually move the needle.
While the data in Meta will never match exactly, that doesn’t mean we won’t do our absolute best to give it the highest chance of matching. It’s our job to make sure we give Meta the best data possible. Then, it’s up to it to process and display that data. But at least we did our part.
So what makes the best Meta tracking possible when using ThriveCart? I’m glad you asked. Let’s jump in!
Meta Events
Whenever you send data to Meta you do so by sending it an “event”. PageView, AddToCart, InitiateCheckout, and Purchase are all examples of standard events. Events are used to tell Meta that certain behaviors have occurred and can be used as conversions in your campaigns. You can also send custom events that can literally be called whatever you want.
There are 3 main methods of sending events to Meta:
- Event Code Snippet
- Event Setup Tool
- Conversions API
Methods 1 and 2 both require that you add the “pixel” onto the website. The pixel is that chunk of JavaScript that Meta asks you to install on your every page of your website. The pixel code is responsible for setting the ID cookies Meta will use to track your visitors.
Once the base pixel is on your website, you can either add a small bit of code to the page that will trigger the event, or use the “no code” event setup tool to trigger the events.
The third method doesn’t involve a website at all and is an event that is sent from 1 server directly to another.
At the end of the day the most important thing to remember is that you’re sending events to Facebook. It doesn’t matter the method, they are all still events and therefore all follow the same rules for data processing.
Browser Vs. Server-Side Tracking
So which method is going to be the best for tracking your ThriveCart checkout?
Both!
Meta has provided instructions on how to properly configure both the pixel and the server to send the same event and not be counted twice. They actually recommend that you send an event from both the browser and the server in order to have what I call “Full Coverage”.
Typically a server event sent using the Conversions API will have more details about the interaction than the browser event. Usually the cart’s backend has all the details related to the customer and the order that get sent with the server event. The more details you send, especially user details, the higher your match rate will be and the better Meta will be able to optimize and train the algorithm.
Full Coverage Tracking
So what does it look like to have full coverage tracking?
Every single event is sent from both the browser and the server. All events will have an event_id property that will match both. Meta will then be able to know that the incoming event from the browser and the incoming event from the server are actually the same event and to only count one of them.
One of the biggest questions I get asked is to fix their Conversions API setup because they aren’t properly deduplicating the events and they are over counting.
In ThriveCart there are 2 ways of making this happen.
- Use the native integration for Meta
- Build the events manually
Using the native integration is going to be way quicker and more convenient for 90% of people but does come with some downsides.
Building the events manually requires a much bigger lift to make sure your event IDs match and the server-side event is configured properly. However, this method does yield better results since you can be the one to make sure everything is working as expected and even monitor the actual data being sent to Meta.
I prefer not to use the native integration and build it myself.
The Perfect Tech Stack
So far I have not seen anyone else have a better set up for the most robust tracking of Meta ads. Here are all the tools I would use to have the absolute best Meta tracking on ThriveCart.
- Google Tag Manager
- This is where I would deploy the browser pixel from. Using GTM allows you to specifically define all the tags, triggers, and variables in use and exactly when they should be used. Perfect for being able to manually control the event ID.
- GTM is also responsible for sending an event to Server-side GTM. By utilizing Server-side GTM all my normal events like PageView can also be sent from the browser and server.
- Custom Coded Data Layer for GTM
- GTM uses the data layer in order to make advanced data useful for its tags, triggers, and variables. I spent months custom coding the absolute best data layer possible that would perfectly fit all the usecases for Meta, GA4, and Google Ads. It includes all the fancy bells and whistles I would want for advanced match parameters and enhanced conversions.
- The real secret sauce is in the ability to add those juicy visitor IDs (Click IDs, Browser IDs, and other identifiers) into the webhook data that is used in the server-side event.
- Server-Side GTM
- Server-Side GTM is responsible for receiving a browser event from web GTM and also sending it to Meta. This enables all the “normal” events to have full-coverage and you can monitor it at every step of the way to make sure it has the right IDs and advanced match parameters and everything like that.
- But it can also be configured to receive order details directly from ThriveCart, format the incoming data to be in the format Meta wants, and then send the event to Meta in a true server-to-server fashion. Because of the custom data layer, this webhook data has all the identifiers Meta wants so these server events are absolutely packin’!
Why Is This The Best?
One of the biggest reasons is because I know that I can follow the data and see exactly what is happening for the browser and the server at every single step of the way. I also know that all events have full-coverage with the absolute best data physically possible.
Do you think you have a better method? Did I miss something? Let me know 🙂