Coralogix launches Product Analytics, a new feature built directly on top of its existing Real User Monitoring (RUM) sessions, requiring no second SDK. It adds heatmaps, funnels, and pathways computed from the same session data already used for debugging, so a drop in conversion or a spike in rage clicks can be traced directly to the specific sessions, errors, and backend traces behind it. Heatmaps show click/scroll/rage/dead-click patterns over real screenshots; funnels measure ordered flows by unique users or sessions and can be filtered by app version, account, or environment; pathways trace actual navigation routes as a Sankey diagram. The feature is available now to early-access customers who ask their account representative to enable it, and requires a reasonably recent RUM SDK version.
Table of contents
What has changed?Where attention actually landsWhere the flow loses peopleThe routes you did not plan forFrom a percentage to a personWhy run product analytics on telemetry?The telemetry data lake underneathDo I need to change how I integrate?How to try itQuestions this post answers
What is Coralogix Product Analytics and how does it use RUM data?
Coralogix Product Analytics is a new feature that computes heatmaps, funnels, and pathways directly from Real User Monitoring session data already captured by the RUM SDK, requiring no second SDK or tag manager. It reads three event types the SDK already sends: sessions, views, and actions. Every metric links back to the underlying sessions, errors, and backend traces for root-cause analysis. Teams weighing a bolt-on analytics tool versus telemetry-native analytics can compare approaches through posts curated on daily.dev.
Do I need to install a new SDK to use Coralogix Product Analytics?
No, Coralogix Product Analytics reads events already sent by the existing RUM SDK, so it populates automatically once enabled for an account. It does require a reasonably recent RUM SDK version, so teams should check their SDK version against the minimum required for each platform before assuming data is missing. Engineers rolling out observability upgrades can track SDK version requirements like this via daily.dev.
How do I choose between measuring unique users versus sessions in a conversion funnel?
Unique users answers how many distinct people completed a flow, while sessions answers how many attempts completed it, and the two numbers diverge sharply for flows people repeat, such as checkout abandonment followed by return visits. A user who abandons and retries twice counts as three sessions but one unique user, so picking the wrong metric can misrepresent conversion performance. Product teams debating funnel metrics can find comparisons and analytics practices on daily.dev.