Sports Analytics in Practice with R

1. 1State the decision the finding serves before you compute anything. The passages tie player selection, evaluation and lineups to high-cost decisions, so write one sentence naming who acts on the result and what they do differently (e.g., coaching staff setting a minimum viable shot count).
2. 2Visualize before you summarize. Plot the variable pair with a scatter (ggplot + geom_point) before trusting a single statistic such as cor(). A correlation of 0 does not mean no relationship.
3. 3Check that the measure fits the pattern you claim. For the swimmer data, cor(height, weight) returns 0.72 and the scatter shows a positive relationship. For fakeData, cor returns 0 while the plot shows a U-shape. Report the pattern the plot shows, not only the coefficient.
4. 4Match the distance or similarity metric to the question. Euclidean distance pairs Player A with Player B because their magnitudes are closer. Cosine similarity pairs Player A with Player C because their height-to-weight proportions are near-equal. Choose by whether you care about size or shape, and confirm manual calculations against lsa::cosine().
5. 5State the assumption your metric hides, then test it. Shots per game assumes every shot is equally likely to succeed. Engineer the play text with grepl (e.g., wide vs 'BLOCKED') to separate shot quality and rebuild the chart.
6. 6Subset to the question's population. Use grep/grepl and %in% to isolate one team's games, then negate with ! to keep only opponent plays. Filter to action == 'GOAL' to cut clutter. Convert clock strings to seconds with period_to_seconds(ms(...)) so time is comparable across games.
7. 7Phrase the finding with its hedge and its limit. Write 'it appears as though opponents score more after half time (line at 2700 seconds), though data integrity issues exist.' Then name the qualitative input still needed before acting, such as injury or off-field issues a scout can't see in pitch data.
8. 8Add context to the visual: comparisons, source information, and minimal chart junk (Tufte principles). Let the reader infer the takeaway rather than forcing it.

Akron soccer, opponent goals over time. You want to know whether Akron's defense weakens late. Filter macPlays to Akron's games with grep on team 'AKR' and collect their game IDs (gID). Pull all plays in those games via macPlays$gID %in% unique(oneTeam$gID). Drop Akron's own rows with the negated grepl vector (oppTeam[!oppIdx,]) and keep only action == 'GOAL'. Convert clock to gameSeconds with period_to_seconds(ms(clock)) and draw a Cleveland dot plot (gameSeconds by gID) with a vertical line at 2700 seconds for halftime. The chart shows opponent goals clustering after the line, so the finding reads: Akron's defensive vigilance appears to wane in the second half. The text hedges this with the data-integrity caveat the chapter raises repeatedly. The decision it supports is where coaching attention goes, and it is a lead to verify, not proof.

• If you are about to cite a correlation, then plot the pair first. A coefficient of 0 can hide a clear U-shaped pattern, as in fakeData.
• If the question is about profile or proportion (similar kind of player), then use cosine similarity. If it is about absolute size, use Euclidean distance.
• If a metric rests on an equal-weighting assumption (all shots equal), then state it and engineer a quality split (blocked vs wide) before advising on strategy.
• If the data has known integrity issues, then use hedged language ('appears') and frame the output as a hypothesis to verify rather than a conclusion.
• If the decision is high-cost (drafting, signing, lineups), then pair the quantitative finding with qualitative and external inputs before recommending action.

• Trusting a summary statistic over the picture. The tell: a near-zero correlation reported as 'no relationship' with no scatter plot behind it.
• Using the wrong distance metric. The tell: the nearest-neighbor player matches on raw size (A to B) when the question was about proportional profile (A to C).
• Hidden equal-weight assumptions. The tell: 'more shots means better team' with no distinction between blocked, wide and on-goal shots.
• Overclaiming from messy data. The tell: a flat statement of cause (defense collapses after half) with no mention of data integrity, sample size or other factors.
• Analysis disconnected from the decision. The tell: a polished chart with no named actor, no action, and no mention of non-data inputs such as health or character that the data cannot show.

• ▸Decision and actor: who acts on this finding and what choice does it inform?
• ▸Claim in one sentence: the pattern you believe the data shows.
• ▸Visual check: which plot did you draw, and does it match the statistic you quote?
• ▸Metric fit: why this statistic or distance (e.g., correlation, Euclidean, cosine) for this question?
• ▸Hidden assumption: what is treated as equal or constant (e.g., all shots equally likely to score)?
• ▸Subset and cleaning: filters applied (team, action, time conversion) and what was excluded.
• ▸Data caveats: integrity problems, sample size, known gaps.
• ▸Hedged wording: the final claim phrased with its limits.
• ▸Non-data inputs needed: qualitative or external information required before acting.

