A product Lexicon is not a document for documentation's sake. It is a decision tool.

My philosophy is simple: keep event names generic, keep context rich, and keep definitions shared across product, design, engineering, and data.
When everyone uses the same language, you reduce ambiguity and speed up execution.

A very short framework

• Define clear actions (click, view, submit) and avoid over-specific event names.
• Add context to every event (actor_entity, target_entity, interaction_context).
• Connect events to metrics, flags, and experiments so learning becomes systematic.
• Review the Lexicon often, especially when product behavior or tracking changes.

Why I prefer this over "one event per action"

I find this approach much better than creating a different event name for every tiny interaction (for example click_signup_button_homepage_top_nav_mobile).
That style usually looks precise at first, but in practice it creates tracking debt very quickly.

When events are too specific:

• the taxonomy explodes and becomes hard to maintain
• teams debate naming instead of learning from behavior
• analysis breaks every time UI labels or flows change
• dashboards become fragile and inconsistent across squads

With an action-based model, event names stay stable and reusable, while meaning lives in the payload.
You can still answer very specific product questions, but without rewriting your tracking strategy every sprint.

For me, this is the key advantage: less noise in instrumentation, more signal for decisions.

Why this 3-part structure is easy to adopt and scales

I like the actor_entity, target_entity, and interaction_context structure because it is intuitive even for non-technical teams:

• Actor answers: who is doing something?
• Target answers: what are they acting on?
• Context answers: under which conditions did it happen?

This makes events readable like plain language, so product, design, marketing, and ops can all contribute without needing deep analytics expertise.

It also scales well over time. You do not need to reinvent event names whenever the product grows.
You keep the same simple event vocabulary, and expand detail through context fields as new features, channels, and use cases appear.

This is how I think about product operations: simple vocabulary, deep context, and measurable outcomes.

Explore the full open-source project here: Product Lexicon by @antonscap