User Tracking That Answers Questions, Not Just Logs Clicks

User tracking is not about "recording every single click."

Truly valuable tracking translates user behavior into analyzable questions: Where do users come from? Why do they sign up? Where do they churn? Which features are actually used? What did they do before paying? Did the new version improve conversion?

If tracking isn't designed, what you see later isn't data, but a pile of inexplicable event names.

This article references several official resources:

Start with the questions first

Don't start by asking "which points should we track?".

Start with the business questions:

What is the conversion rate from visit to sign-up?
How many people complete the first key action after signing up?
Which entry channels bring users who are more likely to pay?
Which step has the highest drop-off rate?
Is the new feature being used after release?
What do free users typically do before upgrading?

Tracking exists to answer questions, not to appear data-driven.

If an event cannot help you make a decision, optimize the product, or validate a hypothesis, it should not be a priority to track.

Distinguish between Events, Event Properties, and User Properties

Three concepts in tracking are easily confused.

Event: What the user did
Event Property: The context of this action
User Property: A characteristic of the user that is long-term or changes slowly

For example:

Event: checkout_started
Event Properties: plan=pro, source=pricing_page, currency=USD
User Properties: role=owner, company_size=1-10, signup_channel=seo

Events describe actions, properties describe the details of this action, and user properties describe the person or account.

Don't stuff everything into the event name. For example, don't write:

pro_user_from_pricing_page_started_usd_checkout

It should be written as:

event: checkout_started
properties:
  plan: pro
  source: pricing_page
  currency: USD

This allows for subsequent filtering, grouping, and comparison.

Naming must be stable

Once event naming becomes chaotic, the data quickly becomes unusable.

It is recommended to use a unified format, such as snake_case:

page_viewed
signup_started
signup_completed
onboarding_completed
project_created
file_uploaded
checkout_started
payment_succeeded
subscription_cancelled

Don't mix these within the same product:

Signup Success
signup_success
signUpSuccess
register_done
user_registered

Stable naming is more important than "elegant" naming.

Google Analytics 4's recommended event documentation also provides recommended event names like sign_up, login, and purchase. When you can reuse platform-recommended events, prioritize reusing them; define custom events only for what the platform doesn't cover.

Track the critical path first

In the early stages, you don't need to track the entire site.

First, cover the most critical path:

Visit homepage
View pricing page
Start sign-up
Complete sign-up
Complete onboarding
Create first project
Trigger core feature
Start payment
Payment successful
Cancel subscription

For a content product, you might focus on:

Article impression
Article read
Table of contents click
Search
Bookmark
Share
Subscribe

For a tool product, you might focus on:

Template selection
File import
Generation started
Generation succeeded
Export
Collaboration invite

Don't track every button from the start. There are many button clicks, but not all of them can answer core questions.

Every event must have properties

An event without properties has very weak analytical power.

For example, the project_created event can at least carry:

project_type
template_id
source
plan
team_id
is_first_project

checkout_started can carry:

plan
billing_cycle
currency
price
coupon_used
source

article_read can carry:

article_id
category
read_depth
referrer
locale

Properties shouldn't be too many, but they must support common analyses: by channel, by version, by plan, by entry point, by user type.

Design funnels, not scattered points

A single event has limited value; funnels are much better at answering questions.

For example, a sign-up funnel:

landing_viewed
signup_started
email_verified
profile_completed
onboarding_completed
activation_event_completed

A payment funnel:

pricing_viewed
checkout_started
payment_method_entered
payment_succeeded
subscription_activated

A core feature funnel:

feature_opened
input_added
generation_started
generation_succeeded
result_exported

When designing tracking, it's best to draw the funnel directly, rather than listing events in isolation.

Define the activation event separately

Every product should define an activation event.

The activation event is not a successful sign-up, but the action where the user truly experiences the product's value.

For example:

Project management tool: Create the first project and invite a member
AI writing tool: Generate the first usable draft
Image tool: Upload an image and complete the first export
Email tool: Successfully send the first email
Data tool: Connect a data source and generate the first chart

Sign-up is just account creation; activation represents the user beginning to understand the product's value.

If you don't know what your activation event is, it's very difficult to optimize onboarding.

A tracking plan must be maintained

Tracking requires a tracking plan, also known as a tracking specification sheet.

Segment's Tracking Plan documentation describes it as a data specification used to define the events and properties you want to collect.

In the early stages, you can maintain it with a Markdown file or a spreadsheet:

Event name
Trigger timing
Trigger page
Event properties
Property type
Required or not
Example value
Person in charge
Release version
Remarks

Without a tracking plan, in a few months you will forget what the events mean and won't know which events are still being sent.

Don't collect sensitive information

Tracking systems are usually accessed by product, operations, growth, customer service, and external tools.

Therefore, do not collect:

Passwords
Tokens
Verification codes
ID documents
Bank card numbers
Full addresses
Private chat content
Original user-uploaded files
Sensitive personal information without consent

If analysis is needed, use desensitization, grouping, or enumerated values.

For example, record plan=pro, not the full payment information; record company_size=1-10, not the employee roster.

Event versions must be able to evolve

Products change, and tracking changes too.

When the meaning of an event changes, don't modify it silently.

You can adopt these practices:

Add new properties, rather than changing the meaning of old ones
Add a v2 event when necessary
Record the deprecation time in the tracking plan
Keep both old and new events for a transition period
Check if the event is still being sent before going live

The worst-case scenario is when the same event name represents different meanings at different times. This mixes historical data together, and the analysis results will mislead you.

A minimal viable tracking plan

For an indie developer in the early stages, you can do this:

1. First, list 3 core business questions
2. Design a funnel for each question
3. Keep only the key events in each funnel
4. Use snake_case uniformly for events
5. Include necessary properties for each event
6. Define one activation event
7. Use a tracking plan to maintain the event specification
8. Prohibit the collection of sensitive information
9. Check if key events are working normally before each release

This method is a bit slower than "automatic collection of all site clicks," but the data quality is much higher.

Final thoughts

The essence of user tracking is translating product questions into observable behavioral data.

Don't collect data for the sake of data. First, have questions, then events; first, have funnels, then buttons; first, have naming conventions, then code integration.

A good tracking system should ultimately let you know more clearly: at which step the user understood the product, at which step they gave up on the product, and which type of user is most likely to stay.

In the next article, we'll continue discussing growth entry points: how to generate SEO pages.