HubSpot ↔ Snowflake Integration Playbook: Reverse ETL, Events, and Audiences

This playbook shows how to build a robust HubSpot ↔ Snowflake integration that moves data in both directions: warehouse → HubSpot for audiences and properties, and HubSpot → warehouse for analytics and attribution. You will learn patterns for extracting and modeling HubSpot data in Snowflake, designing reverse ETL models, managing identities, governing PII, and measuring success with reliable observability.

Primary keyword: hubspot snowflake integration (US monthly searches ≈ 140; intent: commercial). Supporting terms: hubspot to snowflake, snowflake to hubspot, hubspot reverse etl, hubspot events warehouse.

Why HubSpot and Snowflake Belong Together

HubSpot is the operational home for marketing and sales engagement. Snowflake is where your company integrates data from product usage, billing, and support to find the signals that matter. Without an intentional integration, marketers are stuck with stale or incomplete lists, and analysts cannot reconcile HubSpot with product and finance. A two‑way pipeline closes the loop: your warehouse powers targeting in HubSpot, and HubSpot powers attribution and revenue analytics in the warehouse.

Integration Outcomes

The integration should deliver three durable outcomes:

Clean, modeled HubSpot data available in Snowflake for reporting and machine learning.
Fresh, governed properties and audiences in HubSpot derived from warehouse facts (e.g., PQL score, active seat count, churn risk).
A consistent identity strategy that joins product, billing, and marketing identities without leaks or duplicates.

End‑to‑End Architecture

An opinionated but flexible architecture:

Ingest HubSpot: pull CRM objects (Contacts, Companies, Deals, Tickets, Activities) and Engagement events via API or file exports into Snowflake staging tables on a schedule.
Model in Snowflake: use SQL transformations to build clean, incremental models keyed by surrogate IDs and a stable identity spine.
Build reverse ETL models: materialize narrow, purpose‑built models that produce HubSpot‑ready properties and audience membership.
Push to HubSpot: update Contact/Company properties and static/dynamic lists; optionally send custom events for engagement workflows.
Observe: monitor freshness, volume, error rates, and effect on HubSpot marketing contact counts.

Implement each step as code with repeatable orchestration (dbt + a scheduler + a reverse ETL tool or simple jobs) so the pipeline is testable and auditable.

Extracting HubSpot Data into Snowflake

You can extract HubSpot data via API pagination or bulk exports. For daily analytics, a once‑hourly pull is often sufficient. Key practices:

Use updated‑since filters to fetch only changed records; store a high‑water mark per object.
Request only needed fields, but maintain a “full snapshot” job weekly to catch schema drift.
Normalize property names and types on landing; cast dates and numbers, lower‑case enums, and keep raw text fields unmodified in a separate column.
Persist raw JSON payloads in an audit table for forensic needs.

For Engagements and Activities, use HubSpot’s associations APIs to reconstruct timelines. Avoid one giant denormalized table; model a star schema that keeps facts (emails, calls, meetings) separate from dimensions (contacts, companies, owners).

Modeling HubSpot in the Warehouse

The warehouse model should make analysis and reverse ETL easy:

Contacts and Companies: create cleaned dimension tables with stable surrogate IDs and natural keys (email hash, domain). Maintain SCD Type‑2 rows when values change materially.
Deals: model a fact table with stage entries (one row per stage change) so you can compute stage aging, conversion, and velocity. Keep amounts and currency rates separate for consistent reporting.
Activities: build narrow, queryable facts for emails, meetings, and tasks with consistent timestamp fields and participant keys.
Campaigns and UTMs: build a normalized mapping of campaigns and utm parameters to maintain consistent attribution across systems.

Store mapping tables that connect HubSpot owner IDs to internal employee IDs and team structures; these become essential when joining to product usage or support data.

Identity Spine and Joining Across Systems

Identity is the hard part. Create an identity spine that brings together:

Contact: email (normalized and hashed), contact ID, and any product account IDs.
Company: website domain (normalized), company ID, billing account ID, and CRM account number.
User/product identity: application user IDs, device IDs (if relevant), and account memberships.

