FIELD NOTES / SHAHARIER SHOUROV
Inside the Olist Dashboard: From 9 Messy CSVs to a 3-Page Report
The preparation, modelling decisions and limits behind my Olist Power BI report.
Published · Updated

The work behind the overview
My Olist project brings together separate ecommerce CSV files and turns them into a Power BI report. The dashboard shows revenue, delivery performance and customer sentiment together, but the relationships between the source tables are the more important part of the work.
One order can become several rows
Orders, products, payments and reviews do not all have the same level of detail. My combined fact table is described at product line level. That means a count of its rows is different from a count of orders.
This matters when calculating delivery rates or review averages. If an order appears on several product lines, its delivery status can be repeated. The intended unit of analysis needs to be explicit before a percentage becomes a headline KPI.
Preparing the sources
I used Power Query to standardise location text, translate product categories and prepare delivery fields. The original project notes also describe review deduplication and payment filtering. Those choices need careful documentation because they affect which records reach the report.
For payments in particular, retaining only one record per order can remove genuine payment amounts. The revenue measure needs to be reconciled with the source rather than accepted because the dashboard looks reasonable.
What the report suggests
The report brings delivery performance and review scores into the same discussion. Differences between states are a useful starting point for investigating customer experience. They do not, on their own, prove that delivery causes low scores or rule out product quality.
What I would make clearer
I would show the exact definitions behind revenue, order counts and delivery rates, along with the filters used for each. The executive screenshot also ends the 2018 monthly series in August. Comparing complete annual totals without accounting for that coverage would be misleading.
Read the case study for the project structure, dashboard and limitations.


