How to automate user behaviour analytics: the event taxonomy

Product analytics rarely fails because the pipeline stopped working. It fails because six months in, there are four events that appear to mean the same thing, nobody remembers which one the mobile app sends, and a question that should take five minutes takes a week of archaeology.

That is a schema problem, and it is worth solving before the collection problem. Deciding the event taxonomy deliberately — and building the automation that keeps it honest — is what separates an analytics setup people query from one they distrust.

What we'll cover

• The schema is the whole thing
• Naming events so they stay usable
• Deciding what not to collect
• Building it with CodeWords
• Identity, which is harder than it looks
• Tracking breaks silently
• Questions worth automating
• Getting the answers to people who will act
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

The schema is the whole thing

Events accumulate without design. Each is added by whoever needed it, named however they were thinking that day.

Near-duplicates are the common failure — three events for one action, sent from different platforms, none of which is complete.

Properties drift. The same property name holds a string in one event and an identifier in another.

Nobody can tell what an event means six months later without reading the code that sends it.

Analysis becomes archaeology, and the cost lands on whoever is trying to answer a question under time pressure.

A tracking plan fixes this and is boring, which is why it is usually skipped and usually regretted.

Naming events so they stay usable

Object then action, consistently: the thing, then what happened to it. Any convention works if it is applied; inconsistency is the problem.

Past tense, because an event is a record of something that happened.

Keep the event count small. A handful of events with rich properties beats a hundred narrow ones, and it is far easier to query.

Put the variation in properties, not in the event name, so that "signed up" with a method property beats three separate signup events.

Never encode values in names. A separate event per plan means a new event every time you add a plan.

Write the definition down — what triggers it, which properties, what each means — and treat that document as the thing being maintained rather than the code.

Deciding what not to collect

Genuinely a design decision rather than a limitation, and the teams that make it deliberately have less trouble later.

Do not collect personal data you do not need. Every field is an obligation: retention, access requests, deletion.

Keep identifiers out of properties unless there is a specific reason, since they spread into exports and dashboards.

Never capture free text from input fields, which will contain something sensitive eventually.

Be careful with URLs, which often carry identifiers and search terms in query strings.

Respect consent at collection time rather than filtering later, since "collected then discarded" is still collected.

Collecting everything is not free. It costs storage, query time, and the ongoing cost of governing data nobody asked for.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so the analytics platform, the warehouse, the tracker and your channels can meet in one automation.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which events to watch, the validation rules, and what should be reported to whom.
3. Authorize the connections — the analytics platform or warehouse, and Slack or the tracker.
4. Describe the exceptions: a new event not yet in the plan, a property with an unexpected type, a platform that has gone quiet.
5. Run it against last month's events and see how many already violate the plan.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Identity, which is harder than it looks

Anonymous before known. Most interesting journeys start before sign-in and the join is what makes them analysable.

Aliasing at sign-up is the mechanism, and getting it wrong retroactively splits or merges people in ways that are painful to correct.

One person, several devices, which is the normal case rather than the exception.

Several people, one account, which is common in business software and invalidates per-user analysis if it is ignored.

Account and user are different levels. Most business questions are about accounts and most event data is about users.

Decide the model early and write it down, because changing identity resolution later means reprocessing history and explaining why every historical number moved.

Tracking breaks silently

A release removes an event and nothing fails — the data simply stops.

Volume monitoring per event against its own baseline is the detection, and it is rarely set up.

Platform-specific breakage is the common shape: web keeps working, mobile stops, and the total barely moves.

Property drift — a property that stops being sent, or starts arriving in a different format — degrades analysis without stopping it.

Validate against the plan continuously, rejecting or flagging events that do not match, rather than discovering the mismatch during an analysis.

Alert to the team that owns the feature, since documentation of a broken event is useless to anybody else.

Questions worth automating

Activation: the proportion reaching the point where the product has demonstrably worked for them, which needs that point defined and agreed.

Where people stop, by step, segmented, since the aggregate funnel hides the variation that matters.

Feature adoption after release, against a realistic expectation rather than against hope.

The difference between retained and churned cohorts in early behaviour, which is the most actionable single analysis in product analytics.

Error and dead-end encounters, which are behaviour too and are usually left to engineering monitoring.

Anomalies against a weekly baseline, since product usage has a strong weekly rhythm and day-on-day comparison alarms every Monday.

Getting the answers to people who will act

