Behaviors

A recording answers “what happened to this one user?”. A behavior answers a different question: how many people do this, and which ones? You describe a pattern once — “reached the cart and never bought”, “clicked the same spot five times in a row” — and Espejo counts every session that matches it and links you straight to those recordings.

Start from a template

The Behaviors screen opens with a catalog of ready-made patterns. Pick one, name it, and fill in the couple of parameters it asks for (usually which screen):

• Cart abandonment — entered the cart route and never reached the success route.
• Conversion — reached the purchase/sign-up completed screen.
• Form abandonment — started filling a form and never submitted it.
• Rage click — several clicks in the same place within a second: a frustration signal.
• Error on screen — interacted on a screen and a console or HTTP error fired.
• Stuck on a screen — sat on a screen with no clicks, typing or navigation.

Screens are picked from a list of your app’s real routes (the ones Espejo already saw), and durations are picked from named options — nothing is typed in milliseconds.

Every template is just a preset over the same grammar, so you can also build a custom one from the same building blocks (an event, on a route, optionally in sequence or within a time window).

What you get

For each behavior, two things:

• Counts — how many sessions matched, out of how many were evaluated, over the last N days. The match rate is the headline number.
• The segment — expand a behavior and you get the actual sessions that matched, newest first, each one a click straight into its replay. This is the point: a rate is a number, the segment is the recordings behind it.

Intervene while it happens (optional)

A behavior can also carry a message: a banner in the corner or a centered modal that your app shows live, the moment the pattern completes — someone rage-clicking gets a “need a hand?” with a link to support, someone stuck on checkout gets a nudge. You write the title, the body and an optional button, and pick how often it can appear: once per session, or once per visitor ever.

Under the hood the rules travel to the page and are matched in the browser as the session unfolds — this is not a nightly batch. The matching code lives in a separate file (espejo.triggers.js, ~4 KB gzip) that is only downloaded by projects that actually configured a message; everyone else’s pages don’t pay a byte for it. A behavior without a message never touches the page: it only counts.

How screens are grouped

Behaviors (and the heatmap) group by normalized route: /order/123 and /order/456 are the same screen, /order/:id. The origin and query string are dropped, numeric ids, UUIDs and long tokens are collapsed, and readable slugs are kept. That is why “cart abandonment on /checkout” counts every visit to that screen, not one exact URL.

Capture is automatic

There is nothing to install and nothing to turn on in your page. Every session is evaluated against your enabled behaviors as it arrives, deterministically — no model, no extra request, no cost on your side. A behavior with a corrupt definition can never break ingestion; the worst case is that one behavior doesn’t count.

Viewing behaviors is a Team feature

The underlying signals are gathered on every plan — nothing is lost while you are on the free tier. Defining behaviors, seeing their counts and segments, and showing in-app messages are part of Team. The template catalog is visible to everyone, so you can see what you’d get before upgrading.