A B2B prospect list like that works beautifully in LinkedIn Ads. You upload a CSV of companies, and the platform builds an audience out of the people who work at them. There’s huge potential here: B2B advertising is a tough game to begin with, but a list filtered on something real makes pinpoint targeting possible.

Is this even legal?

We never touch personal data, only publicly available company data. LinkedIn takes that company data and builds an audience from the people who work there, and we never see who ended up on it. So the process most likely doesn’t create legal headaches. Even so, bring in a privacy lawyer who is willing to put their name on it.

What does LinkedIn need for a good match?

LinkedIn tries to match the B2B prospect list you hand it against the companies on the platform. Then it puts the people working there into an audience you can advertise to. The B2B prospect list has to include, among other things, the company name, website domain, category, city, postal code, and country. The joker in the deck is the LinkedIn company URL: hand that over and there’s no question which company you’re targeting.

You can only upload a list if it holds at least 300 companies, and no more than 300,000. In Hungary, our home market, we identified exactly 300 blocked healthcare providers, so yes, we do have a Hungarian blocked-healthcare list too.

After the upload, LinkedIn spends two to three days matching your data against its own companies. Wherever a company matches, the people who work there go into an audience you can start advertising to. At the end you get a match rate telling you how well it went. Anything above 80% counts as good, though we often end up with lists above 90%.

What about the other ad platforms?

Unfortunately this is limited to LinkedIn Ads. On the other big platforms you can only upload first-party user data, and to have any of that, the user has to explicitly consent to going on a list.

LinkedIn works completely differently: we’re not using personal data, we’re building a list out of publicly available information. Legal angles aside, the approach probably wouldn’t even be effective elsewhere. Google, Meta and the rest expect personal data, email addresses and phone numbers, and a pile of hello@ addresses scraped off websites is never going to hit a usable match rate. On top of that, the upload itself would break those platforms’ terms of service, so we don’t recommend using it that way.

How did our audit work?

Meta’s blocking is a technical thing. When the Meta pixel fires, it loads a config file. That config holds whether the site is under restriction and, if so, at what level. You can read a domain’s restriction level straight out of the config, as long as the pixel actually runs on it.

So all we need is a domain name to tell whether Meta is blocking it. It isn’t quite that simple, of course, because on plenty of sites the Meta pixel only fires after consent is accepted (exactly as it should). So auditing site after site through an automated process calls for a headless browser that

1. Opens the domain
2. Accepts the marketing cookies
3. Checks whether a Meta pixel is there
4. If it is, checks the Facebook pixel config for a restriction
5. If there is one, collects every data point LinkedIn needs to identify the company, from structured data or wherever else it can find it
6. And finally rolls all of that into a B2B prospect list we can upload to LinkedIn Ads

We put the whole thing together with Claude Code, and Claude supervised the runs as well. The run took about a week. Claude didn’t eat many tokens over that stretch, because the machine ran the script Claude had written. Along the way Claude produced all sorts of statistics about the audit results, and reported in every few hours on where the process stood. So screening prospects like this won’t blow up your AI bill either.

But how did the headless browser know which sites to check?

From public databases. We used two of them, both completely free and nicely structured:

• OpenStreetMap
• Overture Maps

Really it came down to filtering for healthcare providers in a given country. The list that came back already carried some of what LinkedIn needs: company email address, city, postal code. But the most valuable field in these databases is the company’s website. As we showed above, a single URL is all we need to run the audit.

Once we have a company’s domain, we can walk it through the audit steps. No two websites are alike, though, so the headless browser might fail to get past the consent bar, or the site might carry no structured data at all. Then it has to go digging around the site itself, hunting for the Contact page, say, hoping the information we’re after is sitting there.

Those extra rounds are why the audit deserves a reasonably powerful machine with plenty of RAM. Keep an eye on how many sites the headless browser audits in parallel, too.

What is a B2B prospect list actually good for?

We used the process to find out one specific thing about a prospect’s website. The same process runs behind the Metamorph audit page, except there it happens in real time. So when we promote that audit page on LinkedIn to the audience we just built, it’s a safe bet. The people seeing the ad are ones we already know Meta is blocking, which makes the outcome of the on-site audit pretty much a given.

Auditing the websites isn’t mandatory either. You can also build a B2B prospect list straight off the databases above, seasoned with extra data collected from the sites. We’ve put together a global PPC agency list this way, purely from what the databases hold.

Limits

The process has its limits, of course. These databases only list companies with a physical store, headquarters, or site. Fully online businesses, like a lot of PPC agencies, aren’t in there, so they’re not on our B2B prospect list either. With healthcare providers that’s rarely a problem.

Results: how the B2B prospect list performed

So how did the list actually perform? We ran a Thought Leader Ad against that 300-company B2B prospect list of Meta-blocked Hungarian healthcare providers. For anyone less familiar with LinkedIn: that’s the ad format where an employee of the company (usually a leader) writes a post in their own LinkedIn feed, and the company then promotes it. So our Péter wrote a post, in Hungarian, linking to the blog post about Meta’s blocking.

We narrowed the identified healthcare companies further, down to those with 1 to 50 employees, to filter out the largest blocked companies. LinkedIn would also let us filter by seniority, but we skipped that this time.

The result was a 7.69% CTR, which for a plain image ad on LinkedIn is, in our view, a genuinely good number.

The post How We Built a B2B Prospect List for LinkedIn Ads first appeared on DataCrew Blog.

