Product Analytics
A product that reads user behavior collected by the same SDK as RUM in the form of funnels and retention. Whereas RUM looks at "is it fast, is it broken," this answers "who did what, and where did they drop off."
What it does
Using sessions, views, and actions recorded by the browser and mobile SDKs, plus server-side events sent via the API, it analyzes feature usage, conversion rate trends, user paths, and retention by segment. Behavioral data is retained for 15 months by default, and if RUM is already configured, it can be enabled without re-instrumentation.
When to use it
Use it when you need to answer with numbers questions like "we shipped a new feature, but is it being used," "at which stage of the signup flow do people disappear," and "what did users who dropped off in their first week step on." Its strength is that you can check whether slow performance is contributing to drop-off by placing it side by side with RUM data from the same session.
An everyday analogy
If the in-store patrol (RUM) is the job of checking "are the shelves standing, is the register working," Product Analytics is a survey that counts customer traffic patterns on the same sales floor. It tallies which aisles people walk down and where they pick something up and put it back, and tracks week by week the share of people who made it to the register.
The questions RUM answers and the questions Product Analytics answers are different
Once you have RUM, you know from users' real sessions how many seconds a page took to display and where errors occurred. But questions like "half of the users disappear on page 3 of the signup form" or "only 10% of people touched the feature we released last month" cannot be answered with performance and error numbers alone. Product Analytics is the product that takes on these questions, and the official documentation describes its uses in 4 points: understanding product adoption, tracking conversion rates and their trends, understanding key behavior patterns, and visualizing user interactions (as of September 2026, source: Product Analytics). The raw material is collected with the same SDK and the same configuration as RUM, and apps with RUM already configured need no re-instrumentation. Enabling is just pressing Enable on the application settings screen, and the ability to cross-reference "is it fast" and "is it being used" on the same session ID is the fundamental difference from a setup that places a separate analytics tool alongside.
Which analysis tool answers what
The Product Analytics screens are divided into tools according to the question you want to answer. Here are the features the official documentation lists and the question each answers (as of September 2026, source: Product Analytics).
| Feature | Question it answers | Example from the official documentation |
|---|---|---|
| Engagement | Which features are used, and how much | Understanding product adoption |
| Funnel | At which stage of a key flow does drop-off occur | Seeing whether poor performance causes drop-off from a specific stage, and how the drop-off rate changes when steps are added |
| Pathways | In what order do users actually move between pages | Visualizing all user paths and analyzing the critical path |
| Retention | How many people come back after first use | Measuring how much users return to pages and actions |
| Users & Segments | Who are the groups of users with common characteristics | Creating a segment of people who added to cart but did not purchase, and sending a nudge email |
| Heatmaps | Where on the page was clicked, and how far was scrolled | Overlaying 3 kinds, Click maps / Top elements / Scroll maps, on Session Replay data |
What to note in this table is that the Funnel example includes "whether poor performance causes drop-off." When behavioral data and performance data live in separate tools, cross-referencing whether the cause of drop-off is UI design or slow loading takes effort. Heatmaps overlaying Session Replay recordings follows the same idea: you can see "where they stopped" both in numbers and on the actual screen.
Units of data - sessions / views / actions / server-side events
What the SDK collects automatically comes in 3 tiers of units. A session is one whole visit from when the user opens the app until they leave, a view is each page or screen visited within it, and an action is an interaction such as a click, tap, or scroll (as of September 2026, source: Product Analytics). A session ends after 15 minutes of inactivity or 4 continuous hours, and sessions from Synthetics browser tests are excluded from billing (source: RUM Browser Data Collected). How they are counted and how that affects billing is left to the RUM explainer. Because Funnel and Segments select actions as stages or conditions, whether operations with business meaning, such as "click on the purchase button," have names determines the quality of the analysis. Events that cannot be observed in the browser, such as payment completion or order processing, can be sent as server-side events via the Product Analytics API. They are billed separately, with the unit price following the pricing page.
Why 15-month retention matters for behavioral data
Product Analytics data is retained for 15 months by default (as of September 2026, source: Product Analytics). Because Retention tracks "how many came back 1 month and 3 months after first use" by groups (cohorts) per starting month (source: Retention Analysis), short retention leaves you without the groups to compare. For flows that run only once a year (procedures such as annual renewal), you cannot judge improvement unless the previous year's same-period Funnel remains. In contrast to RUM Investigate, which searches individual sessions and has 30-day retention (as of August 2026, source: Datadog Pricing), Product Analytics can be read as a product that leans toward aggregating and keeping data for a long time. Because part of Retention cannot be used until 15 months of data has accumulated after enabling, the right time to adopt is not "when you want to analyze" but 1 year before that.
Billing is per 1,000 sessions and does not double up with Session Replay
The billing unit is 1,000 sessions, and the unit price differs across the three forms of annual contract, monthly contract, and on-demand (SKU breakdown as of August 2026; source: Datadog Pricing). It covers all traffic, and behavioral data retention is 15 months. Lining it up with the RUM-side SKUs makes its position clear. For the actual unit prices, check Datadog's official pricing page.
| SKU | Billing unit | Scope and retention | Main caveats |
|---|---|---|---|
| RUM Measure | 1,000 sessions / month | All traffic / metrics 15 months | The tier focused on measuring performance and stability |
| RUM Investigate | 1,000 sessions / month | Filtered sessions only / 30 days | Counts only the sessions you narrow down for deep dives |
| Product Analytics | 1,000 sessions / month | All traffic / behavioral data 15 months | The subject of this article. All sessions form the base |
| Session Replay add-on | 1,000 sessions / month | Replay 30 days | Billed once even when used in both RUM and Product Analytics |
There are 2 key points for estimation. First, because Product Analytics covers all traffic, you get the monthly charge by dividing monthly sessions by 1,000 and multiplying by the unit price. Sessions from Synthetics browser tests are not billable (source: RUM Browser Data Collected). Second, even when you use Session Replay for Heatmaps, if you already have Session Replay under contract on the RUM side, you do not pay twice. How to read the overall pricing structure is left to the pricing guide.
Where the role differs from web analytics tools
Web analytics tools start from measuring marketing results. The questions Product Analytics answers overlap with part of that, but the data sitting next to it is different. Because RUM display times and errors, Error Tracking Issues, and APM traces are tied to the same session, you can move from the observation "the drop-off rate went up" to the cause side, "this API's latency increased that week," without crossing tools. Conversely, analysis of results per advertising acquisition channel and of traffic acquisition from search engines is the home ground of web analytics tools, and even though Product Analytics has UTM attributes, it is not positioned to aim at replacing them (UTM attribute collection as of September 2026, source: RUM Browser Data Collected). The dividing line between roles is "up to bringing the user in" versus "what happened inside the app after bringing them in," and it is a product suited to organizations that want to read the latter together with the context of performance and failures.
Should you adopt it, or pass?
The adoption decision changes greatly depending on whether you already use RUM. If RUM is in place, instrumentation is done and you can start with just the enablement operation.
- 1. Enable Product Analytics on an app with RUM already configured (no re-instrumentation needed)
- 2. Name the actions with business meaning (purchase, signup, save) and define just 1 Funnel
- 3. With 1 month of data, confirm the Funnel's drop-off stage and separate the cause by placing it alongside RUM performance data from the same session
- 4. Create a segment of users who dropped off, and measure the effect on the same Funnel after countermeasures
- 5. Anticipate the period needed for Retention comparison (several months to 15 months), and mainly use Funnel and Pathways until data accumulates
The conditions for passing are also clear. On a static information site with almost no user interaction, there are no stages to place in a Funnel. Even with a large session count, if the organization lacks the authority and structure to change the UI and flows in response to analysis results, 15 months of data becomes material that is merely looked at. Regarding the handling of personal information, the design of collected attributes and masking is a point of discussion shared with Session Replay, so we recommend the order of settling that sorting-out first and then enabling.
Things to watch out for
- This article is based on the official documentation as of September 2026. Feature names and screen layouts may change, so when in doubt, give priority to what the screen shows and what the official documentation states.
- This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.
- Server-side events are billed separately from Product Analytics session billing (as of September 2026). Check the unit price on the official pricing page.