1. 1Name the skeptic before you build. The source opens with Charles Barkley's line, 'Analytics don't work at all. It's just some crap some people who were really smart made up,' and answers it with Ross Drucker's, 'Just because you don't understand something doesn't mean it's crap.' Write down who the decision-maker is and what they currently believe, then design the output for that person.
2. 2Decide the model's purpose before you pick it. The source separates predictive accuracy ('black-box' models, justified when cost or benefit is high and no one needs the reason behind the output) from explanatory modeling. If the audience must act on the reasoning, choose the explainable model and use its coefficients.
3. 3Show a table, then convert it to a visual. The logistic-regression chapter says the table of winning-team stats 'can be useful to practitioners' for coaches, but 'people often respond to visuals, so additional data manipulation is needed to increase the explanatory insights.' Keep the table as backup and lead with the chart.
4. 4Make each number carry its own context. For each statistic, compute the percent of winning teams above the average, so the audience sees 'how easy it is to be above average in a statistic' and what the true elite look like. Do not assume a normal distribution; the source loops over each statistic individually.
5. 5Encode direction explicitly. Add a Positive/Negative label from the coefficient sign (an `ifelse` on coeffs > 0) and color-code points by it, so a coach reads 'do more' versus 'deprioritize' without reading coefficients.
6. 6Frame the output as a decision. The chapter objectives interpret scatter-plot quadrants to show what 'should be focused or deprioritized by players and coaches' and to identify teams that excel at statistics other teams overlook. Present quadrant labels as actions, not as model output.
7. 7Make the visual interactive for exploration. Use echarts4r with tooltips, zoom, and save-as-image, so stakeholders can inspect the values behind a bar themselves. Also export a static version for decks.
8. 8Pair each visual with a plain-language explanation. The source says machine-learning chapters supply 'visuals and explanations in the hopes of winning over skeptics,' and that the data narrative plus intuitive comprehension raises adoption in data-skeptical organizations. Write the narrative sentence first, then check that the visual proves it.

The women's collegiate basketball chapter builds a logistic regression on winning-team statistics and then makes it usable by coaches. The summary table (Table 5.7) lists each stat's average winning-team value, its model impact, and its coefficient. FG_PCT has an impact of 0.328 and a positive coefficient of 1.17; FT_PCT has 0.194; Assists_PG has 0.163; Three_Pt_FG_PCT has 0.155; Rebounds_PG has 0.152. PPG has an impact of only 0.008 and a negative coefficient of -0.028. A coach who sees raw coefficients may not trust them, so the chapter adds a Positive/Negative color label and a frequency measure showing what percent of winning teams sit above average on each stat. These feed a scatter plot whose quadrants say what to focus on or deprioritize. The takeaway for a skeptical coach is that shooting efficiency explains far more of winning than points per game, and that statement can be checked against the plotted teams.

• If the audience will act on the reasoning rather than just consume a prediction, then choose an interpretable model (coefficients, waterfall) over a black-box one, even at some accuracy cost.
• If the stakeholder is data-skeptical, then lead with the visual and a one-sentence narrative, and put the table in an appendix.
• If a statistic's coefficient is negative or its impact is near zero (like PPG at 0.008), then flag it explicitly as a surprise and explain it, because an unexplained counterintuitive result gives skeptics their reason to dismiss the work.
• If a stakeholder asks 'why', then provide an interactive chart with tooltips instead of a new slide, so they can check the value themselves.
• If you cannot state the chart's takeaway as a coach-level action (focus on, deprioritize), then rework the visual before presenting.

• Presenting only the coefficient table to coaches. The tell: the audience nods at the numbers but asks you to 'just tell us what matters', and no behavior changes.
• Using a black-box model where the decision-maker needs a reason. The tell: the model is accurate, yet executives will not act because they cannot explain it to their own staff.
• Showing a stat's importance without context on how common it is. The tell: stakeholders ask whether 'above average' is rare or easy, which the above-average frequency measure should have answered.
• Leaving counterintuitive results unexplained, such as PPG with a negative coefficient. The tell: a skeptic seizes on it as proof that 'analytics don't work', echoing the Barkley quote.
• Assuming a visual speaks for itself. The tell: a polished chart with no accompanying narrative, and questions about what you want them to do with it.

• ▸Decision-maker and current stance: who they are and their belief about analytics (skeptic, neutral, supporter).
• ▸Decision to be informed: the specific coaching or executive action the analysis supports.
• ▸Model purpose: predictive accuracy or explanation, with one line on why.
• ▸One-sentence narrative: the finding in plain language, no jargon.
• ▸Lead visual: chart type and the single comparison it makes.
• ▸Context metric: the benchmark that shows how rare or common each value is (e.g., percent of winning teams above average).
• ▸Direction labels: how positive/negative or focus/deprioritize is encoded.
• ▸Counterintuitive result and explanation: the finding most likely to trigger doubt and your answer.
• ▸Interactivity and fallback: tooltips or zoom for exploration, plus a static export and the backup table.

1. 1Position the analysis as one input, not the verdict: before presenting, state explicitly that the human decision maker holds full responsibility and may incorporate or ignore the finding.
2. 2Build the analysis as a 'data narrative' with five explicit parts: problem statement, the data used, methods, limitations, and how the outcome reinforces or deteriorates current thinking on the problem.
3. 3Match delivery to the audience's technical acumen — for non-technical decision makers, translate tabular output into visualizations because humans extract patterns from images far better than from tables.
4. 4Name the unmeasured qualitative factors the analytics cannot see (obvious superstars, game strategies, locker-room fit) and concede that trained experts identify these without any model.
5. 5Aim your quantitative effort at the harder margin — the non-superstar or middling players and opportunity costs a qualitative mindset struggles to differentiate — since that is where analysis adds value the eye misses.
6. 6Set aside intellectual arrogance: acknowledge the domain expertise of others out loud and invite the decision maker to probe the analysis.
7. 7When the decision maker disagrees or overrides you, do not take it personally — your role is to supplement, so let them incorporate or ignore.
8. 8Justify the analytics function economically when challenged: a data scientist costs roughly 5–15% of a single minimum professional contract, so avoiding one bad contract or optimizing ticket sales covers the expense.

