--- title: "Act on live behavior the moment it happens | Snowplow Signals" description: "Real-time rules for plan limits, failed searches and idle baskets. Signals checks them continuously and delivers to your app, Braze, Kafka or a webhook." source: https://signals.snowplow.io/use-cases/act-in-the-moment --- [Solutions](https://signals.snowplow.io/solutions) / Use case # Respond while the customer is still there. Write the condition once, such as a trial that hits its plan limit, a third failed search or a basket gone quiet. Signals checks it continuously and tells your app, Braze, Kafka or a webhook the moment it is true. [Start free](https://signals.snowplow.io/start) [Talk to an engineer](https://signals.snowplow.io/start?intent=engineer) The real engine · no card · no sales call ![A phone showing the Ridgeway game after a third failed attempt at the level, with a bottom sheet asking Try an easier route? and a Take the valley path button, and a Signals callout reading third_failure fired attached to the side.](https://signals.snowplow.io/images/products/hero-act-in-the-moment.webp) Fires on what happens, or on what does not. your handler decides what happens next [ Try it on yourself ↓ ](#live-panel) Below is your own visit to this page, computed by Signals as you read. ## Signals, about you connecting What Signals knows about your visit, right now Signals is computing your first attributes from the events this page just sent. Every highlighted part is an attribute Signals computed from the behavioral data your browser sent during this visit. Open the Product menu above and watch the sentence change. Show me how Signals knows this Keyed on an anonymous session id. Signals drops these values a day after your last event. Why it usually fails ## Most stacks notice the moment after it has passed. Emails, dashboards and syncs run after the fact. They are right about what happened, and too late to change it. **Polling misses it**The moment falls between checks, and every check costs a read. **Silence sends nothing**A user who goes quiet emits no event. Something has to watch the clock. **Rules in a second system**They drift from the data they check. What you build with it ## Moments worth acting on before they pass. Each of these is a rule over what a customer is doing, delivered while there is still time to change the outcome. Software · Upgrade ### Higher trial to paid conversion The upgrade prompt arrives on the trial's schedule, not the user's. A rule fires when a workspace hits its plan limit, so the prompt appears then and names the limit. Retail · Checkout ### Fewer abandoned baskets The reminder lands in tomorrow's email. A rule fires when a high-value basket goes quiet, so the page offers help while the shopper is still there. Media · Subscriptions ### Higher subscription conversion The paywall offer is the same for every reader. A rule fires on a reader's fourth article this week, so the offer goes to the reader most likely to pay. Gaming · Retention ### Higher D1 retention A new player failing the same level a third time is about to quit. A rule fires on the third failure, so your game server can ease the level in time. What you build ## Write the condition once. Signals watches it continuously. 01 · Collect ### Add a Snowplow SDK Web, mobile or server. Events start flowing, validated against your schemas. No event stream to build first. 02 · Define ### Describe the moment as a rule A threshold, a window and a key, over attributes you define. In the console without a ticket, or in code. 03 · Deliver ### Pick where it goes Into your page over a live connection, or to Braze, Kafka, a webhook or Pub/Sub. Signals supplies the moment; your handler decides what happens next. ![The plan_limit_hit rule fires with plan_limit_name set to projects, the Signals plugin delivers it to the page, and a trial app shows an upgrade prompt reading You've used 3 of 3 projects on the trial.](https://signals.snowplow.io/images/products/usecase-act-in-the-moment.webp) Works with * Braze * Kafka * Pub/Sub The code ## One handler on the page, called the moment a rule fires. Signals ships a plugin for the Snowplow browser tracker. It holds one live connection for the visitor and calls your handler with the rule's name and the attributes that made it fire. First, give your agent the Signals skills $ `npx plugins add snowplow/skills` Copy Copied Write it yourself ``` import { newTracker } from "@snowplow/browser-tracker"; import { SignalsInterventionsPlugin, addInterventionHandlers, subscribeToInterventions, } from "@snowplow/signals-browser-plugin"; newTracker("sp1", collectorUrl, { appId: "web-app", plugins: [SignalsInterventionsPlugin()], }); addInterventionHandlers({ upgrade(intervention) { if (intervention.name === "plan_limit_hit") { showUpgradePrompt(intervention.attributes.plan_limit_name); } }, }); subscribeToInterventions({ endpoint: signalsEndpoint }); ``` Or hand your agent this prompt Add Snowplow Signals to this app so it reacts when a trial user hits their plan limit. Add the Snowplow browser tracker with the Signals interventions plugin, define a rule named plan_limit_hit over the user's usage against their plan, and register a handler that shows our upgrade prompt when it fires. Leave the billing logic as it is, so the only thing that changes is when the app hears about the limit. A rule fires the first time its condition is true for a key, and rules keyed on the session re-arm with the next session. The plugin tracks each delivery as an event, so you can measure what the nudge did. The feature: [Real-time triggers →](https://signals.snowplow.io/products/real-time-triggers) Full reference: [Subscribe to interventions →](https://docs.snowplow.io/docs/signals/applications/subscribe/) What changes ## The page hears about it while the shopper is still there. <1s Event in to attribute updated 0 polling loops Your page holds one live connection instead of asking any key user · session · basket · listing · store Questions ## Before you write your first rule ### Does Signals decide what happens when a rule fires? No. Signals tells your code the moment the condition is true and sends the attributes behind it. Your handler, or the tool you deliver to, decides what the customer sees. ### Can a rule fire when something does not happen? Yes. A rule can fire when an expected event does not arrive inside a window, such as a trial user who stops halfway through setup or a basket that goes quiet. ### Where can a rule deliver? Into your page over server-sent events, or to Braze, Kafka, a webhook or Pub/Sub. ### Will the same customer get it over and over? Not by default. A rule fires the first time its condition is true for a key, and rules keyed on the session re-arm when a new session starts. A rule built on a change in value fires on every change, if that is what you want. ### Can I test a rule before it goes live? Yes. Replay it over warehouse history to see how often it would have fired, then publish. Old versions keep firing until you retire them. ### Do I need an event stream already? No. Collection is part of Signals. Add a Snowplow SDK and events start flowing. If you already run Snowplow, Signals reads the pipeline you have. ### Related use cases [In-session personalizationRank against what this customer is doing in this visit, while they are still on the page.](https://signals.snowplow.io/use-cases/in-session-personalization) [Behavioral memory for AI agentsThe agent remembers what the customer did this session, beside what they said.](https://signals.snowplow.io/use-cases/customer-aware-agents) [State for System One modelsA typed decision is only as good as the state you send it.](https://signals.snowplow.io/use-cases/system-one-models) ## Fire your first rule on your own traffic. Add the SDK, write one rule, then set it off yourself by clicking around your own site. The free tier runs on the real engine: no card, no sales call. [Start free](https://signals.snowplow.io/start) [Talk to an engineer](https://signals.snowplow.io/start?intent=engineer) Evaluating? [Build vs buy →](https://signals.snowplow.io/evaluate/build-vs-buy)