Atlas Charts & the Ride-Analytics Problem

Thirty-seven percent of bookings never carry a passenger. Today we build the dashboard that finds out why.

Learning Objectives

• ✓ State a business problem in a form that a dashboard can actually answer
• ✓ Connect Atlas Charts to a collection and build a chart without writing a query
• ✓ Explain the relationship between a Charts encoding channel and a $group stage
• ✓ Choose a chart type from the question being asked rather than from habit
• ✓ Use a query filter and an aggregation pipeline inside a chart's data source
• ✓ Recognise the small-sample, missing-field and truncated-axis traps before they reach a slide
• ✓ Assemble four charts into a dashboard that answers one coherent question

Session Timeline

Section 1: The Brief — A Real Business Problem

For four lectures you have been running queries against bdma.rides because they were on a worksheet. Today the worksheet is replaced by a person.

That is a real brief, and it is typical in exactly the way that matters: it names a symptom, not a question. Before you open any tool, the first job is to convert it into something answerable.

From a complaint to a question

“Where is the money going?” cannot be plotted. Decompose it until each piece can be:

Each row of that table becomes one chart. Nothing else gets built. This discipline — no chart without a question written down first — is the single most useful habit in this module, and it is also the first thing the project rubric checks.

Sizing the problem before you start

Begin by establishing the magnitude, because it determines how much effort the problem deserves. From the aggregations you wrote in Lecture 14:

Even halved, the figure is roughly ₹6.7 lakh against ₹22 lakh of realised revenue. That is large enough to justify the work. Establishing this in the first five minutes is what separates an analysis from a hobby.

Section 2: Why Atlas Charts Rather Than Excel

You could export a CSV and build this in Excel in an afternoon. Many analysts would. It is worth being precise about what you lose when you do.

Where Charts sits in the wider market

Atlas Charts is not competing with Tableau or Power BI on features, and you should not present it as though it were. It wins on exactly one axis: it is already connected to your data.

• Tableau / Power BI — far richer visual grammar, modelling layers, enterprise governance. They also need a connector, an extract schedule, a licence per seat, and someone to own all three.
• Atlas Charts — included with the Atlas cluster, no connector, no extract, handles nested documents natively. Weaker at complex blending across many sources.
• A hand-built dashboard (what the course dashboard is) — total control, no licence, and you own every bug forever.

For a team already on Atlas that needs an operational dashboard this week, Charts is usually the right call. For a finance function blending ERP, CRM and warehouse data, it is not. Saying which situation you are in is the analysis; the tool follows.

Section 3: Charts' Mental Model — Sources, Encodings, Filters

Atlas Charts has three concepts. Once they click, the interface stops being a maze.

1. The data source

A data source is a collection, a view, or a collection with a pipeline attached. It is defined once in Charts → Data Sources and reused by every chart that needs it.

The important option is the one people miss: a data source can carry its own aggregation pipeline. Everything you learned in Lecture 14 is available here. If a chart needs a derived field — booking hour, say — you do not fight the chart builder. You attach a pipeline to the source and the field simply exists:

[
  { $addFields: {
      hour: { $toInt: { $substr: ["$booked_at", 11, 2] } },
      failed: { $cond: [{ $eq: ["$status", "Completed"] }, 0, 1] }
  } }
]

Two lines, and every chart built on that source can now encode by hour or average the failure flag. Recall from Lecture 12 that booked_at is stored as an ISO string in this dataset, which is why we slice characters 11–12 rather than calling $hour. If you prefer the date operators, convert first with { $toDate: "$booked_at" }.

2. Encoding channels

A chart in Charts is built by dragging fields onto channels. Each channel is a visual property, and each one maps directly onto something you already know how to write by hand:

This equivalence is the point of teaching aggregation before visualisation. Charts is a graphical front end to a pipeline. When a chart shows a number you did not expect, you debug it by asking what pipeline would produce this? — and then you go and run that pipeline in mongosh to check.

3. Filters

Filters exist at three levels, and knowing which one you used matters more than it sounds:

• Source-level — a $match in the source pipeline. Applies everywhere, invisible on the chart.
• Chart-level — set in the chart's own filter panel. Applies to that chart only.
• Dashboard-level — an interactive control the viewer manipulates. Applies to every chart bound to that field.

Section 4: Building the First Four Charts

Build these along with the lecturer. Each one states its question first, then its configuration, then the answer it gives.

Chart 1 — How do bookings actually end?

The result, which should match your Lecture 14 pipeline exactly:

