
The event data you never get to keep
Your platform's analytics tab answers the questions somebody at the vendor decided you would ask. Webflow Analyze, which Webflow sells as a site add-on starting at $9 a month on a 2,000-session tier, captures page views, sessions, unique visitors, bounce rate, time on page and clicks, then renders them as a site overview and a page detail report. Those are good numbers. They are also the only numbers, and they arrive already added up.
Aggregates answer yesterday's questions
Read Webflow's own Analyze documentation and the shape is clear. You get top pages by traffic, top referrers, top audiences by country and device, the top ten internal pages visitors saw before and after a given page. The Pages list holds up to 150 of your top pages. You can view 90 days of data at a time. A session closes after 30 minutes of inactivity, because somebody had to pick a number and 30 minutes is the number they picked.
Every one of those is a decision made before you had your question. Say you want to know whether the people who read two pricing pages in one visit before contacting you convert better than the ones who read one. That query needs rows: one line per event, with a timestamp and a person identifier, that you can group however you like. A top-ten list cannot be made to produce it, and no amount of filtering in the dashboard will get you there. The data existed for a moment and then it was summed.
I do not think this is a flaw in Analyze. It is an honest product doing an honest job for the price. Ninety days of bounce rate for $9 a month is fine value. The problem only shows up on the day the interesting question arrives, and interesting questions tend to arrive after you have shipped something, not before.
What an events table actually buys you
On the Stay World Class migration we replaced Webflow and Xano with Next.js, NestJS and Supabase, and built a four stage ETL that mapped every legacy ID onto a PostgreSQL UUID so nothing orphaned on cutover. The performance numbers were the headline: Lighthouse went from 55.91 to 91 out of 100, and LCP came down 77%. The quieter win was that behaviour started landing in a table the client controlled.
Once events are rows in Postgres, analysis stops being a feature request. You write SQL. You join sessions against orders, cohort by signup week, look at the funnel from a direction nobody built a report for. PostHog is worth naming here because it is the open path: MIT licensed, deployable yourself with Docker Compose, and PostHog's own self-host docs put the requirement at a Hetzner-class box with 4 vCPU, 16 GB of RAM and more than 30 GB of storage.
Be honest about what that path costs, though. PostHog says plainly that self-hosted instances are unsupported, that it offers no guarantees, and that every paid-plan feature is Cloud only. Their hosted free tier covers a million events a month, which is more than most sites produce. And their own raw events API is deprecated: no `after` parameter now returns only the last 24 hours, offsets above 50,000 are disabled, and they are pushing everyone to batch exports instead. Owning your data means owning the pipeline that moves it, not just having API credentials.
When the dashboard is enough
If the questions you ask about your site are the ones a dashboard already answers, you are done and you should stop reading. Which pages get traffic, where it comes from, whether the new homepage lowered bounce rate: Analyze handles all of that, and standing up your own event pipeline to learn the same facts is a worse use of a week.
Staying put is also right when nobody on the team writes SQL. An events table with no analyst attached is a storage bill with a sense of promise. And it is right when your retention needs sit inside 90 days, which for a lot of marketing sites they genuinely do.
The case for moving starts when you notice yourself describing a question you cannot ask. Not a report you have not built yet, a question the system structurally cannot answer. That is the moment the aggregate stopped being a summary of your data and became the whole of it.
