Dynamic vs. Static Groups: A Segmentation Playbook for PLG SaaS

Segmentation breaks down once signups outgrow a spreadsheet

Most PLG teams start segmentation in a spreadsheet or a CRM view: a list of "enterprise trials," another for "high-intent free users," maybe a tab for "churn risk." It works for the first few hundred signups. Then the product picks up momentum, the list goes stale within a week, and someone has to remember to re-pull it before the next campaign.

The underlying problem isn't the tool. It's that most segmentation is built as a one-time export instead of a standing rule. A user who matches "enterprise trial, week 2, no second seat added" today might not match it tomorrow, and nothing updates the list to reflect that.

Groups solve this by splitting segmentation into two modes: static, for lists that should stay fixed, and dynamic, for lists that should update themselves as enrichment and usage data change. Knowing when to use each is most of the work.

Two ways to group users

Static groups

A static group is a fixed set of members you add on purpose and don't expect to change automatically. Think of it as a named list: "Q3 webinar attendees," "beta testers for the new dashboard," "accounts in a signed pilot." Membership only changes when someone explicitly adds or removes a user or company.

Static groups are the right tool when membership is an event, not a state. Someone either attended the webinar or they didn't. That fact doesn't change based on their ICP score next week.

Dynamic groups

A dynamic group is defined by a rule, and membership is recalculated automatically as user and company data changes. In Groful, that rule can reference any enriched attribute: job title, company size, industry, ICP score, teammate count, or a custom attribute you've configured.

An example rule: "PERSON group, ICP score above 80, company size 50-500, signed up in the last 30 days." As new signups come in and existing users get re-scored, they move in and out of the group without anyone touching a list. That's the difference that matters at scale: the group reflects current reality instead of a snapshot from whenever someone last exported it.

Choosing between them

Signal	Use a static group	Use a dynamic group
Membership is based on an event (attended, invited, opted in)	Yes	No
Membership should reflect current attributes (ICP score, plan, company size)	No	Yes
You need the list to stay exactly as-is for reporting or an email send	Yes	No
You want the segment to grow and shrink automatically	No	Yes
The rule can be expressed with enriched attributes	Either works	Dynamic is less maintenance

A rough rule of thumb: if you'd have to manually re-check the list every week to keep it accurate, it should be dynamic. If manual control is actually the point, and you want to lock in exactly who's in a pilot cohort, keep it static.

Building a dynamic segmentation model that holds up

Start with attributes you actually enrich

Dynamic groups are only as good as the data behind them. Before writing rules, check which attributes are reliably populated for most of your signups: job title, company domain, company size, industry, and any ICP scoring fields you've already configured. A rule built on a field that's empty for 40% of users will produce a group that misses real accounts, not one that's simply smaller.

Layer conditions instead of stacking one big rule

Broad rules like "ICP score above 60" catch too much. Narrower ones like "ICP score above 80 AND company size 100+ AND signed up in the last 14 days" catch too little as soon as timing shifts. A more durable pattern is to build a small set of layered groups instead of one catch-all:

• A wide group for ICP-qualified signups, used for general nurture.
• A narrower group for high-score signups at target company sizes, used for sales-assist routing.
• A time-boxed group for recent signups still in their first two weeks, used to drive onboarding personalization.

Each group answers one question. Combining them at the point of use (in an email tool, a CRM view, or a Slack alert) is more flexible than trying to encode every condition into a single rule.

Group companies, not just people

Groful supports groups for both people and companies. Company-level groups matter for PLG because expansion decisions are usually made at the account level, even when the product is used by individuals. A COMPANY group like "3+ ICP-scored teammates, no expansion conversation started" surfaces accounts worth an outbound touch even if no single user in that account looks like an obvious upsell target on their own. It's the same signal that powers teammate discovery, just as a standing view instead of a one-off report.

Re-check rules after ICP changes

If you update your ICP profile, say a new target industry or a revised company size range, every dynamic group built on ICP score should be reviewed. The group will update its membership automatically, but the rule itself won't adjust to a redefinition of what "ICP fit" means. Treat ICP profile edits as a trigger to audit dynamic groups, not just a scoring change.

Common mistakes

Teams often pull a dynamic group into a spreadsheet for a one-off campaign, then keep reusing that spreadsheet for the next three. That quietly turns a dynamic group into a stale static one, and nobody notices until the numbers look off.

Another one: a dozen dynamic groups with barely different thresholds. "ICP 70+," "ICP 75+," "ICP 80+ with 2 teammates" all exist at once, and nobody remembers which one is supposed to be authoritative for outbound versus onboarding. Fewer, clearly-named groups with a documented purpose beat a sprawling list nobody fully understands.

Group definitions also need an owner. Left alone, dynamic groups drift out of usefulness as the product and ICP evolve. Put one person, usually on growth or RevOps, in charge of the group list and let them prune the ones that aren't tied to an active workflow.

And watch for static groups doing a dynamic group's job. A static "high-intent trial" list built two weeks ago just tells you who was high-intent two weeks ago. If the use case is time-sensitive, it almost always belongs in a dynamic group instead.

A rollout checklist

1. List your current segmentation lists, spreadsheets, and CRM views. Mark each one as event-based or attribute-based.
2. Convert attribute-based lists to dynamic groups first. Those are the ones going stale right now.
3. Keep event-based lists (webinar attendees, pilot cohorts, beta testers) as static groups.
4. Define 3-5 dynamic groups covering your main workflows: nurture, sales-assist routing, onboarding personalization, and expansion.
5. Assign an owner to review group definitions whenever ICP profiles change.
6. Connect groups to the tools that act on them: email, CRM, Slack alerts, or webhooks, so membership changes actually trigger something.

Segmentation isn't a one-time project. The signup volume that made a spreadsheet unworkable is the same signup volume that makes rule-based groups worth setting up. Groful enriches every signup with the attributes these rules depend on, then lets growth teams and RevOps build both static and dynamic groups on top without exporting a single list by hand. Check pricing or get in touch to see how it fits your current segmentation setup.