Trait rules
Get specific. Build conditions over any user trait you send Wakeline — combine them with AND/OR and operators like equals, in, contains, greater/less than, before/after, and exists.
Any trait you send
Plan, role, signup date, usage — target on whatever you pass to Wakeline.
AND / OR logic
Match all of your conditions, or any one of them.
Rich operators
Equals, in, contains, greater/less than, before/after, and exists.
Live in three steps.
Add a rule
Pick a trait, an operator, and a value.
Combine them
Stack rules with AND or OR.
Publish
Only matching users qualify.
One rule set, aimed at exactly the right accounts.
The upgrade nudge is the canonical trait-rule job: seats nearly full, on the plan below, decision-maker on screen. Every clause maps to a trait your app already knows.
Send the traits
Your identify() call includes plan, role, seats_used, and seats_limit. Traits are just key-values — anything your app knows about the user can become targeting.
Write the conditions
plan equals "pro" AND role equals "admin" AND seats_used greater than 8. Numeric comparison needs numeric traits — send 9, not "9 of 10".
Mind the operators
equals, in, contains, greater/less than, before/after, exists. before/after compares dates — signup_date before 2026-01-01 targets your veterans; exists checks presence with no value at all.
Combine with AND/OR
AND narrows, OR widens: (plan equals "pro" OR plan equals "business") AND seats_used greater than 8. Read the rule aloud — if the sentence is right, the targeting is.
What to expect: The slideout reaches only admins actually approaching their limit — measured in Reports by a click-through rate no broadcast blast ever hits, with zero users asking "why am I seeing this?"
When not to use trait rules.
No pattern fits every job. Here’s where we’d point you at something else — sometimes ours, sometimes not.
The same rules on every guide
Rebuilding "Pro admins over 8 seats" per flow invites drift — one guide says 8, another says 9. Save it as a segment once and reference it everywhere.
Traits you do not send yet
Rules match what identify() delivers. If plan is not in your traits, plan rules match nobody — silently. Check the traits arriving on a user profile before writing conditions against them.
Anonymous traffic
No identity, no traits, no matches. For visitors, target by audience and page URL instead — trait rules are a signed-in instrument.
Sensitive attributes
Send what targeting needs — plan, role, usage. Health data, precise location, and anything you would not want subpoenaed do not belong in a guidance tool's traits.
What traits can I target on?
Anything you send: identify(userId, { plan, role, seats_used, ... }) — strings, numbers, booleans, dates. Each extra trait becomes a targeting attribute immediately, for rules and for saved segments.
Which operators exist?
equals, in (any of a list), contains, greater than / less than for numbers, before / after for dates, and exists. Combine clauses with AND/OR to arbitrary depth — enough to express "trial admins in their second week" without code.
Why does my greater-than rule match nobody?
Almost always a type problem: the trait arrives as a string ("9 of 10") rather than a number (9). Numeric operators compare numerically, date operators need date-like values — send clean types and the rules behave.
When are rules evaluated?
At view time, against the user's current traits. Update a trait via identify() and targeting shifts with it — cross an 80% usage threshold today, see the relevant guide today, not after a sync.
Rules here or a saved segment?
Inline rules for one-off targeting; segments for any audience you will use twice. Segments also centralize edits — change the definition once and every guide that uses it follows.
See it on your own app.
Ship your first guide in minutes. Free to start — no credit card.