Feed live features to your models.
Signals turns what the customer is doing right now into features your model reads in 6ms, in-region.
A model, about you
connectingSignals is computing your visit from the events, we will ask Jev about it next.
Browse around the site, come back, and watch both answers move.
Your model's scores lag behind the customer.
Most models score each customer on their history in a batch job, nightly or hourly, and use that score until the next run. Meanwhile the customer shows you what they want right now, and the score stays the same.
Your model reads what the customer is doing now.
Each event, such as a product view, updates your features in <1s. Your inference code reads them in one call, in 6ms in-region, right before the model scores.
Step by step: Score prospects with a live model →The background: Feature stores, explained →
- Snowflake
- Databricks
- BigQuery
- Vertex AI
What your model can read in one session.
Pick a model to see what it reads and what it does with it.
- Lands on a category
Recommendations from the first page
first_category_session: runningYour model ranks running gear higher from the first page view. - Views items
Recommendations that follow what they view
viewed_items_session: 3The next carousel ranks items like the three they just viewed higher. - Scrolls past a title
Fewer repeats of titles they skip
impressions_no_click: 12Your ranker drops a title they have scrolled past 12 times.
- Searches
Results based on this visit's searches
searches_session: trail, waterproofYour ranker uses the two earlier searches when it ranks the next query. - Gets no results
A wider search after a miss
failed_searches_session: 2Your ranker widens the next query instead of returning nothing again. - Filters by price
Results within their price
max_price_filter_session: 80Your ranker puts items under that price first for the rest of the visit.
- Fails to log in
A risk score that counts failed logins
failed_logins_session: 4Your fraud model sees the failed logins before it scores the next payment. - Adds a card
Card attempts counted during checkout
card_attempts_session: 3Your fraud model sees all three attempts before the payment is authorized. - Tries a fifth card
A trigger after five attempts
Triggers to Braze, Kafka and webhookscard_attempts_session: 5A Signals trigger sends the session to your fraud service before the next attempt.
- Visits billing again
Churn risk across the last 30 days
billing_views_30d: 7Your churn model scores the account on 30 days of billing visits, before they leave the app. - Opens cancel
A score before they cancel
cancel_flow_started: trueYour app offers a pause plan to accounts the model scores high. - Exports data
Exports count toward churn risk
exports_session: 2Your churn model counts this visit's exports when it scores.
Read live features in one call.
Define the features once with the Python SDK and read their live values at inference. On Snowflake, the same features can also build a point-in-time correct training set.
npx plugins add snowplow/skillsfrom datetime import datetime, timezone
from snowplow_signals import (
Attribute, AtomicProperty, Criteria,
Criterion, Event, EventProperty,
Signals, StreamAttributeGroup,
TrainingSpan, domain_sessionid,
)
sp = Signals(
api_url=api_url, api_key=api_key,
api_key_id=api_key_id, org_id=org_id,
)
# Define the features once.
search = Event(
name="search",
vendor="com.example",
version="1-0-0",
)
searches_session = Attribute(
name="searches_session",
type="int32",
events=[search],
aggregation="counter",
default_value=0,
)
last_query_session = Attribute(
name="last_query_session",
type="string",
events=[search],
aggregation="last",
property=EventProperty(
vendor="com.example",
name="search",
major_version=1,
path="query",
),
)
ranker_features = StreamAttributeGroup(
name="ranker_features",
version=1,
attribute_key=domain_sessionid,
owner="you@example.com",
attributes=[
searches_session,
last_query_session,
],
)
sp.publish([ranker_features])
# At inference: read the live values.
features = sp.get_group_attributes(
name="ranker_features",
version=1,
attributes=[
"searches_session",
"last_query_session",
],
attribute_key="domain_sessionid",
identifier=session_id,
)
score = model.predict(features)
# Optional, Snowflake only: a training
# set from the same features. Each row
# uses only the events before its label.
utc = timezone.utc
start = datetime(2026, 1, 1, tzinfo=utc)
end = datetime(2026, 4, 1, tzinfo=utc)
sp.submit_dataset_run_with_session_anchors(
attribute_groups=[ranker_features],
goal_criteria=Criteria(all=[
Criterion.eq(
AtomicProperty(name="event"),
"transaction",
),
]),
training_span=TrainingSpan(
start_time=start,
end_time=end,
),
)Add Snowplow Signals to this model's serving path. Rewrite the session features from our notebook as a Signals attribute group, and replace the serving path's feature code with get_group_attributes. Keep the model and its hyperparameters as they are, so the only thing that changes is where the features come from.
The dataset builder supports Snowflake today. You can run a managed build, or generate the SQL and run it yourself.
The feature: Real-time attributes →Full reference: Retrieve attributes →
Current features, read at inference.
Event in to feature updated
To read features at inference, p50 in-region
To read features at inference, p95 in-region, load test
Frequently asked questions
What are real-time features?
Model inputs that include what the customer did in this session, up to their last event. Signals computes them from events and serves them at inference. It calls each feature an attribute.
What is training/serving skew, and how does Signals avoid it?
Skew is the gap between the feature values a model trained on and the values it sees in production. It often starts when a feature is written twice, once for training and once for serving. On Snowflake, Signals can build a point-in-time correct training set from the same definitions it serves, which removes that source of skew.
Can a feature cover more than this session, or come from my warehouse?
Yes. You key each feature on a session, a user or an account, so a feature can count an account's billing visits over 30 days. A warehouse table keyed on a user or an account, such as a churn score, can become an attribute read from the same service as the live ones. Live serving does not need a warehouse. Training sets build in Snowflake today.
Warehouse attributesIs Signals a feature store?
Partly. For behavioral features, Signals does the serving half of a feature store, and it collects the events too. If most of your features come from other sources, a general feature store may suit you better. You can also run both. Your inference code reads behavioral features from Signals and the rest from your store, such as Feast or Tecton.
Signals vs a feature storeDoes Signals train or host my model?
No. Signals computes and serves the features. Training, hosting and inference stay where they are, such as Vertex AI, Databricks or your own service, and your code decides what to do with the score.
Who runs it, and where does the data live?
We run it as managed SaaS, or it runs in your own AWS or GCP account. Collection is built in, so you add a Snowplow SDK and events start flowing. Signals is ISO 27001 certified, and runs in deployments that meet GDPR, CCPA and HIPAA.
Plans and deployment optionsServe one live feature to your model.
Define one feature and read it live on your own traffic. The free tier runs on the real engine: no card, no sales call.