So what happens when everything looked fine on Friday in the Meta campaigns for the dental practice you run ads for, and on Monday you find out that not a single lead came in all weekend? The campaign starts drying up: on Friday it could see the conversions, on Monday it can’t. Nobody changed anything in between. Strange. Very strange. Analytics looks fine, but Meta simply doesn’t see the conversions. Time to start worrying.

What’s going on?

Meta continuously watches the data coming in through the pixel and the CAPI, and infers from it what a given site is about. It looks at the hostname, the page path and the URL parameters. Then it sorts sites into categories based on the URLs it finds. The point of all this is to catch sites that may be sending Meta data they shouldn’t under the Business Tools Terms.

And the terms do include a clause saying you can’t send health information to Meta. So if the Meta pixel fires on, say, bestever.md/ear-nose-throat-surgery (made up), you’re sending Meta health information, plain and simple. Anyone browsing that page probably has a condition that calls for that kind of treatment, and there you have it, prohibited data shared with Meta.

So now you’re on the wrong side of the terms, even though you didn’t really do anything wrong. The pixel is just sitting there on the site. It’s alarmingly easy to walk into a restriction like this, and getting back out is another story entirely.

Which topics does Meta restrict?

Beyond healthcare sites, it restricts gambling, adult, firearms, religion, tobacco and fintech topics, among plenty of others. Customer portals and sites behind a registration gate often get restricted too.

Still, the restriction that causes the most headaches for advertisers is the one hitting healthcare and dental sites. That’s an enormous market, and a huge number of clients can be caught up in it.

Third-party booking systems

Worth calling out: healthcare providers using a third-party booking system may be in luck. If the booking doesn’t happen on the provider’s own restricted domain but on an external URL, those providers can dodge the restriction. Medio, a booking platform popular in our home market of Hungary, carries no Meta restriction at all. The reason is that they don’t use URLs that could trigger one. Take a made-up Medio URL: besteverdoctor.mymedio.hu/doctors?specializationId=86435. There’s nothing in there that reveals sensitive health information. So Meta doesn’t restrict the mymedio.hu domain, and the healthcare providers using it don’t lose conversions.

We’re not getting paid by Medio for the free advertising, sadly. We just wanted to use them to show how the restriction logic works. If you dropped the Medio booking widget into the restricted bestever.md site inside an iframe, you’d have no conversion tracking for Meta. Use the external booking flow and you would.

Our audit

We ran an automated audit against more than 36,000 healthcare sites running a Meta pixel. 41.2% of them turned out to be living with Meta data sharing restrictions.

More than 15,000 of the advertisers we audited are restricted, which is a staggering number. These sites can’t advertise the way their competitors can, the ones Meta isn’t restricting. Flip it around and it’s also an enormous business opportunity for the advertisers who aren’t restricted, because solving the restriction puts you in a much thinner field.

Even after auditing this many sites, no clear picture emerged of why Meta restricts site X but not site Y. Not even when both sites belong to the same Business Manager. Meta restricts one site and not the next in what looks like a completely arbitrary pattern.

What kind of restriction does a site get?

Meta data sharing restrictions come in three levels:

Minimal: core setup

Here Meta only makes page paths and/or URL parameters unavailable. So it found URL parameters it would rather hide. On a financial site, for example, if the loan term is passed as a URL parameter, that typically gets restricted. This restriction level isn’t much of a problem in practice. Just watch out that you can’t define custom conversions and audiences based on the blocked parameters or pages.

Medium: certain standard events blocked

Now you have a real problem. You can’t send Meta just any event. Meta usually blocks the mid and lower funnel events, CompleteRegistration and Lead among them. From that point on you can’t optimize campaigns toward those events, and any campaign already optimizing toward them stops receiving fresh events. Campaigns can still optimize toward events that aren’t blocked, or toward landing page views.

Full restriction

Meta completely blocks data sharing from a site categorized this way. Not even PageView really comes through, or it does in very limited numbers. With a full restriction, the best you can optimize toward is an ad click, which is a long way from a conversion.

What does the advertiser see?

Not much, by default. On some gloomy day, the admin of the Meta Business Manager gets an email saying the site will fall under Meta data sharing restrictions in 30 days. The email looks like every other Meta BM system email: easy to ignore. That’s especially dangerous when the PPC campaign manager isn’t an admin in the Business Manager, because then only the client receives it, and since roughly no client understands what it’s about, the news that conversion tracking breaks in 30 days quietly evaporates. Here’s what the email looks like:

When the Meta BM admin gets one of these, it means that in 30 days conversion tracking as you know it is over. Around the time the email lands, a notice also appears in Meta Events Manager:

Anyone with access to Events Manager who isn’t a Meta BM admin can find out here that trouble is coming, and soon. But I doubt many PPC campaign managers spend much time in Events Manager, so this isn’t an easy way to find out either.

Events Manager is also where you appeal the decision, through the Manage categories button. Only bother if Meta’s automation genuinely got it wrong and put the site in a category it doesn’t belong to. If the categorization is correct, your job is to adapt to the new situation.

What happens after 30 days?

As soon as the grace period runs out, another system email arrives from Meta, and again only the Meta BM admins get it:

And of course the Events Manager message changes too:

Does this mean you’ll never run a proper conversion campaign on Meta again? Thankfully not. But it definitely won’t work the way it used to.

What doesn’t fix Meta data sharing restrictions

The problem is the domain name. Which is exactly why dropping a new pixel into the site isn’t the answer. The domain is restricted, so a new pixel can’t send data from there to Meta either.

Implementing the Meta Conversions API is a great move in general, since Meta gets more data and pays you back with better results. But if you’re doing it to lift the restriction on your pixel, you’ll be disappointed. It won’t lift. Meta categorized the domain name itself, and the Meta data sharing restrictions came with that category.

