Every journey, watched live.
A real-time platform intelligence system for a leading ride-hailing and delivery platform. It tracks millions of user journey events and shows where a journey breaks, and why, before the problem becomes a customer complaint.
- The journey is the unit: every team watches the same customer journey, not its own separate dashboard.
- Cause, not symptom: each break is traced to marketing, UX, supply, system or support risk.
- While customers are active: teams act during the journey, not after the complaint.
Every event is read as part of a journey.
Meet our client
- Client
- Leading ride-hailing and delivery platform
- Industry
- Ride-hailing, logistics, on-demand services
- Market
- South Asia · millions of users across major cities
- Technology
- Real-time event tracking, streaming analytics, SQL, BI dashboards, AI-assisted querying
In a nutshell
The platform had no live, end-to-end view of how its ecosystem was working. Teams relied on delayed reports and separate dashboards that showed outcomes but not causes, so finding the source of a problem meant manual investigation across teams and tools. We built a real-time platform intelligence layer that treats every interaction as a signal in one live journey. It shows where a journey breaks and whether the cause is marketing, UX, supply, the system or support risk, while customers are still active. Product, operations, marketing and leadership now work from a single real-time operational truth.
Dashboards showed what happened, not why
Each team had its own dashboard, and each one looked fine on its own. Pick a symptom, then look at the journey.
Illustration · sample symptoms and journeys
- Conversion drops: caused by UI/UX friction, supply shortages or technical failures? No one could say.
- Cancellations: behavioural, operational or system-driven?
- Campaigns: bringing quality demand, or low-intent traffic?
- Support issues: could they have been prevented earlier in the journey?
- Found too late: issues surfaced only after complaints or performance had already dropped.
- Blame cycles: without a shared view of where failures started, teams argued instead of acting together.
One journey, watched by every team
Every department touches the same customer journey. So the journey, not the department, became the unit of monitoring. Pick a team to see the part of the journey it watches.
“Every department interacts with the same user journey, so the journey itself should be the unit of monitoring.”
- Diagnosing issues while users were still active, not in the next day’s report.
- Separating UX, operational, supply and technical failures, so the right team acts first.
- One operational view across teams, grounded in the same real-time event stream.
Where a journey breaks shows why
The system reads live sequences of events. When a journey stalls, loops or stops, the pattern points to the cause and to the team that owns it. Pick a journey and watch it break.
Illustration with sample event names. The two-minute window is the example rule from the project.
- Marketing: users land from a campaign but never move on to pricing or a ride request. That is low-intent traffic or misaligned targeting, not a product failure.
- UI / UX: repeated navigation between screens, returning to the same page without progressing, or journeys that stall point to friction in a specific part of the app.
- Supply: a ride request with no driver assigned inside a set window, for example two minutes, is flagged as a supply imbalance.
- System: an event fires (for example, ride started) but the next expected event never arrives. That points to a backend failure, an API issue or an app crash.
- Support risk: breakpoints that usually end in a complaint are caught before the customer contacts support.
Supply gaps, zone by zone, as they open
Request and assignment patterns show where supply is short, where demand is spiking and where riders should move. Pick a time of day, then act on a flagged zone.
Illustration · sample city, zones and patterns.
- Supply shortages by city or zone, from requests that wait too long for a driver.
- Demand spikes that need driver incentives, while the spike is still happening.
- Areas that need rider redistribution, by comparing short zones with nearby zones that have spare drivers.
Quality demand, not just traffic
Campaigns were judged by what users did after they landed, in real time. Switch from counting clicks to following the journey.
Campaign A Looks smaller
Campaign B Looks bigger
Fixing it before the ticket
Failed journeys were caught before customers contacted support, so the team could step in early. Compare the two.
Illustration · sample journey
- Early CX intervention: failed journeys are visible while the customer is still active.
- Proactive resolution: the team resolves the issue instead of waiting for the complaint.
- Fewer tickets: problems caught early reduce support ticket volume.
Minute, hour and day, from one event stream
Teams could watch live activity minute by minute, hourly operational patterns and daily structural trends. Every layer comes from the same real-time events. Switch the view and the layers.
From app events to answers
Events stream from the app and backend, are shaped with SQL, stored in a central warehouse, and reach teams through operational dashboards and an AI-assisted query interface. Open a layer, then ask a question.
From reactive reporting to operational intelligence
Teams could detect problems while users were still active, tell product, supply, marketing and system failures apart, and find root causes across departments.
Know why, while it’s happening.
Real-time journey monitoring that shows product, operations, marketing and engineering where a problem started, before customers feel it.
- 01Your business objective
- 02The technical context
- 03The right next step