Daniel Eneanya

Problem

A stakeholder at Meridian Retail (simulated retailer) needed to walk into an investor meeting able to state exactly how many customer records were clean and how many were flagged as duplicates. They asked me to use the is_duplicate column in the customers sheet and return three figures: duplicates, clean records, and the total, with the three numbers adding up as a cross-check.

What I did

Using COUNTIF against the is_duplicate column, I produced two targeted counts: one for TRUE (duplicates) and one for FALSE (clean records), placed in adjacent labelled cells so the results were immediately readable. For the total I used COUNTA on the same range, which counts every non-empty cell regardless of value. Placing all three in a row with clear headers in row 1 meant the numbers were presentation-ready without any additional formatting work.

Outcome

The stakeholder had three audited, labelled figures they could cite with confidence in the investor meeting and a built-in check that the counts were consistent.

Next step

A useful next step would be checking whether the 200 duplicate rows cluster around specific acquisition dates or regions, which could point to a data entry or import problem worth fixing at source.

Problem

A stakeholder at Meridian Retail needed to walk into an investor meeting with a clean customer number and could only read a message on their phone between sessions. They asked me to send a short email stating the clean count, one sentence explaining why it is the right figure to use, and one sentence flagging the duplicates so nobody in the room would be surprised by the higher raw total.

What I did

The email led with the clean count of 2,131 stated plainly in the first line, because that is the only thing the stakeholder needed to confirm before the meeting. One sentence followed explaining that duplicates had been excluded, making it the trustworthy figure. A third sentence noted that 200 duplicate rows exist in the raw data and that the total before deduplication is 2,331, giving the stakeholder a ready answer if anyone in the meeting quoted a different number.

Outcome

The stakeholder entered the investor meeting with a verified number, a one-line rationale, and a preemptive caveat, all readable in under thirty seconds on a phone.

Next step

I did not investigate whether the 200 duplicates represent real customers counted twice or entirely erroneous entries; knowing the split would sharpen how the caveat is worded in future communications.

Problem

Different teams at Meridian Retail were producing different customer counts and the senior analysts were trying to understand why. My piece of that effort was to produce one definitive clean count using the is_duplicate flag in the customers table, a number that everything else could be compared against.

What I did

Filtering on is_duplicate = false isolates the rows the business considers reliable, removing every row the system has already flagged as a bad record. COUNT(*) then returns the size of that clean set with no additional assumptions. Keeping the query short and direct made it easy for reviewers to verify that nothing unintended was filtered out.

Outcome

Having one confirmed number gave the team a fixed reference point so that discrepancies between other counts could be traced to their source rather than debated indefinitely.

SELECT COUNT(*)
FROM retail.customers
WHERE is_duplicate = false

The WHERE clause uses a boolean comparison to exclude all flagged rows, and COUNT(*) returns the size of the remaining clean set.

Next step

Comparing the 2,131 clean records against the counts produced by the other teams would be the direct next step, to identify which teams are including duplicate rows and why.

Problem

Senior analysts at Meridian Retail (simulated retailer) were investigating a revenue gap in October 2023 and needed a single confirmed fact before proceeding. The stakeholder asked me to count every order placed in October 2023 using the created_at column in the orders table. One number, verified and ready to anchor the broader analysis.

What I did

To capture the full month without ambiguity, I used a half-open date interval: created_at >= '2023-10-01 00:00:00' AND created_at < '2023-11-01 00:00:00'. This boundary includes any rows timestamped at midnight on the first and cleanly excludes November without needing to guess at end-of-day values. COUNT(*) was the right aggregate here because every row represents one order and no row should be skipped.

Outcome

The verified count gave the investigation team a reliable starting point, removing any ambiguity about the denominator before they moved into revenue breakdowns.

SELECT COUNT(*)
FROM orders 
WHERE created_at >= '2023-10-01 00:00:00' 
 AND created_at < '2023-11-01 00:00:00';

The half-open interval captures every timestamp in October, including midnight on the first, while guaranteeing no November rows are included.

Next step

A useful next step would be breaking the 610 orders down by day to see whether the revenue gap is concentrated in a specific week or spread evenly across the month.

Problem

While a revenue question was still open, a stakeholder at Meridian Retail needed a number they could glance at immediately. They asked me to connect Power BI to the Meridian database, bring in the orders table, and display total gross revenue in naira on a single card visual. The amounts in the table are stored in kobo, so a conversion step was required.

What I did

I wrote a DAX measure, Gross revenue = SUM('retail orders'[total_cents])/100, which sums all values in the kobo column and divides by 100 to produce naira. The measure was set to Currency format with two decimal places in the Measure tools ribbon, so the output reads as a clean financial figure rather than a raw integer. Placing this measure in a single card visual and titling the page 'Total gross revenue in naira' kept the deliverable focused on the one question being asked.

Outcome

The card gave the stakeholder an always-current gross revenue figure they could check while the deeper revenue investigation was underway.

Next step

Adding a date slicer to this page would let the stakeholder compare gross revenue for specific periods rather than only viewing the all-time total.