What Progressive Profiling Is (and What It Is Not)
Progressive profiling replaces known form fields with new ones. When a contact submits a HubSpot form a second time, fields you already have values for swap out for fields you don't. The result: a shorter form every visit, a richer contact record over time.
It lives in HubSpot Forms, under the progressive fields panel. Available from Professional tier upwards.
What it is not: personalisation. Progressive profiling does not change the form headline, body copy, or surrounding page content. It changes which fields appear. Dynamic page personalisation requires Smart Content. It is a separate tool, on a different tier, with its own setup logic.
It is also not segmentation. You are not routing people to different forms. You are showing the same form with a different field set, based on what HubSpot already knows about that specific contact.
If your contact is anonymous (no tracking cookie, no email match to an existing record), progressive profiling does not fire at all. The form shows its default fields every time.
- Replacing known fields with unknown ones on a repeat submission
- A shorter form every visit
- A richer contact record over time
- Available from Professional tier, in the progressive fields panel
- Not personalisation, which needs Smart Content
- Not segmentation, since it is the same form with a different field set
- Silent for anonymous contacts with no cookie or email match
Why It Matters
The average B2B form asks for seven fields on first submission. Most of that data is not needed to start the conversation. But you do need it eventually to route, segment, and score leads accurately.
Progressive profiling is how you collect the depth without adding friction up front. The contact fills out a short form each time. You accumulate the picture over multiple touchpoints.
When it is set up wrong, one of two things happens. The form keeps asking for information the contact already gave because the progressive queue has not been configured to check existing property values. Or the form shows fields that make no sense for where the contact is in the journey, because there is no conditional logic tying the questions to context.
The first outcome is frustrating. The second signals to the contact that you are not paying attention. Neither converts well.
The Queue Model
The queue model is HubSpot's native progressive profiling approach. You define an ordered list of fields, up to 20 per form. Each time a known contact submits a form, HubSpot checks which fields in the queue still have no value for that contact. Those are the fields it shows next.
Set it up inside the form editor. Select a field, open the progressive fields panel, and add the properties you want to collect over time. Drag to set priority order.
The logic is simple:
1. Contact submits Form A with Name and Email.
2. On their next visit to any form with progressive fields enabled, HubSpot checks what it already knows about that contact.
3. Fields with existing values swap out. Fields from the queue with no value yet take their place.
4. This happens automatically, per contact, per form submission.
This model works well when your data collection needs are relatively flat. You have a list of properties you want to fill in across the database, and the order matters more than the context in which a given field is asked.
The limitation is that the queue does not account for why the contact is there. A contact downloading a case study and a contact booking a demo will see the same rotating fields, regardless of their intent or the stage of their relationship with you.
- 1Contact submitsA known contact submits Form A with name and email.
- 2HubSpot checksOn their next visit, HubSpot looks at what it already knows about that contact.
- 3Fields swapFields with existing values swap out, and queued fields with no value take their place.
- 4RepeatThis happens automatically, per contact, per form submission.
The Dependency Model
The dependency model introduces conditional logic. Fields appear based on what other properties already contain, not just what is empty.
HubSpot supports this natively through dependent fields, available from Professional tier. A dependent field only appears when a parent field has a specific value. Industry Subsector only appears after Industry is filled in. Number of Sales Reps only shows if Company Size indicates an organisation large enough to have a sales team.
You configure this in the form builder. Select a field, click Dependent field, and set the condition. Parent field equals value X, child field appears. You can chain these: a field's visibility depends on value A, and a further field only appears once both A and B are collected.
The dependency model takes more upfront work. Each field has a reason to exist, and that reason is encoded in the form logic. When underlying property definitions change, the logic needs updating too.
But the payoff is real. The form adapts to the contact's context, not just their data gaps. You stop asking a startup founder about enterprise procurement cycles, and stop asking a senior buyer whether they have decision-making authority.
When to Use Each Model
Use the queue model when:
You are collecting a standard list of firmographic or demographic properties across the database (job title, phone, region, company size).
The forms are early in the journey, where contact context is limited.
Your team needs a configuration that is fast to set up and easy to maintain across many forms.
You are on Professional tier and want to keep form logic lean.
Use the dependency model when:
Your properties have genuine parent-child relationships. Industry and subsector. Company size and headcount per team. Buying stage and budget authority.
You are collecting data mid-journey, where the contact's situation matters to which question you ask next.
You want to avoid irrelevant questions that signal you are not paying attention.
You are building a qualification flow where each answer unlocks the next question.
Do not use either model when:
You have one form and one traffic source. A single-entry-point setup gains nothing from progressive configuration.
The contact is anonymous. Progressive profiling only activates for contacts already in HubSpot with a cookie or email match.
You are on Starter tier or below. Dependent fields and the full progressive fields panel are Professional features.
- A standard list of firmographic properties across the database
- Forms early in the journey, where context is limited
- A configuration that is fast to set up across many forms
- Properties with genuine parent and child relationships
- Data collected mid-journey, where the situation matters
- A qualification flow where each answer unlocks the next
- One form and one traffic source
- The contact is anonymous
- You are on Starter tier or below
Tier Awareness
Free and Starter: basic form fields only. No progressive fields panel. No dependent fields. You can collect additional data through workflow-based property updates, but it is not the same mechanism.
Professional: full progressive profiling (up to 20 fields per form) and dependent field logic. Both models become available here.
Enterprise: same as Professional plus Smart Content. Relevant if you are combining progressive profiling with personalised form headlines, gated content, or dynamic page sections that change based on collected property values.
How It Interacts with the Rest of HubSpot
Progressive profiling connects to three other systems that need to stay aligned.
Contact properties
Every field in the progressive queue maps to a HubSpot property. If the property has inconsistent data types, mixed dropdown values, or no clear definition, the data collection will work but downstream segmentation and scoring will not.
Lead scoring
Lead scoring uses progressive field values as score triggers. If job seniority is a scoring trigger and you collect it on form submission three via progressive profiling, the score does not update until that third submission. Build the scoring model with this lag in mind.
Workflows and Smart Content
HubSpot does not distinguish between values collected through a progressive field versus a direct field. If a contact fills in a progressive field that triggers workflow enrolment criteria, the workflow fires immediately on submission. This is usually what you want, but test it before launch if the workflow has significant downstream effects.
Smart Content (Enterprise): you can use property values collected through progressive submissions to personalise surrounding page content on subsequent visits. The progressive collection and the Smart Content personalisation are separate configurations, but they compound. Progressive profiling builds the data; Smart Content uses it.
Common Failures
Configuring progressive fields on a form most contacts only ever see once. Progressive profiling is a returning-visitor feature. If your highest-traffic form is a one-time entry point (newsletter signup, event registration), the queue never cycles. You have added configuration complexity with no data return.
Setting up the queue without aligning the contact properties. Progressive fields collect into properties. If those properties have no clear definitions, inconsistent picklist values, or no team agreement on what the collected data means, the form data is noise from the moment it is submitted.
Ignoring that each form has its own progressive queue. A contact submitting Form A and Form B cycles through both queues independently. If both forms include Job Title in their progressive pool, HubSpot collects it once from whichever form the contact submits first. The second form does not re-ask. But if your field priorities differ between the two forms, the order in which properties get collected across forms may not match your intent.
Treating progressive profiling as a personalisation tool. The form does not know why the contact is there. It knows what it does not know about them. Asking fewer questions and asking contextually relevant questions are related goals, but they require different tools. Progressive profiling handles the former. Dependent field logic handles the latter at the field level only. Page-level context requires Smart Content.
What to Ship the Team
When you implement progressive profiling, development and operations need:
1. A property map showing which fields belong in the progressive queue and in what order, with the reason each field is prioritised where it is.
2. For dependency model implementations: a conditional logic diagram showing which field value triggers which dependent field, with the exact property values and field names used in the form builder.
3. A data hygiene note for any property entering the progressive queue. Mixed case, abbreviated text, and varied spellings already in the system will persist after collection starts. Clean the property first or the data coming in will be noise.
4. A pre-launch baseline. Pull the current percentage of contacts missing each property in the queue. This gives you a before-and-after comparison to measure fill-rate improvement after the forms go live.
If you are setting this up on a live portal, the order of setup matters more than the model you choose. We run it as part of Marketing Hub onboarding.
Across 50+ HubSpot projects, the setup sequence above is where most teams find the gap between what they configured and what reached the database.
Related.
Talk it through
If this maps to something you are wrestling with in your own portal, book a free thirty-minute consult and we will tell you where to start.
Book a free consultCommon questions.
What is progressive profiling in HubSpot?
Progressive profiling replaces form fields you already have values for with fields you don't yet know. When a known contact submits a HubSpot form a second or third time, the form shows a different set of fields based on what is already recorded against their contact. The result is a shorter form on each visit and a richer contact record over time. It is available from Professional tier upwards, inside the progressive fields panel of the form editor.
What is the difference between the queue model and the dependency model?
The queue model works through an ordered list of up to 20 properties. It collects each one in turn across multiple form submissions, regardless of the contact's context. The dependency model uses conditional logic: a field only appears when a parent field already holds a specific value. Industry Subsector appears after Industry is filled; Number of Sales Reps appears only when Company Size indicates a team large enough to have one. The queue model is faster to configure and suits standard firmographic collection. The dependency model takes more upfront work but stops the form asking irrelevant questions.
When should you not use progressive profiling?
Three situations where progressive profiling adds no value. First, when most contacts only ever see your form once: the queue never cycles on a single-visit entry point like an event registration. Second, when the contact is anonymous: progressive profiling requires a HubSpot tracking cookie or an existing email match to fire at all. Third, when you are on Starter tier or below: the progressive fields panel and dependent field logic are both Professional features. The mechanism is not available at lower tiers regardless of how the form is configured.