What it tells you immediately: driver cancellations are 17.99% — more than two and a half times customer cancellations at 6.81%. Add “No Driver Found” at 6.91% and roughly 25% of all bookings fail on the supply side. That single comparison reframes the brief: this is not customers changing their minds, it is the operator failing to deliver a car. Every subsequent chart should be chosen to test that hypothesis.

Chart 2 — Which products carry the value?

The insight hiding in the ordering: Premier Sedan earns the most revenue from only 1,954 bookings, while Go Sedan takes 2,854 bookings to earn less. Uber XL earns ₹4.3 lakh from 1,231 bookings. Ranking by volume and ranking by revenue give different answers — and a failed Uber XL booking costs ₹558.77 against ₹278.77 for a Go Sedan. If you can only fix cancellations for one product, the arithmetic says start where each failure is most expensive, not where failures are most numerous.

Chart 3 — Does failure depend on the time of day?

This is the finding of the session. The busiest hour is 18:00, and the instinct of every operations team is to throw resources at the peak. But 17:00 — one hour earlier, still carrying 1,062 bookings — fails at 39.92% against the peak's 37.14%. Supply is thinnest just before demand peaks, not during it. Drivers have not yet repositioned for the evening rush.

Chart 4 — Which failures are most common?

A genuinely awkward result. Four reasons, all between 24% and 27%. There is no dominant cause. This is worth sitting with, because the temptation is to pick the top bar and call it the answer — but a 27% leader among four near-equal options is not a finding, it is a flat distribution.

The honest read: there is no single fix available. Either you attack all four, or you accept that the reason codes themselves are too coarse to act on and recommend better instrumentation. “The data cannot answer this; here is what we would need to collect” is a legitimate and often valuable recommendation. We develop it properly in Lecture 16.

Section 5: Choosing the Right Chart Type

Chart choice is not aesthetic. Each type encodes a specific relationship, and using the wrong one makes the reader work to undo your encoding.

Four choices that are almost always wrong

• A pie chart with twelve slices. Nobody can rank slices 7 through 12. Use a sorted bar chart.
• A 3D anything. Perspective distorts the lengths and areas the reader is trying to compare. There is no situation in this course where 3D is the right answer.
• A line chart over an unordered category. A line between “Go Sedan” and “Uber XL” implies a progression that does not exist. Lines are for ordered dimensions only.
• A dual axis chosen to make two lines cross. Dual axes are legitimate for genuinely different units. Scaling them until the lines intersect at a dramatic point is a rhetorical trick, and an informed audience will catch it.

Section 6: Three Traps That Produce Confident Nonsense

Each of these is live in the course dataset right now. They are not hypothetical.

Trap 1 — The small-sample rate

Sort the hourly failure rates from Chart 3 by rate instead of by hour, and the top of the list is not 17:00. It is 03:00, at 43.48%.

The fix is a volume floor, applied in the source pipeline after the grouping stage:

{ $group: {
    _id: "$hour",
    bookings: { $sum: 1 },
    failed:   { $sum: { $cond: [{ $eq: ["$status", "Completed"] }, 0, 1] } }
} },
{ $match: { bookings: { $gte: 1000 } } },
{ $addFields: {
    failure_rate: { $round: [{ $multiply: [{ $divide: ["$failed", "$bookings"] }, 100] }, 2] }
} },
{ $sort: { failure_rate: -1 } }

Now 17:00 tops the list legitimately. The threshold of 1,000 is a judgement call, not a law — but you must state it and be able to defend it. “We excluded hours below 1,000 bookings because rates below that are unstable” is a defensible sentence. Silently excluding them is not.

Trap 2 — Averaging over absent fields

Recall from Lecture 12 that booking_value is absent on cancelled and no-driver-found bookings. MongoDB's $avg skips missing fields silently — it does not treat them as zero, and it does not warn you.

Both produce a plausible-looking number. Only the second has a definition you can state in one sentence. Filter explicitly to the population you mean, and name that population in the chart title.

Trap 3 — The truncated axis

Completion rates by vehicle type run from 61.77% to 62.79% — a spread of one percentage point across the fleet. Plot that on an axis from 61% to 63% and Uber XL's bar towers over Go Sedan's. The chart is technically accurate and completely misleading.

Start value axes at zero. The honest conclusion here is that completion rate barely varies by vehicle type, which is itself informative: the failure problem is not product-specific, so a product-specific fix will not work. A truncated axis would have hidden that conclusion behind a dramatic-looking bar chart.

Section 7: Hands-On — Build the Dashboard

Key Takeaways