Your data will never match 1:1 across platforms, and that's fine.

It’s ok for data to be different, as long as it’s consistently different.

On my mind this week

There’s something fundamentally human about wanting a single version of reality.

Numbers feel like they should be objective, unlike opinions or feelings, a number seems like it shouldn’t be arguable. And in most aspects of life, that instinct is correct.

If your bank statement and your receipt don’t match, one of them is wrong, right?

We’re conditioned from early experiences with numbers that disagreement means error. So, we carry that reflex into our day to day work almost automatically.
And, unless you work in a finance or revenue focused role, that instinct might cause you issues in how you work with data, and how you understand it.

Exposure to different data in different formats (like dashboards, interfaces) definitely compounds that. For example, when you stare at a dashboard long enough (and you guys know how much I “love” dashboards), you see sessions next to clicks next to revenue, all in the same font, the same grid, the same color scheme, your brain starts treating them as commensurable.

The interface flattens what is actually a fundamentally heterogeneous set of realities into something that looks like a single coherent system.

Over time you tend to forget that the visual proximity was a design choice, and not really a statement about the data’s compatibility. (I know I do, lol)

And don’t even get me started on analytics tools, because they have so little incentive to remind us about that. Nobody markets their platform leading with “our data model is completely different from everything else you use.”

Currently, the costs of switching that every platform is marketing are “easy, fast, and simple” and completely hiding underlying complexity.

Ultimately different tools measure different things, collect data at different moments, handle identity differently, and apply their own logic to attribution and deduplication, much of which isn’t visible to us at all.

You see numbers popping up in the interface when in reality they are the output of a long chain of assumptions and trade offs that vary from tool to tool. Different data schemas, different data collection mechanisms. There’s also a deeper layer around accountability, and this is what affects most of us that have to report on numbers, or are responsible to produce them.

In a meeting, a single number is defensible to our stakeholders. Two conflicting numbers make us look like we don’t know what’s happening, or what we’re doing, even if that difference is perfectly rational and reflects genuinely good measurement practices.

So…the pursuit of matching numbers becomes a way of outsourcing confidence to the data, rather than developing our own judgment about what it means.

And what is ironic, if you ask me, the people chasing number parity are often the ones who trust the data least, they just want it to agree with itself so they don’t have to sit with ambiguity. And if that doesn’t happen, it’s our fault as analysts.

I think we should be more comfortable (in general) with numbers not matching and understand the underlying data collection processes well enough to know that a gap often reveals something useful about how different tools measure reality.

That’s why in this edition of my newsletter I decided to double click on the question “do the numbers match?”, and discuss with you all about how each tool is telling a consistent story with itself over time, and whether the picture they’re collectively painting makes sense.

This newsletter edition is written in partnership with Stape.

It’s ok for data to be different, as long as it’s consistently different.

It’s 2026 but yet, here we still are :)

Because I want to start with an example, I’m laughing on the inside because for someone like me who avoids GA like plague 😂, I still remember a lot of conversations and use cases I’ve been part of over the years. #NeverForgetten

So, let’s see. If you work across teams, you know very well the “fun” of the cross platform numbers conversation. GA says one thing, Google Ads says another and then you might have an A/B Testing tool that says something else completely just to keep things interesting.

Ultimately your stakeholder wants a single figure for the board deck.

The analytics, paid media and CRO teams have stopped trusting each other’s dashboards a long time ago, and somewhere in the middle of that back and forth, actual performance decisions tend to stall, or if they’re done, they’re done poorly.

For example, Google Ads has MANY reasons to show more conversions than GA, because its attribution model directly affects whether you keep spending.
And the numbers were never going to agree in general, however we still see many people trying to close that gap, which probably is the wrong problem to be working on.

Simo Ahava called it a while back, I don’t remember exactly his words, and the episode of Standard Deviation Podcast it was said in, but he said something along the lines of:
“It’s ok for data to be different, as long as it’s consistently different.”

And ever since he said that, it completely changed how I think about these “data mismatch” scenarios.

IMO, this should be the framing that leads to productive measurement conversations, not “why don’t these match” but “has the relationship between them changed, and why?”

