# Product usage data in HubSpot: build a reliable PQL and sales workflow

Canonical URL: https://www.martechdevs.com/blog/product-data-in-hubspot

By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo)

Data Engineer and Co-founder, martechdevs

Published: 2025-05-29

Last updated: 2026-09-29

To make product data useful in HubSpot, sync a small set of trustworthy user and account summaries, connect them to stable CRM identities and attach a clear action to each signal. Keep detailed event history in the product analytics system or warehouse. Use HubSpot to show who needs attention, what changed and why the team should act now.

A sales rep can see every email a prospect opened and still miss the most useful fact: the prospect's team connected its data source, invited four colleagues and completed the core workflow three times this week.

That gap rarely requires another dashboard alone. It requires the right product facts on the right CRM record, with enough context to make a sensible next step.

## Start with one decision the data should improve

Choose a narrow operating question, such as “Which trial accounts should receive a personal onboarding offer today?” Define the owner, expected response and outcome before choosing a connector.

For that question, useful inputs might be account fit, activation state, trial end date, recent successful usage and an unresolved setup blocker. A raw stream of every page view adds volume without necessarily improving the decision.

[Martechdevs' CRM and lifecycle service](https://www.martechdevs.com/crm-lifecycle) connects product behaviour to the views and workflows teams use. Where several systems need to be joined, the implementation also involves [warehouse and CDP design](https://www.martechdevs.com/data-warehouse-cdp).

Treat the first release as a complete decision loop: signal arrives, the right person acts, and the result is recorded. A green connector status covers only one part of that loop.

## Define the record grain before the fields

Decide whether the commercial unit is a person, workspace, company or subscription. In B2B software, product activity often belongs to a workspace while the buying relationship belongs to a company.

A person can belong to several workspaces. A company can operate several subscriptions. An agency contact may work across unrelated client accounts. Email domain matching alone cannot represent all of these relationships safely.

Create an identity map that preserves:

```text
product_user_id -> HubSpot contact ID
product_account_id -> HubSpot company or workspace record ID
membership -> user, account, role and effective dates
billing_customer_id -> commercial account ID
```

Use durable product IDs as the source identity. Keep the resulting HubSpot IDs for subsequent updates and record merges. An email change should not create a second person if the underlying product identity is unchanged.

If several workspaces map to one company, define the aggregation: sum usage, count distinct active users across all workspaces, or expose the highest-priority workspace separately. Do not let whichever workspace synced last overwrite the company's entire usage picture.

Custom objects can represent richer relationships when the account supports them. A simpler account summary on a standard company record may be enough for the first workflow. Confirm the actual object and feature entitlements rather than assuming every design works on every subscription.

## The first useful property set

Use a dedicated property group with descriptions, owners and internal names. A practical initial set is:

- `product_account_id`: the stable account key.
- `product_plan`: a controlled value that matches your plan dictionary.
- `trial_ends_at`: the actual trial end timestamp.
- `activated_at`: the first time the defined activation condition was met.
- `active_users_7d`: distinct eligible users with qualifying activity in the last seven days.
- `core_actions_7d`: successful core actions in that window.
- `last_core_action_at`: the latest qualifying action time.
- `usage_limit_pct`: usage divided by the relevant entitlement, where meaningful.
- `pql_status`: the current qualification state.
- `pql_reason`: a concise explanation of the qualifying conditions.
- `usage_observed_through`: the latest source-data time included in the calculation.
- `usage_synced_at`: the last successful delivery time to HubSpot.

These are illustrative custom property names, not built-in HubSpot fields. Choose types deliberately: counts as numbers, dates as timestamps and statuses as controlled options.

The two freshness fields answer different questions. A successful sync at 10:00 can contain data only through yesterday. Showing both prevents a fresh delivery timestamp from disguising stale source data.

## Properties and events serve different purposes

A property represents the current summary: an account has four active users this week. An event records something that happened: a user completed an export at a particular time.

Use properties for sales views, routing and current qualification. Use selected events when the timing and occurrence itself matter, such as the first successful integration or a request for an enterprise feature.

HubSpot's current custom-event documentation lists availability across several Professional and Enterprise products and describes API, import and other creation routes. Webhook-based setup has additional product requirements. Older blanket advice that all custom events require Marketing Hub Enterprise is therefore too broad. [HubSpot custom-event requirements](https://knowledge.hubspot.com/reports/create-custom-events).

A particular connector can still have narrower requirements. Verify its specific action and your portal's entitlement together. Do not infer that a general HubSpot capability automatically makes every third-party event integration compatible.

## Route 1: Segment for selected events and profile updates

Segment's HubSpot Cloud-Mode Actions destination supports mapped contact and company updates and custom-event actions. It gives explicit control over which incoming events produce which destination actions. The classic destination is in maintenance mode, so a new implementation should evaluate the current Actions destination. [Twilio's HubSpot Actions documentation](https://www.twilio.com/docs/segment/connections/destinations/catalog/actions-hubspot-cloud), [classic destination status](https://www.twilio.com/docs/segment/connections/destinations/catalog/hubspot).

Use it when Segment already receives the relevant product signals and the required transformation is simple. Create an allowlist of properties and events; do not forward the entire tracking plan by default.

Pay attention to company matching. The current destination uses a stable company identifier for its company action, while existing CRM companies may need an explicit matching strategy. Test contact creation, company creation and the association in the intended order. A company-name property on a contact is not the same as a CRM association.

Segment's documentation still describes an Enterprise requirement for some custom behavioural-event actions. Treat that as a connector-specific compatibility check against HubSpot's newer event documentation, and test the exact action before buying an upgrade. [Destination requirements and mappings](https://www.twilio.com/docs/segment/connections/destinations/catalog/actions-hubspot-cloud).

For a wider collection decision, see [Segment versus RudderStack](https://www.martechdevs.com/blog/segment-vs-rudderstack).

## Route 2: warehouse summaries through reverse ETL

Use reverse ETL when qualification depends on several sources or rolling calculations. The warehouse can combine product activity, billing state, account fit and CRM ownership, then publish one row per destination record.

For example, build an `account_sales_context` model with a unique account key and the properties above. Recalculate it on a schedule appropriate to the workflow. An hourly or daily sales queue may be sufficient even when product events arrive continuously.

Hightouch's HubSpot destination supports object updates and upserts, events and list operations. Its documentation makes field matching, writable property types and null-handling behaviour explicit. [Hightouch's HubSpot destination](https://hightouch.com/docs/destinations/hubspot).

Choose **update-only** when the first release should enrich existing CRM records. Use **upsert** only after agreeing which missing product accounts should become new CRM records and who will own them.

Define null behaviour field by field. A missing plan because an upstream job failed should not clear a correct CRM value. A genuine change to “no active subscription” must not be ignored forever by a blanket “skip nulls” setting. Use explicit states and a freshness check to distinguish the two.

## Route 3: HubSpot's Snowflake Direct Sync

HubSpot now documents a Snowflake Direct Sync beta for Data Hub Enterprise or Smart CRM Enterprise. It maps a Snowflake table or view into CRM objects on a schedule. The direction is Snowflake to HubSpot; it is not real-time, two-way replication. Filtering belongs in the source view because the documented sync does not apply filters itself. [Snowflake Direct Sync](https://knowledge.hubspot.com/integrations/sync-snowflake-data-to-hubspot).

The same documentation distinguishes direct sync from a single warehouse source, which does not consume HubSpot Credits, from preparing data in Data Studio, where relevant actions can consume credits. Warehouse compute and other contracted costs still exist.

Use a curated view with only the required rows and columns. Give the integration the relevant warehouse and data permissions. The fact that a connector can browse a schema is not a reason to expose every raw table.

This route is different from exporting or sharing HubSpot data **into Snowflake**. Always draw the direction before evaluating a feature called “Snowflake integration.”

![Product, billing and CRM data form one row per sales account, sync into HubSpot properties and associations, and drive qualification; recorded sales outcomes return to the model.](https://www.martechdevs.com/assets/blog/product-data-in-hubspot.svg)

## Build a PQL rule that explains itself

A product-qualified lead, or PQL, should indicate meaningful product use by an account that fits the business. It should not merely reward the largest number of clicks.

For a fictional collaboration product, start with hard eligibility gates:

```text
Eligible account:
- target market and supported use case
- not an employee, test or excluded account
- current source data within the agreed freshness limit
- no conflicting active sales process

Qualifying behaviour:
- core workflow completed on at least 3 distinct days in 7 days
- at least 2 distinct active users in 7 days
- at least 1 relevant expansion or buying signal
```

These thresholds are illustrative. They need validation against the product's actual conversion patterns. A developer testing an API thousands of times should not outrank a real buying team solely because event volume is higher.

If a numeric score helps prioritise eligible accounts, cap repetitive activities and preserve the components. HubSpot supports fit, engagement and combined scoring, with object availability, limits and associated-contact aggregation depending on the subscription. Review the aggregation deliberately: summing every associated contact can favour large accounts even when no individual has strong intent. [HubSpot lead scoring](https://knowledge.hubspot.com/scoring/build-lead-scores).

A useful reason might read: “Three active teammates, core workflow used on four days, 86% of plan capacity.” That gives the rep a conversation starter and lets operations inspect the rule.

## Qualification needs an expiry and a transition policy

Define what happens when an account qualifies, drops below the threshold and qualifies again. Otherwise, a rolling score can create a new task every time it oscillates around a boundary.

Store `pql_first_qualified_at`, `pql_last_qualified_at`, the rule version and the last handled qualification episode. Use a cooldown appropriate to the sales process. A reopened opportunity or a fresh explicit request may justify re-entry; an unchanged daily sync usually should not.

Do not overwrite the broad CRM lifecycle stage every time a product score changes. Product qualification, commercial lifecycle and sales ownership describe different dimensions. A paying customer can show expansion intent without becoming a new lead.

Keep acquisition PQLs separate from customer expansion signals and support-risk signals. The owner and next action differ even when some underlying usage properties overlap.

## Give sales a queue they can use

A working view should show account name, owner, plan, trial end, qualification reason, last meaningful activity, freshness and current opportunity state. Include a direct link to the relevant product workspace or internal account view where access is appropriate.

Create a task only when the account crosses the agreed threshold and no equivalent task is already open. Specify the response window and a small set of outcomes: contacted, accepted, not a fit, already engaged or signal incorrect.

Use the feedback to improve the model. “Signal incorrect” should lead to a reason such as stale data, wrong association or misleading activity. A generic dismissal provides little information about what needs repair.

[Stripe and HubSpot integration](https://www.martechdevs.com/blog/stripe-hubspot) adds the billing context that helps distinguish a trial opportunity from a payment-recovery issue.

## Validate with cases that can break the model

Test a new user, an email change, a company merge, a person in two workspaces, a workspace with no recent events, a late-arriving event and a failed source refresh.

Also test zero activity. If the model starts from the events table, inactive accounts can disappear from the output instead of receiving a zero. Build from the eligible account population and join activity onto it so inactivity remains visible.

For a fictional pilot of 100 eligible accounts, manually inspect all newly qualified accounts and a sample of those below the threshold. Track sales acceptance and later conversion by qualification version. Do not claim the score works because its highest band contains more activity; activity is what the score was designed to count.

## Implementation checklist

- [ ] Person, workspace, company and billing identities are mapped.
- [ ] One destination record has one defined summary grain.
- [ ] Every property has a type, owner and calculation definition.
- [ ] Source freshness and delivery freshness are separate.
- [ ] Connector actions and plan entitlements are verified together.
- [ ] Null, zero, deletion and merge behaviour are tested.
- [ ] Qualification has exclusions, expiry and re-entry rules.
- [ ] Sales receives a reason and records the outcome.
- [ ] The pilot compares useful business outcomes by rule version.

At Martechdevs, we connect CRM, product and billing data to the customer workflows your team needs to run. Start with the [free martech AI audit](https://www.martechdevs.com/martech-ai-audit), or explore an [AI assistant built around your approved workflows](https://www.martechdevs.com/custom-martech-ai-agent).

## Frequently asked questions

### Do I need to send every product event to HubSpot?

No. Send current summaries and selected events that support a defined workflow. Keep detailed event history where it can be analysed and recomputed without overwhelming CRM records or creating unnecessary integration work.

### Can Snowflake sync directly into HubSpot?

Yes, HubSpot documents a scheduled Direct Sync beta for specified Enterprise products. Confirm availability and permissions in your portal. It is separate from the feature that makes HubSpot data available in Snowflake.

### Can I calculate PQL scores outside HubSpot?

Yes. A warehouse or application service can calculate the status, score and explanation and sync them as properties. Assign one owner to the calculation so a HubSpot workflow does not repeatedly overwrite the external result.

### Which usage metric should sales see first?

Start with the action most closely connected to receiving product value, its recency and the account context. Logins can be useful supporting information, but successful use of the core workflow is often a more informative starting hypothesis.

### How do we stop stale data creating bad outreach?

Expose the observation cutoff, set a freshness threshold and suspend qualification when the source is too old. Alert the integration owner. Preserve the previous valid values while making their age visible instead of silently treating them as current.

## Sources

1. [HubSpot: custom events](https://knowledge.hubspot.com/reports/create-custom-events). Accessed 29 September 2026.

2. [Twilio Segment: HubSpot Cloud-Mode Actions](https://www.twilio.com/docs/segment/connections/destinations/catalog/actions-hubspot-cloud). Accessed 29 September 2026.

3. [Twilio Segment: classic HubSpot destination](https://www.twilio.com/docs/segment/connections/destinations/catalog/hubspot). Accessed 29 September 2026.

4. [Hightouch: HubSpot destination](https://hightouch.com/docs/destinations/hubspot). Accessed 29 September 2026.

5. [HubSpot: Snowflake Direct Sync](https://knowledge.hubspot.com/integrations/sync-snowflake-data-to-hubspot). Accessed 29 September 2026.

6. [HubSpot: lead scoring](https://knowledge.hubspot.com/scoring/build-lead-scores). Accessed 29 September 2026.