Know where the funnel leaks,
and whether it was the code.
Datadog Product Analytics builds funnels, retention, pathways and heatmaps from the same RUM sessions that hold the errors and the traces. We implement it so the actions have names worth counting, scope the meter to the flows that matter, and run it every month so the funnel still measures the product that shipped.
Quick facts
Related
- Real User Monitoring, the sessions every funnel is built from
- Experiments, the same metrics, split by variant
- Session Replay, the sessions that dropped, watched back
The conversion drop and the stack trace, in the same session
Conversion fell on Tuesday. The product team opened the analytics tool and saw the drop at the address step. Engineering opened the monitoring tool and saw nothing wrong. Both were looking at different users. Product Analytics is the funnel drawn on the sessions the monitoring already has, so the drop and the error are the same row.
Funnels you can open. Each step is a view or an action, and each drop is a set of sessions. Click the drop and you are looking at the people who left, with their errors, their load times and their replays.
Retention by cohort and by release. Who came back a week later, grouped by the version they first used, the device they used it on or the segment they belong to. A release that quietly lost a cohort shows up here first.
Pathways and heatmaps. The routes users actually take, and where on the page they click, scroll and give up. The designed path and the real path are often different, and this is where the difference is visible.
Outcomes the browser cannot see. A payment that settles an hour later, a signup that is approved by a back-office process. Server-side events through the API join the funnel, so the last step is the real one.
Actions called click, users called anonymous, and a meter that follows the sample rate nobody set for it
How it bills. Product Analytics is billed per session on its own meter, counted on full traffic. It uses the same SDK and configuration as RUM, so the session sample rate set in that SDK decides which sessions are there to be counted. Server-side events sent through the API are billed separately from client-side sessions. Session Replay is a separate per-session meter if it is on, and a replay used in both RUM and Product Analytics is billed once. Behavioural data is kept for at least 15 months, which is what makes retention charts possible. Datadog publishes the rates. We publish nothing here, because the price is not the problem. The sample rate, set for RUM and inherited by analytics, is.
The configuration traps. The RUM SDK names actions automatically from the element the user touched. That is fine for debugging and useless for a funnel, where step three needs to be called submit address and not click on div. User identity is optional in the SDK, and without it retention measures browsers rather than people. The RUM sample rate was chosen for performance monitoring, where a representative share is enough. A funnel on a low-volume flow with that same sample rate has too few sessions to say anything. None of these produce an error. They produce a funnel that is confidently wrong, which is worse than no funnel.
Field noteThe most common gap we see is funnels built on automatic action names. A redesign changes the button text, the action name changes with it, and the funnel shows conversion falling to zero on the day of the release. The product did not break. The measurement did.
Field noteUser identity is never set in the SDK because the privacy review has not happened. Retention is calculated on anonymous browser IDs, every cleared cookie is a new user, and the retention chart says the product is losing everyone when it is losing nobody.
Field noteThe pattern we keep finding is two analytics tools on the same page, each with its own definition of a session, and a monthly meeting about why the numbers differ. The meeting never ends, because the definitions are different and nobody has written them down.
Field noteThe last step of the funnel is the browser confirming the order was placed. The order is then rejected by the fraud check a minute later, server-side. The funnel reports a conversion the finance system never saw, and the two reports disagree by exactly the fraud rate.
Name the actions. Identify the user. Then draw the funnel.
Product Analytics rides on RUM, so it is implemented with RUM. If neither is on, LaunchPad runs both as a managed project, and the Digital Experience Accelerator covers the critical flows in its four weeks. If RUM already runs, a Datadog HealthScan reports session volumes and action naming before we change anything.
- Agree the questions. Which flows need a funnel, which cohorts need a retention chart, and which decision each one will change. A funnel nobody will act on is a meter nobody needs.
- Name the actions in the code. Each funnel step gets an explicit action name in the frontend, set by attribute, so a redesign cannot rename it. Custom actions for the steps that are not clicks.
- Set user identity, with the privacy team in the room. A stable, pseudonymous user ID from the application, never an email address. Consent follows the same banner RUM already honours.
- Add server-side events for the real outcomes. Payment settled, account approved, order fulfilled. Sent through the API with the same user ID, so the last step of the funnel is true.
- Check the sample rate against the volumes. A flow with few sessions may need a higher RUM sample rate than performance monitoring would choose. We make that decision per application, with the meter in view.
- Hand over, in writing. The action naming convention, the user ID scheme and which events come from the server. The funnels and segments built, what each is for, and the session volumes on the day we finished.
Access is admin on the Datadog organisation plus a pull request into the frontend repositories, and a short working session with the product owner and whoever answers for data protection. We do not need production shell access to implement Product Analytics, and we do not ask for it.
A funnel is a claim about the product. The product changes every sprint.
A step is removed. A button is renamed. A new flow launches without action names. A campaign triples the sessions and the analytics meter with them. Managed Observability is the monthly service that keeps the funnels measuring the product that shipped.
Every month, we review the meter. Analytics sessions per application against the RUM sample rate, with server-side event volumes alongside. Anything that moved gets a reason or a fix.
Coverage follows the roadmap. New flows get action names and a funnel before launch. Retired flows lose theirs. A new cohort worth watching gets a segment the month it appears.
The funnels are kept honest. After each frontend release we check every funnel step still fires. A step that went to zero on release day is a naming break, and we fix it before the product review meets.
The fault is ours to take. When the drop at step three opens to a JavaScript error or a slow backend call, Critical Support takes it as an incident, 24x7, with the sessions that dropped as the evidence.
We operate the stack. You own the product.
An implementation partner builds the funnels and hands them over. A managed partner is still there when a redesign renames step three in March. We are the second kind. The action names, the user ID scheme, the funnels and the decisions stay in your Datadog organisation and your code, documented, and you can take them in-house whenever you choose.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Product Analytics, answered plainly
How is Datadog Product Analytics billed?
Product Analytics is billed per session, on its own meter. Datadog counts it on full traffic, and it uses the same SDK and configuration as RUM, so the session sample rate set in that SDK decides which sessions are there to be counted. Server-side events sent through the Product Analytics API are billed separately from the client-side sessions. Session Replay is a separate per-session meter if it is on, and a replay used in both RUM and Product Analytics is billed once. Behavioural data is kept for at least 15 months by default, which is what makes a retention chart possible. We do not publish prices. The sample rate and the event design are what we tune.
Do we need to instrument the app again if we already have RUM?
No. Product Analytics is built from the sessions, views and actions the RUM SDK already collects. What usually needs work is the naming. An action called click on button is useless in a funnel, so we add action names and custom actions for the steps that matter. We set the user identity so retention can tell one person from a thousand. Server-side events are added only where the browser cannot see the outcome, such as a payment that settles later.
How is this different from Google Analytics or Mixpanel?
The funnel sits on the same session that holds the JavaScript error, the slow request and the backend trace. When conversion drops at step three, you can open the sessions that dropped and see whether step three threw an error, took too long, or was fine and people simply left. A standalone analytics tool shows the drop. Datadog shows whether engineering caused it. It is not a replacement for a marketing attribution tool, and we do not pretend it is.
What do heatmaps and pathways add?
Heatmaps show where users click, which elements get the most attention and how far down a page they scroll, drawn from the same sessions. Pathways show the routes users actually take between views, rather than the one the product team designed. Together they answer the question a funnel cannot: not just that people left at step three, but what they tried first.
What does Critical Cloud do with Product Analytics every month?
Managed Observability runs it every month. We review the analytics session meter against the RUM sample rate. After each frontend release we check that the actions each funnel depends on still fire. We add funnels and segments for new flows, retire the ones for flows that no longer exist, and report what changed. When a funnel drop turns out to be a production fault, Critical Support takes the incident, 24x7.
- Datadog products: every product, and how we implement and run each one
- Real User Monitoring: the sessions, the sample rate and the meter underneath
- Experiments: the same funnels, split by variant, with the statistics done properly
- Digital Experience Accelerator: RUM, Synthetics and the dashboards in four weeks
One session. One funnel. One answer to whose fault it was.
Tell us which flow the product review argues about. We will tell you what the sessions already say, what they could say with the right action names, and what it costs to get there.