As said above, GA and Google Ads are just different. They use different data schemas, different collection mechanisms, and different attribution models. Layer on top of that consent mode, ITP, ad blockers, and the privacy infrastructure we all know and “love”, what do you really get at the end?

Well, first of all, globally, the % of users accepting tracking cookies is not high or growing (we’ll cover that later) which means the majority of your traffic can be either invisible to traditional tracking or showing up as modelled estimates rather than observed behavior. (not even going to into how the customer journey completely changed, zero-click scenarios, let’s put that aside, for now…)

This means that the data you’re comparing across platforms is, in many cases, two different partial pieces of the same reality.

AAAAND, we haven’t even touched on bots yet, thanks Jason Packer for the reminder. Because on top of all the consent and privacy stuff, automated traffic now accounts for more than 53% of all web traffic globally (check out this report from Imperva), meaning the majority of what hits your site isn’t human to begin with. Each platform applies its own logic to filter that out, and “shockingly”, they don’t agree on what counts as a bot. So the gap you’re staring at between GA and Google Ads? It’s not only attribution models doing their thing anymore, but also 2 platforms with completely different opinions on how many of your “users” were real.

This is what Jason shared with me:

While all analytics tools have some amount of bot blocking, no two tools are going to agree what parts of your traffic was bots. Some tools only block very obvious bots that declare themselves via User-Agent. Some tools block based upon other signals like IP reputation, user behavior, or browser inspection like fingerprinting. None will get all the bots, and none will exactly agree.

Also, let’s not forget, starting June 15, 2026, Google is separating the controls that govern data use in GA and Google Ads entirely.
Google Signals in GA will no longer act as a governance layer for ad data, and ad_storage in Consent Mode becomes the single authority for what reaches your Ads account. The direction of travel was quite clear here given that Google had already tightened enforcement of the EU User Consent Policy, cutting personalization for accounts not passing correct EEA signals.

But, let’s take a step back here.

None of this is an argument for accepting bad data passively.

A consistent 5% discrepancy between GA and Google Ads every month is a known quantity. You document it, you account for it, you make decisions with full awareness of it. A gap that’s 5% in January, 14% in February, 30% in March, and back to 5% in April is a different story entirely. Something changed, either in your tagging, your consent rates, your traffic mix, your implementation and that instability is what actually needs further investigation.

We’re working with less data than we used to, and that’s just the reality

The signal environment your campaigns are running in is materially thinner than it was even 2 years ago. Cookie consent rates have dropped roughly 15% in a single year, landing at a global average of 39%. And, there are markets like France, Germany where the acceptance rate is even smaller.
So, once again, a meaningful share of your traffic is either invisible to traditional tracking entirely, or showing up in GA as modelled estimates.

Now, what makes this interesting is that most teams believe they’ve addressed it.

67% of Consent Mode v2 implementations contain technical errors, and only 23% actually recover the 65% of lost data the setup theoretically promises.

This means that the org has done the work, the implementation looks correct on the surface, but, the data is still degraded in ways nobody has fully traced. And you only find out when you actually try to use this data for something :)

So, that gap between perceived and actual signal quality is where a lot of misplaced confidence in dashboards lives.

What this means for how enterprise marketing teams actually make decisions

Once again, the instinct when data is “bad” is to chase the technical fix.
Which sure, can be a fair assumption as with many things in “analytics”, but incomplete if the conversations don’t reach the layer where the business actually operates: how decisions get made, what they get made on, and who’s accountable for the quality of the inputs.

For example, when your conversion signals are incomplete, your bidding algorithms are learning from a biased sample. Google’s smart bidding is trained on what you feed it, and if a meaningful share of your converting traffic isn’t observable, the algorithm optimizes toward a proxy for your actual customers rather than your actual customers. Nothing new here.
But, that will show up in ROAS, in audience quality, in the gradual drift of campaign performance that’s genuinely hard to attribute to any single cause.

This is a compounding business (not technical) problem that gets worse the longer signal degradation goes unaddressed at the right level.

The budget justification problem sits right next to it. When measurement is fragmented across teams, with different KPIs, different measurements of success, and ultimately different tools, the performance conversation becomes a negotiation rather than a presentation. Something along the lines of: What should we show to leadership and what can pass as good in front of them?