One thing that could work is registering a new domain, moving the entire site over there, and shaping the page paths so Meta never figures out that you’re running a healthcare site. Kill that idea in the cradle. From a brand and SEO standpoint it’s the worst thing you can do.

What actually fixes Meta data sharing restrictions

The medium and full restrictions above have the same fix. Whether Meta blocks a couple of events or the entire domain, the business impact is roughly the same. Either way your ability to advertise takes a serious hit.

So the goal is to keep Meta from seeing the domain the data comes from, and to keep it from receiving a page path that could trigger the restriction all over again. Which means the Meta pixel has to go, because you can’t control what data it sends: wherever it fires, it hands over the site URL. The answer is a 100% Meta Conversions API setup, where Meta can only receive data through CAPI and the event source parameter in that data is rewritten so you’re not sending a restricted domain, or a page path that would likely trigger a restriction again.

Data sharing through CAPI only

You can build this properly with sGTM or with backend tracking. That can get expensive, and either way you’ll want an experienced team (a Crew ) on the project to solve it. One thing to watch closely during the build: don’t let event match quality sink through the floor afterward, or Meta won’t attribute properly.

In a CAPI-only setup that’s the biggest hurdle to clear. The mere presence of the Meta pixel does a lot of work for attribution, and without it you’re solving a lot of that by hand. Build a CAPI-only server-side setup badly and you’ll fall between two stools: you’ll have measurement, it just won’t be attributable. Given the complexity, a project like this can easily run into several thousand euros if you want data flowing to Meta again. Plenty of smaller businesses don’t have that budget.

And now the ace: Metamorph

We built Metamorph to cut through this Gordian knot. It’s subscription software at €100 per pixel per month plus VAT, which even the smallest restricted healthcare practice can earn back.

Under the hood, using Metamorph does essentially what sGTM tracking would do, only far more simply. Metamorph can step fully into the pixel’s shoes, storing the cookies you need for proper attribution, for instance. It then hands the data to Meta through the Conversions API, using a domain name generated for your site as the data source.

That’s how it gets around the restriction: Meta sees data arriving from a domain it has never encountered, one that isn’t on its restriction list. And since the data goes over without a page path, there’s nothing there to trigger a restriction on the new domain either.

Anyone with solid GTM-focused technical skills can roll out Metamorph, but for a limited time we’ll do the setup for you free of charge. The subscription starts with a free 7-day trial, which is plenty of time to see whether the tool works for you. And you can cancel Metamorph at any point.

Is your site restricted?

Meta data sharing restrictions are a fairly technical business, and they’re hard to spot from a client’s or a PPC manager’s seat. That’s what the Metamorph audit is for. Give it any site and it’ll tell you whether Meta is currently restricting it. Enter the domain name and the tool reports whether the site is:

• Not restricted
• Under a level one restriction
• Under a level two or three restriction this is where Metamorph, or an sGTM setup that solves the restriction, may be needed.

If a healthcare PPC prospect walks through your agency’s door, it’s worth running the Metamorph audit on their site before you send a proposal, so you know what you’re dealing with.

From all of us at DataCrew, we’re rooting for every advertiser and client caught up in this to get out from under it.

Key takeaways

• Meta data sharing restrictions don’t hit the pixel, they hit the domain name itself, which is why a new pixel won’t lift the restriction.
• There are three restriction levels, and the first one isn’t a serious problem.
• Roughly 41.2% of healthcare businesses across the countries we audited are affected. The rate ranges from 21.4% in Belgium to 53.8% in Italy.
• The restriction can be solved with a proper server-side setup or by rolling out Metamorph.

The post Everything about Meta’s data sharing restrictions first appeared on DataCrew Blog.

What is it, and why should you care?

Offline conversion tracking is when you send data from an event that didn’t happen online to your ad platforms. You can optimize campaigns toward those conversions exactly the way you would toward online ones.

Lead gen sites are the obvious use case, but we also know an agricultural supplies store that badly needed accurate tracking of conversions happening over the phone. Sites like these typically have a contact form, maybe a phone number, and possibly a clickable email address. What can you actually measure there with online conversion tracking alone? Form submissions, phone number clicks and email clicks. And those are thin gruel as conversions go:

• Sure, somebody filled in the form, but the submission might be completely irrelevant and never turn into anything;
• There’s no guarantee that someone who taps a phone number actually places the call. In fact most people don’t tap the number at all, they punch it into their phone by hand. We measured it. And even when the tapper does call, there’s no guarantee anything relevant to your business happens on that call;
• Email clicks are an even bigger lottery. That only works if the user wants to fire off an email from their default mail client right then and there, which isn’t exactly how people behave.

Measuring the conversions that come through these channels is fundamental if you want the ad platform optimizing toward real outcomes. In our view, clicks of any kind are micro conversions at best. A form submission at least signals some intent, but let’s be honest, it’s still not the real thing.

So how do you do conversion tracking properly on a site where these are the channels you’d want to build your campaign optimization around? Offline conversions.

How it works under the hood

Offline conversions always have an online prequel. Say the visitor who closed a deal originally landed on your site from a Google Ads campaign. To send an offline conversion, you reference the click ID (gclid) captured when they landed. That’s what lets Ads attribute the later offline conversion to the right campaign. There are three ways to get an offline conversion into Google Ads:

