A rule that fires the moment it happens.
When a condition over live attributes is met, Signals sends the trigger to your app, Braze, Kafka, a webhook or Pub/Sub.
The moment passes before anything downstream knows.
A high-value basket goes idle, or a visitor's third search comes back empty. Most stacks learn about it too late to act while the visitor is still on the page.
Write the rule once, and Signals checks it on every event.
We host it, or it runs in your own AWS or GCP account. Signals collects events with its own SDKs, updates what it knows within a second of each event, and answers a read in 6ms at the median and 10ms at p95, in-region.
Event in to attribute updated
user · session · basket · listing · store
A rule over live attributes, in the console or in code.
A basket over a set value that sits idle for ten minutes, or a third search in one session that returns nothing.
Every incoming event updates the attributes the rule depends on.
Each event updates the attributes in <1s, and the rule is checked as they change, in the same engine that computes them. There is no second system to keep in sync.
Into your app over a live connection, or to a tool you already run.
Signals sends the fired trigger, with the attributes you chose, to Braze, Kafka, a webhook or Pub/Sub. Your tool decides what happens next.
- Braze
- Kafka
- Pub/Sub
What a trigger can check, and where it goes.
- newTracker("sp1", COLLECTOR_URL, {
- plugins: [SignalsPlugin()],
- });
- addInterventionHandlers({
- basketOffer(i) {
- if (i.name === "high_value_basket_idle")
- showOffer(i.attributes);
- },
- });
- subscribeToInterventions({ endpoint: ENDPOINT });
Reuse the attributes you defined. A rule is a threshold, a window and a key over them, checked as each event changes them, with no second definition to maintain.
A trigger can fire when something does not happen inside a window, such as a basket that sees no events for ten minutes.
Over server-sent events, so the page can change while the customer is still on it.
- newTracker("sp1", COLLECTOR_URL, {
- plugins: [SignalsPlugin()],
- });
- addInterventionHandlers({
- basketOffer(i) {
- if (i.name === "high_value_basket_idle")
- showOffer(i.attributes);
- },
- });
- subscribeToInterventions({ endpoint: ENDPOINT });
Preview how many keys match a rule against your warehouse data, and send a test to one key, before you publish it. Old versions keep firing until you retire them.
Defining interventions, the in-app delivery →See it in Snowplow Console →
Four moments a rule catches in time.
- Upgrade timing play: A workspace hits its plan limit. The upgrade prompt names that limit.
- Cart recovery play: A full cart goes quiet for ten minutes. A line by the cart says what is waiting.
- Search inputs play: A third search with nothing opened. Results switch to a looser match.
- Difficulty tuning play: A new player fails one level three times. The next try loads a little easier.
Frequently asked questions.
We already run journeys in Braze. Why add triggers?
Keep them. Braze still decides what to send and when. A Signals trigger tells Braze the moment a condition over live behavior is true, such as a high-value basket idle for ten minutes, with the attributes behind it attached, so the journey can start while the customer is still on the site.
How is this different from a webhook fired off our warehouse?
A warehouse job checks a condition when it runs, so the moment can pass between runs. Signals updates the attributes a rule reads within <1s of each event and checks the rule as they change, in the same engine that computes them, then sends the result to your webhook or another destination. Your warehouse still holds the history, and you can preview a draft rule against it before you publish.
What happens if a rule fires too often?
A Signals rule fires the first time its condition is true for a key, so one customer does not get it on every event. Rules keyed on the session re-arm when a new session starts, and a rule built on a change in value fires on every change, if that is what you want. Before publishing, you can preview how many keys match the rule against your warehouse data and send a test to one key.
Does Signals decide what happens when a rule fires?
No. Signals tells your app or tool the moment the condition is true and sends the attributes you chose with it. Your handler, or the tool you deliver to, decides what the customer sees.
What if acting tomorrow is fine for us?
Then a scheduled job over your warehouse is cheaper, and you should use that. Signals triggers are for moments that have to reach your app or messaging tool while the customer is still there, such as a third failed search or a plan limit hit mid-task.
Start with one attribute.
Add the SDK, define one attribute, and watch it update as you browse and search your own product. The free tier runs on the real engine: no card, no sales call.