Also, there’s another question I think the industry is not really interested in answering, or avoiding. For instance, if we have less quantitative signal, are we leaning enough on the qualitative layer? (and no, I’m not thinking of plugging a LLM here lol)

Things like customer interviews, sales team input, post-purchase surveys, CRM data, session recordings. Sure, none of these replace conversion tracking, 100%, but all of them carry signals that don’t require a cookie.

From my experience, when the quantitative picture is incomplete, the organizations making better decisions are the ones triangulating it with qualitative input rather than just trying to recover the lost data points.

And listen, I’ve been talking about first party data for so many years, before it was cool lol

So, yes, first-party data belongs in this conversation too. And it should have been for AGES.
I would love to think and say, based on the years I’ve spent talking about it, that most companies have solid 1p data strategies, and it’s never-ending in audiences, and personalization flows, and all that good stuff, but tbh, sadly, this is still not the case. Not sure what else is needed to happen in our industry for companies to fully commit to this approach….

But, I will say it again, If you can’t observe what users do on their first visit, you can observe what your customers tell you directly through account creation, preference centers, loyalty programs, email engagement, and every touchpoint where the relationship is consented and first-party by design.

Is server-side the save here?

WELL, it depends on how you’re looking at the problem. I guess this is a more useful answer than either “yes, migrate everything” or “it’s overhyped.”

There is so much content and not all of it good, or realistic about how server-side works, especially in a business context aaaand, especially on LinkedIn, lol.
And I guess in this series of articles I’m doing with Stape, I’m happy that we’re able to work together to demystify what server-side can or cannot do from a business growth POV. And I love their transparency and willingness to work together with me on doing so.

So, even if you go/are server-side, your client-side JavaScript still fires in the browser to capture events. Page views, clicks, form submissions, etc, all of it still originates on the device ¯\_(ツ)_/¯

What server-side does is route that data through a server you control before it reaches any vendor endpoint, so instead of the browser firing directly to Google or Meta, it sends one request to your own subdomain and your server handles the distribution. That’s it.

Now, I know I’m not a server-side expert, nor I want to pretend to be one, but I know enough to be able to tell you that, sure from a business perspective, using it does give you real benefits like control over data enrichment before it reaches platforms, fewer outbound requests from the browser, and first-party cookies that are considerably more durable under browser restrictions.

Ad blockers? Well, it depends. Typically ad blockers work by blocking requests to known third-party domains; because server-side sends requests from your own subdomain, it reduces signal loss from ad blocking.
But that only helps once the event has already been captured. If a blocker prevents the client-side script from loading in the first place, there’s nothing for the server to receive, and no recovery possible from there. So, yeah...

Server-side improves signal reliability compared to browser-only setups, but it doesn’t eliminate blocking or recover all lost data.

A cool use case here, mentioned briefly above!
Because server-side sits between your site and your vendor endpoints, you can enrich conversion events with data from your CRM or data warehouse before they reach Google Ads (profit data, customer lifetime value, new versus returning customer status) and send a modified conversion value that reflects actual profit rather than revenue.

That means for our Google Ads example, that Smart Bidding can be trained to optimize for what the business actually cares about, not just the transaction value that fired on the confirmation page.

NOTE HERE: For enterprise teams running significant spend, the shift from ROAS optimization to profit optimization is one of the highest leverage moves available right now, and server-side infrastructure is what makes it technically feasible at scale. I’ve seen this work really well for industries like retail, hospitality, etc.

Also worth noting here that many performance / paid media teams might not have an incentive to do this right away because optimising for profit also exposes performance issues, and the numbers ofc might be lower.. Something for another newsletter 🙂

BUT…

What server-side doesn’t touch is consent. If a user hasn’t agreed to be tracked, the server in the middle doesn’t change that.

And, as in my previous article in collaboration with Stape, I want to bring Dan Murovtsev, Product Manager at Stape to describe the differences between client-side/server-side tracking and what actually can be done with server-side in this context because most people think, well my platform data doesn’t add up so, I guess I need to go server-side.

