Digital Marketing Tagging Maturity in 2025
Introduction to Marketing Tagging
In the world of digital advertising, success hinges on smart data usage. For years, the answers came from simple snippets of code called "tags" or "pixels." But as browsers, privacy regulations and user expectations have evolved, so too has the technology we use to achieve tracking this.
At its core, a marketing tag / pixel is a small piece of code placed on your website. It has sole job: to observe user behaviour (e.g. page view / button click / purchase) and send that information to an ad platform’s server, such as Google / Meta / TikTok. This allows the advertising platform to measure campaign effectiveness, build audiences for retargeting and optimise ad delivery.
The method by which this data is collected and sent determines your tracking maturity. Let's walk through the key stages, from the humble beginnings to the state-of-the-art.
Simple: Client Side Image Tag
This is the original tracking pixel. It's literally a 1x1 pixel transparent image that is loaded from the ad platform's server when a user visits a page that it is implemented on. The request for this tiny image carries basic information back to the server.
How it works: An
<img>
HTML tag is placed on a page (e.g. a confirmation page after a purchase). When the browser loads the page, it requests this image, and the ad platform's server logs the request as an event / conversion.Pros:
Simplicity: Extremely easy to implement. You just paste a line of HTML.
Universal Compatibility: Works in every browser, even with JavaScript disabled.
Security: By nature of not using JavaScript, there is less manipulation of data. Therefore sensitive verticals like Financial Services favour this approach.
Cons:
Limited Data: Generally is limited to page load events & requires manual parameter implementation to track dynamic variables.
Obsolete: Rarely used today due to JavaScript being pushed by all major platforms, but remains the backup.
Simple: Client Side JavaScript Tag
This has been the industry standard for the last decade. Instead of a simple image, you embed a more powerful JavaScript snippet from the ad platform (e.g. the Meta Pixel or Google Ads tag) onto your website, often managed through a Tag Management System (TMS) like Google Tag Manager or Tealium.
How it works: The JavaScript code executes in the user's browser (hence "client-side"). It can collect a wealth of information based on how it is configured, such as device information, button clicks, form submissions, page scroll depth and package it up to send to the ad platform's servers. In the past few years, the likes of Google / Meta / TikTok have pushed it heavily, as a means to allow their JavaScript to capture 1st party cookies under the advertiser’s domain name, to persist their ad tracking capabilities by stitching this 1st party cookie to an ad interaction like a click.
Pros:
Rich Data Collection: Captures detailed events and user properties, allowing for sophisticated audience building and conversion tracking.
Flexibility: Can be configured to fire on specific user interactions, not just page loads.
Relatively Easy Implementation: With Tag Managers, marketers can often deploy and manage these tags without needing a developer for every change.
Cons:
Vulnerable to Ad Blockers: Most ad blockers specifically target the network requests made by these popular JavaScript tags, leading to significant data loss.
Performance Impact: Every tag you add increases the amount of JavaScript the user's browser must download and execute, which can lead to bloat on your website, implicating speed / SEO elements.
Technological Changes: These tags can rely on 3rd party cookies, which remains a legacy identifier to work with. Apple have also been going much further with changes to their browser / OS, such as ITP, which will also double down when Safari 25 drops later in 2025.
Advanced: Client Side through a 1st Party Domain
This is slowly becoming the norm, but historically has always been a thing for the most mature advertisers, specifically those that care about site analytics. Whether this was Adobe Analytics in the past, where you implement it through a 1st party CNAME domain, the big push has now come from Google with Google Tag Gateway, in order to run a container of tracking through a CDN like Cloudflare to help persist tracking a bit more under a 1st party domain.
How it works: Instead of firing a marketing tag in it’s legacy 3rd party domain form, this approach either migrates the tag to a 1st party domain under the advertiser itself where supported, or leveraging a gateway still solution through a CDN, which is effectively the pipe behind the website.
Pros:
Persistency: Leveraging a CDN to handle the network call through a 1st party domain allows more flexibility and opportunity to get pass browser limitations that apply to 3rd party domains.
Ownership: This can be tied to a domain / sub-domain that is already owned by the advertiser, giving more control.
Ease of Implementation: Google have made Google Tag Gateway fairly easy to implement, with more CDN integrations on the way as long as you have admin access on both sides.
Cons:
3rd party context: In the case of a tag gateway, just because 1 domain goes through a CDN doesn’t mean that all post network calls from 3rd party marketing tags also do, meaning there can be still reliance on 3rd party network calls through client side JavaScript.
Technical Implementation: To implement a site analytics solution through a 1st party domain requires a lot more resource / skill than just implementing a tag / container once on a website.
Client Side: Ultimately this remains a client side solution, so can still be implicated by some of the browser side restrictions, that Apple in particular can continue to update on.
Advanced: Server Side Tagging Lite
This is a hybrid approach and a common first step into the server side world. It still uses a client side JavaScript tag, but instead of sending data directly to the ad platform, it sends it to a "gateway" server first. This gateway then forwards the data to the ad platform. Meta's Conversions API Gateway is a prime example.
How it works: The client side tag sends data to a proxy server that you control. This server then communicates with the ad platform's server.
Pros:
Improved Data Resiliency: Because the final request to the ad platform comes from a server, not a browser, it can bypass client side limitations such as ad blockers.
Transitional Step: It's easier to set up than a full server-side implementation while providing some of the benefits, with Meta’s approach effectively a 5 step toggle process that takes < 5 minutes.
Integrations: A lot of ecommerce plugins build off the back of this premise, including Shopify / WordPress / WooCommerce.
Cons:
Still Client-Initiated: The process still starts in the user's browser, so if the initial JavaScript tag is blocked, no data is sent at all.
Capped by Client Side Implementation: If you have a bad client side implementation, you cannot expect gateway to be any better.
Server Side “Cheat”: You can argue this is not really a true server side solution, but more of a band-aid approach.
Advanced: Hashed PII Enrichment
Whether this is done client side or server side, the enrichment of marketing tags beyond a cookie is pretty much commonplace in all major ad platforms. Rather than sending a cookie led signal to an ad platform, the use of PII in a hashed format is now the standard for ad platforms to match on a different signal.
How it works: Primarily for key events like a purchase or lead, where PII may be available to work with, you send across this data to the ad platform via a specific solution (e.g. Google Enhanced Conversions) or enriched call (user-enhanced parameters on a pixel / CAPI solution).
Pros:
Stronger Signal: Hashed PII is much more persistent than a cookie, to allow the ad platforms to work with.
Security Means: Most ad platforms enforce hashing through SHA-256, so that sensitive data is passed in a secure manner.
Stronger Attribution: Matching on PII, specifically in Google / Meta where users are logged in a lot, generates much higher attributed conversions (> 10%) than without using this technique.
Cons:
Trust: There can be some mistrust on whether sending PII in any form to certain platforms is a good idea or not.
Matching: Just because you know who the user is on a PII basis, doesn’t mean they exist in the ad platform to match on.
Match Rates: It can be common to see lower match rates on Google for example which largely matches on gmail addresses and a bit of phone numbers vs social platforms where more hashed PII can match to an user who likely exists on a personal level in those platforms.
Advanced: Server Side through a 1st Party Domain
This is the best in class of server side tagging. The aim is to make use of your own servers, which already likely powering your website content / images, but now for marketing use cases. This server can run through a subdomain of your own website (e.g. metrics.yourbrand.com
). Your server then decides what data to enrich and forward to various ad platforms.
How it works: Multiple approaches exist, from making use of existing server / 1st party data through something like a cloud / CDP to more container led 1st party requests as a vehicle to use for server side tracking.
Pros:
Maximum Data Accuracy: Handy when dealing with ad blockers and browser restrictions that may exist client side
Improved Performance: You can replace many heavy client-side JavaScript tags with one lightweight data stream to your server, improving page load speeds.
Enhanced Security & Privacy: You have full control over what data leaves your ecosystem. You can remove or hash sensitive user information before forwarding it to third parties. Also prevents JavaScript tags taking more information that they need.
Extended Cookie Lifespan: Cookies set from your server in a first-party context can have a much longer lifespan if you want them to.
Cons:
Complexity: Requires technical expertise to set up and maintain.
Cost: Unlike client side tagging where you copy & past some code, there are infrastructure costs to keep in mind here.
Personal Data: Server side tracking particularly works well when you have a lot of 1st party (consented) data to work with. If you don’t, it is less powerful.
Advanced: First-Party Analytics
This is the pinnacle of tracking maturity. It's less about a single tool/approach and more about a data philosophy. Here, you collect all behavioural data into your own first-party data warehouse (like Google BigQuery or Snowflake) using an event collection pipeline. Your website, your server or even going further to your mobile apps. All can send data to this central repository. This becomes your "single source of truth."
How it works: All raw event data is collected and stored by you. How you want to do it can differ by advertiser, where 3rd party tools can be relevant but also building some bespoke is also viable. Then, using server-side integrations, you push clean, curated, and consented data from your warehouse out to the ad platforms as needed, but more powerfully do smarter cross-domain analytics with.
Pros:
Complete Data Ownership: The data is yours. This is invaluable for long-term business intelligence needs.
Future-Proof: You are completely insulated from the whims of browser changes or a specific ad platform's tracking technology. You control the pipeline.
Ultimate Flexibility: You can model the data in any way you choose and integrate with any tool beyond just ad platforms.
Privacy by Design: You can build your entire data model around user consent and privacy.
Cons:
Highest Cost & Complexity: This requires significant investment in data engineering talent and infrastructure. It is a major project, not a simple tag / server setup.
Buy In: To get value from this approach, the entire organisation needs to be invested in using data for decision-making.
Data Ethics: It is still important to respect consent / tracking legalities, even if you do not plan to use it for marketing use cases where relevant.
Closing Thoughts
Simply sticking with client side JavaScript tags is no longer a viable long-term strategy for a variety of reasons when wanting to maximise tracking on a website.
The path forward is clear: move towards the server. For most businesses, a full server side implementation strikes the perfect balance of accuracy, performance and control without the enterprise-level overhead of a full 1st party data warehouse. But to achieve this requires a certain skillset, the right technology & buy in from all the right stakeholders. If we look at specific channels like affiliate marketing or postbacks in a mobile app space, this is not particularly new but adoption on the web side of things outside of affiliates has been slow due to the reliance of legacy ad identifiers like cookies (both 1st / 3rd party) to achieve certain use cases.
But on the other hand, it is imperative to know that whilst server side tagging / first party analytics is now the gold standard for both advertisers & vendors / ad platforms, there are still limitations. It will never be perfect, whether this is for remarketing on an audience segmentation level or measurement in forms of attribution against clicks / impressions.