Skip to main content

​
Session replay and search analytics

Orbit ships two capabilities whose names are easy to confuse, and this page keeps them separate: session replay, a piece of the inbound message routing model that decides where a matched inbound message goes — and search analytics, a workspace-analytics surface that records what your team types into the search box and reads it back as four aggregate panels. The routing model carries the sessionReplay capability, and the analytics model carries searchAnalytics, but they sit on different paths and are configured independently. Read the first two sections for replay, the third for analytics, and the fourth for how the two interact.

​
Two capability lines

  • sessionReplay — inbound routing. An inbound rule with a session-replay target hands the matched message off to the replay recorder instead of a raw webhook or inbox destination. See inbound message routing and how routing picks a sender for the full match/target language.
  • searchAnalytics — workspace analytics. Every ?q= search executed against the messages, contacts, calls, campaigns, inbox, or global surfaces writes one row in your tenant schema; the analytics aggregates read it back as top queries, zero-result queries, click-through rate, and parse failures. This page explains what is recorded, why zero-result trends matter for agent tuning, and the abstraction behind the pipeline.

​
Session replay — inbound rules with replay targets

Session replay sits in the same rule engine as inbound message routing. A rule evaluates the inbound message against one field (number, sender, keyword, or regex), in ascending priority order, and the first enabled match dispatches to one target. A session-replay target hands the message to the recorder rather than to a raw webhook endpoint or the default inbox handler — useful when the inbound reply chain (a WhatsApp bot, a support-thread opener) wants the pre-chat session context that the Orbit web widget captures. Priority is the ordering tool: a lower priority value wins; leave gaps (10, 20, 30) so you can insert exceptions without renumbering. Fall-through is deliberate: when no rule matches, the message takes the default path that always existed (inbox persistence plus the tenant-wide received event). Replay targets never originate an outbound reply — no match type and no target type in the inbound rule engine will send a message on your behalf; the replay-handling target only receives a message that already arrived.

​
Session analytics — what queries get recorded

Search analytics is the workspace-analytics counterpart built on a per-tenant table that every ?q= list controller (messages, contacts, calls, campaigns, plus the inbox live query and the global command-palette search) writes to immediately after the search parses and the result count resolves. The write captures the normalized query text (whitespace-collapsed, lowercased, personal data such as phone numbers and emails masked), the surface it ran against, whether the query parsed successfully, and the result count (zero for a zero-result run). A click on a result updates the row with the clicked entity id, and a click recorded by its exact query text (used when a static command-palette row is opened before the search response returns an analytics-row id) inserts or stamps a row within a short attribution window. Per-destination granularity is deliberate. The top-queries, zero-result, click-through, and parse-failures panels project the distinct surfaces a query ran against as an array — the dashboard groups runs of the same normalized query text across surfaces while still telling you which destination (messages, contacts, calls, campaigns, inbox, or global) produced them. A surface filter narrows any panel to one destination; all (the default) aggregates across them. Zero-result trends matter because they separate “the data genuinely does not exist” from “the index or grammar missed a query your team expected to match” — the former is normal, the latter is a routing-grammar or coverage problem you can remediate once rather than pay a search tax on every day. The pipeline deliberately excludes runs captured under support impersonation and deduplicates rapid keystroke repeats per user per surface per minute, so aggregates reflect your team’s real behaviour rather than retyping noise.

​
Cross-channel search in the inbox

Search is a first-class inbox feature, not only an analytics input. The inbox conversation list, the contacts hub, and the global command palette (/search/global) each accept the same ?q= DSL, and a match in one surface nudges the analytics to record the query under the surface that fired. The per-destination channels the surfaces enum enumerates (messages, contacts, calls, campaigns, inbox, global) are the same channels the analytics reads back per query, so a cross-channel workflow — an operator who searches the inbox for an open thread, falls back to the contacts hub, then opens the global palette — is recorded accurately per destination rather than collapsed into an unhelpful “search” bucket. Owner, admin, developer, and viewer roles can all read the aggregates; recording and click-attribution writes stay tenant-isolated to the schema and org the request resolved.

​
See also