Charles Barkley dismisses analytics as 'just some crap some people who were really smart made up' and insists 'just because you got good stats doesn't mean you got a good team.' The human-over-the-loop stance neither surrenders to his qualitative certainty nor overrules it — it notes he is right that superstars are outlier players easy to identify by eye without any model. But it also names his blind spot: the economic opportunity cost of non-superstar and middling players is hard to differentiate qualitatively, and that is where the analyst supplements the front office's judgment. The analyst presents this as a data narrative — the roster problem, the contract and performance data, the method, its limitations, and whether the numbers reinforce or challenge the scout's read — then hands the call to the GM. The GM, holding full responsibility, integrates the scout's unmeasured read on leadership and fit and either incorporates or ignores the analysis. The point is that sports decisions are neither exclusively qualitative nor quantitative; treating them as one or the other is myopic.

• If the factor is an obvious superstar, game strategy, or clear business decision, then defer to the trained qualitative expert — analysis is not needed there.
• If the field of options and inputs is expanding beyond what a person can hold, then push the analysis forward because qualitative expertise is limited at that scale.
• If the audience is non-technical, then convert tabular results to a visualization and lead with the pattern, not the table.
• If the decision maker rejects your finding, then do not defend it as personal — restate that your role is to supplement and let them own the call.
• If cost of the analyst is questioned, then benchmark it against a single bad contract avoided or ticket revenue optimized (analyst salary is ~5–15% of a minimum pro contract).

• Framing the analysis as the answer rather than one factor — the tell is the analyst treating a difference of opinion as a personal loss instead of a supplement being weighed.
• Intellectual arrogance that dismisses domain experts — the tell is language like the skeptic being 'wrong,' rather than acknowledging expertise is limited only as inputs expand.
• Dumping tabular data on a non-technical audience — the tell is the decision maker unable to see the pattern the numbers contain (the 60 data points that hide a face until plotted).
• Judging sports as somehow uniquely immune to analytics — the tell is the same person who trusts algorithmic trading, streaming recommendations, and search results calling sports analytics 'crap.'
• Omitting limitations from the narrative — the tell is a presentation with problem, data, and methods but no honest statement of where the analysis is weak, which forfeits the decision maker's trust.

• ▸Problem statement: the one decision the human must make, in a sentence.
• ▸Data used: the specific dataset and its source (for credibility).
• ▸Method: the analytical technique applied, plainly named.
• ▸Limitations: what the analysis cannot see or measure.
• ▸Unmeasured qualitative factors: expert-only inputs (fit, strategy, obvious superstars) the human must add.
• ▸Reinforces or deteriorates: whether the result supports or challenges current thinking.
• ▸Audience acumen: technical level and the visualization chosen to match it.
• ▸Decision owner: name of the human holding full responsibility for incorporating or ignoring this.
• ▸Cost justification: analyst expense vs. bad-contract/revenue upside at stake.

1. 1Name the single decision the analysis supports before touching data. The source frames this as a contract, a draft pick, ticket sales, or a game strategy. Write it as 'Decide whether to ___ by ___.'
2. 2Position the analysis as one input to a human decision ('augmented intelligence' or 'human over the loop'). Record who holds full responsibility for the decision and confirm they know the analysis supplements their judgment.
3. 3Sort the decision by obviousness. Superstars and obvious strategies are easy for a trained qualitative expert to spot and need little analysis. Direct analytic effort at the harder cases: middling or non-superstar players, where opportunity costs are hard to differentiate qualitatively and the field of options and inputs is large.
4. 4Package the result as a 'data narrative' with five parts: problem statement, data used, methods, limitations, and whether the outcome reinforces or deteriorates current thinking.
5. 5Fit the delivery to the audience's technical acumen. For non-technical decision makers, visualize rather than hand over tables. Humans struggle to find patterns in tabular data (the 60-point table) but see them quickly in a plot (the face in Figure 2.1).
6. 6Choose the visual form deliberately and check it for misleading the audience. The source notes that visualizations are as much practitioner choice as data. Points plus a path revealed the face pattern, while points alone might not have.
7. 7Let the decision maker probe, then incorporate or ignore the analysis. Do not take disagreement personally, because your role is to supplement.
8. 8Value the outcome against cost. The source benchmarks a data scientist at roughly 5–15% of a single minimum professional basketball contract. Record the avoided bad contract or optimized ticket revenue as the measurable return, then compare it to the analyst's cost.

The source's own case is the front-office analyst in professional basketball. A data scientist costs roughly 5–15% of one minimum professional contract, so the bar for justification is low: avoiding a single bad contract or optimizing ticket sales could easily cover the salary. Take the contract case. A superstar is an outlier who is easy to identify, so a veteran evaluator needs no model. The harder call is a middling player, where the economic opportunity cost is difficult to see qualitatively. The analyst builds a data narrative with the problem statement, data, method, limitations, and whether the result supports or undermines the scouts' view. It goes to the decision maker as a visual, not a table, because people read patterns in plots far better than in rows of numbers. The decision maker probes it and decides, and the human keeps full responsibility. If the analysis helps avoid one bad contract, the value is the avoided cost set against the small analyst expense. The source gives no specific player or dollar figures, so those stay as inputs you supply.