Your spine resolves many‑to‑many relationships and survives changes like email updates or domain changes. Prefer a deterministic priority for joins (e.g., product user ID → contact email linkage outranks email‑only matches). Store edge provenance (which system created the linkage) so you can debug and repair.

Reverse ETL Design Principles

Reverse ETL is not simply “write columns back.” It is a productized publish step:

Each reverse ETL model has a single owner and a single purpose (e.g., a PQL score, a churn risk flag, a list of customers with unpaid invoices).
Models should be narrow (a few columns), versioned, and tested for nulls and ranges.
Outputs map to HubSpot Contact or Company properties and optionally to list membership or custom events.
All writes are idempotent and bound by rate budgets; throttling protects HubSpot marketing contact limits.

Keep reverse ETL changes behind a feature flag until the business owner validates performance.

Pushing Properties to HubSpot

When writing properties:

Create properties in HubSpot with correct field types and labels; avoid free‑text where enumerations suffice.
Write only properties that changed since the last run; include a checksum column in Snowflake to detect real changes.
Use batch update endpoints to reduce API overhead; respect 429 responses with backoff.
For booleans and flags, treat null deliberately; avoid wiping fields unless the model explicitly says “unset.”

For sensitive attributes (e.g., churn risk), consider whether to expose to all users in HubSpot or keep internal only in a custom object with limited access.

Building Audiences and Lists

Warehouse models can define audiences more precisely than UI filters. There are two primary approaches:

Push computed list membership directly via a batch update of a list (static list pattern). This is simple and predictable, but membership only changes on job runs.
Push properties and let dynamic lists in HubSpot handle membership continuously. This is more flexible but requires stronger guardrails to avoid promoting too many marketing contacts unintentionally.

In both cases, publish a README for each audience: definition, owner, refresh cadence, and downstream campaigns.

Events: Warehouse to HubSpot and Back

Sometimes you need more than properties. Publishing key events into HubSpot enables workflows and scoring. Examples: “Trial Activated,” “Usage Milestone Reached,” “Subscription Churned.”

When you publish events:

Define a canonical event dictionary with fields, types, and privacy flags.
Use idempotent event IDs derived from natural keys (user ID + event timestamp) so replays do not duplicate.
Ensure events do not inadvertently make Contacts “marketing” unless intended; keep audience promotion explicit.

For outbound, capture HubSpot form submissions, email sends/opens/clicks, meetings, and ticket events into Snowflake. Normalize timestamps and join to your identity spine to make engagement analytics meaningful.

Observability for the Data Plane

Observability is the difference between a helpful pipeline and midnight pages. Track:

Freshness per model (max updated_at vs. now) with alert thresholds.
Volume per run and per day; watch for spikes that may indicate runaway marketing contact promotion.
Error rates by source (API failures, schema change, permission) with actionable messages.
SLA compliance: p95 time from data arrival in Snowflake to property updated in HubSpot.

Dashboards should allow operators to drill from a failing run to the specific contacts or companies affected.

Privacy, PII, and Data Residency

Minimize PII replication. Keep only the fields you need in Snowflake, and mask or hash sensitive identifiers when possible. Avoid copying email bodies into the warehouse unless analytics demands it; if you must, encrypt at rest and lock access. For EU data, consider separate Snowflake accounts or schemas with access controls; document processing activities in your privacy inventory and implement deletion workflows that honor GDPR/CCPA requests across both systems.

Access Control and Least Privilege

Grant narrow roles in both systems. In Snowflake, separate warehouses for ingestion, transformation, and reverse ETL; grant the reverse ETL service role SELECT on curated models only and no access to raw engagement payloads. Use masking policies for sensitive columns like email and phone. In HubSpot, give the integration app permissions only to the objects and properties it needs. Keep secrets in a vault and rotate quarterly.

Error Handling, Retries, and Dead Letters

Treat failures as normal. Your pipeline should distinguish between:

