HubSpot Custom Event Properties: How to Track Product Usage Like GA4 (Without Breaking Your CRM)

TL;DR: HubSpot custom events are the cleanest way to capture product usage and key actions without stuffing your CRM full of noisy properties. The win is simple: track what matters, keep it consistent, and make it reportable.

The problem (and why most portals get this wrong)

You want to answer questions like:

• Which trial users activated within 7 days?
• What actions correlate with conversion (invite teammate, connect integration, publish first campaign)?
• Which customers are actually using the features they pay for?

Most teams try to solve this by creating a pile of contact properties like Last feature used, Feature A used, Feature B used, and so on. That approach usually ends in:

• Bloated property lists nobody trusts
• Inconsistent definitions (“activation” means 3 different things)
• Reporting that’s either impossible or misleading

Custom events are built for this exact use case: track behavior as behavior, then summarize it into CRM fields only when it’s genuinely useful.

What a “good” custom event setup looks like

Think of your tracking plan in two layers:

1. Event layer (behavior): capture actions like trial_started, integration_connected, report_exported.
2. CRM layer (summary): store only the handful of rollups you’ll actually use for segmentation and handoffs (e.g., Activation date, Activation status, Last product activity date).

That’s how you keep your CRM clean and your reporting accurate.

Step-by-step: implement custom events in HubSpot (practical version)

Step 1) Define 3–5 “money events” (don’t start with 50)

Pick the actions that clearly indicate progress. Here are examples that work well for SaaS and software teams:

• trial_started (the moment a real trial begins)
• activation_completed (your definition of “aha moment”)
• integration_connected (Stripe, Slack, Google, etc.)
• first_value_delivered (first campaign sent, first invoice created, first report published)
• feature_used (only if you add properties to specify which feature)

Direct advice: if you can’t explain the event in one sentence, it’s not ready.

Step 2) Add event properties so the data is usable

Events without context are basically useless. Add properties that answer “what exactly happened?” For example:

• For integration_connected: integration_name, integration_type, plan_tier
• For feature_used: feature_name, feature_area, usage_count
• For report_exported: report_type, export_format

Keep property names consistent and boring. Boring is good. Boring scales.

Step 3) Decide how events will be sent to HubSpot

You typically have three realistic paths:

1. Native tracking (where applicable): use HubSpot’s tracking code and built-in tools when they match your needs.
2. Product instrumentation: your app sends events server-side (cleanest for product usage).
3. Integration middleware: Segment, RudderStack, Zapier/Make, or a custom integration if you need control.

Rule: if the event matters for revenue decisions, don’t rely on fragile front-end-only tracking.

Step 4) Map events to the right CRM record (this is where accuracy lives or dies)

Custom events need to tie back to a real CRM identity. That usually means:

• Contact (user-level behavior)
• Company (account-level behavior)
• Deal (pipeline-stage behavior, sales motion)

If your product is account-based, don’t pretend everything is a contact story. Get your association strategy right early, or you’ll rebuild it later.

Step 5) Build reporting that answers real questions

Once events are flowing, use them to create clear, decision-ready reporting:

• Activation funnel: trial_started → activation_completed → first_value_delivered
• Feature adoption: % of active customers using Feature X in last 30 days
• Sales signal report: deals where key event happened in last 7 days

Then (and only then) create a few CRM rollup properties to support handoffs and segmentation, like:

• Activation status (Activated / Not activated)
• Activation date
• Last product activity date

Common mistakes I see (and how to avoid them)

• Mistake: Tracking everything. Fix: start with 3–5 events tied to revenue outcomes.
• Mistake: Inconsistent naming (e.g., “Activated”, “activation”, “Activation Completed”). Fix: define a naming convention and stick to it.
• Mistake: No event properties, so you can’t segment. Fix: add the minimum context you’ll need for reporting.
• Mistake: Storing raw usage as CRM properties. Fix: keep raw behavior in events; store only rollups in CRM.
• Mistake: Bad identity mapping (duplicate contacts, wrong associations). Fix: decide your source of truth for identity and enforce it.

Quick checklist (steal this)

• We defined 3–5 core events tied to activation, retention, or revenue.
• Each event has consistent naming and 2–5 useful properties.
• We know how events map to Contact vs Company vs Deal.
• We built at least one funnel report and one adoption report.
• We only created CRM rollups that support real workflows and handoffs.
• We documented definitions so sales, marketing, and CS stop arguing.

Official HubSpot docs (worth bookmarking)

• Create and use custom events
• Analyze custom events

Want this implemented cleanly (without CRM clutter)?

If you want a tracking plan that’s actually reportable—and doesn’t turn your portal into a mess—I can help you design the event taxonomy, identity mapping, and reporting so your team can trust the numbers.

Contact DnA Tech Solutions or book a strategy call here: Book a strategy call.