Backend

User Tracking That Answers Questions, Not Just Logs Clicks

By Harries · Jul 30, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Without a designed tracking plan, analytics dashboards fill up with uninterpretable event names that can't answer a single product question. A small upfront investment in naming, properties, and funnel design prevents months of wasted instrumentation and misleading analysis.

Summary

User tracking design fails when it tries to record every click. The discipline starts with specific business questions—conversion rates, drop-off points, feature usage, pre-upgrade behavior—and only then defines the events, properties, and funnels needed to answer them. Events describe what a user did; event properties capture the context of that action; user properties describe the person or account. Stuffing everything into a single event name destroys the ability to filter and compare later.

A stable naming convention like snake_case matters more than elegance, and reusing platform-recommended event names from GA4 or similar tools saves time. The critical path gets instrumented first: landing, sign-up, onboarding, activation, payment. Every event carries just enough properties to support analysis by channel, plan, version, or user type. Funnels—not isolated events—reveal where users drop off, and a single, explicitly defined activation event marks the moment someone actually experiences the product's value.

A tracking plan, even a simple Markdown table, prevents the slow decay where nobody remembers what an event means or whether it still fires. Sensitive information stays out of the tracking system entirely, and event versions evolve by adding properties or v2 events rather than silently changing meanings. The result is a minimal viable setup that is slower to build than automatic click collection but produces data that can genuinely guide product decisions.

Takeaways

— Start with specific business questions, then define the events and funnels that answer them.

— Separate events (what happened), event properties (context of the action), and user properties (who the person is).

— Use a stable naming convention like snake_case and reuse platform-recommended event names where possible.

— Instrument the critical path first—landing, sign-up, onboarding, activation, payment—not every button.

— Every event needs properties that support filtering by channel, plan, version, entry point, and user type.

— Design funnels directly rather than listing isolated events; a single event has limited analytical value.

— Define one activation event that captures when a user first experiences the product's core value.

— Maintain a tracking plan as a living document so event meanings don't decay over time.

— Never collect passwords, tokens, PII, or raw user content in tracking systems; use desensitized or enumerated values instead.

— Evolve events by adding properties or creating v2 events; never silently change an existing event's meaning.

Conclusions

Automatic click collection is a trap: it produces volume but no signal, because clicks without a question behind them are just noise.

The distinction between event properties and user properties is the single most underrated concept in analytics instrumentation, and getting it wrong makes cross-cohort analysis impossible.

An activation event is the linchpin of onboarding optimization; teams that can't name theirs are guessing at what makes users stick.

Silently changing an event's meaning over time is worse than having no data at all, because it corrupts historical comparisons and trains the team to distrust the numbers.

Concepts & terms

Activation Event

The specific user action that indicates someone has experienced the product's core value for the first time—not sign-up, but the moment of meaningful usage (e.g., sending a first email, generating a usable draft, inviting a team member).

Tracking Plan

A living specification document that defines every event and property being collected, including trigger conditions, data types, required fields, and version history. Without it, event meanings decay and become uninterpretable.

Event vs. Event Property vs. User Property

An event records what action occurred (e.g., checkout_started). Event properties describe the context of that specific action (e.g., plan=pro, currency=USD). User properties describe long-term traits of the person or account (e.g., company_size=1-10, signup_channel=seo).

Source: juejin.cn ↗ Google Translate ↗ Backup ↗