1. Enhanced conversions for leads. You send Ads the hashed personal data of whoever filled in the form (email address, phone number) along with the gclid recorded by the conversion linker. Google stores which hashes go with which gclid. So when it later receives, say, a hashed email address, it can look up the matching gclid and pull the conversion into the right campaign;
2. You store the gclid yourself, and when you send the offline conversion you pass that stored gclid along, which is how Ads knows which campaign gets the credit;
3. Combine the two: send user data on form submission and store the gclid as well, then send both when the offline conversion happens. Google says this is worth a median 10% lift in match rate.

Offline conversions work a little differently on Meta, TikTok, LinkedIn and the rest. The principle is the same though: an offline conversion needs an online prequel. That means capturing click IDs, cookie values and similar identifiers from the visitor’s device, so you can reference them when you send the offline conversion later.

How do you actually measure offline conversions?

This used to take serious development work. Your developers had to store all sorts of IDs, cookie values and consent levels in an internal database. It’s much easier now, because off-the-shelf solutions exist. We built one ourselves, and that’s what we’ll walk through here. Meet Phonevert.

Phonevert integrates with any website regardless of the platform it runs on. Tracking phone numbers or emails takes one line of code in your site, and you can deploy it straight from Google Tag Manager. There’s even a GTM tag template for it. Adding the form to your site is similarly easy, though you may want a developer’s help for that part.

Call tracking

Phonevert uses Dynamic Number Insertion (DNI) to track the phone numbers on your site. Here’s what that looks like step by step:

1. Phonevert finds the phone numbers on your site and swaps them for a unique proxy number. One user gets that number for the duration of a browser session. So when a call comes in on that number, you know exactly which user placed it, because nobody else ever saw that number. The person you’re calling still sees the caller’s real number, not the proxy.
2. The call to the proxy number gets recorded. You can play it back later in the Phonevert interface;
3. The recording is transcribed, and you can read the transcript in Phonevert
4. An AI agent reads the transcript and looks for a conversion. What counts as a conversion is up to you, defined in plain language. Something like ‘an appointment is booked’ or ‘the caller ordered the super vacuum cleaner’
5. If a conversion happened, it goes into your ad platforms referencing the attribution IDs you stored earlier

In the flow above, the completed call itself goes into your ad platforms as an offline conversion, which carries far more information than a phone number click event. And if the AI agent spots a conversion in the transcript, the closed deal goes in as a separate conversion. On top of that, Analytics receives considerably more data, which makes your calls much easier to analyze in detail.

Other call tracking features

There’s plenty of interesting data in a call beyond the conversion itself. With an appointment booking, for example, it’s worth capturing the appointment time, the treatment duration, the product purchased and so on. Phonevert can store these as custom dimensions and pass them to Google Analytics.

Sometimes you’ll want to track calls that don’t originate on your website. Phonevert has a dedicated number feature for exactly that. You get a fixed number that always forwards to the destination number you set in Phonevert, and it still runs through the whole pipeline: recording, AI analysis, the works. Use these numbers for offline placements. Print them on business cards, posters, T-shirts ().

You can also call customers back through Phonevert. Your agent gets a proxy number, and calling it from their own phone rings the customer. Handy for the times you couldn’t pick up.

We took a lot of steps to keep Phonevert’s call tracking GDPR compliant. Before the call connects, the caller hears a notice:

Please note that this call is being recorded by DataCrew Kft. for the purpose of preparing a quote, and will be retained for one year. Our privacy notice is available on our website. If you do not agree, please contact us directly on +36201234567. By staying on the line you consent to the recording.

Conversion tracking follows the Consent Mode v2 flags too. The conversion reaches your ad platforms (or doesn’t) with exactly the consent level the visitor granted on your site.

Recordings can only be played back inside Phonevert, and they’re end-to-end encrypted.

Form tracking

There’s no shortage of form tools out there. You can build forms inside Phonevert too. The app includes a form editor that makes it easy to put together good-looking forms like this one:

