--- title: "Real-time attributes | Snowplow Signals" description: "Define what you want to know about a customer once. Signals computes it from live behavior, keeps it current and serves it in single-digit milliseconds." source: https://signals.snowplow.io/products/real-time-attributes --- [Product](https://signals.snowplow.io/products) / Live attributes # Know what a customer did, not only how many times. A live attribute is a computed property of whatever you key on, computed live on your events and served to your application in single-digit milliseconds. [Start free](https://signals.snowplow.io/start) [Talk to an engineer](https://signals.snowplow.io/start?intent=engineer) What you see below is your own visit to this page, computed by Signals as you read. ## Signals, about you connecting What Signals knows about your visit, right now Signals is computing your first attributes from the events this page just sent. Every highlighted part is an attribute Signals computed from the behavioral data your browser sent during this visit. Open the Product menu above and watch the sentence change. Show me how Signals knows this Keyed on an anonymous session id. Signals drops these values a day after your last event. <1s Event in to attribute updated 10ms p95\. Load-test benchmark 1 definition Streaming for now, batch for history any key user · session · basket · listing · store The problem ## You know how many times. Not what. Most customer data is counts computed overnight: propensity to purchase, next best action, product recommendations. By the time it reaches your product the moment has passed, and it says nothing about what this customer is doing right now. In Snowplow Console ## An attribute group, published and serving. Each attribute is a name, an aggregation, the events it reads and a window. Define them in the Console or in code, and every version is kept. ![The Snowplow Console showing a published attribute group with attributes such as categories_viewed and basket_value.](https://signals.snowplow.io/images/products/console-attribute-group.webp) Snowplow Console, shown with example data. How it works ## Define once. Computed on the stream. Served to your app. ![A product_view event for a pair of Trail runner shoes in the trail category, sent from the app via the SDK and marked schema validated.](https://signals.snowplow.io/images/products/attributes-step-event.webp)01 · Event in ### A product\_view event on a pair of trail shoes arrives from your app via our SDK. Schema-validated on the way in. Bad data never reaches the attribute. So you can always trust your attributes. ![The product_view event updates the categories_viewed attribute in under a second, adding trail to its 10-minute window.](https://signals.snowplow.io/images/products/attributes-step-recomputed.webp)02 · Recomputed ### An attribute named categories\_viewed gains trail, inside the 10-minute window. <1s from the event arriving to the attribute being current. Windowing, late events and hot keys are handled in the engine, not in your code. ![A ranker reads categories_viewed and reorders the shopper's shoe recommendations so the trail shoes come first.](https://signals.snowplow.io/images/products/attributes-step-read.webp)03 · Read back ### Your ranker reads the attribute and reorders the shoe recommendations, in the same session. Or a trigger fires the moment the condition is met and delivers it to you. Works with * Snowflake * BigQuery * Databricks * Vertex AI * Amazon Bedrock Capabilities ## Attributes that describe the moment, kept current for you. ![A last_cart_value attribute defined with the Signals Python SDK, shown updated on the shopper's live profile.](https://signals.snowplow.io/images/products/define-attribute.webp) ![A timeline of one shopper's product_view events with a 10-minute rolling window, where the three recent views count and older ones drop out, giving product_views_last_10_min of 3 and categories_viewed of road and trail.](https://signals.snowplow.io/images/products/attributes-window.webp) ![Four profile cards for a user, a session, a basket and a store, each with its own live attribute values such as recent product views and categories.](https://signals.snowplow.io/images/products/attributes-any-key.webp) ![One attribute definition feeds the streaming engine for live updates and a warehouse backfill for history, both arriving at the same attribute on the shopper's profile, and the same definition builds an ML training set.](https://signals.snowplow.io/images/products/attributes-two-engines.webp) ![A product_view event updates a shopper's attributes in under a second, then the app reads the whole service in one getServiceAttributes call and gets every attribute back, with its p50 and p95 read latency shown in-region.](https://signals.snowplow.io/images/products/attributes-fast.webp) ![An attribute group with v1 and v2 both published, where v2 adds a categories_viewed attribute and a service pinned to v1 keeps serving alongside a service on v2.](https://signals.snowplow.io/images/products/attributes-versions.webp) 01 ### Counts, recency, order and custom logic How often, how recently, in what sequence. Or your own function, versioned like the rest. ![A last_cart_value attribute defined with the Signals Python SDK, shown updated on the shopper's live profile.](https://signals.snowplow.io/images/products/define-attribute.webp) 02 ### Windows and TTLs that end when the moment does Ten minutes, this session, since last purchase. Late events, TTLs and hot keys handled in the engine. ![A timeline of one shopper's product_view events with a 10-minute rolling window, where the three recent views count and older ones drop out, giving product_views_last_10_min of 3 and categories_viewed of road and trail.](https://signals.snowplow.io/images/products/attributes-window.webp) 03 ### Key on any entity user · session · account · basket · listing · store. A profile is whatever you say it is. ![Four profile cards for a user, a session, a basket and a store, each with its own live attribute values such as recent product views and categories.](https://signals.snowplow.io/images/products/attributes-any-key.webp) 04 ### One definition, two engines Streaming for now; backfill from Snowflake, BigQuery or Databricks on publish, so a new attribute has history on day one. The same definition builds the ML training set, so serving matches training. ![One attribute definition feeds the streaming engine for live updates and a warehouse backfill for history, both arriving at the same attribute on the shopper's profile, and the same definition builds an ML training set.](https://signals.snowplow.io/images/products/attributes-two-engines.webp) 05 ### Current within a second, served in single-digit milliseconds An event updates its attributes in <1s. Reads come back in 6ms p50, 10ms p95 in-region, one call for every attribute in a service, mid-render. ![A product_view event updates a shopper's attributes in under a second, then the app reads the whole service in one getServiceAttributes call and gets every attribute back, with its p50 and p95 read latency shown in-region.](https://signals.snowplow.io/images/products/attributes-fast.webp) 06 ### Governance included Every attribute is versioned, and manageable in code and CI/CD. Old versions keep serving until you retire them. ![An attribute group with v1 and v2 both published, where v2 adds a categories_viewed attribute and a service pinned to v1 keeps serving alongside a service on v2.](https://signals.snowplow.io/images/products/attributes-versions.webp) Full reference: [Defining attributes →](https://docs.snowplow.io/docs/signals/attributes/) ## Collect. Define. Serve. Add the SDK, define one attribute, and watch it change while you click around your own product. The free tier runs on the real engine: no card, no sales call. [Start free](https://signals.snowplow.io/start) [Talk to an engineer](https://signals.snowplow.io/start?intent=engineer) Next up: [Real-time triggers →](https://signals.snowplow.io/products/real-time-triggers) and [Agentic context →](https://signals.snowplow.io/products/agentic-context).