Permanent errors: missing required properties, unknown picklist values, or permission denials. These go to a dead‑letter queue with a remediation note and a link to the source row.
Transient errors: API timeouts, short‑lived throttles, or network hiccups. Retry with exponential backoff and jitter; cap retries and surface an alert when the budget is exceeded.

Dead letters should be replayable after a fix without manual data patching. Store the minimal context required to reconstruct the outbound request: keys, property values, and the version of the mapping code that produced it.

Schema Contracts and Registry

Avoid “stringly typed” chaos. Define a schema contract for each reverse ETL model: required columns with types, allowed ranges, and whether null is acceptable. Keep these contracts in the repository, under version control, and load them into a tiny registry table that the job reads at runtime. If a contract changes, the job fails fast and alerts the owner to review downstream impacts before pushing bad data into HubSpot.

Multiregion and Data Residency

Global teams sometimes need region‑specific processing. Run separate pipelines by region where required, with their own Snowflake databases and HubSpot apps. Keep cross‑region movement minimal and document each flow. If you must centralize certain analytics, aggregate to non‑PII metrics before moving across regions.

Monitoring and Incident Response

Create a single operational dashboard that answers four questions: Is data fresh? Is volume normal? Are errors within budget? Are HubSpot marketing contacts within target? Hook alerts to your incident channel with clear runbooks:

Freshness breach: review the scheduler, check upstream dependencies (e.g., product events), and either pause reverse ETL or allow stale reads temporarily.
Volume spike: validate whether a real campaign or product change occurred; if unknown, freeze audience pushes until explained.
Error spike: classify new schema changes or permission rollouts; roll back the last change if needed.
Contact surge: stop audience promotion immediately and triage the responsible model; re‑enable only after an explicit sign‑off.

After incidents, hold a brief review and update mapping dictionaries, tests, and documentation.

Cost Examples and Right‑Sizing

For a mid‑market SaaS with 500k Contacts and 50k Companies, a practical setup might be: one small ingestion warehouse (auto‑suspend), one medium transformation warehouse running 15 minutes hourly, and a small reverse ETL warehouse running in short bursts. Monthly compute can land low four figures. The bigger cost is the team’s time when the pipeline lacks observability; invest there early. On the HubSpot side, be intentional about what properties and events you push—every extra field competes for user attention and time.

Secrets, Keys, and Security Reviews

Store credentials in a secrets manager, not env files committed to repos. Use least‑privilege API keys and rotate them quarterly. Where your security team requires, implement short‑lived credentials with workload identity and avoid long‑lived static keys. Keep an asset inventory of all places where HubSpot tokens and Snowflake keys live and review access quarterly. Build a simple “break glass” procedure to revoke credentials quickly if a laptop is lost or a token is leaked.

Disaster Recovery and Backfills

Disks fail, jobs stall, and APIs sometimes return wrong data. Plan for backfills: keep raw HubSpot payloads in low‑cost storage for a limited time so you can re‑land if needed; store reverse ETL outputs with a distinct job run ID so a bad run can be reverted or superseded. When you backfill, throttle writes to HubSpot to avoid rate limits and marketing contact surprises. Document a step‑by‑step backfill runbook in the repo and rehearse it at least once before you need it.

Audience Examples (Narrative)

Two high‑value audiences illustrate the approach:

“Activation Risk” targets accounts where fewer than two users performed a core action in the last seven days, AND no admin visited the billing page in a month. The warehouse model emits a boolean flag and the last‑seen dates; a reverse ETL job sets a activation_risk property on eligible Contacts and adds them to a dynamic list limited to admins. CSMs receive sequences to nudge adoption.

“Upsell Ready” targets customers whose usage is within 15% of their plan limit for three consecutive weeks AND whose NPS last month exceeded 8. The model emits an upsell_ready flag and a usage_pct metric; marketing uses a nurture that pairs education with a human‑touch offer. Because the model is narrow and well‑owned, changing the threshold from 15% to 20% is a one‑line config update with a visible diff and a preview of impacted contacts before push.

