Python Projects

Rather than reusing the treated Gold-layer tables from OlistEcom, this project works from the 9 raw Olist CSVs (~1M+ combined records), so the cleaning and validation decisions are made fresh in Python instead of inherited from the SQL pipeline. Each notebook has its own log with exact numbers, decisions, and caveats.

01–03 Raw audit, cleaning, validation: profile every raw table, surface the structural facts later work depends on (for example, customer_id is a per-order key and customer_unique_id is the real person), produce the cleaned tables, and confirm row counts and join integrity before anything trusts a merge.

• 04 Sales & Revenue: overall sales, sales over time, payments, category performance
• 05 Customer & Seller Intelligence: seller performance, customer value, customer acquisition trend, customer geography
• 06 Fulfillment & Delivery: delivery timeline breakdown, on-time vs late, geographic patterns, delivery trends
• 07 Cross-Business Synthesis: questions that combine sales, customer/seller, and delivery lenses, which no single earlier notebook could answer
• 08 Key Insights Visualization: 8 matplotlib/seaborn charts, each visualizing one finding already established in 04–07

• Revenue is concentrated: the top 3 categories make up 25.2% of revenue and the top 20 make up 83.9%. Seller concentration is even steeper.
• Repeat buying is not the engine: 97% of customers buy once, and one-time buyers drive order volume in essentially every month, so Olist runs on constant new-customer acquisition.
• Delivery performance is strong: 91.86% of orders arrive on time, with two real late-rate spikes (Nov 2017 and Feb/Mar 2018) in high-volume months, so they are not small-sample noise.
• Geography is the biggest delivery lever: customers in states with no local sellers wait about twice as long (22.04 vs 11.93 days), yet those states hold only 1.16% of revenue, so it is a customer-experience problem more than a revenue risk.
• Lateness costs retention: a late first delivery lowers the repeat rate (2.62% vs 3.13%).
• Freight-expensive items have a non-completion problem, with a much higher rate of non-delivered orders, not a lateness problem, so the fix is about why orders get canceled.
• "Reliable seller" depends on the threshold: among the top 50 sellers by revenue, 16 pass a strict reliability bar and 34 do not, but most of the 34 fail only on delay speed, and loose bars passed all 50.

Built as a series of Jupyter notebooks using Pandas and NumPy for data handling and Matplotlib/Seaborn for the visuals. Revenue is defined as item price plus freight, and gross (all orders) and net (delivered only) figures are always reported as a labeled pair. One-to-many relationships between orders, order items, and payments are handled explicitly to avoid double-counting revenue on joins.

Two habits run through the whole project: every average is checked against its median because right-skew is the norm in this data, and real order volume is checked before trusting any monthly or categorical number, since several dramatic-looking figures (like a "100% late rate" in 2016-09) turned out to be near-zero-sample artifacts. Near-empty ramp-up and tail-off months are excluded from growth narratives. Five of the eight charts read small pre-aggregated summary tables exported from earlier notebooks.