The symptom
A client asks whether they can use AI on their marketing data, and it feels like it should be yes. You pull an export, hand it to a tool, ask it something a junior analyst could answer in an afternoon, and get back a number that does not match the dashboard you sent that client last week.
So you check the number, then the export. An hour later you are not debugging the AI, you are debugging six years of tracking decisions nobody wrote down, and you still cannot tell the client whether the answer was wrong or the data was.
The instinct at that point is to clean the file. Rename the columns, drop the duplicates, write a data dictionary. That is real work, and it is the last step rather than the first, which is why the second pilot tends to fail the same way as the first.
Why the readiness work has an order
Every defect in a client's dataset sits somewhere on the path the data takes, from the browser through the reporting tool into whatever you finally export. What decides the order is not how bad each defect is, it is which ones can still be fixed after the fact. Most of them cannot.
A row that was never collected cannot be cleaned later
Before this is an AI problem it is a collection problem. Consent refusals, ad blockers stripping 30-40% of events, and browser restrictions on client-side tracking mean 15-30% of conversions are consistently never recorded at all. No prompt reaches those rows. No cleaning step recovers them. A tool handed the remainder will answer confidently about the traffic that survived and describe it as the market.
It is also invisible in the file. A missing conversion does not arrive as a blank cell, it arrives as a slightly smaller number that looks entirely plausible.
The reporting tool removes detail by design
An export from a reporting interface is a report, not the underlying data, and they are built to summarize. GA4 condenses less common dimension values into an (other) row once a table gets wide, treating any dimension above 500 values as high cardinality and calling 500 guidance rather than a hard limit (Google Analytics Help). Explorations get sampled above the property quota, documented as 10 million events for standard properties and up to 1 billion for 360, after which Analytics "uses a portion of the data and then scales up to provide directionally accurate results" (Google Analytics Help). Rows can also be withheld outright by data thresholds, which Google states are system defined and cannot be adjusted (Google Analytics Help).
Directionally accurate is fine for a trend line in a monthly report. It is not fine as the input to a tool that will do arithmetic on it and hand back the result as a finding.
Estimates and observations arrive in the same column
Platforms mix measured and modeled numbers deliberately, and they do not pass you a flag for it. Google Ads is explicit: "In the 'Conversions' column, Google reports both modeled and observed conversions", where modeled conversions estimate what Google could not observe directly (Google Ads Help). GA4 does something comparable for consent, applying machine learning to "estimate the behavior of those users based on the behavior of similar users who do accept analytics cookies" (Google Analytics Help).
Then the part that catches teams out. That modeled GA4 data is not available to the BigQuery export, which Google lists as an unsupported surface for modeling (Google Analytics Help). So the export can legitimately read lower than the GA4 report over the same dates. Ask a tool to reconcile the two and it will not report a discrepancy, it will produce an explanation. That is the shape of most wrong answers about marketing data.
Personal data gets more expensive after the pilot
Google's policy is that "no data be passed to Google that Google could use or recognize as personally identifiable information", naming email addresses and personal mobile numbers among the examples (Google Analytics Help). It lands there anyway, in URL query strings, form field values and transaction identifiers, and it is still in the export you were about to upload.
Under the GDPR that matters twice over. Personal data is "any information relating to an identified or identifiable natural person", and pseudonymized data that can be re-attributed with additional information is still personal data (Art 4). Purpose limitation separately requires data to be "collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes" (Art 5(1)(b), EUR-Lex). Whether pointing an AI tool at a client's analytics data is a compatible further purpose depends on what is in the columns, what the client's privacy notice said, and where the tool processes it. That is a real "it depends", and it is cheaper to answer before the data moves.
What good looks like
Five steps, in this order, because each is only worth doing once the one before it holds.
Fix collection first. Move measurement server-side so the events browsers and blockers currently drop get recorded at all. It is also the step with a return attached: 15-40% more conversions recovered is the normal range, and around +25% more captured than standard GA4 tagging.
Get event-level data out of the reporting layer, and start the clock early. The BigQuery export sends raw, unsampled events once a day, and it runs forward from the day it is linked, not backwards over history (Google Analytics Help). Standard GA4 properties hold event-level data for 2 or 14 months, then delete it automatically (Google Analytics Help). Cheapest item here, and the only one that gets more expensive every month it waits.
Separate what was observed from what was estimated. Keep modeled and measured figures in different columns, and decide per question which of them is allowed to answer it. A budget decision can run on estimates. A statement to a client about what happened should not, unless it says so.
Settle the personal data question before the pilot. Strip the identifiers you do not need, agree in writing what the tool may be asked, and put that in front of the client's legal contact while it is still a plan.
Write the definitions down, last. One conversion definition per client, one currency, one timezone, one meaning for the word lead. Do it now and the tool inherits it. Do it first and you rewrite it three times as the steps above change what the columns contain.
Archon AI does this on a client account: recovered collection underneath, event-level data the agency owns, observed and modeled figures kept apart, definitions written where a tool can read them. What it buys is not a better answer to every question, it is knowing which questions the dataset can carry, on up to roughly 95% of events in a good setup. That is a ceiling rather than a promise.
Frequently asked
Can we not run the pilot first and fix the data afterwards?
You can, and it is a reasonable way to find out whether anyone will use the output. Scope it as a tooling test, and keep the numbers away from the client. The risk is not a wasted month, it is one plausible wrong answer reaching a client conversation and you spending the next quarter defending it.
Do we need BigQuery, or is an export good enough?
It depends on two things: how many events the account produces, and how far back the questions reach. Under the sampling quota, for questions about recent weeks, a straight export answers plenty. Above it, or for anything year on year, the interface summarizes before you see the file, and event-level data is the only way past that.
The client wants to point a chat tool at a spreadsheet. Is that different?
Same failure modes, smaller surface. A chat tool will calculate correctly on the file it was given and still be wrong about the business, because that file arrived thresholded and short of the conversions nobody measured. There is more detail on what a chat tool can and cannot do with an export.
How ready is ready enough?
Ready enough is when you can name, for a given question, what is missing from the answer and roughly how much. That is a lower bar than clean and a more useful one, because it tells you which questions to stop asking.
If you want to know which questions a specific client's data can already answer, a free tracking audit maps what is being collected, what is modeled, and what is missing.