An analytics pipeline that only serves people who write queries serves a handful of people. The distribution is a separate design problem from the collection.

Push the recurring questions, since a dashboard requires somebody to remember to open it and a scheduled answer does not.

Attach the definition to every number, because most disputes about product metrics are disputes about method rather than about the figure.

Segment before sending. An aggregate that hides opposite movements in two segments is worse than no number.

Say what changed and what it might mean, briefly, rather than delivering a chart and expecting interpretation.

Alert on the specific thing somebody would act on — an activation drop, a feature nobody adopted after launch — rather than on general movement.

Make the underlying query visible so somebody can check it, since an unverifiable number in a weekly message eventually gets challenged and has to be defended from memory.

Making it survive

Handle at-least-once delivery with a stable event id, since duplicates are normal.

Buffer rather than drop when a destination is unavailable.

Version the schema and record when it changed, so a step change in a metric can be attributed to the instrumentation rather than to users.

Keep the raw events as well as any processed form, since every reprocessing you will want depends on having them.

Report the outcome: events received per type, validation failures, and anything that has gone quiet.

Limits worth knowing about

Client-side collection is incomplete — blockers, privacy settings and network failures all remove events, unevenly across segments.

Consent changes the population you measure, and a consent banner change moves every metric without anything else changing.

Server-side and client-side disagree, which is expected and is worth reconciling as a difference rather than resolving.

Platform limits on cardinality and retention vary, and a high-cardinality property can become expensive quickly.

Behaviour is not intention. A click tells you what happened and not why, and analytics answers the first question only.

What to build first

Event volume monitoring: every event type in the plan, watched against its own baseline, broken down by platform, alerting the owning team on a significant drop. It is read-only, it is quick to build, and it catches the failure that costs most — instrumentation removed by a release, found six weeks later when somebody asks why a number looks odd.

Two habits make the difference. Write the tracking plan before adding events and validate against it continuously, since retrofitting a taxonomy onto two hundred accumulated events is a project nobody funds. And alert on an event going quiet rather than only on metrics moving, because absence produces no error anywhere and is the characteristic symptom of broken tracking.

Frequently asked questions

Why do analytics setups become unusable?

The schema, not the pipeline. Events accumulate without design, near-duplicates appear across platforms, properties drift in type, and nobody can tell what an event means six months later without reading the code.

How should events be named?

Object then action, past tense, consistently. Keep the event count small and put variation in properties rather than names — "signed up" with a method property beats three separate signup events.

What should I deliberately not collect?

Personal data you do not need, identifiers in properties, free text from input fields, and URLs carrying query-string identifiers. Every field collected is a retention, access and deletion obligation.

Why is identity resolution hard?

Anonymous activity precedes sign-in, one person uses several devices, several people share one business account, and account and user are different analytical levels. Changing the model later means reprocessing history.

How does tracking break without anyone noticing?

A release removes an event and nothing fails — the data just stops. Often it breaks on one platform while the total barely moves, which is why per-event, per-platform volume monitoring is the detection.

What is the most actionable analysis?

The difference in early behaviour between cohorts that retained and cohorts that churned. It points at something you can change, which most funnel reporting does not.

Why does day-on-day anomaly detection produce false alarms?

Because product usage has a strong weekly rhythm. Compare against the same weekday over recent weeks, using a median, or you will alert every Monday and teach people to ignore it.

Does analytics tell me why users do things?

No. A click records what happened. Why requires asking people, and treating behavioural data as though it answered intent is the most common misreading of it.

How should analytics answers reach people?

Pushed rather than pulled, segmented rather than aggregated, with the definition attached and the underlying query visible. A dashboard requires somebody to remember to open it; a scheduled answer does not.

Why attach the definition to every number?

Because most disputes about product metrics turn out to be disputes about method. A figure with its definition can be argued about productively; one without gets defended from memory.

Should I keep raw events as well as processed ones?

Yes. Every reprocessing you will eventually want — a corrected identity model, a new derived property, a fixed bug in a transformation — depends on having the raw events. Discarding them makes those changes impossible rather than expensive.

How do I handle a schema change without breaking historical trends?

Version the schema and record when it changed. Otherwise a step change caused by the instrumentation is indistinguishable from a real change in user behaviour, and somebody will spend a week investigating the wrong thing.

Related reading

• Google Analytics and CodeWords
• Automating product feedback categorisation
• Automating a weekly team digest