Scoring rules
A scoring model is a short list of rules that describe what a good-fit visitor does. This page explains every signal type, how weights and recency combine into a score, how to choose a threshold, and how to test changes safely against real history.
On this page
How a score is calculated#
Each rule pairs a signal with a weight. Whenever a visitor does something that matches a rule, the weight is adjusted for recency and added to their score. The total is capped between 0 and 100 and recalculated in under 400 ms after every event, so the score your team sees always reflects the latest behavior.
score = clamp( Σ ( rule weight × recency multiplier ), 0, 100 )Every score is explainable. The visitor profile lists the contributing rules in order, so anyone on your team can answer “why is this lead qualified?” in one sentence — no black-box model, no hidden features.
Signal types#
| Signal | Matches when | Typical weight |
|---|---|---|
| Page viewed | A page URL matches an exact path, a prefix or a pattern (/pricing*) | +5 to +30 |
| Page category | Any page in a category you define, such as Case studies or Comparison pages | +4 to +15 |
| Repeat session | The visitor starts a new session within a time window you set | +10 to +20 |
| Time on page | Active (visible, focused) time on a page exceeds a threshold | +3 to +10 |
| Custom event | An event sent with aurora('track', …), such as demo_video_played | +5 to +30 |
| Email engagement | An open or click from a connected email tool or CRM | +2 to +8 |
| Visitor trait | A trait from identify or the CRM, such as plan = trial | +5 to +20 |
| Account trait | Company size, industry or country from account resolution | +5 to +15 |
URL matching#
Page rules support three match types. Exact matches one path only. Starts with matches a path and everything below it, which is the right choice for most rules. Pattern accepts * wildcards anywhere, for example /*/pricing for localized sites. Query strings and fragments are ignored unless you enable Match query string.
Weights#
Weights range from −50 to +50. A useful way to set them is to ask: how many times would a visitor need to do this before we'd want to talk to them? If two pricing visits and a return session should qualify someone at a threshold of 60, pricing is worth about 24 and a return session about 12–18.
- Strong intent (pricing, demo request, trial activation, integration docs): +15 to +30.
- Supporting interest (case studies, comparison pages, product tours): +6 to +15.
- Background research (blog, general docs, changelog): +1 to +5.
Scoring frequency#
By default, a rule scores once per session, so reloading the pricing page ten times in a minute still counts once. You can change this per rule to once per visitor (for one-time milestones such as a signup) or every time (for events that are genuinely meaningful each time they happen).
Recency multipliers#
Interest fades. Aurora applies two multipliers so scores reflect intent right now:
| Multiplier | Default | Effect |
|---|---|---|
| Repeat boost | ×1.5 | A repeat visit to the same high-value page within 24 hours scores 1.5 times its weight. |
| Gap decay | ×0.5 | The first activity after a gap of 21 days or more scores half its weight. |
| Score decay | −10% / week | Scores of inactive visitors decrease by 10% for each full week without activity. |
All three can be adjusted or turned off under Scoring → Settings. The reasoning behind the defaults is explained in What we learned rebuilding the scoring model.
Negative signals#
Some behavior is a strong sign that a visitor is not a buyer. Negative rules keep them out of your team's queue:
- Careers pages (−20 to −40): job seekers often read pricing and product pages too.
- Support and login pages (−10 to −30): existing customers shouldn't be routed as new leads. Better still, exclude identified customers entirely with a trait rule.
- Competitor email domains (−50): competitors research your pricing more thoroughly than anyone.
- Very short sessions (−5): single-page visits under 10 seconds are usually accidental.
Choosing a threshold#
The threshold is the score at which a visitor becomes qualified and is routed to your team. The default of 60 is a reasonable starting point; the right number depends on how many leads your team can work well each day.
- Estimate capacityDecide how many qualified leads per rep per day is realistic — most teams land between 5 and 15.
- Use the distribution chartScoring → Threshold shows how many visitors from the last 30 days would have qualified at each score. Move the slider until the daily average matches your capacity.
- Check against outcomesIf you've connected a CRM, the chart also shows how many visitors at each score later became opportunities. Look for the score where that rate rises sharply.
- Review after two weeksAsk your team which alerts weren't worth their time, then raise weights on the signals the good leads shared and lower the rest.
Status labels follow the threshold automatically: Ready at or above the threshold, Warm within 15 points below it, and New for everything else. You can rename the labels and change the Warm band in Scoring → Settings.
Backfill and re-scoring#
When you install through Segment or Google Tag Manager, Aurora imports the previous 30 days of history so your first rules have real data to run against. You can also import historical page views from a CSV under Settings → Import.
Changing a rule never rewrites history silently. When you save a change, you choose whether it applies to new activity only or triggers a re-score of all visitors active in the last 30 days (Starter) or 90 days (Team and Scale). Re-scoring runs in the background and typically completes in a few minutes. Visitors who newly cross the threshold during a re-score are marked qualified but are not alerted, so a rule change never floods your team with old leads.
Testing rules safely#
Every rule can be saved as a draft. Drafts appear in the preview panel with the number of visitors they would affect and the change in qualified leads per day, but don't change any live score. When you're happy with the result, choose Publish. Each publish is recorded in the rule history with the author and a diff, and any previous version can be restored in one click.
Change one or two rules at a time and give each change a week. Adjusting everything at once makes it impossible to tell which change helped.
Example model#
A starting model for a B2B SaaS product with a free trial. Adapt the paths and events to your own site.
| Rule | Signal | Weight | Frequency |
|---|---|---|---|
| Pricing page | Page viewed, starts with /pricing | +24 | Once per session |
| Came back | Repeat session within 7 days | +18 | Once per session |
| Integration docs | Page viewed, starts with /docs/integrations | +11 | Once per session |
| Case study | Page category Case studies | +8 | Once per session |
| Trial started | Custom event trial_started | +20 | Once per visitor |
| Invited a teammate | Custom event teammate_invited | +15 | Once per visitor |
| Job seeker | Page viewed, starts with /careers | −30 | Once per visitor |
| Existing customer | Trait customer = true | −50 | Once per visitor |