What building this yourself actually costs.
The cost of running an in-house profile service, row by row, next to buying the same capability.
Everything after the first attribute.
| Dimension | Signals | Build it yourself |
|---|---|---|
| Event collection | Add the SDK and collection starts, schema-validated on the way in. | Collectors, a schema registry and failed-event handling, before any attribute can be trusted. |
| Where it runs | Managed SaaS, or a private deployment in your own AWS or GCP account with the same architecture. | Your cloud, run by your team. |
| Streaming compute | Describe the attribute once. Windowing, late events and hot keys are handled in the engine, not in your code. | A Flink or Spark Streaming job per attribute family. Windowing, watermarks, late events, state size. |
| Low-latency store | Managed store, read in 10ms at p95, in-region. | Pick Redis, DynamoDB or Aerospike. Design the key schema. Solve hot keys, TTLs, eviction and cold caches. |
| Serving API | Included. Your app asks Signals with one GET. | Build it, rate-limit it, and keep it inside the request path's latency budget. |
| Authentication | Scoped API keys exchanged for a short-lived token. Attribute reads stay server-side; triggers reach the browser through the browser plugin. | Service credentials, key rotation, and a safe way to reach the browser without shipping a secret to it. |
| Governance | Every attribute group is versioned with a named owner. Editing a published one creates a new version, and the old one keeps serving until you unpublish it. Preview against recent events before you publish. | Nobody can say which version of an attribute production is reading, or who owns it. An upstream change breaks it silently. |
| Historical features | Turn on backfill and a new attribute is filled from Snowflake, BigQuery or Databricks on publish. | A second pipeline out of the warehouse, plus reconciliation when batch and stream disagree. |
| Training and serving parity | One definition, computed live and from history. Structurally the same attribute. | Your problem. The notebook feature and the production feature drift within weeks, and nobody notices until a model degrades. |
| Training datasets | Labeled, point-in-time correct datasets from the serving definitions. Name the goal event, get the table in your warehouse (Snowflake today). | Hand-built point-in-time joins. One mistimed join leaks future data into training, and the model fails only in production. |
| Identity and keys | Key attributes on anything you track. Pair with Snowplow Identities for deterministic resolution. | Build stitching or accept fragmented IDs. Non-user entities need a second key schema, usually a second store. |
| The next attribute, and the one after | A definition change, deployed from the console or CI/CD. | More platform work each time, queued behind everything else. |
| Self-service | PMs define attributes in the console, so the ticket never reaches you. | None. Every new attribute is a ticket to your team. |
| Triggers | Real-time triggers, delivered to your app or to Braze, Kafka, webhooks and Pub/Sub. | A whole second system for condition evaluation, delivery, deduplication and outcome logging. |
| Handing it to a coding agent | An SDK call and one GET. Point your coding agent at the docs, the agent skill or the MCP server and it will wire it up. | An agent can write the streaming job. It cannot own the state, the rebuilds or the pager after launch. |
| On-call | Ours, including the 3am page. | Your platform team, indefinitely, for a system in the request path. Long after its author has moved teams. |
Build column describes a typical in-house streaming stack. Signals latency from the load-test benchmark, in-region.
The roadmap has product work on it that this project would displace.
Nobody on the team wants to own a stateful streaming service at peak.
You need training and serving definitions to agree, permanently.
The value is in the attributes, not in the pipeline that computes them.
Real-time attribute serving is itself your differentiator.
You already run the streaming stack, staffed, with capacity to spare.
Requirements are unusual enough that no vendor model fits.
Regulatory constraints rule out both managed SaaS and a deployment in your own cloud.
Pick the one that matches your team.
Build it yourself
For platform teams with a mandate to own the stack. Build it on validated events, and talk to an engineer about the hard parts before you start.
Path 02Integrate with your ML platform
For teams on Vertex, Bedrock, Databricks or LangChain. Signals supplies the behavioral attributes; your platform does inference and orchestration. We are not asking you to move.
Path 03Adopt Signals end to end
For teams who need this running this quarter. Start free and see an attribute updating against your own traffic in the first session, then deploy through CI/CD as SaaS or in your own cloud.
p50, in-region API round trip
p95. Load-test benchmark
Event in to attribute updated
Streaming for now, batch for history
The questions your architect will ask.
Isn't this just a stream processor and a cache?
The first attribute is. The rest of the table is the work: late events, hot keys, batch and stream reconciliation, triggers, and the on-call rotation. That is the part teams underestimate.
Are we locked in?
Events are yours and land in your warehouse. Definitions are portable. Leaving costs you the engine, not the data.
Our coding agent could build a version of this in an afternoon.
It could build the first attribute, a counter in a cache behind a function. History, late events, batch and stream parity and the rota are the same work on any stack, however it was written. Point the agent at Signals instead and the afternoon ends with something you don't have to own.
Do we need real time at all?
Not always. If next-day is fine, a nightly warehouse job is cheaper than either option on this page. Signals earns its place when the product has to react inside the session.
What if our attribute logic is unusual?
Counts, recency and ordering over windows such as ten minutes, this session or since last purchase cover the common cases. Raise the unusual ones early and we will tell you plainly whether they fit.
How do we justify this internally?
Compare against a staffing plan, not a license fee. The build cost is mostly people, and it does not end at launch.
Test the claim on your own events.
Define one attribute, read it from your product, and compare the latency to whatever you run today.