Skip to main content

Surge Triggers

Surge triggers fire when a lead's activity spikes sharply — for example, three or more high-value events in a short window. Where milestone triggers respond to a cumulative score, surge triggers respond to sudden acceleration in a lead's engagement. Use them to catch leads who went from cold to hot in a matter of hours.

How Surge Triggers Work​

kenbun continuously monitors engagement velocity for every lead. When a lead's activity rate in a rolling window exceeds the threshold you configure, the surge trigger fires and sends a notification — even if that lead's overall score hasn't crossed a milestone yet.

This makes surge triggers especially useful for:

  • Catching re-engaged leads who have been quiet for weeks but suddenly return with a burst of activity
  • Alerting sales to time-sensitive intent signals before a competitor does
  • Monitoring leads who are rapidly moving through your content without yet having filled out a form

Creating a Surge Trigger​

  1. Navigate to Configure > Triggers > Surge
  2. Click New Surge Trigger
  3. A panel slides in from the right side. Configure the trigger settings:

Basic Settings:

  • Event Type: The type of event to monitor (e.g., page_view, email_open). Leave as All Events to monitor every event type.
  • Threshold: The minimum number of events that must occur within the time window to fire the trigger.
  • Time Window: How long the rolling window lasts. Enter a number and choose Minutes, Hours, or Days.

As you fill in these fields, a live explanation sentence updates to confirm exactly what the trigger will do — for example: "This trigger will fire when a lead generates 5+ page_view events within 2 hours."

Notification Channel:

Select a saved Notification Channel to route the alert. Channels must be created before configuring a surge trigger — if none exist, a link guides you to set one up.

Activate Immediately: Toggle on to activate the trigger as soon as you save it. Leave it off to save in a paused state and enable it manually later.

  1. Click Save

Backtesting a Surge Trigger​

The panel includes a Backtest section that lets you test a saved trigger against a specific lead's event history before relying on it in production. This helps you confirm that the threshold and time window are calibrated correctly.

Backtesting is only available for saved triggers. Save the trigger first, then reopen it to run a backtest.

Running a Backtest​

  1. Open an existing surge trigger from the list (click the row)
  2. In the Backtest section, search for a lead by email or Lead ID
  3. Set the Lookback (days) — how far back into the lead's history to scan (1–90 days, default 30)
  4. Click Run Backtest

Understanding Backtest Results​

ResultWhat It Means
Would FireThe trigger's conditions were met for this lead at least once during the lookback period
Would Not FireThe lead's activity did not exceed the threshold in any time window during the lookback period
Matched windowsClick to expand a list of the specific time windows where the threshold was exceeded, including window start and end times and the event count

If the trigger would fire more often than expected, consider raising the threshold or narrowing the time window. If it never fires for an active lead, the threshold may be set too high.

Backtest via API​

You can also run a backtest programmatically using POST /surge-triggers/{id}/simulate. See the Surge Trigger Simulate API documentation for full details.

Notification Payload​

The webhook payload for a surge trigger looks like:

{
  "trigger_type": "surge",
  "lead_id": "ld_123",
  "event_count": 7,
  "explanation": "Lead 'Jane Doe' generated 7 page_view events within 2 hour(s).",
  "snapshot": {
    "event_type": "page_view",
    "count": 7,
    "threshold_count": 5,
    "window_seconds": 7200
  }
}

The explanation field gives a plain-language summary of why the trigger fired and is useful for displaying context in external systems or custom notification templates.