If you’ve ever tried to “just add event tracking” and then watched your backlog burst into flames, welcome.
Raw events are the low-drama, high-signal way to understand what users are actually doing in your productwithout
begging engineering for “one more tiny snippet” (which is never tiny, and we all know it).

In Userpilot, Raw Events are automatically captured user interactionsthink clicks, text inputs,
and form submissionsthat start getting collected as soon as Userpilot is installed and auto-capture is enabled.
The magic is that you can explore what’s happening before you perfectly predict what you’ll care about.
Then you can label the meaningful stuff and turn it into analytics, segmentation, and in-app targeting that doesn’t feel like guesswork.

What “Raw Events” Means (in normal human language)

In product analytics, an event is a recorded action: clicking a button, submitting a form, finishing onboarding,
or any moment that matters to your user journey. “Raw” events are the unpolished versioncaptured directly from what users do in the UI,
typically with minimal formatting and lots of volume.

Why does this matter? Because teams often don’t know which actions will become important until after a new feature ships,
a UI changes, or leadership asks, “So… do people use the thing we built?” Raw events give you coverage from day one,
so you can analyze and refine later instead of re-instrumenting in a panic.

What Userpilot Auto-Captures as Raw Events

Userpilot’s Raw Events auto-capture focuses on core interaction types that show intent and behavior. You’ll typically see:

1) Clicks

Click events generally represent meaningful user actionsclicking buttons, links, and interactive UI elements.
This is the category that answers questions like: “Are users even noticing this CTA?” and “Which settings are actually being used?”

2) Text Inputs

Text input events capture when users type into fields. This can be surprisingly useful for identifying friction:
a field users repeatedly edit can signal confusion, a broken validation pattern, or unclear instructions.

3) Form Submissions

Form submission events capture the moment a user submits a form (usually by a submit button or form action).
These are especially valuable for onboarding steps, upgrade flows, contact forms, and “save settings” moments.

Where Raw Events Fit in Userpilot’s Event Ecosystem

Userpilot supports multiple event types so both technical and non-technical teams can get what they need:

• Raw Events: auto-captured interactions (great for discovery and retroactive analysis).
• Labeled Events: raw events (or other UI elements) you name and define so they become reusable, report-friendly signals.
• Tracked Events: events you send intentionally (e.g., via userpilot.track() or API) with richer metadata.
• Custom Events: groupings of multiple events into one “umbrella” event for simpler measurement.

In other words: raw events help you discover, labeled events help you operationalize, tracked events help you enrich,
and custom events help you simplify.

How to Enable (or Disable) Raw Events Auto-Capture in Userpilot

In Userpilot, raw events auto-capture is controlled in settings. When enabled, Userpilot collects the interactions;
when disabled, it stops capturing them.

Excluding what you don’t want captured

Auto-capture is powerful, but “capture everything” is not the same as “keep everything.” Smart teams exclude:

• Sensitive UI areas (billing details, identity fields, anything that could contain personal data)
• Internal/admin pages that would pollute product usage metrics
• Specific domains or locations that don’t represent the real product experience (staging, QA tools)

Think of exclusions like a bouncer at a club: they don’t ruin the partythey keep the party from turning into a spreadsheet nightmare.

From Raw to Useful: Labeling Raw Events

Raw event tables can feel like drinking from a firehose. The key move is to label meaningful actions so they become
clear, named events you can use across reporting and targeting.

What labeling actually does

When you label a raw event, you’re essentially saying: “This messy-looking UI interaction is actually this product behavior.”
That new labeled event can then be used in segmentation, content triggering, and analytics reports.

“Label Event” vs. “Visually Label”

Userpilot lets you label from the raw events list, and also supports visually labeling so you can confirm you’re targeting the right
element in the live UI (especially helpful when your app has repeating components or similarly named buttons).

A critical nuance: historical data vs. activation data

Once you label an event, you can often see historical interaction data in analytics/reporting. But for activation workflows
like segmentation and content triggering, the clean rule of thumb is: activation typically starts counting from the moment
the event is labeled. That keeps targeting logic consistent and prevents surprise “instant segments” built from yesterday’s noise.

Supported CSS Selector Styles (and why you should care)

UI-based event tracking often relies on selectors to identify elements. Userpilot supports common selector approaches so labeling can match
what’s stable in your UI.

Common selector styles include tag names, class/id combinations, nth-child patterns, attribute selectors, and combinators.
Practically speaking, this means you can track a button reliably even if your UI is built with modern frameworks and component libraries.

Examples of selector patterns

Pro tip: favor selectors that will survive UI refactors. If your selector depends on a generated class name that changes every deploy,
your “event tracking” will turn into “event guessing.”

Using Raw and Labeled Events for Real Product Questions

Raw events are not the goal. Answers are the goal. Here are practical ways teams use raw events and labeled events to get there.

Use case: Find where users spend time (and where they bounce)

Look for clusters of clicks and form interactions around key screens. If users hammer a settings panel but rarely submit changes,
you may have an unclear configuration flowor a form that’s failing silently.

Use case: Trigger in-app guidance based on real behavior

Example: A user clicks “Invite Team” but never completes the invite form. That’s a perfect moment for a tooltip:
“Need help inviting teammates? Here’s the fastest way.” Targeting based on actual behavior beats targeting based on vibes.

Use case: Measure onboarding impact

You can define a goal around raw events (“Clicked ‘Create Project’” + “Submitted ‘Create Project’ form”)
and then measure whether an onboarding flow increases completion. This keeps onboarding measurement anchored to outcomes,
not just “people saw the checklist.”

