Choosing an event schema when you have no data team

Most product teams don’t have a data engineer. They have a frontend person, a backend person, and a Notion doc called “analytics (we’ll figure it out).” If that’s you: the good news is the modern stack doesn’t need a schema up front. The better news is you still need some discipline — just less of it.

Start with a vocabulary, not a schema

You don’t need a formal schema to start collecting. You need agreement on a small set of event names and a convention for properties:

• Five to ten events cover most of your product’s story: page viewed, signup started, signup completed, activation reached, upgrade, churn risk.
• Properties carry the detail: plan, source, region, feature.
• Names use the noun.verb convention (we wrote about why).

Write these down — a code comment is fine — and start sending. Structure can emerge later.

Let inference do the paperwork

This is the part that’s new. Modern analytics accepts messy events and infers structure as they arrive. A typo in a property name doesn’t block the pipeline; it becomes a fun discovery in the data dictionary. Your events define the schema by existing, and the dashboard adapts automatically.

That frees you to do the only thing that actually matters: keeping names readable and consistent.

Keep the backdoor open

Even without a data team, someone will eventually need a weird query. Make sure your tool has an escape hatch — a SQL mode, an export, or a warehouse destination. The discipline isn’t “never need a data team”; it’s “don’t be blocked by not having one.”

The trap to avoid

The classic failure is over-planning: a 40-event taxonomy designed in a doc, shipped in month three, already outdated by month four. Ship five events this week instead. Add the next five when a real question needs them. The schema that fits your product is the one your product actually produced — and you can only discover it by sending events.

Start small, name well, and let the data tell you what matters next.