(no promises that I’ll actually call you back, this one’s here for the demo

You can receive form submissions by email, or push them into a CRM through a webhook. When somebody fills in the form, gets a callback and turns into a deal, one click marks the lead as converted and the deal lands in your ad platforms as an offline conversion.
Best part: if all you want is offline conversions from website forms, that’s available on the free Phonevert plan, with some limits.

Tracking deals that start over email

Phonevert can also make an email click open a mini form in a bubble instead of launching the visitor’s default mail client. It’s the same kind of form as the one above, so if an inquiry that starts here turns into a deal, that deal can go into your ad platforms as an offline conversion too.

Everything else

Phonevert can pass conversions to Google Ads, Google Analytics, Meta, LinkedIn and TikTok.

We could go on about Phonevert features for a while. There’s the unified, CRM-style customer handling, sGTM support, and the fact that it can work around Meta’s data sharing restrictions, so Phonevert is usable even on sites Meta has restricted, healthcare being the classic example. But none of that matters as much as the main point: with Phonevert, your ad platform can finally see the conversions that actually closed, and optimize toward those instead of the small stuff along the way.

To give you a nudge to try it, the coupon code DCBLOG20 gets you 20% off your first month. Worth a shot

Agency clients can register a dedicated agency account. As an agency you can send invites to your own clients, and you earn 10% commission on every transaction those clients make. The details are on the agency page. Agencies can also log into the Phonevert account of any client they invited, so you can wire up the integrations yourself and see the install code you need.

The post Offline conversion tracking, the way the pros do it first appeared on DataCrew Blog.

Client-side tracking means the tracking code runs in the visitor’s browser and hands data off to an external analytics or advertising platform from there. Dropping an Analytics tag or an ad platform’s pixel onto your website is exactly this.

Server-side tracking, by contrast, brings a server you own or rent into the loop and sends the data on to the destination platforms (Analytics, Meta, TikTok and friends) from there. Which means a plain server log technically counts as server-side tracking, just as much as a lavishly built server-side Google Tag Manager setup does.

When do you need server-side tracking?

When you want to cut your ad spend

Cookies are in the crosshairs in modern browsers. Third-party cookies are already blocked outright by plenty of them (Safari and Firefox, for instance), and even first-party cookies get their lifetime cut short in certain cases. Server-side setups don’t necessarily use cookies at all, and sometimes they don’t even touch the visitor’s browser, which makes for far more reliable and accurate delivery to the ad platforms.

And ad platforms do their best work when they get plenty of data. They need to know how the people they send to your site actually behave there. When the system sees that one visitor segment converts much better than another, it goes looking for more people like that segment, and your conversion rate goes up. So the path to more conversions runs through more data, because that’s what lets the AI sharpen its ad delivery.

More data, then, lowers your cost per result and raises the number of conversions you actually measure. By how much? It depends heavily on your audience, but Meta reports a 13% drop in cost per result and 19% more measured conversions on a global average.

When you want more accurate data

If you spend time in Analytics, you’ve probably noticed the gap between users and new users getting smaller, and the share of direct traffic creeping up. Same root cause: some browsers are shortening cookie lifetimes. Analytics identifies your visitors with a first-party cookie that’s set to expire in a year by default, but Safari, for example, knocks that down to seven days.

Which means if your visitor comes back on day eight, they show up in your reports as a brand new user. And if that second visit doesn’t come from a campaign but does produce a conversion, the conversion lands under direct traffic, no matter what data retention setting you’ve got in Analytics.

A well-built server-side setup can get you all the way to 100% data accuracy. Picture running an online store and seeing exactly as many transactions and exactly as much revenue in Analytics as you see in your admin panel. That sounds like science fiction if client-side tracking is all you’ve known. It isn’t.

When you want a faster site

Server-side setups don’t just improve data accuracy, they’re good for site speed too. The reason is simple: you’re no longer loading a pile of external scripts. Instead you send requests to your own nearby server. That speeds up page loads, which is good news for your SEO as well.

When you want more control over the data you collect

Privacy is often the reason a server-side setup gets built in the first place. Your server can double as your own proxy, filtering data before it ever reaches your analytics platforms. We’ve had clients who wanted to see the value of every input field on the site in Analytics, for instance. Those fields can contain personal data, which you’re not allowed to send to Analytics. Your own server can strip that out.

We’ve also run into a legal team that would only sign off on Analytics for a site if the data carried no IP address, since they treated it as personal data. In that case you can build a setup where the IP goes to Analytics as 0.0.0.0. Our client had to give up IP-based geo data, but in exchange the legal team cleared Analytics to run without consent, which did wonders for campaign attribution.

Server-side tracking also opens the door to feeding profit figures into Analytics and your ad platforms. The idea is to use the profit realized on the products instead of the revenue. For an ecommerce site the revenue value is normally the total value of the purchase. Instead, you can pull the profit margin of the purchased products from a database and send that on to your destination platforms.

That makes your ROAS real. You’ll see exactly how much profit each campaign brought in. And since your margins are a trade secret, it matters that the competition can’t sniff them out. Server-side handles that: nothing about your profit figures is visible on the client side.

Off-site events

Everything above is a case where server-side tracking adds something on top of client-side. But there are things you simply cannot do without a server-side setup. Those are the events where your customer isn’t on your website at all, and you still want to measure something about them.

Subscription models with recurring payments keep getting more common. When the card gets charged, the visitor isn’t on your site, so there’s no client-side code to run. Server-side lets you push that revenue into your platforms at the moment the charge goes through, attributed to the right campaign and source, exactly as if the visitor were right there. Their measured lifetime value can grow whether or not they’re on your site.

Refunds are another case for server-side. If you want your numbers to be honest, revenue isn’t enough, you have to handle cancellations too. Those rarely happen while the customer is browsing your site, and server-side deals with them without breaking a sweat.

Think about what that lets you automate: an online store voiding an order the courier delivered but the customer never picked up. Or a bank transfer that never arrives by the deadline. Getting cancellations into the data is fundamental if you want a realistic ROAS and realistic revenue in your analytics.

Server-side is a powerhouse for lead gen sites too. If all a visitor can do on your site is fill in a form, and the actual deal closes offline, you still don’t have to give up revenue values. It gets really good when you pipe every meaningful lead milestone from your CRM into Analytics, so you can see the campaign source of every lead at every status, with a value attached. Compare that to treating a form submission as your conversion. It’s night and day.

Fine, but is this legal?

Of course. Server-side tracking isn’t about measuring whatever you like without the visitor’s consent. It’s about actually having the data when they do consent. You aren’t measuring anything different server-side than you would client-side, you’re just measuring it differently.

Server-side tracking isn’t a black-hat tool. It just helps you get the most accurate version of the data you’re already entitled to.

How do you roll it out?

So there are plenty of situations where server-side tracking is useful, or flat-out required, if you want data you can work with. Time to talk about how you actually build it.

A lot of very different setups go by the name „server-side tracking”. It’s server-side tracking when your hosted store platform supports Meta’s Conversions API (CAPI) out of the box, and it’s also server-side tracking when a request fired from your backend delivers data to Analytics’ servers. With that many ways to build it, the price and the accuracy vary just as widely.

Given all those options, the job is finding the setup that fits your environment and satisfies your appetite for data. Not every setup can be adapted to every stack. So rather than getting lost in the maze, it may be worth bringing us in to handle the rollout.

Your options for building server-side tracking

Once you’ve decided to go server-side, you have several routes.

sGTM

The most common option is server-side Tag Manager. The upside is the same as with client-side Tag Manager: one data source can feed several destination platforms.

What you’ll need for an sGTM rollout:

• A server you own or rent
• GTM
• Changes to your domain records

A server you own or rent

Your sGTM can run on a dedicated server you own or one you rent. Clients often figure that since they already run their own servers, they’ll host the sGTM server themselves too. In practice that rarely happens. Self-hosting usually works out considerably more expensive than renting. And it isn’t just the build cost: running the server, maintaining it and the staffing that comes with it are all recurring.

It doesn’t help that Google shares very little about manual server setup, to the point that there aren’t even published minimum system requirements.

In practice we host sGTM containers on rented infrastructure every time. Google Cloud is one option, and so are providers that specialize in exactly this. We usually recommend Stape.io. Their pricing is clear, predictable and cheaper than the Google Cloud route. On a low-traffic site sGTM hosting can even be free, and at moderate traffic it won’t run you more than €50 a month. You can work out the exact number with the calculator on their site.

GTM

Before you roll out sGTM you’ll need GTM, assuming your tracking was built with native code up to now. Here’s why: the client-side GTM sends the data into the server-side GTM, and it travels on to the destination platforms from there. So you need the client-side container too.

Changes to your domain records

To make your sGTM as resistant as possible to ad blockers, the container should live under your own URL. So if your site is example.com, the sGTM container can run at server.example.com, which means requests land on your own hostname. You create a subdomain like that by editing your DNS records.

Better still is putting sGTM on a page path under your existing hostname, say example.com/server. In that case a service worker on /server forwards the request on to server.example.com.

Picking the right subdomain matters. Steer clear of names that give the game away, like gtm.example.com or tracking.example.com, or the name alone will trigger an ad blocker and all your work goes out the window.

Pros and cons

An sGTM rollout takes minimal developer time and buys you a lot of credibility with the ad platforms. You can build server-side tracking toward a long list of destinations with it. Meta, TikTok and X CAPI become available, and data can flow server-side into Google Ads, Analytics and plenty of other platforms.

The downside is that client-side code still kicks off the handoff, so there’s no 100% guarantee that something won’t block it along the way. It also carries a recurring cost. Not a big one, but you have to budget for it.

Backend tracking

You can also send events straight from your backend to the destination platforms’ servers, with no server-side GTM in the picture. The advantage is that the visitor’s browser plays no part in the handoff, so 100% data accuracy is on the table. It’s also a one-time build cost with nothing recurring.

The downside is that it’s rigid. Without GTM in the middle, every change means calling a developer again. And you have to build the tracking separately for every destination. If you want Meta and TikTok CAPI alongside Analytics, that’s three integrations and three development projects.

Since your backend is what sends the data, the events arrive carrying your server’s location. If you need accurate geo data, this isn’t the setup for you.

Backend tracking still needs code running client-side, too. If something blocks that client-side code, your backend events will still reach the destination platforms, but they’ll be useless for campaign attribution. In practice that means the conversion shows up in Analytics with a source of (not set), and Meta won’t attribute it to a campaign at all.

The hybrid

You can roll out server-side GTM and still send your key conversions from the backend. This combines the strengths of both: sGTM sharpens the accuracy of your client-side tracking, while the events you treat as real KPIs arrive from the backend, so 100% accuracy is achievable. As a bonus, you only build one integration on the backend and it can feed every destination.

This is the genuinely advanced option, and it’s what most of our clients end up choosing.

Gateways

The simplest and cheapest way into server-side tracking is a gateway. Each gateway forwards data to exactly one destination, so you’ll need as many gateways as you have platforms. The upside is the price: a gateway runs about €10 a month at stape.io, our preferred provider.

For that money you get a fairly generous event cap, enough to cover a mid-to-high traffic site. Accuracy matches sGTM, which means the handoff can in theory be blocked, since this isn’t backend tracking.

Setting up a gateway is very simple. With the right access in hand it’s a few minutes of work.

If you need more than one or two destinations, it’s worth thinking about sGTM instead. Depending on your traffic it can come out cheaper, and it’s a far more flexible ecosystem.

On our own site we run Google Tag Gateway, because we don’t need any other destination, we just want accurate numbers on our own traffic.

Gateways come with the same geo caveat: you’ll be waving goodbye to precise location data. Analytics shows you the server’s location, which for European visitors usually means whichever nearby data center the provider runs. If geo data matters to you, we’d steer you away from gateways for the same reason we steer you away from pure backend tracking.

The bottom line

Rolling out server-side tracking is a broad term that can mean a lot of things. It can mean a gateway for a few euros a month, or a development project running into the thousands. What matters is that even a cheap solution, implemented properly, moves you a long way forward on data accuracy and attribution. There’s always room to do better, of course, so if accuracy is critical, there’s no ceiling on how good a setup you can build.

In 2025 server-side tracking is essentially unavoidable, even in segments that used to get by on client-side alone. But execution matters just as much:

• Work with what your site already gives you;
• Be clear about the measurement goal;
• Be honest about the resources you have

Build it badly and you won’t have more data than before, you’ll just have an extra line item. That’s why, if you’re about to take on a server-side project, we’d suggest you ask us for a quote and let us help.

We were the first agency in Hungary to earn Stape partner status, and there still aren’t many of us. When it’s needed, we can back our clients with priority support and a lot of hard-won experience.

The post Everything about server-side tracking first appeared on DataCrew Blog.

Think back to the not-so-distant past, when you could open a website without reading a wall of text about cookies, storage and processing purposes, and then making an important decision on a screen like this one:

It really wasn’t that long ago. The whole circus kicked off in 2018, when the GDPR took effect. It introduced the roles of data controller and data processor, and it put a long list of obligations on service providers, including the right to have your personal data deleted. The big players didn’t get a free pass either, and Google had no interest in collecting fines, so it had to move.

Enter Consent Mode

One thing you have to understand up front: when Google built Consent Mode, it wasn’t primarily thinking about its customers or its advertisers. It needed to stay out of trouble, and that’s why the thing works the way it works.

Nobody, ever, promised that rolling out Consent Mode makes you GDPR compliant.

So no, implementing Consent Mode does not guarantee that your website or mobile app complies with the GDPR. Getting the details right takes a privacy lawyer. We can’t give legal advice and we don’t want to, so please read everything below with that in mind.

What is Consent Mode?

The idea behind Consent Mode is that Google tags fire according to the consent the visitor actually gave. Tags support several consent types:

• analytics_storage
• ad_storage
• ad_personalization
• ad_user_data

There are a few more beyond these, but they don’t affect how Google tags behave. We call these consent signals flags. Each flag has its own job, and if you want to go deeper, Google’s documentation on consent types is worth a read.

The short version: if you want the visitor to show up in Google Analytics, you need analytics_storage. If you want to use that visitor for advertising that actually performs, you need the ad_ flags accepted too.

When do you actually need this?

Pretty much always. If you advertise on Google, it’s non-negotiable. Even if all you run is Analytics, you still want it. And this applies to your mobile app just as much as your website. Your app needs a consent screen and a proper Consent Mode implementation, exactly like the web does.

Skip Consent Mode and Google will make your life harder in a lot of small ways: remarketing becomes impossible, campaign performance drops, and you end up watching your competitors pull ahead.

Google is quite happy to reach for that stick when consent isn’t implemented properly on your site or in your app. Sure, there are loopholes, like simply telling Google that the visitor granted full consent. But take our word for it:

It’s just not worth it.

Once Google penalizes you, getting good results out of the platform again is genuinely hard. When a site lands in an enforcement cycle, you have to fix the setup and then appeal through a form. That triggers another review, except now every little mistake gets picked apart, and it stays that way. Those post-appeal reviews aren’t fast either. For a larger company, one of these episodes can easily cost tens of thousands of euros.

Consent Mode isn’t Google’s only requirement for advertising, by the way. There’s a checklist that spells out exactly what boxes you need to tick before Google considers your site or app compliant.

We’ve seen a case where Consent Mode worked flawlessly on a website, but Google noticed the site had no link to its privacy page and penalized our client with worse performance anyway. So take the holistic view: get the consent banner right, make sure Consent Mode respects the visitor’s actual preferences, and work through Google’s checklist.

Advanced vs. basic implementation

Deciding to implement Consent Mode is just the start. The safest approach from a legal standpoint is to send Google nothing at all until the visitor makes a choice. That’s the basic implementation. It’s probably the most defensible option legally, but it’s the weakest one for data. You’ll know nothing about your visitors until they grant „adequate” consent.

The advanced implementation, on the other hand, sends data to Google both before consent is given and when it’s denied. That data takes the form of cookieless pings. They contain no personal data, but they help the system model conversions from visitors who declined.

Compare the two and modeling is the main difference. With basic mode, the only conversions you’ll see in your reports are the ones that were actually measured. With advanced mode, Google tries to model certain metrics for the visitors who said no. That’s a genuinely useful feature, because when modeling kicks in, the platforms tend to make pretty accurate guesses.

Keep in mind, though, that this is modeled data, not measured data. It is not an exact number, no matter how confidently Analytics or Ads presents it. And modeling needs volume to work. Realistically, only mid-sized businesses and up generate enough declined consents to meet the thresholds. Below that, advanced Consent Mode adds nothing to your Analytics reporting.

If you work with raw data, though, and export your Analytics data to BigQuery, advanced Consent Mode can be a real win. Those exports include the visitors who declined analytics_storage, anonymized behind pseudo IDs.

The consent banner

Which cookie tool should you pick?

Once you’ve settled on an implementation mode, you need a consent tool, a CMP, for the visitor to give consent through. You’d think this part is easy. It isn’t. Look for a Google Certified CMP, essentially off-the-shelf consent tools that support Consent Mode.

We’re not here to sell you on any particular one. What matters is that the tool shouldn’t block things automatically. You want to build the blocking logic manually. Here’s why: your legal team might be fine with a particular setup, and automatic blocking can make that setup impossible. Manual configuration gives you far more room to move.

The tool also needs to be properly customizable. The technical details matter enormously, but your acceptance rate only goes up when the banner looks right, meaning a high share of visitors grant full consent.

Consent banner design

Design, or rather layout, is a big deal. You can do everything right, roll out Consent Mode, tick every box on Google’s checklist, and then strangle the whole thing with a banner that converts terribly. That’s an own goal. You’ll be beautifully compliant and your ad platforms will have no data.

Three things matter in a consent layout:

• The visitor should give consent on the landing page
• The banner should cover as much of the page as possible
• Guide the visitor toward the choice that works best for you

Let’s take these one at a time.

Consent on the landing page

Getting consent on the landing page is critical. Why? Because if it happens later, the campaign parameters can be gone by then, and the visitor ends up in your analytics as direct traffic.

Picture this. A visitor arrives with XYZ UTM parameters. There’s a tiny consent banner on the landing page, they ignore it, but they like your product and start moving through checkout. On that first page the UTM parameters were still in the URL. On the next page they’re gone. If the visitor accepts consent there, it doesn’t matter how far down the funnel they go, they’re a direct visitor now, because there were no campaign parameters in the URL at the moment consent was granted.

You can pass campaign parameters through internal links alongside Consent Mode, which works around the problem of visitors consenting somewhere other than the landing page. But it breaks plenty of sites, so test it seriously before rolling it out. And these days navigation doesn’t happen through links alone, while this workaround only covers links.

The full-screen consent banner

The consent banners that convert are the ones that cover the entire page on arrival and force the visitor to choose. From a UX standpoint that sounds obnoxious, but it’s the best practice, and the reason is the point above: you want complete data in your analytics from the very first touchpoint.

A lot of people balk at a full-screen consent banner, but at this point it’s so common that visitors click the friendliest-looking button on reflex. Sure, there are sites where it’s hard to pull off, but aim for it.

Guiding the visitor toward the right choice

Now we’re in CRO territory. The goal is to get the visitor to grant the highest level of consent. Pre-selected consent levels are one way, assuming your legal team allows it. You can give the accept-all button a distinct color and shape, or even drop an emoji on the button that leads to the outcome you want. The sky’s the limit. Heatmap analysis and A/B tests are fair game too when you’re dialing in the perfect layout.

Take a look at this consent banner, for example:

Just about everything that can be wrong here is wrong:

• A white consent bar on a white page, covering essentially nothing
• The copy doesn’t meet Google’s checklist
• The toggles default to off, so hitting save grants nothing at all, exactly like ignoring the banner or clicking „Reject all”. Two of the three buttons leave you with no consent
• The accept-all button sits in the middle instead of at the top
• The buttons are too close together. Even a visitor who wants to give consent can miss and end up giving none

For comparison, here’s another consent dialog:

It’s pretty obvious what behavior we’re steering the user toward here.

We measured a 16% acceptance rate on the first consent tool and over 94% on the second. That’s an enormous gap, and we got there while still giving users a real option to decline.

Every other ad platform

We don’t want to leave you thinking Google is the only platform that needs consent to function. Every ad platform’s tracking code should fire, or not fire, according to the consent you did or didn’t receive. We focused on Google’s Consent Mode here because it’s the largest ecosystem, and because Google Analytics and Google Ads are more or less unavoidable.

That said, plenty of other ad platforms have their own consent handling. We usually run the rest the way we’d run basic Consent Mode: if the visitor consents, the tag fires, and if not, it doesn’t. The Meta pixel, for example, typically runs on marketing consent. But again, the exact behavior should follow what your legal team asks for. Bing Ads is worth a mention too, since it needs a Consent Mode setup similar to Google’s to work properly.

Turn the cookie problem into money

Ignoring consent and measuring everything without permission can land you in legal trouble. The GDPR is not optional, and mishandling visitor or customer data can cost you up to 2% of your corporate group’s revenue in fines. For a larger international company that’s several million euros, so it isn’t worth the gamble. Especially since, as we’ve seen, a good implementation means you barely have to give up any data.

And the rest of the world is catching up fast. The UK GDPR, Switzerland’s revised FADP, Canada’s PIPEDA, Australia’s Privacy Act and the growing pile of US state privacy laws all push in the same direction. If you sell across borders, the strictest regime in your footprint is the one you should be building for.

Exactly how much data you’ll give up, call it the cost of doing business legally, depends on where you’re starting from. If your site or app doesn’t account for consent at all today, expect less data after you implement it. The good news is that there are ways to make that drop as painless as possible.

If you already account for consent, the work is about finding the pieces that can be improved, meaning more visitors granting full consent. One thing is certain: the more data your ad platforms get, the better they perform, and they’ll pay you back in revenue.

The big drawback of off-the-shelf CMPs is the subscription model, and the prices sting. We built our own, which we can deploy on your site for a one-time fee, so there’s no recurring cost. It’s 100% Consent Mode compatible with a full-screen design, fully responsive so it looks right on mobile too. Another advantage over off-the-shelf tools: it loads no external scripts. All the code lives in the page source, so it loads instantly, which is a nice win for SEO as well. If our CMP sounds interesting, get in touch for a quote.

The post Everything about cookie consent first appeared on DataCrew Blog.

About what we do

We know our line of work can look like a dry technical sport from the outside. We see it differently: analytics is a challenging craft that gets better (and harder) by the day. No two analytics people are alike, and no two setups are alike either. There are industry standards, usually dictated by Google, but the road to the finished implementation is different for everybody. We’re pretty sure any given task would be solved a different way by every practitioner out there, so there’s no guarantee a setup will ever be built exactly the way you’d think through it. What we really love about this job is that the goal is always exact. Once something is measurable, you’re done. Setting up measurement is a project, not an ongoing effort. Which means both the start and the finish are something you can plan.

We think analytics is cool.

Is this going to be too technical for me?

We know the deep technical details are mostly interesting to fellow practitioners, and nobody should be expected to live inside digital analytics the way we do day after day. This content is written first and foremost for agencies that also work with analytics and for freelance analytics specialists, of whom there are strikingly few anywhere you look. It’s no big secret that we’re a digital analytics agency ourselves, and we make a living from client work. Feel free to ask for a quote on our site and we’ll help you adapt the solutions we cover here, or the ones we haven’t covered yet, to your company’s website or mobile app.

Good luck with whatever brought you here, whether you’re a client, just browsing, or an enthusiastic amateur looking to make your own measurement better. Don’t worry, we’ve got you.

Stick around, and follow us on LinkedIn and GitHub too.

The post Hello world! Why we started this blog first appeared on DataCrew Blog.