Server-side is not a consent waiver. It’s 2026 outside and we still have to repeat this mantra at least a couple of times per week. Just because you can override pretty much anything on the server, that does not necessarily make it OK (or legal) to do so.

Not only do you still care about consent, you actually have to be extra careful, since your non-Google tags will not inherit consent mode v2 data natively. Which means you need to make sure your server tags only fire when they have corresponding consent. Remember, in addition to producing API calls, those tags also return Set-Cookie headers back to the browser, which is visible.

As Juliana mentioned above, enrichment is the name of the game these days and, what I feel is overlooked is that a profile sitting in your CRM did not necessarily give you all the possible consent, there’s variations, I may have consented to analytics only. Something to think about when enriching. Consent choices may suddenly become very important fields in your CRM entry.

That being said, I feel like the biggest consent impact is still in the browser, however much regulation is there, banner UX (and I don’t mean a shady one) is king. Banner placement, colors, annoyance level do influence accept/reject rates heavily. Acceptance rate drops overall- true, but even in a data-discrepancy-accepting world, not giving enough love to your consent banner is a luxury indeed.

Where to go from here

The measurement environment isn’t getting more forgiving, and the gap between organizations that navigate it well and those that don’t is only a technical gap but definitely a strategic and organizational one too.

But, there are a few places worth starting at to solve for data inconsistencies problems:

1. Be okay with data not being the same across all your platforms. As long as it’s consistently different. Which takes me to…

2. Document the baseline and monitor it. The relationship between your platforms should be a known quantity you track over time, not something relitigated every reporting cycle. As said on point 1, it’s ok for data to be different across platforms as long as it’s consistently different.

3. If you haven’t already, have someone in the room who owns signal quality as a business problem (shouts to timo dechau 🕹🛠 and Barbara Galiza here that are doing amazing content about this topic, check out their upcoming webinar). This means owning it, outside of opening a tagging error ticket, or filling a compliance checkbox, this person should be someone who has visibility across both the implementation layer and its business consequences, and is accountable for the connection between the two.

4. Prioritize a strategic investment in your qualitative data layer. While methods like post-purchase surveys, customer interviews, CRM enrichment, and first-party behavioral data from authenticated users do not replace traditional analytics, they provide excellent and key signals often missing from standard dashboards. Use these insights to enrich your quantitative data, allowing for more robust modeling within your paid media/CRO efforts.

5. Invest in your first-party data infrastructure like the asset it is. Preference centers, loyalty programs, account creation flows, any touchpoint where the relationship is direct and consented gives you a durable signal that doesn’t degrade with every browser update or platform policy change. This is something that is definitely non-negotiable, you won’t be able to survive in business without this.

6. Before committing to a server-side infrastructure investment, know where your actual gaps are. The answer might be server-side. It might be a consent mode misconfiguration sitting unaddressed for six months. It’s worth knowing before you spend on infrastructure.

None of this requires a perfect data environment to get started. It requires deciding that the gap is a condition to manage rather than a crisis to solve and building the organizational habits around that decision.

The numbers will keep disagreeing. The question is whether your team is equipped to work with that, or still waiting for the dashboard to sort itself out :)

Other (random) updates

1. Latest episode of Standard Deviation Podcast is live and we had Talia Wolf again, and we are talking about why CRO has fundamentally changed, why your website is no longer where buying decisions are made, and why doing more is actually killing your conversions. The answer is customer research, and nobody is doing it ffs, it’s been 15+ years... let’s just do it for once?

   PS here: We have a lot of amazing guests lined up and a new episode will drop next week! So make sure if you haven’t subscribed yet to our scintillating podcast to do so!

2. I’m obsessed with Youtube. But not in the classic doom-scroll way only, but measuring Youtube creative assets effectiveness in pre, in and post flight. I’ve been playing a lot with Youtube assets lately and built together with my team at Jellyfish a really cool solution. More on this soon!

3. Last week I marked off 2 things on my bucket list: being an MC for an event and cosplaying as Darth Vader. And while I think I suck as an MC and shouldn’t quit my day job, I think I did a really good job as the Dark Lord.

   

   I think this is what you call… aura farming?!

Until next time,

Juliana

x