Week 5 drew a trendline through a scatter. This is the same idea made numeric and multi-variable: an
ordinary least squares (OLS) model. The target here is days_to_pay — how long a Summit Gear customer
takes to pay an invoice — and the predictors are the customer's account and order history. The AI writes the
Python; the work that matters is choosing the predictors, judging the fit, and reading each coefficient
in collections terms. This page builds that reading in two halves: first fit a line and see what least squares
is minimizing, then read the full coefficient table the way you would read a real regression output.
A. Fit it visually — what is least squares minimizing?
Pick one predictor and watch OLS draw the single line that best predicts days_to_pay from it.
The line is not eyeballed: it is the one line that makes the sum of squared vertical misses as small as
possible. Toggle the residuals to see those misses — the dashed segments from each point to the line are what
the model is shrinking.
What this panel is for: there is nothing to submit and no answer to get right. The point is to see what "best fit" actually means. For any predictor you pick, OLS lands on one specific line, the one that makes the squared residuals as small as possible. Read the slope, R², and RMSE, and toggle the residuals to see exactly what is being minimized, so that the coefficient tables later in the page are reading off a process you have already watched.
A model that fits the customers you already have is not the same as a model that predicts customers you have not seen. Split the sample: fit on one part (train), then score the held-out part (test). The chart colors the train customers and the held-out test customers differently and draws the line fit on the train set only, so you can see which points the model learned from and which ones it is being judged on. With a single clean predictor and a real relationship, you should expect train and test R² to track each other. That is the honest baseline this panel sets. The dramatic case (train great, test collapses, because the model memorized noise) takes many predictors to produce, so it is deferred to the feature-selection and multicollinearity trainer; this widget cannot manufacture it.
B. Read the output — the full coefficient table
A real forecast uses many predictors at once. Half A fit one predictor at a time; this is the
multiple regression the AI would run for you — all the numeric predictors in one OLS on
days_to_pay, 2,200 Summit Gear customers. The coefficients below are the fitted values from the Week 8
answer key. Read each one as: holding the other predictors fixed, a one-unit rise in this predictor changes
predicted days-to-pay by this many days.
Move a predictor and watch predicted days_to_pay update, term by term. The bar chart shows each
predictor's contribution to this one customer's prediction (coefficient × value). This is what a fitted model
is: a weighted sum plus an intercept.
avg_balance and credit_limit are locked
together: in this dataset they move as a unit, so the slider will not let you raise one while holding the
other fixed. That "all else equal" move is exactly what the collinearity makes impossible to identify.
Notice too that credit_limit and noise_a barely move the prediction on their own —
their fitted coefficients are essentially zero. The next trainer shows why leaving collinear and
noise predictors in is still a problem even when the coefficient looks small.
This is the fitted output for the full model (R² = 0.844, adjusted R² = 0.843, n = 2,200). The Significant? column flags whether the predictor's effect is distinguishable from zero (|t| > 2, p < 0.05). Watch what gets flagged.
| Predictor | Coef (days) | Std err | t | p | Sig? | Reading |
|---|
noise_a and
noise_b are not significant — they are random columns and the model correctly cannot find an effect.
(2) credit_limit and annual_spend look near-zero and unstable, while
avg_balance is strongly significant — these three move together, so the model can't tell their
effects apart. That instability is the multicollinearity problem (next trainer). (3) Only
avg_balance, prior_late_count, days_since_last_order,
orders_per_year, and discount_rate are doing real work.Before trusting any coefficient, read the model-level numbers. These say how well the whole model fits and whether it is over-rewarded for the predictors it carries. The figures below come from the full multiple-regression fit in Section B: all numeric predictors on 2,200 Summit Gear customers, taken from the Week 8 answer key.
R² can only rise when you add a predictor, even a useless one, because the line always has more room to bend toward the points. Adjusted R² subtracts a penalty for every predictor you spend, so it rises only when the new column earns its keep. Start from the five clean predictors, then add the size-cluster correlates and the noise columns and watch the two numbers split. The two endpoints are taken straight from the Week 8 answer key: five clean predictors fit R² 0.8438, and all ten fit R² 0.8441, with adjusted R² 0.8434 either way. The per-column increments in between are illustrative.
Optional predictors on top of the five clean ones. Each is a column the next trainer argues you should drop. Click to include or exclude it; included predictors are highlighted.
Adjusted R² uses 1 − (1 − R²)(n − 1) ÷ (n − k − 1), where k is the predictor count. At n = 2,200 the penalty is tiny, so R² and adjusted R² read almost the same no matter what you add. Shrink n to 40 and the penalty bites: adding the noise columns now visibly pulls adjusted R² down even as R² creeps up. That divergence is the whole reason to prefer adjusted R² when comparing models.
Each bar is a coefficient with its 95% confidence band, scaled so the effects are comparable. If a band crosses the zero line, the predictor is not significant: the data can't rule out "no effect". The noise columns and the unstable cluster members land on or across zero.
Bands are standardized (coef × predictor SD) — each bar is the effect of a one-SD move in that predictor, in days — so a dollar predictor and a count predictor can sit on the same axis. Red = raises days-to-pay, blue = lowers it, and grey marks a predictor tagged n.s., short for not statistically significant: its confidence band crosses zero.
C. Write the reading
Running OLS is not the skill here; the AI can do that. The skill is reading the result like an analyst. Write a
one- or two-sentence interpretation of the prior_late_count coefficient (3.34) in plain collections
language: what it predicts about days-to-pay, what "holding the others fixed" adds, and whether you trust it.
Then ask the tutor to react. It will not write the sentence for you, but it will tell you what a strong reading
includes.
A strong reading names the direction and size (about 3.3 more days per prior late payment), states the "all else equal" caveat, ties it to a collections action, and notes that the coefficient is significant (t ≈ 30) so it is not a fluke. Try it before asking — the tutor holds back until you have an attempt down.
credit_limit and annual_spend in the model
destabilizes the coefficients even though R² barely moves, and how a correlation matrix (a hot off-diagonal cell
between two predictors is the tell) flags the cluster while adjusted R² stays flat. After that,
Logistic does the same read-the-output skill for a yes/no target, defaulted.