Skip to main content
An AI trace (input, output, reasoning) only tells you what the model did. It doesn’t tell you whether that was actually useful: did the user accept it, edit it, cancel it, escalate it to a human? That’s what a signal is: an event you send us about user or product behavior. A journey is the thread that ties a user’s signals to the AI traces that happened around them, even across multiple calls or agents. Every signal and every trace carries the same journey_id, so DataFramer can line them up into one timeline.

​
The pieces

Browser SDK

@dataframer/signals: runs in your frontend, sends track/identify/group events, and generates the journey id.

Server Instrumentation

dataframer-journey: runs in your backend, picks up the journey id, and stamps it onto your Langfuse traces automatically.

Connect AI Observability

Already using an observability tool? Connect it and DataFramer pulls the traces in directly. Langfuse and LangSmith are supported today.

​
How it fits together

Browser@dataframer/signals

Sends track/identify/group events, tagged with journey_id, straight to DataFramer

Your Backenddataframer-journey

Stamps journey_id onto every trace

→
↓
Your Observability ToolLangfuse / LangSmith

Holds the tagged traces

→
↓
DataFramer
Signal · journey_idTrace · journey_id

Both land with the same journey_id and get lined up into one timeline

You only need the browser SDK if you want to capture user/product events. You only need the server library if you want your AI traces auto-tagged with the journey id. If your traces already live in an observability tool (Langfuse or LangSmith today), you don’t need either: just connect it and DataFramer pulls them in. Most setups combine the SDK with one of the other two.
This feature is early; reach out at info@dataframer.ai if you hit anything unexpected.