As part of my Subscription Churn project for StaffWise, I decided to use simulated data to practice creating a clean pipeline, building a data model, and analyzing real-world subscription business challenges. I wanted my dataset to mimic realistic scenarios, so I included details like subscription plans, trial periods, failed payments, and even customer locations.
But here’s where things got messy.
The Problem
I added a Location table because I thought it would be useful for analyzing geographic patterns in churn or retention. When I started building the data model, I discovered something frustrating:
- The
Locationtable had no columns in common with customers, subscriptions, or transactions. - There was no key to connect it to any of my other tables.
In short, my Location table was an island, completely disconnected from the rest of the dataset.
The Decision
I stepped back and thought about the business problem I was trying to solve: uncovering what’s driving revenue leakage at StaffWise. Since location data wasn’t necessary to address the executive team’s key questions about churn, trial conversion, and failed payments, I decided to drop the Location table from my model.
Sure, it would have been interesting to explore geographic churn trends. But at this stage, keeping the table would only have added complexity without adding value.
The Lesson
Working with simulated data feels like designing your own little world. But even then, things won’t always line up the way you expect. This experience reminded me that data modeling often involves making tough calls about what stays and what goes. And that’s part of the process, regardless of whether your data is simulated or real.