Raw game log data is not useful to an editorial team in its original form. A play-by-play file contains thousands of rows per game: shot attempts, possessions, substitutions, foul calls, momentum shifts measured in individual events. None of that is a talking point. Turning it into something a writer can use in 90 minutes of pre-game production requires a specific pipeline, and the design decisions in that pipeline are where most of the editorial value is either created or destroyed.
We have built and iterated on this pipeline over two years, starting with the spreadsheet version we used for our own fantasy leagues and moving to an API-based system that sports media clients can connect directly to their CMS. This post is about what that pipeline actually looks like, where the tricky parts are, and what editorial teams should know about the data they are receiving.
Stage 1: Event Log Ingestion and Normalization
Game event logs come from data providers in formats that are not standardized across providers or even across sports. A play-by-play feed for one sport might encode player IDs differently from another sport's feed from the same provider. Event types vary in granularity depending on how the data was collected. Some events have timestamp precision to the millisecond; others are rounded to the nearest second or minute.
The first stage of the pipeline is normalization: mapping the raw event types and identifiers to a consistent internal schema. This is unglamorous work and it takes longer than it should, but it is the foundation everything else depends on. A model trained on inconsistently encoded event types will produce outputs with systematic errors that are very difficult to trace back to the input encoding problem.
Practical notes from our experience: maintain a mapping layer between each data provider's identifier scheme and your internal identifiers. When a provider changes their ID scheme (and they do, more often than documented), you want the change to affect only the mapping layer, not the downstream feature engineering code. Also: log raw event counts per game immediately at ingest. A game where the event count is 40% below the sport's typical range is usually a truncated or partial feed, not a blowout that ended in the second quarter.
Stage 2: Feature Extraction from Event Sequences
Once the event log is normalized, the next stage is extracting the features that go into predictive and analytical models. This is where domain expertise intersects with data engineering.
The features that matter most for sports prediction are rarely the ones that are easiest to calculate. Total shot attempts are trivial to compute but weakly predictive. Shot attempts under specific spatial and time-pressure conditions are harder to compute but substantially more informative. Creating those conditional features requires encoding the game context at each event: what was the score margin, how many minutes remained, was this a transition opportunity or a half-court set, what was the team's rolling pace over the last six possessions.
For talking point generation, the features that matter are slightly different. We are not optimizing for prediction accuracy here; we are looking for features that are analytically interesting and editorially usable. A team's scoring efficiency in the last eight minutes of close games is interesting because it is specific, it is directional, and a writer can build a sentence around it. A team's aggregate point differential is not interesting because it is obvious and does not give readers anything to engage with.
The feature extraction stage should explicitly distinguish between model features (fed to the prediction model) and talking-point features (surfaced in the editorial output). They overlap but are not identical, and conflating them produces output that is either too abstract for editorial use or too low-level to be predictive.
Stage 3: Aggregation Windows and Recency Weighting
Sports performance data decays rapidly in relevance. What a team did 40 games ago is almost always less informative about Sunday's matchup than what they did in the last six games. This seems obvious, but many data pipelines do not encode it explicitly, and the result is features that treat a team's recent peak and their current form as equally relevant.
We use explicit exponential decay weighting across all time-windowed features in our pipeline. Recent games are weighted more heavily than older ones, with a decay rate that we calibrate separately for each sport and each feature type based on historical predictive performance. The decay rate is not the same across all features: player performance metrics decay faster than venue effects; scheduling context (back-to-back, travel distance) decays faster than roster composition effects.
For talking points, we typically compute three windows: the last 3 games (hot/cold streak signal), the last 12 games (medium-term form), and the current season (baseline context). A talking point might reference all three in one statement: "Defensive efficiency over the season sits at X, but over the last 12 games it is Y, and the last three games it is Z." This multi-window framing is more editorially useful than a single aggregate because it lets writers tell a directional story.
Stage 4: Anomaly Detection and Significance Filtering
Not all interesting-looking statistics are actually interesting. This is the stage that separates a useful talking point pipeline from one that produces noise that editorial teams have to manually filter.
The key question is statistical significance given the sample size. A team that has won 8 of their last 10 home games might look like a strong home record. If the league average for home winning percentage is 56%, then 8 of 10 is roughly 2.5 standard deviations above baseline, which is notable. But if the team has played at a new venue for only 6 home games, the sample is too small to distinguish genuine home-court advantage from variance.
We flag talking points with their underlying sample size and significance level. If a talking point is based on a sample of fewer than 15 comparable events, it carries a low-confidence flag in our API response. This does not mean the talking point should not be used; it means the writer should know the statistical context and frame it accordingly ("the early-season data suggests..." rather than "this team has demonstrated...").
Stage 5: Narrative Template Generation
The final stage in the pipeline is converting structured features and significance-filtered statistics into natural-language talking points. This is the step that is most visible to editorial teams, but it is actually the least technically complex once the preceding four stages are done correctly.
We use a set of template patterns that pair feature types with editorial framings. A trend-direction feature becomes a "heading into this matchup" narrative frame. A matchup-specific historical angle becomes a "historically, when these teams meet in these conditions" frame. An upset-risk signal becomes a "despite the win probability, the variance in possible outcomes is elevated because" frame.
The goal is not to write the article for the editorial team. It is to give them a structured starting point that is factually grounded and editorially usable in under two minutes of reading time. A good talking point should be completable: a writer should be able to take it and extend it with their own editorial voice within a sentence or two, not rewrite it from scratch.
The whole pipeline runs in under four minutes for a full slate of pre-game matchups, which means it can produce current talking points as of game-day roster announcements without requiring editorial teams to wait for an overnight batch process. That timing matters: a talking point based on yesterday's data can miss the injury news that landed this morning.