Onboarding flow targeting rules: who sees what, when

Onboarding flow targeting rules decide which users see which flow, and when. Teams treat that as a choice between one flow per persona and one flow for everybody, and that is the wrong fork. Most flows that misfire are not aimed at the wrong persona. They are aimed at the wrong moment.

A targeting rule isn't a description of a user. It's a condition that is either true or false when the flow is about to show.

Target the condition, not the persona

"Admin on a paid plan" is a persona. It tells you nothing about whether a walkthrough of the billing screen helps that person today.

The condition is what makes it useful:

• They are on the screen the flow talks about.
• They have not yet done the thing the flow is asking for.
• They are inside the window where they still count as new.

Page, event, and days since signup get you surprisingly far. Everything else is refinement.

Here is the difference, in one pair.

Weak rule
  Admin
  Paid plan
  New user

Useful rule
Show if ALL match
  Page is /billing
  Plan is one of pro, business
  Billing setup is incomplete
  Days since signup is under 14

The first rule describes who someone is. The second describes when the flow is useful. The first stays true for months. The second stops being true the moment the user finishes setting up billing, which is exactly when you want the flow to stop.

No-code targeting in Onbixo is built on those fields, plus user and company attributes, device, country and language. You pick the conditions from lists, so a product manager can write a rule without booking time from a data team.

Rules are groups, not a flat list

A list of conditions joined by AND runs out fast. Real audiences need nesting: on the reports page, AND either a paying customer or past their trial.

You build that with ANY and ALL groups, and a group can sit inside a group. The rule above, written out:

Show if ALL match
  Page URL contains /reports
  ANY of
    Plan is one of pro, business
    Days since signup is more than 14

Three habits keep a rule set readable:

• Save the audience once and reference it from every flow that needs it.
• Put the narrowest condition first, so the rule says what it is about.
• Use the words your app already uses. If the trait is plan, do not write a rule against tier.

Then test it. Reading a rule and checking a rule are different jobs. Run the rule against a real user and watch it pass or fail, because that is what catches the two mistakes behind most misfires: an ANY that should have been an ALL, and a trait name spelled one way in your identify() call and another way in the rule.

Two flows can match the same user

Segmentation guides skip this one. You write a tooltip for new users on the dashboard. Someone else writes an announcement for everyone on the dashboard. A user lands there on day two and qualifies for both.

Nothing is broken. Both rules are true.

The fix is a rule, not a setting. Make the conditions mutually exclusive: add "days since signup is more than 7" to the announcement and the overlap is gone. A rule you can read beats a priority order you have to guess at.

A flow that fires at the wrong moment is not a copy problem. It is a rule that was true when it should have been false.

How often is part of the rule

A condition that stays true can qualify the user again and again. Frequency capping decides how often that qualification can turn into a showing. "On the reports page" is true every single time the user opens reports.

Frequency capping matters most for messages that interrupt the user's work. A tooltip does exactly that: it appears on top of the task the user is trying to complete.

Every cap is one of three shapes. Once ever. A maximum number of times. A cooldown between showings. Pick the shape from the job: a welcome tour is once, a nudge toward an unused feature is a cooldown, and a flow someone already finished should never come back at all.

Pick the cap when you write the rule, not after the first complaint.

What targeting deliberately does not do

Targeting works on what your app already knows. Traits you pass with identify(), events your app fires, the page, the device, the country, the language. It does not read your warehouse and it does not guess at personality.

That is a narrower set of inputs than a marketing segmentation tool works with, and the narrowness is the point. Rules are evaluated at the moment the flow would show, so there is no nightly segment sync to go stale. And anyone on the team can open a rule and see exactly why a user saw something.

The thing to plan for: a rule can only use a trait you actually send. If you want to target on plan, pass plan in identify() before you write the rule. Device, country and language are derived server side, so those are there without any work from you.

The honest limit

There is no agreed answer to how many rules is too many. Teams that segment hard end up with flows nobody can audit, and teams that segment loosely show the wrong thing to somebody every day. Both failures are real and nobody has a number that settles it.

What helps is a habit rather than a threshold: if you cannot say out loud what a rule is for, it is too complicated, whatever the count.

The rule of thumb

Write the condition that has to be true, group it with ANY and ALL when one clause is not enough, then cap how often it can fire. If two flows can both be true for the same user, change a rule until they cannot.

Targeting only decides who gets a flow. Which flow to build is a separate question, and a tour and a checklist answer different jobs.

Target the moment, not the persona. The best targeting rule isn't the one that describes your audience most precisely. It's the one that identifies the moment when your flow is actually useful. Try it free.