Data Dictionary and Mapping Narrative

Successful teams keep a living data dictionary. For each property pushed to HubSpot, document:

Definition in plain language and its SQL source.
Owner and business purpose.
Refresh cadence and backfill process.
Allowed values and what each means for campaigns and reporting.

Make the dictionary the first place marketers look when they wonder, “Can I target by this?”

Cost Management and Performance

Warehouse pipelines cost money when they do unnecessary work. A few ways to keep costs in check:

Incremental models everywhere; full refreshes only when schema changes.
Small batch sizes for reverse ETL writes; spread over time to smooth API and compute usage.
Partition large event tables by date and, where relevant, by account to keep queries fast.
Measure ROI using campaign effectiveness and sales cycle benefits, not just compute spend; a well‑targeted audience often pays for the pipeline in a single campaign.

Change Management and Testing

Treat data like code. Version models, properties, and audiences. Add tests for not‑null, unique keys, and distribution checks (e.g., churn risk should not suddenly be true for 80% of your base). Use preview runs to generate candidate property changes and compare against a sample of Contacts before pushing. Document each breaking change and coordinate with campaign owners.

Example: PQL Score to HubSpot

Suppose your product team defines a PQL score that combines weekly active users, key feature usage, and account fit. In Snowflake, you model a table of account‑level PQL scores and join it to Contacts that meet a role filter (e.g., admin or decision‑maker). Your reverse ETL model outputs contact_id, pql_score, and pql_tier. The job writes those to HubSpot, where dynamic lists pick up pql_tier = high for SDR sequences. Sales leaders see a dashboard that correlates PQL with conversion rates; marketing uses the same property to target webinars. Everyone trusts the number because the model is tested, versioned, and observable.

Example: HubSpot to Snowflake for Attribution

You build a deal stage fact table that records each stage entry, join it to campaign touchpoints derived from HubSpot email and ad events, and compute multi‑touch attribution in the warehouse. The model pushes “Primary Attribution Campaign” back to the HubSpot Deal for reporting while finance uses the warehouse view to reconcile sourced pipeline against bookings. When a marketer changes UTM tagging, tests flag the new source as unknown until they update the mapping dictionary.

Rollout Plan

Launch incrementally:

Land: extract a subset of objects (Contacts, Companies, Deals) into Snowflake and validate volumes.
Model: build cleaned dimension and fact models with a simple identity spine.
Publish: ship one reverse ETL property (e.g., active seats) to a small cohort; validate usefulness and data quality.
Expand: add audiences and events; implement freshness and SLA dashboards; add dead‑letter remediation.
Harden: add privacy controls, change review, and disaster recovery playbooks.

FAQ

Should I use a reverse ETL tool or build my own jobs?

Use a managed tool when you want speed and a maintained API surface; build your own when you need custom batching, privacy controls, or lower cost at scale. Many teams begin with a tool, then bring the top two pipelines in‑house later for cost control while leaving the rest in the tool.

How often should I refresh properties and audiences?

Most engagement properties update hourly; some account‑derived properties daily; and high‑volatility events rarely need to be in HubSpot at all. Choose cadences based on campaign needs and SLO cost. Faster is not always better if it burns contacts or thrashes compute.

How do I prevent promoting too many marketing contacts?

Keep audience promotion explicit. Never let an event write flip the marketing contact flag automatically. Require an allowlist and a “dry‑run” preview that shows contact counts before pushing.

What if my product has many users per account?

Push account‑level properties to the Company first and then down to Contacts who meet a role or activity threshold. Avoid putting every product counter on every Contact; focus on signals that change behavior.

How do I handle schema changes in HubSpot?

Run a weekly full snapshot to detect new fields. Use schema diff reports to decide whether to map new fields. Don’t automatically replicate everything; you’ll pay in storage and confusion.

Can I stream events in real time?

Yes, but start with batch. Streaming is useful for truly real‑time triggers like in‑app actions that should send an email within seconds. For most campaign use cases, minutes are fine and radically simpler to operate.