Why SafariConnect
Every LuxDev assignment so far has taught me one technique at a time: a JOIN here, a window function there. SafariConnect was different. It wasn’t a lesson; it was a simulation: a multi-day project where I had to act as the analyst a company actually hires—clean the data, interrogate it, and walk out with something a board could act on.
That last part is the bit that changed how I worked. I wasn’t writing queries for a grade. I was writing them for a slide.
Day one: the data doesn’t trust you yet
I pulled the raw SafariConnect tables into PostgreSQL and opened them in DBeaver, and the first thing I learned (again) is that “clean” is a decision, not a state. Some nulls should have been zeros, dates stored as text, and duplicate records sitting quietly under slightly different primary keys.
This is where the Week 2 habits paid off — I wasn’t fighting PostgreSQL syntax anymore; I was fighting the data itself, which is a much better problem to have. I leaned on:
- COALESCE to make missing values explicit instead of silently wrong
- Type casting to pull dates and numbers out of text columns
- A few CTEs to look at the mess before deciding how to fix it, rather than writing a fix and hoping
That last habit, inspect first, transform second, is probably the single biggest shift from how I used to write SQL.
Day two plus: asking the data actual business questions
Once the tables were trustworthy, the project moved from ‘clean this’ to ‘tell me something useful'. This is where JOINs, CTEs, and window functions stopped being syllabus items and started being tools I reached for instinctively:
- RANK() and DENSE_RANK() to surface top performers without writing a subquery essay
- PARTITION BY to compare segments against their own group, not the whole dataset
- Layered CTEs to build a query in readable stages instead of one unreadable monster
The mental shift here: a business question rarely maps to one query. It maps to a chain of small, honest queries, each one answering a piece of the bigger question.
Getting it board-ready in Power BI
The last stretch was translating query output into something a non-technical board member could glance at and understand in ten seconds. That’s a different skill from writing correct SQL; it’s about deciding what not to show.
A few things I kept in mind while building the report:
- If a number needs a paragraph to explain it, it’s not board-ready yet.
- Visuals should answer “so what,” not just “what”
- The SQL work is the foundation; in Power BI, the board doesn’t get credit for cleverness, only for clarity.
*What I’m taking into the next project *
SafariConnect made the gap between “I can write a query” and “I can produce an insight” very visible. By the end, SQL was the easy part; the harder, more valuable skill was deciding which numbers actually mattered to decision-makers.
If you’re working through a similar LuxDev style project: don’t wait until the dashboard stage to think about your audience. Ask “who reads this, and what do they need to decide?” from day one, and let it shape your queries, not just your slides.
_This is part of my ongoing series documenting the LuxDev Data Science, Data Analysis, and AI programme.
Top comments (0)