Rank on the last three searches, not the last three months.
Signals computes what this visitor has been searching, viewing and skipping, and serves it to your ranker in 6ms, inside the budget the query already has.
- 6ms p50 read, in-region
- <1s event to attribute current
- Free tier, no card
Below is your own visit to this page, computed by Signals as you read.
Signals, about you
connectingSee live events firing as you browse this page on the left; what Signals computed about you on the right, refreshed every few seconds.
Add the Signals MCP server to Claude Code, Cursor or any MCP client, then run this. The agent adds the SDK, defines the attribute and wires the read into your own app.
$ npx plugins add snowplow/skills
> Use the Snowplow MCP server and Signals skill, then help me plan and implement a use case. Make sure everything is tested and works as intended.
trackPageView(); // browser tracker, already on this pageAttribute(name="pages_last_5_min", events=["page_view"], aggregation="category_count", property="page_urlpath", period=timedelta(minutes=5))
await signals.getServiceAttributes({ name: "signals_site_session_service", attribute_key: "domain_sessionid", identifier: "…", // your session id, once set });
Your ranker sees the words they typed. Not the two searches before it.
The query string and a nightly profile
Two failed searches a minute ago, the category they keep circling, the result they opened and bounced straight back from. None of it reaches the ranker in time to matter.
q = waterproof jacketSession context at query time
One call returns what this visitor has been doing in the last few minutes, current to the event, fast enough to sit inside a query that already has a latency budget.
failed_searches_session = 2The second search is better than the first
The ranker boosts the category they have been circling and demotes what they already rejected, while they are still typing.
same session, better resultsSignals that only exist while the visitor is still searching.
A search session is short. Anything computed overnight arrives after the visitor has either found it or left.
Recover a failed search before they leave
Two queries with no results is the clearest intent signal you get, and it is worthless tomorrow. Rank the third query differently, or swap the zero-result page for something they might actually want.
null result rate · search exit rateRank on what they skipped
The results they scrolled past say as much as the ones they opened. Both are in the stream already, and neither survives a nightly aggregate.
search click-through · position of first clickGive an anonymous visitor a profile
Most searchers are not logged in. Keying on the session rather than the person means the ranker has context from the second query onward, with no identity to resolve first.
coverage of ranked sessionsOne context for search, browse and the recommender
The same definitions feed the search ranker, the category pages and whatever recommends alongside them, so the three surfaces stop disagreeing about what the visitor wants.
surfaces per definitionOne call, inside the query you already run.
Signals does the knowing. Your search engine keeps doing the ranking, with inputs that are seconds old instead of a day old.
- 01Collect. Add a Snowplow SDK to your application and search, view and click events start flowing in.
- 02Define. Say what the ranker should know about the session, in the console or in code.
- 03Serve. An event updates its attributes in <1s, and your ranker reads them at 6ms p50, on the way to the query.
Before you sign up
Does this replace my search engine?
No. Signals does the knowing. Elasticsearch, OpenSearch, Vespa, Algolia or the ranker you wrote yourself keeps doing the ranking, with inputs that are seconds old instead of a day old.
Will it fit inside my query budget?
6ms p50 and 10ms p95 for an in-region round trip, and one call returns a whole service rather than one attribute at a time. Whether that fits is your call, but it is a number with a boundary on it rather than a claim.
What about visitors who are not logged in?
Attributes can be keyed on the session rather than the person, so an anonymous searcher has context from their second query onward. Pair it with identity resolution later if you want the history to follow them.
Do I need an event stream already?
No. Collection is part of Signals. Add a Snowplow SDK to your web, mobile or server application and events start flowing in. If you already run Snowplow, Signals reads the pipeline you have.
What does the free tier include?
The full product against your own traffic, up to 5 million events a month, with no card and no sales call. You should see an attribute updating against your own traffic in the first session.
Search your own site and watch the context change.
Add the SDK, define one attribute, then run two searches on your own product and watch the second one arrive with the first one attached.
npx plugins add snowplow/skills