If Tracklution is server-side, why use a browser script?

If you began the Tracklution installation process, you might have noticed that you do have to install a browser script to get it running.

So, why would server-side tracking software use a browser script to begin with?

The TL;DR version

It’s actually quite simple:

• The browser script collects data (unlike regular tracking scripts, it can load under your own domain, as part of your website, not as a third-party tag).
• The Tracklution server processes it.

As visualised above, those are two different jobs, and confusing them is what makes this feel like a contradiction (when it isn't).

The security camera analogy

The way I like to explain this is from the perspective of a security camera.

The camera captures what's happening and sends the footage to a recording server. The camera itself doesn't store or analyze faces, flag suspicious behavior, or make any decisions.

It records, transmits, and the intelligence lives on the server.

Tracklution's browser script works the same way.

It captures what's happening in the user's browser and sends it to the server. The script doesn't process, enrich, or decide anything. That all happens server-side.

Without the camera, nothing gets captured.

And without the browser script, nothing gets captured.

Client-side tracking vs. what Tracklution enables

Here’s what client-side tracking looks like in practice.

1. A script sits in the browser,
2. captures an event (a purchase, for instance),
3. does light processing activities, like hashing, if and when needed,
4. sends it directly to the ad platform.

That's it.

A pipe.

The event travels in a pipe, from the browser to Google or Meta (or any other ad platform) with no stop in between, no enrichment, no cross-referencing with anything else.

And if something gets in the way (ad blocker, or cookie restrictions), ad platforms won’t receive that information.

The added value from server-side tracking with Tracklution

With Tracklution, the script sits in the browser and captures the same events.

But instead of going directly to an ad platform, the event goes to the server.

Meet hybrid server-side tracking

More than server-side tracking, Tracklution actually makes hybrid server-side tracking possible.

Uh? On top of capturing and processing events fired from the browser, you can also feed your server with offline conversions (CRM updates, brick and mortar conversions, phone orders, subscription renewals, etc.), through webhooks, to train ad platform algorithms with the most complete and accurate data.

And if you want to learn more about how Tracklution manages offline conversions, check this walkthrough from Emma, Customer Success Manager at Tracklution.

From there, it's stored and processed against historical data before being sent on to the ad platform.

That processing step is where the added value of Tracklution is: deduplication of events, session stitching, user identification, data enrichment… None of that is possible when you're sending events directly from the browser in real time.

In short, scripts are the best tool for capturing events in the browser, especially in a first-party context. Everything after that—transforming, enriching, cleaning the data, and making sure it actually reaches ad platforms—is dealt with server-side, as visualized below.