• If the decision is obvious to a trained expert (a clear superstar or an evident strategy), then don't force analytics onto it. Spend effort on middling or multi-option choices where qualitative judgment degrades.
• If the audience is non-technical, then lead with a visualization and keep tables as backup, because pattern recognition outperforms reading tabular data.
• If the analysis contradicts current thinking, then present it inside the full data narrative, with limitations included, and let the decision maker probe it rather than defending it.
• If you need to justify analytics spending, then compare the analyst cost (about 5–15% of one minimum contract in the source's basketball example) to a single avoided bad contract or an optimized revenue line.
• If the decision maker ignores your analysis, then treat it as the process working. The role is to supplement, and the human owns the decision.

• Intellectual arrogance: framing analysis as superior to expertise. The tell is stakeholders dismissing it as 'crap some smart people made up' and skeptics hardening.
• Presenting a number or table without the narrative. The tell is that decision makers can't say what the problem, method, or limitations were, so they can't weigh the result.
• Mismatching technical depth to audience. The tell is blank stares or a table nobody reads, when a plot would have shown the pattern at once.
• A misleading visual choice. The tell is that a different geom or encoding would change what the viewer sees, as with points versus points plus path.
• Claiming value without a cost comparison or decision link. The tell is that no avoided mistake, optimized outcome, or opportunity is stated, so the benefit is hard to defend as measurable.

• ▸Decision to support: one sentence naming the choice (contract, draft pick, ticket pricing, strategy).
• ▸Decision owner: the person with full responsibility, and their technical comfort level.
• ▸Obviousness check: is a qualitative expert likely to get this right alone? If yes, reconsider the effort.
• ▸Problem statement: the question the analysis answers.
• ▸Data and method: what was used and how, in plain language.
• ▸Limitations: what the analysis cannot tell the decision maker.
• ▸Effect on current thinking: does it reinforce or deteriorate the existing view?
• ▸Visual chosen and misleading-risk check: the plot used and why it does not distort.
• ▸Value estimate: avoided cost, optimized outcome, or opportunity found, compared with analyst cost.

1. 1Write the question as a sentence that names the outcome, e.g. 'which team will win a match', 'which player is a good draft pick', 'how engaged are fans on a forum', or 'what lineup is best under constraints'. The passages treat the outcome as the thing that picks the technique, so do this before touching code.
2. 2Inventory the data by R type and structure. Run `class` on each object (integer, numeric, logical, factor, character). Character fields such as fan forum posts or tweets point to NLP. Numeric and factor fields point to tabular analysis or modeling.
3. 3Check table grain and relationships before choosing a method. `People` has one row per player, while `Pitching` has many rows per `playerID` (one per season or team). Decide whether the unit of analysis is the player, the season, or the pitch, and join with `dplyr` (e.g. a left join) only after that decision.
4. 4If the structure or the question is unclear, start with exploratory analysis. Subset to one entity (one player), then one statistic by season, then finer detail such as pitch types by season with velocity, then spatial detail such as pitch and swing location. Each pass narrows what later modeling should ask.
5. 5Pick the visualization deliberately, because the source says visuals are 'as much practitioner choice as the data itself'. Individual points can hide a pattern that an aggregate shows. Choose the form that makes the pattern visible without misleading, and treat persuasion as a legitimate goal (the Florence Nightingale example).
6. 6Match the outcome type to the technique. Predicting a known future result (a win, a draft pick) calls for a model whose predictions you can check against the outcomes that sports data makes public. Text calls for NLP. Selecting a best lineup under constraints calls for optimization (the fantasy football example). Unknown patterns call for exploration.
7. 7Keep the method portable. A chapter's technique is meant to be 'a broadly useful tool, not a brittle or narrowly focused analysis', so pick the approach by data type and question. Text analysis built for cricket forum posts transfers unchanged to men's basketball tweets.
8. 8Place a human over the loop before acting. Statcast pitch data alone does not reveal a substance abuse problem or a needed surgery. Pair the analytic output with qualitative and external inputs, and let a person supervise and intervene on high-cost decisions.

The source's pitcher analysis starts with a single named player, Miguel Castro, among 20,000+ players in `People`. The analyst declares `playerFirst` and `playerLast` as objects, runs `grep` on each name column, and uses `intersect` on the two index sets. That returns row 2933, which is selected with `People[index, ]` into `onePlayer`. Before any modeling, the analyst recognizes the grain: `People` has one row per player, `Pitching` has many rows per `playerID`, and `xWalk` adds a second ID, `MLBID`. A left join from `dplyr` appends the pitching and ID data to the single row. The method then moves from exploration to detail: a seasonal statistic, then Statcast pitch types tabulated by season with velocity compared across seasons, then geospatial pitch and swing location. Each step is descriptive and visual, because the aim is to surface initial inquiries, not to predict. The chapter then adds that a scout would not rely on pitch data alone, so the output informs a human decision rather than replacing it.

• If the field is character text (fan forum posts, tweets), then use NLP. The sport and the platform do not matter; the same method transfers.
• If you are choosing among players or teams for a future outcome (who wins, who to draft), then build a model that predicts a known outcome and review its predictions against the results, which sports data makes available.
• If the task is selecting a best set under constraints (a fantasy football lineup), then frame it as optimization, not description.
• If the dataset is large and you do not yet know what to ask, then explore first: subset to one entity, move through time (season, then pitch), then space (pitch and swing location), and let that shape the questions.
• If the decision is high-cost (player selection, evaluation, lineups) then treat analytics as one input and keep a human over the loop with qualitative and external information.

• Jumping to a model before checking table grain. The tell: joined data has duplicated player rows, or per-season rows are treated as per-player rows after joining `People` to `Pitching`.
• Plotting raw individual points and calling the pattern absent. The tell: the chart looks like noise, and an aggregation or different visual form would show structure. The source warns this can also mislead the audience.
• Choosing a method because it is familiar, not because of the outcome type. The tell: the technique cannot be stated in terms of the question, such as a text field being ignored or forced into numeric analysis.
• Building a narrow, sport-specific analysis that does not transfer. The tell: swapping the data (cricket forum posts for basketball tweets) would require rewriting the method, not just the input.
• Treating the analytic output as the decision. The tell: no qualitative or external check, such as health or injury context, appears before a high-cost selection call.

• ▸Question (one sentence): State what you want to know or decide.
• ▸Outcome type: Is it a known future result, a text signal, a best-set choice under constraints, or unknown patterns?
• ▸Data types present: List each key field's R class (integer, numeric, logical, factor, character).
• ▸Table grain and joins: Name the unit per row in each table and the join key (e.g. `playerID`), noting one-to-many links.
• ▸Chosen technique: Visualization, supervised model, NLP, optimization, or exploratory analysis, with one line on why it fits the outcome.
• ▸Exploration path: List the subset, time, and space steps you will take before any modeling.
• ▸Visual choice and misleading-risk check: Name the chart form and what could make it mislead the audience.
• ▸Outcome validation: Say how you will check results against known outcomes.
• ▸Human-over-the-loop input: List the qualitative or external information a person must weigh before acting.

1. 1Write down what the dataset should contain before you inspect it: which entities, which variables, how many rows. The passages show both scales. The swimmers frame is explicitly a 'partial' roster of eight athletes with `height`, `weight`, and `gender`. The NFL combine file is 6,829 player observations across 15 variables. Record these expected counts and check them with `nrow` and `ncol` immediately after loading.
2. 2Check structure before content. Every column in a data frame or matrix must be complete, and you cannot `cbind` a three-value vector to a two-value one. Confirm all vectors have equal length (for swimmers: athlete, height, weight, gender are each 8). Where a ragged gap exists, it must be filled explicitly with `NA`, not left to chance.
3. 3Check data types. A matrix needs a single type, and mixing numeric, logical, and character coerces everything to character without warning. Use a data frame for mixed columns, and confirm numeric columns are still numeric after any conversion.
4. 4Inventory missing values per column, then decide what each `NA` means. In the draft data, `NA` in `Round` is information (an undrafted player), not an error. The fix is `treatedTraining$Round[is.na(treatedTraining$Round)] <- as.factor('NA')`, applied identically to `treatedValidation`, so the model treats it as a class level. Apply the same rule to every partition, or the partitions will not align.
5. 5After any join, subset, or `grep` filter, verify what was retained. Use `unique` on the game identifiers to show which games survived from all MAC plays. For derived fields such as `shotsPerGame <- shots / games`, confirm both inputs came from the same joined, tabulated table and cover the same teams.
6. 6Verify what each column means before plotting it. In the pitch data, `plate_z`, not `plate_y`, is the vertical position as the ball crosses the front of home plate. A plausible-looking column name can carry the wrong meaning and still produce a clean chart.
7. 7Plot before you summarize. `cor` on `fakeData` returns 0, yet the points (y = 5, 0, -3, -4, -3, 0, 5) form a clear curve. A single summary statistic can hide a real pattern or a data problem that a scatter plot exposes.
8. 8Document the limits of the data next to the result. State the source, and state what the data cannot support. The shots-per-game chart assumes all shots have equal probability of success, and shot quality would require extra engineering on the play `text` column.

The swimmers data frame is built from four vectors: `athlete`, `height`, `weight`, and `gender`, each with eight values. Because the lengths match, `data.frame` constructs without raggedness. You first note it is a partial roster, so any conclusion applies to these eight athletes only. `ggplot(swimmers, aes(height, weight)) + geom_point() + theme_tufte()` shows a positive relationship, and `cor(swimmers$height, swimmers$weight)` returns 0.72. The scatter plot also shows spread you would not see in the single number: the two athletes at height 73 weigh 175 and 137. The `fakeData` set shows why the plot matters. Its `cor` is 0, yet the plot shows a pattern. That means a correlation near 0 is not proof of a clean, relationship-free dataset, and a high correlation on eight rows is not proof of a general rule. You report 0.72 with the sample size and the 'partial roster' caveat attached.

• If a vector length differs from the others, do not force the join. Fill the gap deliberately with `NA`, or find the missing records first.
• If `NA` has a real-world meaning (such as an undrafted player's `Round`), recode it to an explicit level like 'NA' in every partition. If it is simply missing, treat it as missing and do not pass it off as a category.
• If your data mixes numeric, logical, factor, and character columns, use a data frame, not a matrix, to avoid silent coercion to character.
• If a correlation is near 0 or the relationship might be non-linear, plot the data before concluding there is no relationship.
• If you filter or join (for example `grep` on team, or `shotsGames`), run `unique` on the identifiers and compare counts with the source before analyzing.

• Trusting the correlation alone. A `cor` of 0 is read as 'no relationship', but the `fakeData` curve shows otherwise. The tell is that no plot was made.
• Treating a small or partial dataset as the population. Eight swimmers from a 'partial' roster are generalized to all athletes. The tell is a claim with no stated row count or scope.
• Leaving `NA` untreated or treating it inconsistently across partitions. A model then fails or learns different levels in training and validation. The tell is `NA` handled in `treatedTraining` but not `treatedValidation`.
• Silent type coercion. A matrix is built from mixed columns and everything becomes character. The tell is arithmetic errors or numbers that print in quotes.
• Misreading a column's meaning, such as assuming pitch height is `plate_y` when it is `plate_z`. The tell is a heatmap with an implausible strike-zone position.
• Reporting a derived metric without checking its inputs or its assumptions. Shots per game treats all shots as equal in value. The tell is a ranking presented with no stated limitation.

• ▸Dataset name and source: record where the data came from so the audience can judge credibility.
• ▸Expected vs actual rows/columns: state the expected counts (for example 6,829 observations by 15 variables) and the counts you actually loaded.
• ▸Scope statement: note whether the data is complete or partial (for example 'partial roster') and what population it covers.
• ▸Column length and type check: confirm all vectors are the same length and that each column has the intended type, with no accidental character coercion.
• ▸Missing values by column: list columns containing `NA` and the count in each.
• ▸NA meaning and treatment: say whether each `NA` is information or missing, the recode used (for example factor level 'NA'), and confirm it was applied to all partitions.
• ▸Join/filter retention check: record the `unique` identifier count before and after each subset or join.
• ▸Column semantics verified: list any ambiguous columns (such as `plate_z`) and what each one actually represents.
• ▸Plot reviewed before summary stats: record the chart you used and any pattern that differs from the summary number.
• ▸Known limitations to state with results: list assumptions the data cannot support (for example all shots treated as equally likely to succeed).

1. 1State the single finding in one sentence before opening R. Every later choice (geom, scale, title) either serves that sentence or gets cut. The passages' own chapter-1 plots are tool demos, and the book calls its single-point `plot(x = 1, y = 2)` scatter 'not visually appealing'. A plot with no stated finding looks like that.
2. 2Pick the comparison first. Decide what the reader should compare (player vs. player, team vs. team, one stat vs. another) and put those items on a shared axis or in adjacent tiles. In the chapter-1 heatmap the comparison is across stats for the Dallas team.
3. 3Shape the data to the chart. The heatmap workflow reshapes wide stats into long form with `tidyr::pivot_longer`, then maps each stat/entity pair to a tile with `geom_tile`. Do the reshape explicitly so each variable you want in the picture has its own column.
4. 4Add multivariate context deliberately. Map a second or third variable to position, fill, or facet (for the heatmap, `scale_fill_gradient` carries the value). Add a variable only if it changes how the reader interprets the first one.
5. 5Build credibility into the labels. Use `xlab`/`ylab` and `ggtitle` to say what is measured and for whom (the passage's title is 'Dallas Team Offensive Stats'). Keep the data source and any filtering recoverable from your script, since the book shares data and scripts for reproducibility.
6. 6Strip junk with a clean theme. Apply a minimal theme such as `theme_hc()` from `ggthemes`, then remove only elements that carry no information. Removing the legend with `theme(legend.position = "none")` is justified only if the tiles or labels already convey the values.
7. 7Choose the modality for the job. Static plots appear in the RStudio 'Plots' pane and can be saved to disk; interactive plots and small web pages appear in the 'Viewer' pane. Use static for a fixed argument and interactive when readers must look up individual values.
8. 8Run a last check against your sentence from step 1. Show the plot to someone unfamiliar with the data and ask what they conclude. If it differs from your sentence, revise focus, comparison, or labels, not the data.

The passages build two plots in Chapter 1, and they show the gap between a demo and a finding. The first is `plot(x = 1, y = 2)`, a one-point scatter that the authors call 'basic, yet not visually appealing'. It has no comparison, no context, and no message. The second is the heatmap of Dallas team offensive stats. It pivots the stats to long form with `pivot_longer`, draws tiles with `geom_tile`, and colors them with `scale_fill_gradient`, so many stats can be compared at a glance. The code then adds `theme_hc()` to remove clutter, `ggtitle('Dallas Team Offensive Stats')` to say what the picture is, and `theme(legend.position = "none")` to drop the legend. Applying the best-practice checklist, the title and clean theme support credibility and focus. Removing the legend is a judgment call: if color encodes value and nothing else shows the numbers, the reader cannot decode the fill, so you would either restore the legend or print values on the tiles. The passages do not state this critique, so treat it as application of the principles rather than the authors' claim. The full best-practice treatment is in Chapter 2, which these passages do not reproduce.

• If your chart has no comparison (one point, one bar), then add a baseline, peer group, or second entity before publishing.
• If a fill or color gradient carries the values and you hide the legend, then add value labels to the tiles or restore the legend.
• If a added variable does not change the reader's reading of the main variable, then remove it.
• If readers need exact values for individual players or teams, then use an interactive plot in the Viewer. If the argument is fixed, then use a static plot and save it from the Plots pane.
• If a theme element (gridlines, borders, background) carries no information, then drop it. If removing it hides scale or units, then keep it.

• Demo-grade plots shipped as findings: a plot that shows one point or an unlabeled grid with no stated takeaway. The tell is that you cannot write its conclusion in one sentence.
• Undecodable color: a heatmap with `scale_fill_gradient` but `legend.position = "none"` and no tile labels. The tell is that viewers ask 'what does dark red mean?'
• Missing context in titles and axes: default axis names or a generic title. The tell is that a reader cannot say which team, player, or stat is shown without opening the code.
• Variable overload: every available stat is thrown into the plot because reshaping with `pivot_longer` makes it easy. The tell is that nobody can name the comparison the chart makes.
• Treating styling as design: applying a theme like `theme_hc()` and assuming the plot is finished. The tell is a clean-looking chart that still has no comparison, causal framing, or focus.

• ▸Finding sentence: write the one-sentence conclusion the chart must deliver.
• ▸Comparison: name the items or groups the reader compares and where they sit on the chart.
• ▸Variables mapped: list each variable and its encoding (x, y, fill, facet) and why it earns a place.
• ▸Data shape: note the reshape needed (e.g., pivot_longer) and the column names the plot uses.
• ▸Labels and credibility: record the title, axis labels, data source, and any filters applied.
• ▸Legend/decoding check: state how the reader converts color or size to a value (legend, labels, or both).
• ▸Junk removed: list theme elements cut and confirm none carried information.
• ▸Modality: choose static (Plots pane, saved file) or interactive (Viewer) and give the reason.
• ▸Reader test result: record what an unfamiliar reader concluded and whether it matches the finding sentence.

1. 1Name the workflow before you touch data. For a machine learning project, the passages use SEMMA (Sample, Explore, Modify, Model, Assess), described as a standard industry practice for organizing an analytical project. Write the five stages as a checklist and state the business question first. In the football chapter the questions are: will an athlete be drafted, which round, and which cohorts exist.
2. 2Sample: partition by the structure of the data, not by habit. If the data is temporal (the NFL Combine data has a `Year` column and annual drafts), do not partition randomly. Use out-of-time sampling: `subset(NFLcombine, Year<2017)` for training, `Year==2017` for validation, `Year>=2018` for the holdout test set.
3. 3Define the target during Sample or Modify and record how you derived it. For the binary problem, `NFLcombine$drafted <- !sapply(NFLcombine$Round, is.na)` turns an `NA` Round into FALSE (undrafted) and any real round into TRUE.
4. 4Explore with both tables and visuals before modeling. Run `names()`, `head()`, and `summary()` for tabular facts, then plot, because the passage notes the human brain is excellent at visual pattern recognition. Use this stage to identify the possible y-variables and to see missing values.
5. 5Modify, then Model. Apply the same data treatment (the `vtreat` objects `treatedTraining` and `treatedValidation`) to every partition. Fit the model that matches the question: KNN binary for drafted or not, KNN multiclass for round, KNN regression for overall pick, and K-means, K-medoid, or spherical K-means for cohorts.
6. 6Assess on training and validation together. Call `predict` on both, put each in a data frame (`preds` and `picks` columns), and compute RMSE for each. A large gap signals overfitting or a flawed model. Training 66 against validation 69 is consistent, so the model is not structurally flawed.
7. 7Interpret in units a decision-maker understands. RMSE is in the units measured, so 66 means about 66 draft picks of error. Say that plainly. If the number is that high, note the model probably regresses toward the population mean and name the next step (a tree-based method, more rows, or more drill columns).
8. 8For unsupervised output, close the loop to a known label. Append cluster assignments to the non-numeric player data, add `actualRound`, then use `table()` and `round(prop.table(..., 1), 2)` to see how each cluster maps to rounds. Contextualize the clusters from that table.

The football chapter runs SEMMA end to end on NFL Combine data. Sample: the target `drafted` is built with `!sapply(NFLcombine$Round, is.na)`, and because drafts recur yearly the data is split out of time. Players from 2000 to 2016 form `combineTraining`, 2017 forms `combineValidation`, and 2018 to 2020 form `combineTest`. Explore: `names` and `head` show the columns and candidate y-variables. Modify and Model: treated data feeds a KNN regression predicting overall pick. Assess: `predict` runs on both partitions and `RMSE` gives 66 for training and 69 for validation. That small gap means the model is not overfit. But 66 picks of error shows it is likely regressing to the mean, so the author suggests trying a tree-based method. The clustering extension then compares cluster assignments to actual rounds. In the medoid table, Cluster6 holds 41% round 1 and 33% round 2 players, while Cluster7 holds 65% round 7 players. Those are the elite and low-expectation cohorts.

• If the data has a time column and events recur (annual drafts), then partition out of time (train earlier years, validate one year, hold out the latest) rather than randomly.
• If training and validation error differ significantly, then suspect overfitting or a flawed model; if they are close (66 vs. 69), then the structure is sound and the remaining error is a modeling-power issue.
• If the outcome is Yes/No, then use binary classification; if it is a category such as round, then multiclass; if it is a continuous quantity such as overall pick, then regression. Choose the model type from the question.
• If an error metric is high and near the spread of the population, then say the model is regressing to the mean and try another algorithm, more rows, or more columns before trusting it.
• If you run clustering with no label, then do not stop at assignments. Cross-tabulate the clusters against a known outcome (actual round) and read row-wise proportions to contextualize each cluster.

• Randomly partitioning temporal data. The tell: validation looks strong because future years leak into training, and the model then degrades on the 2018 to 2020 holdout.
• Skipping Explore and going straight to the model. The tell: you cannot say which columns are y-variables, how many values are missing, or what the distributions look like, and surprises appear only at Assess.
• Treating the workflow as a one-way line and reporting only training accuracy. The tell: no validation comparison exists, so overfitting goes undetected.
• Reporting RMSE without translating units. The tell: stakeholders see a bare number rather than 'off by about 66 picks', so they cannot judge whether the model is usable.
• Producing clusters with no contextualization. The tell: centroids and assignments are delivered but nobody can say what a cluster means for draft outcomes, so the insight is never reached.

• ▸Business question: state in one sentence what decision the analysis informs.
• ▸Target variable and derivation: name the y-variable and the code or rule that creates it (e.g., drafted = !is.na(Round)).
• ▸Sample plan: list the partition rule and why (out-of-time years for train, validation, and test, or random if not temporal).
• ▸Explore findings: record column names, missing values, distribution notes, and the key visuals reviewed.
• ▸Modify steps: list the treatments applied identically to every partition.
• ▸Model choice: name the algorithm and tie it to the question type (binary, multiclass, regression, or clustering).
• ▸Assess metrics: record the training metric, the validation metric, and the gap between them.
• ▸Interpretation in plain units: restate the error as real-world units (e.g., picks) and say whether it is usable.
• ▸Next iteration: name one change (different algorithm, more rows, more columns, or cluster-to-label cross-tab) to try.

1. 1Start every new data set with `summary(nbaData)` (or your own data frame). For each numeric column read the min, first quartile, median, mean, third quartile, max, and the NA tally. Note each column's range, distribution, average, and how much of it is missing before you plot or model anything.
2. 2Form a directional expectation before you plot. The book's example: the more minutes a player averages per game, the more points per game. Write the expectation down, then test it.
3. 3Test the expectation visually first. Call `qplot(x = MPG_min_per_game, y = POINTS_PER_GAME, data = nbaData, size = 5)`. The order is x column, y column, then the data frame, and `data` must be a data frame. Then confirm the relationship numerically with `cor`.
4. 4Add presentation layers with `+`. In `ggplot2`, `+` appends layers to the plot object and is not arithmetic. Append `theme_hc()` from `ggthemes` to change many parameters in one call. Use `theme_tufte` when you want Tufte's practices applied as a style.
5. 5Choose the plot form deliberately, since the choice shapes the story. The book's face pattern uses `geom_point` for one block of rows and `geom_path` for another (`allDat[31:60,]` and `allDat[1:30,]`). Points alone would have hidden the pattern. Try at least two geoms before settling.
6. 6Re-plot contested results in a second form. The Nightingale data re-plotted as a bar chart with `scale_fill_brewer(type = "seq", palette = "Greys")` and `theme_bw()` shows the disease-rate drop began before proper sanitation. Compare both versions and report the one that does not overstate the finding.
7. 7Check the plot against Tufte's six practices: show comparisons, use multivariate data, establish credibility with sources, show causality, integrate text and images, and focus content. Remove 3D effects and other chart junk.
8. 8Adapt, don't just copy, the book's code. Swap in another sport, a newer data set, or a different chart layer (for example `sportyR` for courts and pitches). Each chapter is a standalone reference meant to be extended as your acumen grows.

Using the Dallas basketball player data, you run `summary(nbaData)` and read the range, quartiles, mean, and NA count for each numeric column. You expect more minutes per game to mean more points per game. You test that with `qplot(x = MPG_min_per_game, y = POINTS_PER_GAME, data = nbaData, size = 5) + theme_hc()`, where `+` adds the Highcharts-style theme layer. Figure 1.8 shows that, as expected, higher average minutes go with higher average points. You could confirm this with `cor`, but the scatter plot makes the relationship visible at once. A second case is the Nightingale mortality data, which looks compelling in its original form. Re-plotted as a bar chart (Figure 2.4), it shows the disease-rate decline began before proper sanitation. Overall deaths still fell, so sanitation mattered, but less dramatically. The skill is both running the code and reading what each version says.

• If you have just loaded a data set, then run `summary` first and read the NA tally before plotting or modeling.
• If you hold a directional hypothesis about two numeric variables, then draw a scatter plot (`qplot` or `ggplot`) and calculate `cor` to confirm it.
• If a pattern depends on a single chart form, then re-plot with a different geom (for example bars instead of the original) before presenting it.
• If a 3D chart or a many-slice pie chart tempts you, then use a simpler 2D alternative, because 3D slices exaggerate size and complex pies are indiscernible.
• If a chapter's code is for a different sport than yours, then keep the technique and swap in your data, since each chapter's takeaway is meant to be broadly applicable.

• Skipping `summary` and charting blindly. The tell: NA values or odd ranges surface only after a misleading plot or error.
• Treating `+` in `ggplot2` as arithmetic or forgetting the `data` argument must be a data frame. The tell: errors when appending themes or when `qplot` receives columns not wrapped in a data frame.
• Retyping the book's code without understanding the output. The tell: you cannot say what Figure 1.8 shows, or why `geom_path` and `geom_point` were mixed.
• Letting design choices mislead the audience. The tell: the chart supports your conclusion only in one format, as with the Nightingale original versus the bar chart.
• Using chart junk such as 3D bars and crowded pies. The tell: the audience cannot read exact values (a bar edge at ~0.75 versus ~1.0) or tell the slices apart.

• ▸Data set and source: name the data frame and where it came from.
• ▸Summary findings: record ranges, medians vs. means, and NA counts from `summary()`.
• ▸Hypothesis: state the expected relationship between two variables before plotting.
• ▸Plot call: paste the exact `qplot`/`ggplot` code, including geoms and theme layers.
• ▸Numeric check: record the `cor` value and whether it matches the visual.
• ▸Alternate view: describe a second chart form and whether the story changes.
• ▸Tufte check: note which of the six practices the chart meets or misses.
• ▸Adaptation: describe how you changed the book's example (new sport, data, or layer).
• ▸Interpretation: write two sentences on what the result does and does not support.