Built with Python & Google Colab
I didn’t start this project to build a model. I started it because I couldn’t stop thinking about a number: nearly one in three hotel bookings in this dataset never actually became a stay. This is the full story of how I chased that number down to its root causes — and what I got wrong along the way.
The problem: why cancellations are a revenue problem, not a scheduling one
The client behind this dataset, INN Hotels Group, was bleeding money in a very specific, very predictable way. Not through one big failure — through thousands of small ones. A guest books a room ninety days out, the hotel builds its staffing and inventory plans around that booking, and then, days before arrival, the guest cancels. The room often can’t be resold in time. If it does get resold, it’s usually at a discount, through a third-party channel that takes another cut.
Multiply that by roughly 12,000 cancellations and you have a business problem that looks operational but is actually financial. My job was to figure out, from the moment a booking is made, which reservations were flight risks — and more importantly, why.
Why this mattered to me:
I’ve worked in production planning before this, and this felt familiar — it’s the same story as an unreliable supplier, just wearing a hospitality costume. Predictable disruption is still disruption. If you can see it coming, you can plan around it.
Meet the data
I was working with 36,275 bookings across 19 columns, and for once, the dataset didn’t fight me. Zero missing values. Zero duplicate rows. That’s rare enough in real-world data that I double-checked it twice before moving on.
The columns covered three broad categories: booking mechanics (lead time, nights, room type, meal plan), guest behavior (special requests, prior cancellations, repeat-guest flag), and commercial details (price per room, market segment). My target column, booking_status, was labeled Canceled or Not_Canceled.
Understanding the data before touching a single model
It’s tempting to jump straight to model.fit(). I’ve learned not to. Before any modeling, I spent time just getting to know the dataset — running .info(), .describe(), and value counts on every categorical column, one at a time.
Here’s the actual first move — .info() on the raw dataframe, straight out of the notebook:
# Checking the structure and data type of the given data
data.info()Out [12]
<class 'pandas.core.frame.DataFrame'>
RangeIndex: 36275 entries, 0 to 36274
Data columns (total 19 columns):
# Column Non-Null Count Dtype
--- ------ -------------- -----
0 Booking_ID 36275 non-null object
1 no_of_adults 36275 non-null int64
2 no_of_children 36275 non-null int64
3 no_of_weekend_nights 36275 non-null int64
4 no_of_week_nights 36275 non-null int64
5 type_of_meal_plan 36275 non-null object
6 required_car_parking_space 36275 non-null int64
7 room_type_reserved 36275 non-null object
8 lead_time 36275 non-null int64
9 arrival_year 36275 non-null int64
10 arrival_month 36275 non-null int64
11 arrival_date 36275 non-null int64
12 market_segment_type 36275 non-null object
13 repeated_guest 36275 non-null int64
14 no_of_previous_cancellations 36275 non-null int64
15 no_of_previous_bookings_not_canceled 36275 non-null int64
16 avg_price_per_room 36275 non-null float64
17 no_of_special_requests 36275 non-null int64
18 booking_status 36275 non-null object
dtypes: float64(1), int64(13), object(5)
memory usage: 5.3+ MBAnd the two checks I always run right after — because a model built on data with silent gaps or duplicate rows is a model you can’t trust:
# Checking for missing values
data.isnull().sum().sum()Out [24]
0# Checking for duplicate rows
data.duplicated().sum()Out [27]
0Clean on both counts. That almost never happens with real operational data, so I treated it as a small gift and moved straight into the numbers. Here’s what .describe() handed back for the two variables that would end up mattering most:
A few things jumped out immediately and quietly shaped every decision after this point:
- Average lead time was ~85 days, but the range stretched all the way to 443 days — some people plan trips more than a year out.
- Average room price was €103.42, ranging from €0 (complementary bookings) to €540.
- Only 2.6% of guests were repeat visitors. I flagged this early as a retention problem, and it turned out to matter a lot more than I expected.
Booking_IDwas just a row identifier — unique for every booking, useless for prediction. I dropped it here rather than let it accidentally leak into the model later.
This step doesn’t produce a chart worth sharing, but it’s where I started forming hypotheses — long before I had any statistical evidence to back them up.
Exploratory data analysis — where the real story lives
I’ll be honest: EDA is my favorite part of any project, and also the part I see people rush through most. This is where you either find the signal, or you convince yourself there isn’t one and save weeks of wasted modeling.
Building my own EDA toolkit first
Instead of writing one-off plots for every column, I built four reusable functions at the top of the notebook and reused them for the rest of the analysis:
# reusable across every numeric / categorical column
def histogram_boxplot(data, feature, kde=False, bins=None): ...
def labeled_barplot(data, feature, perc=False, n=None): ...
def stacked_barplot(data, predictor, target): ...
def distribution_plot_wrt_target(data, predictor, target): ...It felt slower on the first two columns and paid for itself by the tenth. Every chart in this section came out of one of these four functions.
Univariate analysis: who is actually booking this hotel?
Looking at each variable in isolation built a surprisingly specific picture of the average guest:
- 72% of bookings are for exactly 2 adults — this is overwhelmingly a couples-and-pairs business, not a family destination.
- 92.6% of bookings involve zero children.
- 64% of bookings arrive through the Online channel, with Offline a distant second at 29%.
- October is the busiest arrival month at 14.7% of all bookings, with September and August close behind — a clear autumn peak.
- 54.5% of guests make zero special requests, and another 31.4% make exactly one.
- 96.9% of guests don’t need a parking space — most aren’t arriving by car.
- Both
lead_timeandavg_price_per_roomwere heavily right-skewed with long tails. I checked whether those tail values were data errors — they weren’t. They were genuine long-lead bookings and premium rooms, so I left them in rather than trimming them out.
The raw value_counts() behind two of those bullets, exactly as they printed:
data["type_of_meal_plan"].value_counts()Out [19]
type_of_meal_plan
Meal Plan 1 27835
Not Selected 5130
Meal Plan 2 3305
Meal Plan 3 5
Name: count, dtype: int64data["room_type_reserved"].value_counts()Out [19]
room_type_reserved
Room_Type 1 28130
Room_Type 4 6057
Room_Type 6 966
Room_Type 2 692
Room_Type 5 265
Room_Type 7 158
Room_Type 3 7
Name: count, dtype: int64Small thing I almost missed:
Room_Type 3 has exactly 7 bookings in 36,275 rows. I nearly one-hot encoded it away as noise — worth a second look before you drop anything a model might quietly be relying on.
Checking correlations before going further
A quick heatmap across the numeric features showed most variables were largely independent of each other — good news for modeling. The one real relationship worth noting: no_of_previous_cancellations and no_of_previous_bookings_not_canceled moved together (r ≈ 0.54), which makes sense — guests with a longer booking history naturally accumulate both counts.
Bivariate analysis: what actually separates a cancellation from a stay
This is where the project stopped being an exercise and started being a story. Comparing every feature against booking_status surfaced patterns that would, weeks later, turn out to be exactly what the final model leaned on hardest.
“Lead time didn’t just correlate with cancellations. It was the difference between a couple locking in a date and a couple keeping their options open.”
- Lead time is a cancellation magnet. Cancelled bookings clustered in a 60–250 day lead-time range; completed stays clustered much tighter, at 20–100 days. The further out someone books, the more time for plans to change.
- Loyalty is the strongest signal in the entire dataset. Repeat guests cancelled just 1.72% of the time, versus 33.58% for first-timers — a nearly 20x gap. Put another way: of every booking that got cancelled, 99.86% belonged to a first-time guest.
That cross-tab, straight from my stacked_barplot() helper — I still remember pausing on the “16” in the top-right cell:
stacked_barplot(data, "repeated_guest", "booking_status")Out [112]
booking_status Canceled Not_Canceled All
repeated_guest
All 11885 24390 36275
0 11869 23476 35345
1 16 914 930930 repeat guests total, and only 16 of them cancelled. That’s the entire loyalty argument in one table.
- Special requests are a commitment signal. As the number of requests rose, cancellation rates fell in a near-straight line. Guests who asked for nothing cancelled over half the time; guests who asked for something specific — a floor, a crib, a quiet room — showed up.
- The Online channel cuts both ways. It brings in the highest average revenue per booking (€112.26 vs. €91.63 Offline) — but it also accounts for 71.3% of every single cancellation in the dataset. Convenience for the guest is risk for the hotel.
- Price sensitivity is real. Cancelled bookings had a noticeably higher median price (~€100) than completed ones (~€80).
- October cancels the most in raw numbers (1,880 cancellations) — simply because it’s the busiest month, so more bookings means more opportunities to cancel.
And the special-requests breakdown — notice the pattern reading left to right, 0 requests through 5:
stacked_barplot(data, "no_of_special_requests", "booking_status")Out [114]
booking_status Canceled Not_Canceled All
no_of_special_requests
All 11885 24390 36275
0 8545 11232 19777
1 2703 8670 11373
2 637 3727 4364
3 0 675 675
4 0 78 78
5 0 8 8Zero cancellations once a guest makes 3 or more requests. Not “rare” — zero, in this sample. That’s a stronger relationship than I expected to find in a real-world dataset.
The moment it clicked for me:
By the end of EDA, I could already guess — correctly, as it turned out — that lead time, channel, and special requests would end up as the model’s top features. That’s usually a good sign you’ve actually understood the data, not just plotted it.
Preprocessing: getting the data model-ready
With the “why” mapped out from EDA, preprocessing was mostly mechanical — but a few decisions here mattered more than they look:
- Outlier check, not outlier removal. I ran boxplots across all 14 numeric features. The extreme values in lead time and price were confirmed as real business behavior, not data entry errors — so I left them untouched.
- Encoded the target:
Not_Canceled → 0,Canceled → 1. - Dropped
Booking_ID— flagged back in Step 1, removed here. - One-hot encoded every categorical column: meal plan, room type, and market segment.
- Scaled numeric features with
StandardScaler— but only for the models that actually need it. KNN measures distance and Naive Bayes assumes a distribution, so both got scaled inputs. Logistic Regression and the Decision Tree don’t care about scale, so I kept their inputs raw. - Split 70/30 into train and test sets — 25,392 training rows, 10,883 test rows — stratified so both sets kept the same 67:33 class balance.
Building four different models
I didn’t want to commit to one algorithm and hope for the best, so I built four baseline models — each with a genuinely different way of thinking about the problem — and wrote two small helper functions to evaluate all of them consistently:
def model_performance_classification(model, predictors, target, threshold=0.5): ...
def plot_confusion_matrix(model, predictors, target, threshold=0.5): ...- Logistic Regression (via
statsmodels, not scikit-learn) — I chose statsmodels specifically because it gives you p-values per coefficient. If I’m eventually explaining this to a revenue manager, “this variable is statistically significant” carries more weight than a black-box probability. - Gaussian Naive Bayes — a fast, probabilistic baseline to sanity-check everything else against.
- K-Nearest Neighbors, starting at K=2 — a distance-based approach that makes zero assumptions about how the data is distributed.
- Decision Tree (CART, unrestricted) — chosen because trees produce rules and feature importances a non-technical stakeholder can actually follow.
None of these were tuned yet. I wanted an honest, apples-to-apples baseline before I started optimizing anything. Here’s exactly what each one handed back on the test set, straight out of model_performance_classification():
logistic_reg_perf_test = model_performance_classification(LogisticReg, X_test_with_intercept, y_test)
logistic_reg_perf_testOut [175]
Accuracy Recall Precision F1
0 0.80391 0.62703 0.73553 0.67696nb_perf_test = model_performance_classification(nb_model, X_test_scaled, y_test)
nb_perf_testOut [184]
Accuracy Recall Precision F1
0 0.40742 0.96411 0.35229 0.51602
That Naive Bayes row is the first sign of trouble — recall through the roof, accuracy in the gutter. I made a mental note and kept going rather than reacting to one number in isolation.
knn_perf_test = model_performance_classification(knn_model, X_test_scaled, y_test)
knn_perf_testOut [195]
Accuracy Recall Precision F1
0 0.84434 0.63208 0.85508 0.72686decision_tree_perf_train = model_performance_classification(dt_model, X_train, y_train)
decision_tree_perf_trainOut [202]
Accuracy Recall Precision F1
0 0.99437 0.98570 0.99708 0.99136decision_tree_perf_test = model_performance_classification(dt_model, X_test, y_test)
decision_tree_perf_testOut [206]
Accuracy Recall Precision F1
0 0.86539 0.79501 0.79434 0.79467There it is — the overfit:
0.994 recall on training data, dropping to 0.795 on test. That ~20-point gap between train and test is the textbook signature of a tree that memorized rather than learned. This exact pair of numbers is what sent me into Step 5.
Tuning each model — the part nobody shows you
This is usually the part that gets skipped in tutorials, and it’s the part that took me the longest. Every model needed something different.
Logistic Regression: fixing multicollinearity before anything else
My first attempt at this model was a mess. Several coefficients had p-values that made no sense given what I’d just seen in EDA — a classic symptom of multicollinearity quietly poisoning the results. I ran a custom calculate_vif() function and this is exactly what came back:
vif_result = calculate_vif(X_train_with_intercept)
print(vif_result)Out [214]
Variance Inflation Factors:
Variable VIF
0 const 1.00000
1 no_of_adults 1.34506
... ...
13 avg_price_per_room 2.03263
... ...
24 market_segment_type_Complementary 4.35005
25 market_segment_type_Corporate 16.63442
26 market_segment_type_Offline 62.51301
27 market_segment_type_Online 69.47183Anything above 5 is generally considered a problem. These two were more than ten times over — a dead giveaway that the online/offline dummy variables were leaking information about each other. I dropped the worst offender and recomputed:
# dropping the highest-VIF variable, one at a time, until every VIF ≤ 5
while vif_result['VIF'].max() > 5:
drop the column with the highest VIF
recompute VIFOut [216]
Dropping market_segment_type_Online due to high VIFprint(vif_result)Out [217]
Variable VIF
... ...
24 market_segment_type_Complementary 1.32469
25 market_segment_type_Corporate 1.53067
26 market_segment_type_Offline 1.60207One drop and the whole block resolved — dropping Online freed up Offline too, since one-hot dummies are naturally correlated with each other. Every remaining VIF sat comfortably under 5.
From there I ran a second, separate loop — backward elimination on p-values, refitting the logistic model each time and dropping the least significant feature, until every remaining variable was significant at p < 0.05. Then, instead of accepting the default 0.5 classification threshold, I plotted the ROC curve and used Youden’s J statistic to find the threshold that actually balanced sensitivity and specificity:
optimal_idx = np.argmax(tpr - fpr)
optimal_threshold_logit = round(thresholds[optimal_idx], 3)
print("Optimal Threshold: ", optimal_threshold_logit)Out [230]
Optimal Threshold: 0.333AUC on that ROC curve came out to 0.86 — meaning the default 0.5 cutoff had been quietly working against recall the entire time. Reapplying the model at 0.333 instead of 0.5:
logistic_reg_tune_perf_test = model_performance_classification(LogisticReg_tuned, X_test_significant, y_test, optimal_threshold_logit)
logistic_reg_tune_perf_testOut [237]
Accuracy Recall Precision F1
0 0.77846 0.76612 0.63402 0.69384Recall jumped from 0.627 to 0.766 for the cost of roughly 3 accuracy points. For this problem, that’s a trade I’d make every time.
KNN: sweeping K instead of guessing
Rather than picking a K arbitrarily, I looped K from 2 to 20, refitting the model and printing recall at every step:
for k in range(2, 21):
knn = KNeighborsClassifier(n_neighbors=k)
knn.fit(X_train_scaled, y_train)
recall = recall_score(y_test, knn.predict(X_test_scaled))
print(f'Recall for k={"{k}"}: {"{recall}"}')Out [244]
Recall for k=2: 0.6320807627593943
Recall for k=3: 0.7372406057206955
Recall for k=4: 0.6581604038137969
Recall for k=5: 0.7254627033090297
Recall for k=6: 0.6676948962422883
Recall for k=7: 0.7212563095905776
Recall for k=8: 0.6758272574312956
Recall for k=9: 0.715086932136848
...
Recall for k=19: 0.7030286034772855
Recall for k=20: 0.6786315199102636
The best value of k is: 3 with a recall of: 0.7372406057206955That odd/even zig-zag isn’t noise — with an even K, ties between classes happen more often and get broken arbitrarily, which drags recall down. K=3 came out on top: close enough to the noisy extreme of K=1 to stay sensitive to real patterns, without being so local that it overfits.
Decision Tree: taming an overfitter with GridSearchCV
The base decision tree was, predictably, a disaster on paper — 0.994 recall on training data against 0.795 on test, the textbook definition of overfitting. Rather than hand-tune it, I ran it through GridSearchCV across a real parameter grid:
parameters = {
"max_depth": np.arange(5, 13, 2),
"max_leaf_nodes": [10, 20, 40, 50, 75, 100],
"min_samples_split": [2, 5, 7, 10, 20, 30],
"class_weight": ['balanced', None]
}
grid_obj = GridSearchCV(dt_model_tuned, parameters, scoring='recall', cv=5)
grid_obj.fit(X_train, y_train)
dt_model_tuned = grid_obj.best_estimator_Out [257]
DecisionTreeClassifier(class_weight='balanced', max_depth=11,
max_leaf_nodes=100, random_state=42)That’s 4 × 6 × 6 × 2 = 288 combinations, cross-validated 5 ways — 1,440 model fits. It took a while to run — long enough that I made coffee and came back. The grid search landed on min_samples_split=2 (the scikit-learn default, so it doesn’t even show in the printed repr), max_depth=11, max_leaf_nodes=100, and class_weight='balanced' to help offset the 67:33 imbalance. Refit with those parameters:
decision_tree_tuned_perf_train = model_performance_classification(dt_model_tuned, X_train, y_train)Out [259]
Accuracy Recall Precision F1
0 0.86354 0.84000 0.76606 0.80133decision_tree_tuned_perf_test = model_performance_classification(dt_model_tuned, X_test, y_test)Out [262]
Accuracy Recall Precision F1
0 0.85427 0.82025 0.75581 0.78671Train recall 0.840, test recall 0.820 — a 2-point gap instead of a 19-point one. Pre-pruning the tree this way closed almost the entire overfitting gap while keeping recall above 0.82.
Comparing all six model variants
Before I show the numbers, one decision needs explaining: I optimized for recall, not accuracy. In this problem, a false negative — telling the hotel a booking is safe when it’s actually about to cancel — is far more expensive than a false positive. Missing a real cancellation blindsides the hotel; over-flagging a safe booking just means one unnecessary check-in call.
This is the actual output of the final comparison cell — I concatenated every model_performance_classification() result into one dataframe so I could eyeball all six variants side by side instead of scrolling back through the notebook:
# testing performance comparison
models_test_comp_df = pd.concat([logistic_reg_perf_test.T, logistic_reg_tune_perf_test.T,
nb_perf_test.T, knn_perf_test.T, knn_tuned_perf_test.T,
decision_tree_perf_test.T, decision_tree_tuned_perf_test.T], axis=1)
models_test_comp_dfOut [273]
LogReg Base LogReg Tuned Naive Bayes KNN Base KNN Tuned DT Base DT Tuned
Accuracy 0.80391 0.77846 0.40742 0.84434 0.84416 0.86539 0.85427
Recall 0.62703 0.76612 0.96411 0.63208 0.73724 0.79501 0.82025
Precision 0.73553 0.63402 0.35229 0.85508 0.77597 0.79434 0.75581
F1 0.67696 0.69384 0.51602 0.72686 0.75611 0.79467 0.78671Cleaned up into a readable table, rounded to three decimals:
| 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 |
Naive Bayes technically posted the highest recall (0.964), and for about ten minutes I wondered if I’d found my answer. Then I looked at precision: 0.352. That model was flagging nearly every booking as high-risk, which is mathematically great for recall and operationally useless — a revenue team can’t act on “everything is risky.”
The tuned Decision Tree won on balance: strong recall, reasonable precision, the best F1 score of any model, and — critically — almost no gap between its training and test performance. That last part matters more than any single metric. It means the patterns it learned are real, not memorized.
The winning model, explained in plain terms
One of the most underrated things about a decision tree is that you can literally print its reasoning as text. Here’s the actual top of the tuned tree, exported straight from the notebook:
print(tree.export_text(dt_model_tuned, feature_names=X_train.columns.tolist(), show_weights=True))Out [267]
|--- lead_time <= 151.50
| |--- no_of_special_requests <= 0.50
| | |--- market_segment_type_Online <= 0.50
| | | |--- lead_time <= 90.50
| | | | |--- no_of_weekend_nights <= 1.50
| | | | | |--- avg_price_per_room <= 202.00
| | | | | | |--- no_of_weekend_nights <= 0.50
| | | | | | | |--- market_segment_type_Offline <= 0.50
| | | | | | | | |--- repeated_guest <= 0.50
| | | | | | | | | |--- avg_price_per_room <= 87.25
| | | | | | | | | | |--- weights: [261.01, 56.47] class: 0
... (the full printout runs another 200+ lines — this is the first branch)The very first split in the entire tree is on lead_time ≤ 151.5 days — the model independently rediscovered, on its own, the exact pattern I’d first noticed back in EDA. Ranked by importance, here’s what the tree actually leans on:
- lead_time — how far in advance the booking was made
- market_segment_type_Online — whether it came through an online channel
- no_of_special_requests — how invested the guest seems to be
- avg_price_per_room — price sensitivity
This is the part of the project I trust most. The top predictors weren’t hand-picked by me — they emerged independently from both the EDA and the model. When two very different analysis methods agree, that’s usually a sign you’ve found something real, not noise.
And here’s what that tree actually got right and wrong on 10,883 test bookings it had never seen. I rebuilt the confusion matrix from the reported recall and precision, since the notebook’s version was a plotted image rather than text:
Turning this into business action
A model that sits in a notebook doesn’t save anyone money. Here’s what I’d actually put in front of a revenue management team:
What I'd tell myself on day one
- Multicollinearity will quietly wreck a linear model and won’t announce itself — check VIF before you trust a single p-value.
- The “right” metric depends on the cost of being wrong, not on convention. Recall mattered here because a missed cancellation is the expensive mistake, not a flagged-but-safe booking.
- Pre-pruning isn’t optional for trees on real data. An unconstrained tree will happily memorize your training set and call it learning.
- Behavioral signals beat static ones. Special requests and repeat-guest status — both reflecting what a guest actually does — outpredicted purely descriptive fields.
- EDA isn’t a formality. Every major finding in the final model had already shown up in a bivariate chart weeks earlier. If I’d rushed that step, I’d have missed it.
Where I’d take this next
This model is solid, not final. If I picked this back up tomorrow, I’d:
- Test ensemble methods — Random Forest, XGBoost, LightGBM — to push past the single tree’s ceiling.
- Apply SMOTE or explicit class-weighting to handle the 67:33 imbalance more directly.
- Engineer new features:
total_nights,price_per_adult,booking_season. - Move from a single train-test split to stratified k-fold cross-validation with a proper hyperparameter search.
- Package the final model as an API that plugs into the hotel’s booking system and scores every reservation the moment it’s made.
FAQs ~
What machine learning model works best for predicting hotel booking cancellations?
In this project, a pre-pruned Decision Tree tuned with GridSearchCV outperformed Logistic Regression, Naive Bayes, and KNN — catching about 82% of real cancellations on unseen test data while staying simple enough to explain in plain English.
What factors most influence whether a hotel booking gets cancelled?
Lead time was the single strongest predictor, followed by booking through an online channel, number of special requests, and average room price. Bookings made more than roughly five months in advance carried the highest risk.
Why optimize for recall instead of accuracy here?
Because a missed cancellation costs a hotel far more than an unnecessary risk flag. Optimizing for recall minimizes the number of real cancellations that slip through undetected.
How can a hotel actually use a model like this?
As a real-time risk score at the point of booking — feeding tiered deposit policies, targeted overbooking strategy, proactive outreach on high-risk bookings, and loyalty incentives for repeat guests.
What dataset was this based on?
A historical reservation dataset from INN Hotels Group: 36,275 bookings across 19 features — lead time, price, market segment, special requests, and guest history — with no missing values or duplicates.
Want the full notebook and code ?
The complete data cleaning steps, EDA visualizations, and analysis are on my GitHub, along with more end-to-end data science case studies.
Add comment
You must be logged in to post a comment.