Signals
Talk to an engineerStart freeSnowplow
Solutions/Industry

Keep more readers, and turn more of them into subscribers.

Signals tells your homepage, recommender and paywall what each reader is doing right now, so they respond while the reader is still on the page.

Start freeTalk to us
How Signals helps

What publishers can do with it.

RetentionMore pages per visitReaders finish one article and leave, and the rail keeps showing stories they skipped. Signals tells your homepage and recommender what this reader read and skipped this visit, so the next link is one they want.How recommendation inputs work →RetentionMore clicks from the homepageAn article pulling readers in sits where last night's plan put it. Signals tells your homepage and CMS how each article is doing with the readers on the site now, so the story that works moves up while it works.How homepage placement works →RetentionMore personalization tests shippedA new rule for what a reader sees usually waits for a release. Signals serves the live reader behavior both rules read, so your experimentation tool can run two rules against each other today and keep the one that keeps readers.How personalization tests work →SubscriptionsHigher subscription conversionA meter that counts free articles treats a first visit and a loyal reader the same. Signals tells your paywall when someone keeps coming back to the same sections, so the offer appears then.How paywall timing works →SubscriptionsLower subscriber churnA subscriber who used to read daily has opened two articles this month, or is on the cancel page now. Signals flags both, so your CRM or paywall can make the save offer while they are still deciding.How the save offer works →Marketing conversionHigher registration and newsletter sign-upAsking for an email on the first visit loses readers who would have said yes on the third. Signals tells your site when a reader is deep into a section this visit, so the sign-up or that section's newsletter appears then.How sign-up timing works →
For your engineers

One SDK, one read call.

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.

Read the docs →
const reader = await signals.getServiceAttributes({
  name: "homepage",
  attribute_key: "domain_sessionid",
  identifier: sessionId,
});
// { sections_read: ["politics", "climate"], stories_skipped: 7, visits_this_week: 4 }
Your CMS or front endasks what this reader is doing when it renders a page
Your recommendergets this visit's reading with each request
Braze, or any tool that takes a webhookgets a message the moment a rule fires
Snowflake, BigQuery or Databricksruns the same definitions over past visits
Questions

Before you hand this to an engineer.

Do we replace our CDP, recommender or paywall vendor?

No. Signals works out what each reader is doing right now and hands it to the tools you run. Your recommender keeps ranking, your CDP keeps its segments, and your meter or paywall vendor keeps deciding when the wall appears, with what this reader did in this visit as one more input.

We built our own homepage personalization. What does Signals add?

Keep it. Signals adds what a single streaming job rarely does. The same reader context goes to an assistant or agent, a rule fires into Braze or your CRM the moment it is met, and one set of definitions runs across every site you own. The next use case becomes a definition, not another job to maintain.

Most of our readers never log in. Does Signals need a login?

No. Signals keys what it knows on the session as well as the user, so an anonymous reader on their fourth politics story this visit is as visible to your homepage as a subscriber is. When a reader registers or subscribes, the same definitions can run on the user id as well.

Is this a data platform project?

No. Add the SDK to your site and app and collection starts. Your product team defines what it wants to know about a reader in the console, and an engineer reads it with one call and deploys through the CI/CD you have. Most of the wiring can be handed to a coding agent, and the docs, MCP server and agent skill are built so it can be.

Where does the data live?

In a deployment we host, or in your own AWS or GCP account. The events are yours either way, validated against your schemas on the way in, and the architecture is the same in both, so what you evaluate is what you run. Snowplow is ISO 27001 certified, and deployments run under GDPR and CCPA.

What if next-day data is fine for us?

Then a warehouse tool is the cheaper buy, and we would say so. If your homepage, paywall and newsletters can act tomorrow on what a reader did today, you do not need Signals. It earns its place when the response has to land while the reader is still on the page.

Try it on your own site.

Add the SDK, define one thing you want to know about a visitor, and watch it update while you click around. The free tier runs on the real engine: no card, no sales call.

Start freeTalk to an engineer