"Can you analyze this dataset?"
It sounds like a data analyst's starting point. In reality, it's usually the last question you should ask.
Before you analyze anything, you have to answer harder questions:
- Can I trust this data?
- What decisions will this analysis support?
- What assumptions am I making before I ever create a chart?
My Cyclistic Bike Share capstone began as a Google Data Analytics Professional Certificate project. But instead of treating it as a visualization exercise, I approached it as if I had inherited a real analytics problem from a business team: imperfect data, unclear assumptions, and a need to produce insights someone could confidently act on.
Instead of asking "How do I answer the business question?" I started asking: "How do I build an analysis that someone else could trust?"
That mindset completely changed the project.
The Business Problem
Cyclistic, a fictional bike-share company based on Chicago's Divvy bike system, wanted to answer a straightforward question: How do casual riders differ from annual members?
The business goal was equally straightforward: Increase annual memberships by understanding how different customer groups use the service.
Simple question.
Not-so-simple data.
Twelve Months of Data Isn't One Dataset
The raw dataset consisted of twelve separate monthly files rather than a single analysis-ready table. During validation, I identified that only the verified January–August 2024 files could be reliably processed for this analysis.
Each file represented a different month of bike-share trips, which meant the first challenge was not finding insights—it was creating a reliable foundation for finding them. I needed to validate questions that could affect every downstream conclusion:
- Are the monthly files structured consistently?
- Are timestamps being interpreted correctly?
- Are duplicate or incomplete records present?
- Are ride durations realistic?
- Can the datasets be combined without introducing errors?
Those decisions shaped the entire workflow. Instead of jumping directly into visualization, I built a repeatable preprocessing pipeline that prioritized data quality and reproducibility.
The first notebook focused on processing the verified monthly datasets, applying consistent cleaning rules, engineering new features, and producing an analysis-ready dataset.
Some of the pipeline included:
- Importing monthly datasets
- Validating consistent structures across monthly datasets
- Parsing timestamps
- Calculating ride duration
- Removing invalid observations
- Handling missing values
- Combining all datasets into a single analysis-ready table
Instead of manually editing files, everything became reproducible.
Nothing flashy.
But this is the kind of work that makes later analysis trustworthy.
Data Cleaning Is Analysis
One lesson surprised me. Cleaning data isn't something you do before analysis. Cleaning data is analysis.
For example, ride duration immediately raised questions. Some trips lasted only a few seconds. Others appeared to last multiple days.
Those aren't just statistical outliers—they influence business conclusions. If I left them in, average ride times became misleading.
Removing them wasn't simply "data cleaning." It was deciding what constitutes meaningful customer behavior. That realization fundamentally changed how I think about analytics.
Descriptive Statistics Are More Powerful Than They Look
Once the processing pipeline was complete, I moved into exploratory analysis. The second notebook focused on understanding behavioral differences between members and casual riders. Some questions included:
- Who rides longer?
- Which days are busiest?
- Which bike types are preferred?
- Does seasonality affect each group differently?
- How do weekends compare to weekdays?
Using Pandas made answering these questions surprisingly elegant.
One line of code.
Hours of business discussion.
Visualization Changes Conversations
Numbers tell analysts something. Charts tell everyone else. Using Python visualization libraries, I created charts exploring:
- Monthly trip patterns by user type
- Ride duration distributions
- Hourly usage behavior
- Weekday versus weekend differences
These weren't decorative. Each chart answered a business question. One visualization immediately highlighted that casual riders used the service much more heavily on weekends, while annual members displayed consistent weekday commuting behavior. That insight supported marketing recommendations focused on converting recreational users into subscribers.
But the biggest takeaway from this project wasn't a single visualization or insight. It was the process that made those insights possible.
What I Learned About Building Better Projects
The biggest lesson from this project wasn't about Python. Or Pandas. Or statistics.
It was about building a system that survives beyond the first draft.
At the beginning of this post, I showed you the modular structure I used for the Cyclistic capstone. Initially, that structure felt like extra work. But as the analysis grew, I realized it was actually a safety net.
When you separate processing, validation, analysis, and insights into distinct stages, you stop worrying about "breaking" your final results every time you tweak a variable. It changes the way you work:
- You build for the future: If new monthly data arrives tomorrow, I don’t have to rewrite the project. I just rerun the pipeline.
- You gain confidence: By isolating the cleaning from the visualization, I knew exactly where to look when a number didn't look right.
- You create a standard: This isn't just about organizing files; it’s about treating an analysis like a production workflow.
That mindset is the biggest takeaway from this project. Whether I'm building a simple capstone or a complex business dashboard, I’ve learned that the most effective analyst isn't the one who writes the most code—it’s the one who builds the most reliable system.
Coming From Politics Changed How I Think About Data
Before transitioning into analytics, I worked in political organizing.
My work involved voter outreach, field operations, campaign metrics, and large-scale data collection.
Success wasn't measured by dashboards.
It was measured by decisions:
- Where should organizers go?
- Which neighborhoods need attention?
- Which messages are working?
That experience taught me something that's still true in analytics: Data only matters if someone can act on it.
Whether I'm analyzing voter engagement or customer behavior, the goal is the same.
Transform information into decisions.
- If I Rebuilt This Project Today
Every project teaches you what you'd improve next.
Today I'd likely:
- Build the pipeline with SQL and dbt
- Store processed datasets in a cloud warehouse such as BigQuery instead of relying primarily on local CSV outputs
- Automate ingestion with scheduled workflows
- Add interactive Tableau dashboards
- Incorporate geospatial analysis to identify station clusters
The questions stay the same.
The tooling evolves.
Final Thoughts
The Google Data Analytics Certificate gave me a business question.
This project taught me something much larger.
Analytics isn't about making charts.
It's about building systems that produce reliable answers.
Sometimes the most important part of a project isn't the final visualization.
It's the pipeline that makes every visualization trustworthy.
If you're building your own portfolio, my advice is simple: Don't just show what you found.
Show how you built confidence in your results.
Because that's the part employers—and fellow developers—remember.
Project Links
GitHub Repository: https://github.com/fpier042/cyclistic-capstone
Tech Stack:
- Python
- Pandas
- NumPy
- Matplotlib
- Google Colab
- Jupyter Notebook
Top comments (0)