When to Use Tracked Events Instead of Raw Events

Auto-capture is great for front-end interactions, but some of your most important events are better sent intentionally:

• Backend-confirmed moments (payment succeeded, invite accepted, export completed)
• High-stakes conversions where reliability matters more than UI signals
• Events that need rich context (plan type, account tier, feature flags, experiment variants)

In Userpilot, tracked events can be sent with metadata (event properties). That’s how you graduate from
“a click happened” to “a click happened for Enterprise accounts on the new pricing page variant.”

Example: a tracked event with metadata

Custom Events: Turning Multiple Signals into One Outcome

Some outcomes are multi-step. “Completed onboarding” might mean:
visited the dashboard, created a workspace, invited a teammate, and configured a setting.
Custom events let you group multiple events into a single “completion” signal so stakeholders don’t have to interpret a five-event spreadsheet.

A pragmatic approach is to start with raw events to discover the true steps users take, label the meaningful ones,
then use tracked events for backend confirmation where needed, and finally group what matters into custom events
for consistent reporting.

Event Naming and Data Hygiene (aka: how not to ruin your own analytics)

Raw events generate lots of data. That’s a giftunless your event taxonomy becomes a junk drawer labeled “misc_final_v7.”
The strongest teams use a simple naming framework and stick to it.

Pick a naming structure

A widely used approach is Object + Action. Examples:

• Project Created
• Invoice Sent
• Integration Connected

Keep properties consistent

Properties should be stable keys that add contextlike plan_type, role, source, or template_id.
Avoid dynamic keys and avoid stuffing unique values into event names.

Balance “track everything” vs. “track only what matters”

Auto-capture leans “track more and analyze later,” while tracking plans often lean “less but richer.”
The best practice is not picking a sideit’s using auto-capture for discovery and using deliberate tracking for core KPIs.

Privacy and Compliance: Don’t Autocapture Yourself into Trouble

Behavior data is powerful. It also comes with responsibility. Before you scale event tracking, align on:

• What data is sensitive and must be excluded or masked
• Which regulations apply (for example, GDPR/CCPA obligations depending on your users and business)
• How your team audits events and prevents accidental collection of personal data

Treat privacy controls as part of analytics qualitynot as a legal footnote. Your future self will thank you,
and your compliance team might even stop sending scary messages with subject lines like “URGENT: DATA QUESTION.”

Field Notes: of Real-World Experience with Raw Events

Here’s what using raw events feels like in the real worldbased on patterns teams repeatedly run into when they finally have
“more data than opinions” (and yes, it can happen).

Story #1: The onboarding flow that looked perfect… until it met reality.
A SaaS team launched a polished onboarding checklist with celebratory confetti. Adoption was “fine,” but activation was flat.
With raw events enabled, they noticed a weird pattern: users clicked “Connect Integration,” landed on the integration page,
then immediately clicked away to settingsover and over. They visually labeled the “Connect” button and the “Permissions Help” link,
then created a simple funnel. The drop-off wasn’t the integration itself; it was a permissions modal users didn’t trust.
They rewrote the copy, added a short tooltip explaining what would (and wouldn’t) be accessed, and activation climbed.
No new feature. Just less mystery.

Story #2: “Nobody uses the feature” was technically true… and also misleading.
Another team believed a reporting feature was a flop because the “Generate Report” button had low clicks.
Raw events showed plenty of clicksjust not on that button. Users were exporting from a smaller “Download CSV” action inside a table.
Once that interaction was labeled, the story changed: users wanted the data, but preferred the lighter-weight path.
The team stopped debating whether to delete the feature and instead improved the CSV workflow and added templates.

Story #3: Support tickets weren’t randomthey were geographically predictable.
A product with lots of form-heavy workflows saw spikes in “my form won’t submit” tickets. Raw events helped isolate the behavior:
users repeatedly typed into one field and hit submit multiple times. The team labeled the input interaction and the submission event,
then segmented by browser and region. A validation script behaved differently for a specific locale setting.
The fix was small; the time saved was not.

Story #4: The best experiments start with “what are people trying to do?”
Instead of A/B testing random UI tweaks, a growth team used raw events to identify the top three “attempted actions” on a pricing page:
clicking plan details, opening FAQs, and interacting with the calculator. They labeled those interactions and used them as success criteria,
not just “clicked Buy.” The experiment that won wasn’t flashierit simply removed friction where users already showed intent.

Story #5: Raw events made self-serve analytics possible for non-analysts.
When raw interactions are unlabeled, only analysts have the patience to decode them. But after a week of focused labeling
naming key UI actions with a consistent conventionproduct, CS, and marketing could all answer basic questions without a ticket:
“Did users discover this setting?” “Which step is the bottleneck?” “What changed after the UI refresh?”
The biggest win wasn’t a dashboard. It was a culture shift: fewer assumptions, faster decisions, and dramatically fewer Slack messages that start with
“Quick question…” (which, famously, is never quick).

Conclusion

Raw events in Userpilot give you immediate visibility into real user behavior: clicks, inputs, and submissions that reveal how your product is
actually usednot how you hope it’s used. The winning workflow is simple: enable auto-capture, exclude what shouldn’t be tracked, label what matters,
and combine raw discovery with intentional tracked events for your most important outcomes.

Do that, and you’ll spend less time debating “what users want” and more time watching what they dothen improving it with confidence.