Designing events that survive sequence analysis

Good event data should retain meaning when read as a timeline, not only when counted in a chart.

Name observable facts

Events should describe something that happened, not an interpretation of intent. A name such as filter_applied remains legible in a trace; interested_user does not explain what the app or person actually did.

Preserve enough context

Sequence analysis depends on stable identifiers, timestamps, app version, entry route and relevant state. Add only properties that answer known questions, and avoid sensitive values when a categorical or derived value will do.

Test by reading traces

Before approving a schema, print several realistic timelines. Ask whether a colleague unfamiliar with the implementation can explain each transition. Ambiguity found here is cheaper to resolve than ambiguity found after release.

A useful next step: choose one active product question and write down the behavioural instance that would provide meaningful evidence. If its boundaries are unclear, resolve that before adding another chart.