In my previous article, I discussed the basics of Tracking and its relationship with Cookies. It provides the basis to this article, where I’m going to break down the concept of Client-side tracking and its use cases.
Let’s start with the name, why do we call it “Client-side” tracking?
The Client, in that context, is the browser. That means that this form of tracking takes place using your browser, making it an integral part of user activity tracking, your activity, that is.
But, how does it actually work?
There are three main implementations — Cookies, Pixels, and SDK’s.
They can all be used together or separately, depending on what the advertising platform provides, and your specific needs and limitations.
Implementation #1 — Cookies
This process is pretty straightforward. You visit a website, and that website saves some information about you — your login token, shopping cart contents, etc. It uses it to provide you with a better experience, but also to learn more about you, for various purposes. Most of these “other” purposes are related to getting you to buy more of their products. That’s in the realm of fair game.
However, if the website you visited happens to be Facebook, Google, or any other website that provides a platform for advertisers to promote their goods, things get a little more complicated.
Most websites you’ll visit are either selling something themselves or promoting other products, via online ads. In both cases, they will have snippets of code on their site, that are essentially using JavaScript code to call Facebook/Google/other advertising platforms’ servers. The servers respond by showing you ads or allowing you to interact with some familiar UI from that platform, the Facebook “like” button being a prominent one.
Once these snippets run, they allow Facebook (I’ll use Facebook as an example) to consume its own cookie, which was created the last time you entered your credentials in order to log in to your account. Back then, it was used “for good” — in order to keep you logged in for your next visit.
Now, however, it allows Facebook to track your activity on the site you’re currently visiting, and use that information to promote relevant products or even that same website’s products, once you revisit your Facebook feed.
The good news here is that if you reject the usage of cookies, or even only “third-party” cookies — (Facebook’s cookies when they’re used outside of Facebook), you essentially “sabotage” the tracking process, preventing third parties from gathering information about you. That’s of course only partially true, as there are other methods I’ll discuss in the upcoming articles (like Server-side tracking).
Implementation #2 — Pixels
To track more specific data across different devices, you can use Pixels. In this article, I’m going to describe browser pixels. There are also server pixels which I will discuss in the upcoming article about Server-side tracking.
It’s also worth mentioning that some people may use “pixels” as an interchangeable term for Client-side tracking in general. However, they are a distinct type of Client-side tracking.
So let’s get to it, how would we define pixels?
The name gives away its meaning — pixels are snippets of code, used to create an actual 1x1 graphic pixel on your screen. Being tiny, and often transparent, visitors don’t tend to notice them.
For example, a very simple pixel code could be something like this:
<img style="display:none;" src="http://www.website.com/pixel.png" />You can put this image tag pretty much anywhere you want.
Some common use-cases might be at a “thank you” page, indicating a purchase occurred. Or on a button — rendering that invisible image after a user clicks on it, to register an important event.
But how does it actually work? All you’re doing is adding an <img> tag to your code. Well, you might have noticed in the code snippet above, that the <img> tag has an external source (src). In order for the browser to display that image, it needs to make a call to the server hosting that image. When that happens, the server registers the call, and where it came from.
“Website A, on page=”/catPictures” asked for pixel at 6:15PM, 01/01/21".
The server also gets additional information about the client that made the request, AKA your browser & operating system. Things like your IP address, the browser you’re using, your operating system, whether you’re using mobile/desktop, and more. If there are multiple tracking pixels on different parts of the site, the advertising platform can create a “customer profile” based on your actions. Then it can use that data to target you with more accurate, tailor-made ads.
There are two main use cases for pixels — Retargeting & Conversion.
Retargeting pixels are used by the same site that used the pixels to promote their own products. For example, you’re looking for a chocolate workshop and land on website A. Inside you saw a workshop that looked interesting and clicked on the “read more” button to get more information. The pixel attached to the “read more” button fires, and that data is registered in some advertising platform, let’s say Facebook. You’re not sure about that workshop, so you go back to scroll your Facebook feed for some funny cat videos. However, you suddenly see an advertisement for that exact workshop from website A. You just saw a retargeting pixel in action.
The second use case is for tracking conversions. In other words — tracking how well certain ads perform.
Performance in this case is measured in the context of the desired outcome. For example, you want to sell more chocolate bars, so you decide to publish ads on Facebook and Instagram. You place their respective pixels on the purchase “thank you” page. When a customer comes through one of their ads, a unique click id is appended to the URL’s query parameters.
http://www.chocolateWebsite.com/hotChocolate?fbclid=12345abcdeNow when the pixel is loaded, it has access to the URL’s query parameters, so Facebook’s servers can associate that unique click id with your ad, along with some additional details. That data is then used to attribute that user’s purchase to a specific ad you placed on Facebook.
Other use cases for conversion pixels, include tracking “interest” in a product, or in other words, tracking “leads”. This could be done by placing a pixel on CTAs (“Get an offer”), or on form submit buttons.
Implementation #3 — SDK’s
The last implementation method we’ll discuss involves using the advertising platform’s SDK. In the context of Client-side tracking, SDK’s are simply code snippets you add to your site, similar to the other implementation methods. The difference lies in how you configure these code snippets. For Pixel and Cookie based tracking, you simply paste it, and you’re pretty much done. The rest of the work is done for you. The SDK based approach requires you to handle customer identification and event tracking yourself.
This is a bit more of a hassle, but it allows you to exercise greater flexibility in the types of events you might want to track, in their payload, and how you choose to identify your customers. For example, tracking a “lead” event followed by a “purchase” event might look like this:
Step 1 — The site loads, you identify the customer using your site
someSdk.identify({ customerId: **someIdFromYour1stPartyCookie** });Step 2 — The customer clicks on “read more” on the chocolate bar page
someSdk.trackEvent({
event_name: "lead",
timestamp: "2021/01/01 09:05",
adId: "facebookAdId123",
product: "chocolate bars"
})Step 3 — The customer purchases the chocolate bars
someSdk.trackEvent({
event_name: "purchase",
timestamp: "2021/01/01 09:15",
adId: "facebookAdId123",
product: "chocolate bars",
price: 15
})So you essentially handle the tracking process yourself, notifying the SDK explicitly of the customer’s journey, from the “lead” to “purchase”.
However, you can also use the SDK to track other events that might not be a part of the purchase flow, in order to build a better understanding of your customers and their needs
Tag Managers — One platform to rule them all
So we’ve covered the ways we can implement Client-side tracking, but how do we manage all of those code snippets? Tag managers to the rescue!
You might have guessed from context, that tags are a fancy term for code snippets. Tag managers allow you to use their UI platform to add/modify all other code snippets you may use. So instead of adding code snippets for each and every advertising platform/analytics provider separately, you simply integrate the tag manager’s code into your codebase, and the rest is managed via the tag manager’s UI.
That is very comfortable, as it removes the need for frequent code deployments, and allows non-technical users to add/modify tags via a friendly UI.
Tag Managers also allow you to manage triggers for your tags.
For example, Define a trigger — “when the purchase button is clicked” and attach a tag to that trigger — “Send a purchase event to Facebook”.
That is very useful, as it allows you to reuse the same trigger for multiple tags, instead of adding the same trigger for each and every tag separately.
They have many other features, including a way to manage all of the data that is relevant for your tags — Customer information, product information, marketing data (whether the customer came from a Google ad or from a Facebook ad), and more. However, it is beyond the scope of this article.
I hope this thorough, yet straightforward and simple overview of Client-side tracking has helped you better understand how web tracking works. In the following article, I will discuss another form of tracking — Server-side tracking, which provides another tracking alternative with its own pros and cons.
