
On the day we launched our data readiness review, a mobile app publisher ran it on their BigQuery. By the evening their data lead had sent us three notes.
Two of them were about us. A column alias we used is a reserved word in BigQuery, so two of the checks failed. And the tool had read the first month of their data as "a shift", when it was simply the month their export started. Both were fixed that night.
The third note was about them. Their attribution vendor's user-level export had been switched off on 1 March and only came back in late September. The vendor can't backfill it. Half a billion rows a month, then a handful, for six months. Nobody had noticed, because every dashboard they look at runs on aggregated data that never stopped flowing.
That gap decides how much history a model can learn from. In a normal onboarding we would have found it in week three, after the NDA, the security review and the data access tickets. This time it took five minutes and nobody shared a single row.
Before anyone can tell you whether predicted lifetime value will work for you, someone has to answer a boring question: is the data there?
Is there a user ID on the revenue table, and does it match the one on the event table? Do the timestamps make sense? Are there 18 months of history, or 18 months with a hole in the middle? Do click IDs exist anywhere? Are refunds new rows, or do they rewrite the original charge?
The usual way to answer that is slow. A discovery call. An NDA. A security questionnaire. Read access to the warehouse. A data scientist who spends a week learning your tables. Only then does anyone find out that the revenue table has no user ID, and the whole thing stops.
Most of these answers don't need your data at all. They need your metadata.
The review lives at ready.churney.io. It is free and takes about five minutes.
It reads names, not rows. On BigQuery you sign in with Google and pick the datasets. The page reads table and column names, then runs a handful of read-only count queries from your browser, inside your own project. Only column names, counts and empty-value rates reach us. No user IDs, no emails, no amounts. That is why it needs no NDA.
It works on other warehouses too. On Snowflake, Redshift, Databricks, Postgres or Athena you run one query that lists your tables and columns, and upload the result. The checks then come as SQL you run yourself. On Snowflake that is a single query that returns a single cell to paste back.
It finds your tables for you. It suggests which table holds your events, your revenue and your attribution, and which columns are the user and the time. You confirm or correct. Data spread across several Google Cloud projects is fine.
It checks what matters for pLTV. Up to six queries, all counts:
It asks what metadata can't show. Ten short questions. How much of a customer's first-year revenue lands in the first week. Whether revenue rows get updated after they are written. How refunds are recorded. What you send Meta today. Your answers are marked as yours in the review.
It gives you a verdict and a list. One of: no structural blockers visible, not yet, incomplete, or no. Each comes with the evidence behind it and the questions to take to your data lead. You can share the link, and we keep it for 90 days.
A clean review means nothing structural stands in the way. It does not mean pLTV will work for you.
Data can be perfectly ready and still not predict anything. If your users' value at day 90 is already obvious on day 1, a predicted value adds little over what you send today. That is a different question, and our Growth Predictability Test answers it: does early revenue rank your users the way day 90 does?
Readiness first, then predictability. If either says no, you just saved yourself a pilot.
Every pilot we have run started with the same weeks of plumbing. The answers were almost always in the column names and a few counts. We kept finding the same problems late: the missing user ID, the refund that overwrites the charge, the migration nobody mentioned, the export that stopped.
Finding those late is expensive for everyone. Finding them in five minutes, before a sales call, is just useful. Even when the answer is no.
One click for Snowflake. Snowflake is the second most common warehouse among our customers after BigQuery. Today it means running SQL and pasting results. We are working on the same one-click start from inside Snowflake.
From readiness to a first model. A clean review followed by a good predictability score is most of what we need to know before a pilot. The step after that is a shadow model: pLTV trained on your data and scored against what actually happened, before anything touches your ad accounts. We are exploring how to make that the next button on the page.
Better checks, from your notes. Two bugs were fixed within hours because a data lead took the time to write to us. If the review gets something wrong about your warehouse, tell us. That is how it gets better.
Run the data readiness review. Five minutes, read-only, no rows leave your warehouse.
If the review comes back clean and you want to talk about what to send to Meta and Google, book a call and we will go through it with you.