Home / Blog / How worker events turn into product views
Data model

How worker events turn into product views

Because the worker is the write path, the product has to make the read path obvious too. Otherwise the UI will feel disconnected from the data it is supposed to represent.

Quick take

The MVP only works if the stored event model stays easy to explain: signup creates the workspace, domains attach to the workspace, worker events land as normalized visits, and the UI rolls those events back up into simple views.

Start with workspace and domain state

The first records are not crawler events. They are the account, the first user, and the tracked domains. That gives the product a stable place to attach future events.

Without that structure, ingest becomes harder to reason about and the UI cannot explain ownership clearly.

Keep the worker event shape small and consistent

For the MVP, each visit only needs a few durable facts: domain, URL path, bot identity, verification result, and timestamp. That is enough to drive the free dashboard and the upgraded views.

Storing the minimum useful event payload makes the reporting logic easier to trust.

Summary views should be obvious rollups

The dashboard, live feed, and domain list should all feel like simple rollups of the same normalized visit table. If a user sees one more visit in the live feed, they should intuitively expect the dashboard counts to change too.

Deeper analysis should still read from the same core facts

BOT and URL analysis do not need a separate universe of data. They need more grouping, more comparison, and longer retention at the domain level. That keeps the upgraded views connected to the same source of truth.

The bottom line

The cleanest MVP data model is the one a user can explain back to us: the worker saves visits, the app rolls them up, and upgraded domains unlock deeper ways to read the same events.

← Back to all posts