Story Inc is a prediction market for movies and TV. People predict what a film will do at the box office, and they earn Story Cash for being right. The founder was about to spend real money on ads and had no way to see what the money bought. Over about three and a half months I built three things in sequence: the event tracking underneath the app, a dashboard sitting on top of it, and an AI assistant that reads everything and answers questions in plain English. Each one removed a different kind of blindness.
The situation: data everywhere, no answers
The app already had analytics installed. Most businesses with this problem do. What was missing was a way to get an answer out of it.
Google Analytics was collecting, and 7 event sets were firing in Tag Manager. Open the Events report and you get more than 40 rows, and most of them are Google's automatic ones sitting next to the custom ones, all named like signup_completed and first_prediction_submit. Watching the founder open that report for the first time, her question was which event meant a completed sign-up. Fair question, and there was no fast way to answer it. So she said this:
"I don't want to start running ads until I can monitor."
Ad budget was frozen behind a reporting problem. She could not see the funnel, so she would not fund the top of it.
Build one: make the app tell the truth
Tracking first. A dashboard built on bad data will confidently point you the wrong way. I verified the 7 event sets that already existed and built 28 new ones, which came out to 84 tags and 28 triggers across Google, Meta, and Reddit. Then UTM attribution so paid clicks carry their source all the way through to sign-up, UTM tagging on the SendGrid emails so the email channel stops hiding inside Direct, Meta's Conversions API, and Facebook domain verification. Delivered March 25, 2026.
By close, 40 of the 41 items on the tracking sheet were done. The last one is a consent banner, which is a policy decision about EU traffic and not a hole in the tracking.
Pain removed: the app stopped losing the story of where a user came from.
Build two: one page, two numbers
The dashboard went live April 3, 2026, inside the admin panel she already logs into. No new platform, no new password.
The design rule was that she should never see an event name. She sees Sign-Ups and Predictions as the two big numbers on the page, because those are the two she checks in the morning. Under them, the acquisition funnel (visit, sign-up started, sign-up completed, first prediction) with the conversion rate between every step, then the engagement funnel, then a traffic source table that says Instagram and Email and Direct instead of facebook/cpc. Every tracked event came pre-labeled in plain English on a settings tab, and she can rename any of them to match how she thinks.
Everything reads from the Google Analytics Data API. One source, so the dashboard and Google can never disagree.
Pain removed: the morning check went from a hunt through a reporting tool to opening one page.
Build three: an analyst on the same page
A dashboard answers the questions you thought to build a card for. Everything else is still work.
So the third build was an assistant, shipped July 7, 2026, living in the same admin panel. It reads the dashboard data, Meta and Reddit ad spend, Search Console, page speed, and referrals, then you type a question and it answers with real numbers. Every figure in an answer is underlined and traceable back to the data that produced it, because an assistant that rounds a number into a story will eventually cost you money. It pulls everything fresh at the start of each session on purpose. Last month's opinion about this month's numbers is how people make bad calls.
It reads screenshots too. Paste a landing page and ask why the traffic on it converts badly.
Pain removed: she stopped needing to know which chart held the answer.
What actually came out of it
This work was never measured against a business-outcome baseline, so there is no lift number to report. What there is: a decision the tooling settled.
In July she asked the assistant about her cost per sign-up, and the number it gave her did not match what Meta was reporting. Meta's pixel claimed 609 registrations in the window. Google Analytics could trace 354 sign-ups directly to someone clicking a Meta link. Her question back was:
"however you count it, that ad spend technically got me 565 sign-ups, directly and indirectly. Yes?"
The answer is no, and the reason is worth the whole build. The 354 were watched: click the ad, sign up. The rest are people Meta counts because they scrolled past an ad at some point and later signed up through an email or a search. Some of those were probably helped by the ads. There is no way to measure which ones. So you budget on the proven number and treat the rest as a bonus.
She now has a sign-up number she can defend to an investor, one that came from her own tracking rather than from the platform grading its own work. The same tracking surfaced something nobody was looking at: email was driving 247 first predictions from 355 sign-ups, a 69.6% activation rate.
If you run a service business, this is the same problem
You almost certainly have analytics. You almost certainly cannot answer which channel deserves more money next month in under ten minutes. The reason is usually the same: the data gets collected in the vocabulary of engineers and read by an owner who thinks in customers.
The sequence that fixes it is the same every time. Make the tracking accurate first. Put the three numbers you actually act on where you can see them without clicking. Then put something on top that will answer the questions you did not predict.
If you want to know what that would look like for your business, start here.
