1. Knowledge Base
  2. Frequently Asked Questions

Client Side Tracking vs Server Side Tracking

Learn the major differences, benefits, and requirements between client and server side tracking.

The internet is composed of nodes that communicate with each others using standard protocols.

For example, when you navigate to a website your browser will display content that the website provides.

In this simple scenario involves a "client" and a "server".

✅ The client being the browser, and the server being the website.

In a similar way, when you buy something from Amazon the action happens between your browser (client) and the Amazon website (server).

But what happens in Amazon Server during the Purchase?

This is a simplistic and logical scenario which can be expanded at will... 

  1. Amazon will send a request to your Credit Card company
  2. Your credit card company will respond with an approval or decline
  3. A transaction will be approved
  4. Your browser will receive and display the transaction approval
  5. Amazon will record the transaction in its database
  6. Amazon will create an order fulfillment request (in another database)
  7. The Fulfillment request will be sent to a warehouse
  8. The Warehouse will dispatch your order
  9. You will receive an email with a tracking number
  10. etc.. etc...

As you perhaps understand, except for step 4, all interactions involving your Purchase do not happen in your browser.

They happen "server-side".

In other words, servers talk to other servers, in a certain language, according to certain rules.

Now, in order for the servers to talk to each other, they use common "keys" that enable Amazon to trace the status of your Order (among other reasons).

The "keys" can be your customer id, the transaction id, the order id, and/or a combination of these keys to uniquely identify your order at each step of the order fulfillment process.

Now that we've established the grounds with simplistic scenarios, we can apply them to the ad tracking and analytics trade craft.

How Client Side Tracking works

You probably heard about the "thank you page".

That's the page that loads when you complete your purchase on Amazon or other merchants.

When the "thank you" page loads (client) a few things happen:

  1. The Response from the Credit Card company appears on your browser with a "transaction id"
  2. The Facebook Purchase Snippet loads
    1. When the FB Snippet loads (from the browser/client), it sends a request to the Facebook Server
    2. The Facebook Server records the Conversion
    3. The Event Manager displays the Conversion Event
    4. The Ads Manager display the purchase event and updates the ROAS

Here is an example of the Facebook Event Snippet

fbq(
'track', 'Purchase', {
value: 40.00,
currency: 'USD'
});

What is (was) the upside of this method?

Quite simply: It only required a simple copy/paste of your facebook pixel on the "thank you" page and it worked out of the box.

We're post iOS14 tracking transparency "act" and that doesn't work anymore.

How server side tracking works

When you complete your purchase, one of Amazon server will do the following:

Amazon servers don't speak with Facebook, so this illustration is pure fiction, but it illustrates the the process.

  1. It will record the transaction
  2. It will transform the recorded data according to the Facebook CAPI requirements
    1. Hashing personal data
    2. Map their internal names to Facebook Standard Names
    3. It will send a POST request to Facebook Conversion API (CAPI)

Note:

The example below is only a short version of the data you can send to the FB api. You can play with the facebook helper here.

https://graph.facebook.com/v14.0/yourpixelid/events?access_token={TOKEN}
{
    "data": [
        {
            "event_name": "Purchase",
            "event_time": 1661941807,
          "action_source": "website",
            "event_id": "123123123123123123",
            "event_source_url": "https://amazon.com",
            "user_data": {
                "em": [
                    "7b17fb0bd173f625b58636fb796407c22b3d16fc78302d79f0fd30c2fc2fc068"
                ],
                "ph": [
                    "72fe84274df481a1ad439dbd462c76f6304a99a8e009e583924ff04f9c17cc01"
                ],
                "external_id": [
                    "932f3c1b56257ce8539ac269d7aab42550dacf8818d075f0bdf1990562aae3ef"
                ]
            },
            "custom_data": {
                "currency": "USD",
                "value": "142.52"
            }
        }
    ]
}

As you hopefully realize, what was once a walk in the park and only required to add a piece of code on the Thank You page, now requires lots of programming and orchestration that happen "server-side".

We've omitted a Key element in this example. 

What is the Key that the Amazon and Facebook Servers can use to talk to each other and make sure they actually talk about your purchase?
  • Can they use the Transaction ID?
    No, because the transaction ID is generated by Amazon and doesn't mean anything to Facebook.
    • The Transaction ID can however be used by facebook to deduplicate conversions sent from both the browser and server, but only when sent alongside other values.
  • Can they use the customer Email?
    Yes, but you might have a different email address in Facebook and in Amazon. So it might work in some cases, but not all cases.
  • Can they use the First and last name?
    Yes, but they have to be sent hashed and together with other parameters otherwise they will be discarded
  • Can they use the phone number?
    Yes. As long as they format and hash it.

Note:

If you're familiar with the Facebook Conversion API - you'll notice that these values among many others are the one giving you the "match rate".

What are the main advantages of Server-Side Tracking?

  1. Accuracy: When servers talk to each others, they usually don't fail.
    • If they fail, they know it, and they can "retry"
    • if they fail, you can get a notification with the Why, fix, and retry.
  2. Ad blockers: They don't see server side communications, so whatever goes on between servers can't be blocked.
  3. Privacy safeguarding: because it's happening server side, data can freely pass from one server to the other - as long as the customer gave its consent
  4. Data instrumentation: when you process the data server side, you can clean it, hash it, normalize it... and so much more.

You can find more reasons for using server-side tracking when you browse the Facebook help / documentation about the Facebook Conversion API (previously called Server-Side API).

What are the disadvantages of Server Side Tracking?

  1. It's complex to setup as you need to know what happens in your server, as well as in the server that you want to talk to.
  2. If you don't control the servers or if they don't have public APIs you're basically stuck.
  3. If you don't have the "keys" you're stuck.

Why do you "need" AnyTrack?

In theory, you don't need AnyTrack. Most platforms you're working with have public APIs, and do their best to help marketers connect the dots.

Yet, when you're a marketer, or own a shop, or run an agency, you need the tools that help you control your data flows, regardless the technologies, servers, or platforms you use.

Note:
Amazon doesn't provide any keys that would enable you to tie a purchase with a user, or piece of data that happened on your website. 

Why is AnyTrack "best" suited to help you?

In a nutshell, AnyTrack orchestrates both client side and server side tracking so you can focus on your marketing rather than figuring out how each platform works, and how to connect the dots.

AnyTrack in its most distilled definition:

AnyTrack is a connector that provide you the keys to insert, process, and extract data to and from the platforms you work with.