Everyone wants to automate. First, you need something to automate.
Automating everything is the current fashion — and yes, it can be done. But automation is only ever as good as the data it's fed. And in e-commerce, the most dangerous errors never show up red. The system shows a green light, data keeps flowing — yet it can still be incomplete or untrue, and you won't know it until someone checks: by hand, or through a properly built automated control.
Two examples, to make it concrete. First — at the point of collection. A customer pays through an external gateway: PayU, Przelewy24, PayPal. After paying they don't return to the confirmation page, or they return via a URL where the purchase tag doesn't fire. The transaction is completed and paid — but it doesn't exist in analytics. Nothing turns red, because as far as the system is concerned, nothing happened. Real revenue and campaign ROAS are simply understated, and nobody sees it.
Second — downstream, once data is already flowing into reports. An integration pulling data from an ad platform runs flawlessly for a year. Then one day the platform retires an old API version — and the connection starts returning less data. No error, no warning. The report keeps generating, because the other sources are working fine — it's just that one stopped returning the full picture. And once part of the cost from one channel is missing in the warehouse, costs and revenue stop reconciling, and every metric built on them — ROAS, margin, acquisition cost — is simply wrong. You only find out once someone notices that revenue from that channel "somehow dropped." The green light was on the whole time — because the report was running. The numbers in it just weren't true.
Two different errors in two different places — but one thing connects them: the interface showed that everything was fine.
We use AI every day in our data work. That's exactly why we know its limitations first-hand. If you simply tell AI to look at the data and judge whether it's fine, it will see a green light and return a status of "all good." Except "all good" isn't always true — and the decision then gets made on a signal that isn't actually there.
The reason is structural. E-commerce analytics involves dozens of non-standard connections that have never been properly documented anywhere: custom order statuses, unusual integrations, exceptions in payment logic, local market quirks. AI by nature fills documentation gaps with its most probable guess — and in analytics, "probable" and "true" are two different things. That's why the risk of hallucination here is enormous.
That doesn't mean automation doesn't work — only that not every kind does. Good automation here isn't AI "looking and approving." It's specific, purpose-built control rules that check exactly the places where data tends to break — plus manual verification wherever context matters. Not because we don't trust automation, but because we know where it breaks down.
That's why it's worth looking at data quality through two lenses: how data enters individual systems, and how it flows out into a single warehouse. These are two different sources of errors and two different ways of working. But one thing connects them from the start: the easiest way to verify anything is when data from every system sits side by side in one place.
Layer one determines whether the data is even true to begin with. Layer two — whether it stays consistent as everything around it changes.
Layer one — data entering the systems
Everything that happens before data lands in GA4, Meta Ads, your ad platform, or CRM: the website, the app, the data layer, tags, events, Consent Mode, server-side. The most dangerous errors at this layer share one trait — everything looks fine from the interface.
Consent Mode that only looks correct
A user declines marketing consent — and through a configuration error, analytics consent gets declined too. The rejection message looks correct. GA4 reports everything working as expected under consent mode. And you simply have less data than you should — systematically, across every channel at once, with no signal that anything is wrong.
In the EU this is most often the single largest, invisible gap in your data. That's why the audit checks not what the system declares, but the actual requests and consent parameters (GCS, GCD, NPA) — before acceptance, after rejection, and after consent.
Missing purchase events
Back to the payment gateway example — because it's one of the most common and costly gaps at this layer. PayU, Przelewy24, PayPal, InPost Pay: the customer pays, but doesn't return to the confirmation page, or returns via a URL where the purchase tag doesn't fire. The transaction is completed and paid, but it doesn't exist in analytics.
The more payments flow through external gateways and wallets, the larger the gap — and the more understated the real revenue and ROAS of every campaign that generated that transaction.
Messy identifiers and currency
Every system collects data its own way: item_id in the data layer doesn't match the ID in the product feed, transactions arrive without a passed value or in the wrong currency when selling across multiple markets. The event technically fired, so nothing turns red — but the data doesn't join across systems, and ROAS calculated from those values is simply wrong.
Product feed: incomplete and missing steering signals
A feed isn't just a product list — it's the data on which Google's and Meta's machine-driven campaigns make decisions on your behalf. Feeds usually have two problems at once. The first is plain errors and gaps: inconsistent item_id, missing attributes, outdated prices and availability. The second, more serious one, is missing data that gives campaigns direction.
Custom labels turn the feed from a passive list into a campaign steering tool — carrying what the algorithm doesn't know on its own: margin, turnover, stock level, clearance status.
User ID that isn't being sent at all
It's not a subtlety like "only sent on login." In practice, user_id often isn't reaching GA4 at all — even though the client is certain it's implemented. Without it, you can't connect one user's sessions across devices or between web and app. Each person fragments into several "new" users, and all retention, cross-device, and purchase-path analysis is built on fiction.
The outcome of errors at this layer is always the same: the data is wrong from the source, and the interface doesn't show it. Everything downstream — reports, campaign optimisation, AI recommendations — inherits that error with no way to detect it.
That's why a tracking audit isn't a dashboard read — we combine automated tests with manual verification wherever context matters. We walk the full path from ad click to paid transaction and verify: data layer events (purchase, add_to_cart, begin_checkout), actual Consent Mode and CMP behaviour, value and identifier integrity, User ID implementation, feed completeness and steering signals, and consistency between web and app. The result is a document with the status of every element and an action plan for IT. Automation and AI do the first, broad pass over the data; non-standard connections, exceptions, and results that look "too clean" get confirmed by hand — so no silent gap ever slips through as "OK."
Layer two — keeping data consistent over time
The nature of the problem changes here. Layer one can be fixed once. Layer two can never be fixed for good — because marketing data isn't a state, it's a process that keeps changing without your consent.
And here comes the temptation to just build your own warehouse and be done with it. The problem is that the hard part isn't building it — it's maintaining it.
Fresh data is always incomplete
Conversions are attributed to the click date, but they trickle in over the following days and weeks, with some arriving as modelled. That's why yesterday's and last week's numbers always look worse than they really are — and will "improve" on their own over the coming days. This isn't an error, it's data maturing. But if someone reads a fresh period as final, they cut budget exactly where the campaign is actually working.
You read a fresh week as the final result — and cut budget where the campaign is actually working. The rest of the conversions are still on their way.
Integrations break quietly
This was the second example from the intro — and it's back here for a reason, because it's one of the sneakiest errors at this layer. Platform APIs are versioned and deprecated. An integration that worked for a year can quietly stop returning some of the data without any error — it simply starts returning less. Tracking itself can be flawless: events collected without a hitch, while the warehouse still ends up with a three-week gap, because the transfer from one source broke. And it only takes one such source to distort every aggregated metric calculated from that data.
Keys and structures change, and reports fail silently
This is the daily, most tedious part of working with data. A store changes its item_id format after a migration — and suddenly CRM data doesn't join with the feed or with GA4, because they join on an identifier that no longer exists. Someone renames a campaign and breaks the channel-mapping rule, so costs land in "other." A marketplace platform renames columns in its export. None of these changes throws an error — the report still generates, the numbers still show up, they're just inconsistent or incomplete.
The hand-stitched warehouse holds together because of one person
The most common alternative looks like this: someone wrote scripts pulling data from Meta, Google Ads, and the CRM, added a handful of manual fixes for edge cases, joined it all in BigQuery, and built reports on top. It works — until it doesn't.
The more sources and manual exceptions, the more fragile the whole thing. A data warehouse shouldn't be one specialist's private creation that stops working the moment they stop watching over it.
Definitions drift. History has seams.
Every system counts differently: different attribution windows, different conversion definitions, different consent handling, different time zones. That's why GA4 and the CRM will, by default, show different conversion numbers — and that's normal, it's not something you "fix." The real problem starts elsewhere: when those numbers drift apart more than the definitions alone explain, or when the gap suddenly shifts over time for no reason. At that point it's no longer a natural methodology gap — it's a signal that something broke. And switching analytics platforms or relaunching a store is its own moment of risk — the data breaks off or changes methodology, so year-over-year comparison becomes worthless unless someone deliberately unifies the historical data.
This is the difference between a hand-stitched warehouse and a maintained platform. It isn't a project that ends — it's operational work: monitoring source completeness, detecting anomalies, updating connectors after API changes and, above all, continuously normalising data into one coherent model. WitCloud does this automatically, regardless of who happens to be on the team: it maps data from every system onto a shared structure and makes sure a change to the item_id format or a campaign rename doesn't blow up reporting. When a transfer breaks or data drifts from the norm, an alert fires — before the gap distorts a decision. The data stays in your Google Cloud project and belongs to you, but its maintenance and consistency no longer depend on one person's memory.
The warehouse doesn't wait for perfect data — it helps fix it
It's easy to draw the wrong conclusion from all this: "I first need six months to get my data in order before I can roll out a warehouse." That's not true — it reverses the order.
As long as data sits in five separate systems, nobody sees how it relates to itself. That GA4 and the CRM show different numbers — that's natural. But whether the gap fits what attribution and consent explain, or whether it's already too large and growing over time — you can't judge that when you're looking at each number in a different panel, on a different day. It only becomes visible once they're all standing side by side.
Consolidating data into one warehouse is the fastest way to see problems at all — gaps in purchase, broken integrations, feeds without labels.
For us, this runs in parallel, not in sequence. Very often it's the data in WitCloud that gives the first signal something is wrong — numbers that suddenly stop reconciling, a channel that disappeared, revenue that doesn't match the CRM. The warehouse shows that a problem exists. The audit says where it comes from and how to fix it. Each drives the other.
You don't need perfect data to start. You need to see it in one place — because only then do you know what to fix first and what can wait.
And above all of this, AI finally has something solid to hold onto: not raw, contradictory systems, but a single, maintained source — one that signals for itself when it stops being reliable.
Truth first, then peace of mind
Data quality plays out on two layers and calls for two different moves. The first — whether the data is even true at the source — is work you do once: an audit that catches the invisible gaps in tracking and tells you plainly what to fix. The second — whether the data stays consistent as everything around it changes — is ongoing work that can never be "checked off." That's exactly why building a warehouse yourself rarely holds up: it's not the build you trip over, it's the upkeep. WitCloud does that for you — it keeps a single, maintained source in your own Google Cloud project and signals for itself when something stops adding up.
The audit fixes the data at the source. WitCloud makes sure it doesn't break again. You don't need perfect data to start — you need to see it in one place and know which numbers you can trust.