Ajiku Iyaniwura

Problem

Nura Ibrahim, a stakeholder at Meridian Retail (simulated retailer), needed a visual analysis of a revenue discrepancy. Before any reporting could begin, the Meridian PostgreSQL database had to be connected to Power BI Desktop with all required tables loaded and relationships in place.

What I did

Using Power Query M code, I connected to the PostgreSQL host and loaded all 8 tables from the retail schema using Import mode, which pulls data into the model rather than querying live. Each table was referenced directly via its schema and item name in PostgreSQL.Database(), keeping the M code consistent and easy to audit. Power BI automatically detected 9 relationships across the model; I verified the sessions-to-customers link was set as inactive to prevent ambiguous filter paths that would corrupt downstream aggregations.

Outcome

Nura received a fully connected data model, including flag columns such as is_duplicate and is_first_order, ready for revenue analysis visuals to be built on top of it.

let
 Source = PostgreSQL.Database("ep-frosty-glade-ab4k8hyw-pooler.eu-west-2.aws.neon.tech", "meridian_retail"),
 retail_categories = Source{[Schema="retail",Item="categories"]}[Data]
in
 retail_categories

This M code pattern, repeated for each of the 8 tables, targets the correct PostgreSQL host and schema and loads each table by name into the Import mode model.

Next step

A useful next step would be to test whether the inactive sessions-to-customers relationship produces different totals when activated temporarily, to confirm the ambiguity concern is real and not just theoretical for this dataset.

Problem

Chidi Okafor at Meridian Retail (simulated retailer) needed a clean breakdown of customer volume by acquisition source ahead of an investor conversation. The specific question was which channels were bringing in the most customers, with duplicate records excluded from the count.

What I did

The customers table contains a boolean is_duplicate flag to mark known duplicate records, so I filtered those out in the WHERE clause before any aggregation. Grouping by acquisition_source and applying COUNT(*) then gave an accurate per-channel figure. Sorting descending by the count meant the highest-volume channels appeared first, matching exactly what Chidi described as investor-ready. The query is short but each clause does specific, required work.

Outcome

Chidi received a ranked, duplicate-free channel breakdown suitable for direct use in an investor conversation about acquisition strategy.

Next step

It would be worth breaking this down further by channel (online versus offline) within each acquisition source, to see whether Instagram's lead holds across both or is concentrated in one.

Problem

Nura Ibrahim at Meridian Retail (simulated retailer) wanted to know whether cancellations were worsening across Q4 2023 or whether October had been an isolated spike. She asked for a PivotTable showing all seven order statuses across October, November, and December, formatted in naira, with a stacked bar chart to visualise the monthly split.

What I did

In a new sheet named Status Breakdown, I set up the PivotTable with status on rows, order_date grouped by month on columns, and Sum of total_naira as the value field, sourcing from the full Orders range. Grouping dates by month inside the PivotTable kept the layout clean without requiring helper columns. Naira currency formatting was applied using the NGN custom format code so values displayed consistently. A stacked bar chart was added directly beneath the PivotTable, referencing the pivot data to show the monthly revenue composition by status.

Outcome

Nura received a formatted, chart-backed PivotTable covering all order statuses across Q4 2023, ready for presentation or further review.

Next step

Calculating cancellations and refunds as a percentage of each month's Grand Total, rather than absolute naira values, would make the trend easier to read when monthly total revenue itself varies.

Problem

Nura Ibrahim at Meridian Retail (simulated retailer) identified that all price columns in the order_items table were stored in kobo, which would produce incorrect results in any downstream revenue or margin calculation. She asked for the unit price, discount, and line total columns to be converted to naira inside Power Query before any measures were built.

What I did

Each of the three columns was transformed using Table.TransformColumns, dividing by 100 and setting the output type to number. This approach handles all three conversions inside a single M step rather than chaining separate column replacements. The renamed columns, unit_price_(#), discount_(#), and line_total_(#), follow the naming convention Nura specified so downstream measures can reference them without ambiguity. Keeping the transformation in Power Query means the conversion happens at load time and does not need to be repeated in DAX.

Outcome

Nura's team could build revenue and margin measures directly on the naira columns without any risk of kobo-scale errors propagating into reports.

Next step

It would be worth checking whether the orders table also contains any cent-denominated columns that need the same conversion, to avoid a situation where order-level and item-level revenue figures are on different scales.

Problem

Before Chidi Okafor's customer dashboard could be built at Meridian Retail (simulated retailer), the customers table required preparation. Known duplicate records needed to be removed, and three calculated columns, Full Name, Acquisition Year, and Customer Tier, needed to be added, with tier logic defined as New for 0 to 1 orders, Regular for 2 to 9 orders, and Loyal for 10 or more.

What I did

The task required filtering, column addition, and conditional logic inside a single Power Query pipeline. Removing duplicates via the is_duplicate flag at the Power Query stage meant clean data flowed through to every visual built on the dimension, rather than requiring repeated filtering in each measure. Full Name and Acquisition Year are straightforward derived columns from existing fields. The Customer Tier column required a conditional column or custom column step with the three-tier threshold logic applied to total_orders.

Outcome

Chidi received a clean customer dimension with pre-classified tiers, removing the need for duplicate-exclusion logic in individual dashboard measures.

Next step

It would be useful to verify how customers with zero total_orders are distributed across acquisition sources, to check whether the New tier is dominated by a single channel or spread evenly.