Built with Python & Google Colab
How I Spent a Weekend Inside 1,898 Food Orders — and What FoodHub’s Data Actually Taught Me?
A full, honest, first-person walkthrough of my exploratory data analysis and revenue-optimization project on the Kaggle FoodHub dataset — every step, every chart, and every moment where the data surprised me.
Why I picked this project
I’ll be honest with you — when I started building out my data science portfolio, I very nearly reached for the Titanic dataset again. Everyone starts there. Everyone finishes there. And after a while, it stops proving anything to anyone, including yourself.
So I went looking for something that felt lived-in instead. Something I interact with as a customer almost every week. That’s what pulled me toward the FoodHub dataset on Kaggle. We’ve all opened a delivery app at 9 PM because cooking suddenly felt like too much effort. What I hadn’t really thought about, until I sat down with this CSV, was everything happening on the other side of that “Order Confirmed” notification.
I wanted to step into the shoes of an actual Data Scientist working inside FoodHub and answer the questions a founder or operations lead would genuinely lose sleep over:
- Why are some restaurants so much more popular than others?
- Does a slow delivery really wreck a customer’s rating, or is that just assumed?
- How does a food aggregator actually turn a $12 burger order into revenue?
This post is my full, unfiltered walkthrough of finding out.
Understanding FoodHub's business, before touching a single line of code
Before I open a notebook, I try to force myself to sit with the business problem for a bit — otherwise I end up writing code that answers questions nobody actually asked. So here’s what I knew going in.
FoodHub is a food aggregator platform — a middleman that connects hungry customers to dozens of restaurants through a single app. New York’s restaurant scene keeps growing, and busy students and professionals are leaning on delivery more than ever instead of cooking or eating out.
The flow behind every order is deceptively simple:
- A customer places an order through the app.
- The restaurant confirms it and starts cooking.
- A delivery partner is assigned, picks the order up, and drops it off.
- The customer can, if they want to, rate the whole experience.
And FoodHub’s revenue model is just as simple on paper: it takes a fixed commission on every order that flows through a partner restaurant. My job, as I framed it for myself, was to dig into FoodHub’s order data and use it to understand customer demand, restaurant performance, and operational efficiency well enough to support real decisions.
Meeting the dataset
The dataset holds 1,898 individual orders, and each row is a tiny story: a hungry customer, a restaurant, a delivery partner, and a clock quietly ticking in the background. Here’s the data dictionary I was working from:
| FEATURES | WHAT IT MEANS |
|---|---|
|
order_id |
Unique ID of the order |
|
customer_id |
ID of the customer who placed the order |
|
restaurant_name |
Name of the restaurant |
|
cuisine_type |
Cuisine ordered (Italian, Chinese, etc.) |
|
cost_of_the_order |
Cost of the order in dollars |
|
day_of_the_week |
Weekday (Mon–Fri) or Weekend (Sat–Sun) |
|
rating |
Customer rating out of 5, or “Not given” |
|
food_preparation_time |
Minutes between order confirmation and courier pickup |
|
delivery_time |
Minutes between courier pickup and drop-off |
Knowing these columns mattered more than I expected. A high food_preparation_time points at a kitchen bottleneck. A high delivery_time could mean traffic, distance, or simply too few couriers on shift. Same slow order, completely different fix.
Setting up my workbench
Every project I do starts the same way — the “digital workbench” ritual. Nothing fancy, just the standard toolkit:
# Import libraries for data manipulation
import numpy as np
import pandas as pd
# Import libraries for data visualization
import matplotlib.pyplot as plt
import seaborn as sns
# Command to tell Python to actually display the graphs
%matplotlib inline
# Restrict float values to 2 decimal places for cleaner output
pd.set_option('display.float_format', lambda x: '%.2f' % x)
import warnings
warnings.filterwarnings('ignore')I worked in Google Colab, mostly because I didn’t want to fight with a local environment on a Saturday afternoon. Mounting Drive and loading the CSV took two lines:
# Loading the dataset
from google.colab import drive
drive.mount('/content/drive')
file_path = "/content/drive/My Drive/Datasets/foodhub_order.csv"
df = pd.read_csv(file_path)Small confession: I always run df.head() right after loading, purely as a sanity check that I pointed at the right file. It has saved me from at least one embarrassing debugging session before.
First look, missing values, and the statistical summary
Before hunting for patterns, I like to “shake hands” with the data — check its shape, its structure, its overall health.
print("There are", df.shape[0], 'rows and', df.shape[1], "columns.")
df.info()
df.isnull().sum()There are 1,898 rows and 9 columns — and every single column came back with zero missing values.
Beginner tip I still live by: always run df.isnull().sum() before anything else. If there are holes in your data, your conclusions will have holes too, and you won’t know it until it’s embarrassing.
What the numbers said at a glance
df.describe().T
df.describe(include='object').T- Average food preparation time: ~27 minutes; average delivery time: ~24 minutes — the kitchen, not the courier, was already looking like the slightly bigger time sink.
- Average order value: ~$16.50, with most orders sitting between $12 and $22 — a tight, consistent spending pattern.
- 178 unique restaurants and 14 cuisine types — a genuinely diverse little marketplace.
- Shake Shack is the single most-ordered restaurant, and American is the most popular cuisine overall.
The ratings gap
df['rating'].value_counts()| Rating | Count |
|---|---|
|
Not given |
736 |
|
5 |
588 |
|
4 |
386 |
|
3 |
188 |
This is the number that stopped me for a minute. 736 orders — nearly 39% of the whole dataset — carry no rating at all. That’s not a rounding error, that’s a massive blind spot in FoodHub’s feedback loop. Among the orders that were rated, sentiment skews positive, but almost 4 in 10 customers are simply staying silent, and the platform has no idea why.
Univariate analysis: one variable at a time
This is where I started building the “big picture,” column by column, before letting any of them talk to each other.
for col in ['cuisine_type', 'day_of_the_week', 'rating']:
plt.figure(figsize=(10, 5))
sns.countplot(data=df, x=col)
plt.title(f'Distribution of {col.replace("_", " ").title()}')
plt.xticks(rotation=45, ha='right')
plt.tight_layout()
plt.show()
Seeing it plotted out made the story land harder than the raw numbers did:
- Cuisine: American (~585 orders) and Japanese (~470) tower over everything else; niche cuisines like Vietnamese and Spanish barely register.
- Day of the week: orders spike heavily on weekends (~1,350) vs. weekdays (~550) — a very clear demand shift toward non-working days.
- Rating: “Not given” beats even a perfect 5-star rating in raw count. That bar chart alone justified the whole “ratings gap” section above.
Then I turned to the numeric columns to understand their shape and spread:
fig, axes = plt.subplots(3, 2, figsize=(14, 15))
fig.suptitle('Distribution of Food Preparation Time, Delivery Time, and Cost of the Order')
sns.histplot(data=df, x='food_preparation_time', kde=True, ax=axes[0, 0])
sns.boxplot(data=df, x='food_preparation_time', ax=axes[0, 1])
sns.histplot(data=df, x='delivery_time', kde=True, ax=axes[1, 0])
sns.boxplot(data=df, x='delivery_time', ax=axes[1, 1])
sns.histplot(data=df, x='cost_of_the_order', kde=True, ax=axes[2, 0])
sns.boxplot(data=df, x='cost_of_the_order', ax=axes[2, 1])
plt.tight_layout(rect=[0, 0.03, 1, 0.95])
plt.show()
Prep time spreads fairly evenly between 20–35 minutes, no dramatic outliers. Delivery time spans roughly 15–33 minutes with a couple of visible clusters. And order cost is right-skewed — most orders sit in that $12–$22 mid-range, with a long tail stretching toward $35.
Answering FoodHub's first questions
With the lay of the land established, I moved on to the specific questions the FoodHub team would actually ask in a meeting.
Which are the top 5 restaurants by order volume?
df['restaurant_name'].value_counts().head(5)| Restaurant | Orders |
|---|---|
|
Shake Shack |
219 |
|
The Meatball Shop |
132 |
|
Blue Ribbon Sushi |
119 |
|
Blue Ribbon Fried Chicken |
96 |
|
Parm |
68 |
Which cuisine is most popular on weekends?
df_weekend = df[df['day_of_the_week'] == 'Weekend']
df_weekend['cuisine_type'].value_counts().idxmax()Output: ‘American’ — the overall cuisine trend holds even when demand peaks.
What percentage of orders cost more than $20?
df_greater_than_20 = df[df['cost_of_the_order'] > 20]
percentage = (df_greater_than_20.shape[0] / df.shape[0]) * 100
print("Percentage of orders above 20 dollars:", round(percentage, 2), '%')555 orders, or 29.24% of everything in the dataset, cross the $20 mark.
Who are FoodHub’s most loyal customers?
df['customer_id'].value_counts().head(3)| Customer ID | Orders |
|---|---|
|
52832 |
13 |
|
47440 |
10 |
|
83287 |
9 |
A small handful of repeat customers is ordering far more often than everyone else. If I were on FoodHub’s growth team, this table alone would be my pitch for a loyalty program.
Multivariate analysis: letting variables talk to each other
This is the part of any EDA project I genuinely enjoy the most — comparing two variables at once and watching a real story emerge (or, just as often, watching an assumption I was sure about completely fall apart).
Cuisine vs. cost of the order
plt.figure(figsize=(15, 7))
sns.boxplot(x="cuisine_type", y="cost_of_the_order", data=df, palette='PuBu')
plt.xticks(rotation=60)
plt.show()
Southern, Middle Eastern, and Thai cuisines command the highest order values, while Korean and Vietnamese sit at the budget end. Most cuisines still cluster in the $12–$20 range — an overall mid-priced market, just with a few premium pockets.
Cuisine vs. food preparation time
plt.figure(figsize=(15, 7))
sns.boxplot(x='cuisine_type', y='food_preparation_time', data=df)
plt.xticks(rotation=60)
plt.show()
I half expected some cuisines — maybe something more elaborate — to take noticeably longer to cook. They don’t. Prep time stays fairly stable across the board, which tells me delays are more about a specific restaurant’s kitchen than the type of food it’s making.
Day of the week vs. delivery time
plt.figure(figsize=(15, 7))
sns.boxplot(x='day_of_the_week', y='delivery_time', data=df)
plt.show()
PLOT TWIST
This one genuinely surprised me. Weekday deliveries are slower than weekend deliveries, despite weekends carrying roughly 2.5x the order volume. My gut said “more orders should mean slower delivery” — the data said the opposite, which usually means the real bottleneck is staffing or routing, not raw demand.
Restaurant name vs. cost of the order — where the money really sits
df['customer_id'].value_counts().head(3)| Restaurant | Total Order Value |
|---|---|
|
Shake Shack |
$3,579.53 |
|
The Meatball Shop |
$2,145.21 |
|
Blue Ribbon Sushi |
$1,903.95 |
|
Blue Ribbon Fried Chicken |
$1,662.29 |
|
Parm |
$1,112.76 |
|
RedFarm Broadway |
$965.13 |
|
RedFarm Hudson |
$921.21 |
|
TAO |
$834.50 |
|
Han Dynasty |
$755.29 |
|
Blue Ribbon Sushi Bar & Grill |
$666.62 |
|
Rubirosa |
$660.45 |
|
Sushi of Gari 46 |
$640.87 |
|
Nobu Next Door |
$623.67 |
|
Five Guys Burgers and Fries |
$506.47 |
Revenue is heavily concentrated at the top — Shake Shack alone generates more order value than the next two restaurants combined. Out of 178 restaurants on the platform, a tiny handful are doing most of the heavy lifting.
Rating vs. delivery time
plt.figure(figsize=(15, 7))
sns.pointplot(x='rating', y='delivery_time', data=df)
plt.show()
Orders rated 3 show both the highest average delivery time and the widest variability. Delivery speed and consistency clearly matter more to how a customer feels about their order than almost anything else I tested.
Rating vs. food preparation time
plt.figure(figsize=(15, 7))
sns.pointplot(x='rating', y='food_preparation_time', data=df)
plt.show()
Unlike delivery time, prep time barely moves across rating buckets. Customers, it turns out, are far more forgiving of a slow kitchen than a slow courier.
Rating vs. cost of the order
plt.figure(figsize=(15, 7))
sns.pointplot(x='rating', y='cost_of_the_order', data=df)
plt.show()
5-star orders skew slightly more expensive than lower-rated ones — a gentle hint that satisfaction rises a little alongside order value, though it’s a soft effect, not a dramatic one.
The “no correlation” surprise
col_list = ['cost_of_the_order', 'food_preparation_time', 'delivery_time']
plt.figure(figsize=(15, 7))
sns.heatmap(df[col_list].corr(), annot=True, vmin=-1, vmax=1, fmt=".2f", cmap="Spectral")
plt.show()
PLOT TWIST
I genuinely expected some relationship between cost, prep time, and delivery time. Instead, every correlation came back essentially zero. Paying more doesn’t get your food made faster or delivered quicker — these are three independent operational systems, not one connected pipeline. That single heatmap quietly reshaped how I thought about the rest of the analysis.
Four real-world business scenarios
This is where the analysis stopped being academic and started sounding like something a FoodHub operations or growth manager would actually put in front of me on a Monday morning.
Scenario A — Who qualifies for the promotional offer?
FoodHub wanted to feature restaurants in its advertising, but only ones that cleared a real quality bar: a rating count above 50 and an average rating above 4.
# Filter out unrated orders and convert rating to integer
df_rated = df[df['rating'] != 'Not given'].copy()
df_rated['rating'] = df_rated['rating'].astype('int')
# Count ratings per restaurant
df_rating_count = df_rated.groupby(['restaurant_name'])['rating'] \
.count().sort_values(ascending=False).reset_index()
# Keep restaurants with more than 50 ratings
rest_names = df_rating_count[df_rating_count['rating'] > 50]['restaurant_name']
df_mean_4 = df_rated[df_rated['restaurant_name'].isin(rest_names)].copy()
# Average rating for each qualifying restaurant
df_mean_4.groupby(['restaurant_name'])['rating'].mean() \
.sort_values(ascending=False).reset_index().dropna()Scenario B — How much money did FoodHub actually make?
Data science isn’t just charts, it’s the bottom line. FoodHub’s real commission structure was:
- 25% commission on orders costing more than $20
- 15% commission on orders costing more than $5
- 0% on everything else
def compute_rev(x):
if x > 20:
return x * 0.25
elif x > 5:
return x * 0.15
else:
return x * 0
df['Revenue'] = df['cost_of_the_order'].apply(compute_rev)
total_rev = df['Revenue'].sum()
print('The net revenue is around', round(total_rev, 2), 'dollars')Output: The net revenue is around $6,166.30 across all 1,898 orders.
Honestly, writing that tiered function was the trickiest part of the whole project for me. It’s a perfect small example of translating a real pricing policy into working code — and a good reminder that “revenue” almost never sits in your CSV as a ready-made column. You have to build it, one if/elif/else at a time.
Scenario C — How many orders take too long?
FoodHub wanted to know what share of orders take more than 60 minutes from the moment they’re placed to the moment they land on the customer’s table — kitchen time plus delivery time, combined.
df['total_time'] = df['food_preparation_time'] + df['delivery_time']
total_orders = df.shape[0]
orders_gt_60 = df[df['total_time'] > 60].shape[0]
percentage = (orders_gt_60 / total_orders) * 100
print(f"Percentage of orders taking more than 60 minutes: {percentage:.2f}%")Output: 10.54% of orders take longer than an hour, door to door.
That’s roughly 1 in every 10 customers left waiting past the point most people consider reasonable for delivery — a small percentage that turns into a genuinely large number of frustrated people once you multiply it across a real customer base.
Scenario D — Weekday vs. weekend delivery speed
Finally, FoodHub wanted a direct, no-nonsense comparison of average delivery time across weekdays and weekends.
print('The mean delivery time on weekdays is around',
round(df[df['day_of_the_week'] == 'Weekday']['delivery_time'].mean()),
'minutes')
print('The mean delivery time on weekends is around',
round(df[df['day_of_the_week'] == 'Weekend']['delivery_time'].mean()),
'minutes')This confirmed what the boxplot already hinted at earlier: despite carrying roughly 2.5x the order volume, weekends still deliver faster than quieter weekdays. That’s not a demand problem — that’s a staffing or logistics problem hiding in plain sight.
What I learned: key insights
Pulling every thread together, here’s what the data actually told me about FoodHub’s business:
My recommendations for FoodHub
If I were walking FoodHub’s leadership team through this deck, here’s exactly what I’d put on the slide:
Lessons for fellow beginners
Finishing this FoodHub analysis was a genuinely satisfying milestone for me, and if you’re just starting your own data science journey, here’s the biggest lesson I want to pass on: don’t just code — tell a story.
A list of numbers means nothing to a business owner. But telling them “1 in 10 of your customers waited over an hour, and here’s exactly why,” makes you the person they want back in the room.
Data science is really just curiosity dressed up in code. It’s looking at a spreadsheet of timestamps and dollar amounts and seeing the actual heartbeat of a city’s food scene underneath it. Keep asking “why.” Keep questioning your own first assumptions — that correlation heatmap humbled mine pretty quickly. And don’t be afraid to get your hands dirty with real, slightly messy, real-world data instead of another perfectly pre-cleaned tutorial dataset.
Conclusion
This analysis paints the picture of a business with stable operations and consistent customer spending, but with demand — and revenue — heavily concentrated among a small set of cuisines and top-performing restaurants. Delivery performance, far more than kitchen speed or order cost, is the strongest lever on customer satisfaction. By tightening delivery efficiency (especially on weekdays), closing the feedback gap, and leaning into its highest-value transactions and restaurants, FoodHub has a clear, data-backed path to a better customer experience — and a healthier bottom line.
If you’re working through your own first EDA project, I’d genuinely love to hear what business questions you decided to answer. That’s usually the most interesting part of any project — not the code, but the question behind it.
FAQs ~
What is the FoodHub dataset on Kaggle?
It’s a public dataset containing 1,898 food delivery orders placed through a food aggregator app in New York, including order cost, cuisine type, restaurant name, day of the week, customer rating, food preparation time, and delivery time.
What tools do you need to do an EDA project like this?
Just Python with Pandas and NumPy for data manipulation, plus Matplotlib and Seaborn for visualization. I ran the whole thing in Google Colab, so there was zero local setup involved.
How long does a project like this take?
This one took me roughly one focused weekend, from loading the CSV to writing the final recommendations. The coding was the fast part — thinking through what each chart actually meant for the business took longer.
What's the single biggest takeaway from this analysis?
Delivery time, not food preparation time or order cost, has the strongest relationship with customer satisfaction — and weekday deliveries are notably slower than weekend ones despite far less order volume.
- Dataset
- Kaggle — FoodHub Data by Tasnim Niger, 1,898 rows, 9 columns, no missing values.
- Tools
- Python 3, Pandas, NumPy, Matplotlib, Seaborn, run in Google Colab.
- Methodology
- Univariate and multivariate exploratory data analysis, followed by four business-driven scenario calculations (promotional eligibility, commission-based revenue modeling, total-delivery-time SLA analysis, and weekday/weekend delivery comparison).
Add comment
You must be logged in to post a comment.