- Joined
- Jul 11, 2008
- Messages
- 1,940
- Reaction score
- 185
- Points
- 63
What neither article covered is the operational question. How do you actually maintain visibility across these metrics for the players you're tracking without spending three hours per week manually pulling FBref tables? How do you notice when a player's progressive carry rate drops meaningfully before the market has had two or three results to catch up on? How do you translate that flag into a specific prop market position rather than a vague sense that something has changed?
That's what this is for. A practical setup guide - specific enough that someone with no coding background can implement it, honest about where the manual steps remain unavoidable, and focused specifically on the metrics that the earlier articles established as most mispriced in prop markets.
The full setup takes three to four hours. The weekly maintenance takes twenty to thirty minutes after that. Both numbers assume you're following the steps rather than building something more elaborate than you need.
What the Dashboard Actually Is
Before the setup, a clarification about what this dashboard is and isn't. It's not an automated system that pulls data, runs analysis, and sends you betting alerts without involvement. Building that requires programming knowledge and API access that most people don't have and don't need.
What it is is a structured workflow - a set of repeatable steps combining FBref data pulls, LLM-assisted structuring and flagging, and a simple spreadsheet you maintain yourself. The word "dashboard" is being used loosely. The output is a spreadsheet you update weekly and a set of LLM prompts you run against it to identify flags worth investigating. It doesn't look like a Bloomberg terminal. It looks like a well-maintained spreadsheet with a reliable update process.
That's enough. The edge isn't in the sophistication of the tool. It's in maintaining systematic visibility across metrics that most bettors aren't tracking at all. A spreadsheet you update every week beats a complex system you abandon after three weeks because the maintenance is too heavy.
Step One: Define Your Player Universe
The dashboard only works if it's focused. Trying to track progressive carry rates and xT contributions for every player in the Championship is a maintenance problem that defeats the purpose. You need a defined player universe - the specific players whose prop markets you're active in or planning to be active in.
The player universe has three tiers.
Primary tracking players are the ones you're actively betting prop markets on. For each of these, you want weekly metric updates without exception. Typically ten to twenty players if you're running a serious prop market operation across one or two competitions.
Secondary tracking players are players where you're monitoring for conditions that might make their props interesting - a player recovering from injury whose carry rate will signal full return before the market catches it, a fullback whose role has changed this season and whose prop line hasn't adjusted yet. These get updated every two weeks rather than weekly. Another ten to twenty players.
Watchlist players are ones you've flagged as potentially interesting but haven't yet established a baseline for. They get a monthly check rather than regular updates. You move players between tiers as your assessment changes.
Write the list before you build anything else. The setup process is much faster when you know exactly which players you're pulling data for rather than deciding as you go.
Step Two: The FBref Data Pull
FBref carries the metrics you need. For progressive carries, the relevant table is under the "Possession" section on player pages and competition pages. For xT - or its closest public-data proxy, which is progressive passes received and shot-creating actions from carries - the relevant tables are under "Goal and Shot Creation."
FBref doesn't have a public API, which means the data pull is manual. There's no way around this for a non-coder without paying for a data service. The manual pull process is faster than it sounds once you have a routine.
For each player in your primary tracking tier, the relevant data is on their FBref player page under two sections: Possession (for progressive carries per ninety, carry distance, carries into final third, carries into penalty area) and Goal and Shot Creation (for shot-creating actions from carries, progressive passes received). The tables are on the page - you're copying them.
For competition-level data, which you need for the positional average comparisons the xT article described as essential context, the Competition pages carry the same tables aggregated across all players. Pull these once per setup and update them monthly rather than weekly - positional averages move slowly.
The copy process: select the relevant table on FBref, copy it, paste it into a plain text document or directly into your spreadsheet. FBref tables copy reasonably cleanly into spreadsheets in most browsers, though the formatting sometimes needs minor cleanup. The LLM handles that cleanup in the next step.
For the weekly pull on twenty primary tracking players, this process takes about forty minutes including navigation time. Faster once you've done it three or four times and have direct URLs bookmarked for each player's page.
Step Three: Using the LLM to Structure and Clean the Data
Raw FBref table data pasted into a conversation has inconsistent formatting, extra header rows, and occasionally merged cells that don't copy cleanly. Rather than fixing these manually, use the LLM to structure and clean it before it goes into your spreadsheet.
The structuring prompt:
"I'm going to paste raw data copied from FBref player pages for a set of football players. The data covers progressive carries and goal creation metrics. For each player, extract the following fields and present them in a clean table: player name, competition, matches played, progressive carries per ninety minutes, total carry distance per ninety, carries into final third per ninety, carries into penalty area per ninety, shot-creating actions from carries per ninety, and progressive passes received per ninety. If any field is not present in the data for a specific player, mark it as N/A rather than leaving it blank or estimating it. Do not add any analysis - just produce the clean structured table. Format as a CSV I can paste directly into a spreadsheet."
The CSV output instruction is the most practically useful part of this prompt. CSV pastes cleanly into Google Sheets and Excel without formatting issues. Asking for a formatted table produces output that looks right in the conversation but has hidden characters that cause problems in spreadsheets.
Paste this structured output into your spreadsheet. The weekly entry goes in a new set of rows dated to the week of the pull. You're building a time series, not updating a single row - you want the historical data, not just the current week.
The Spreadsheet Structure
Keep it simple. Over-engineering the spreadsheet is the reason most of these projects collapse after a month.
One sheet per player tier - Primary, Secondary, Watchlist. Each sheet has the same column structure: date, player name, competition, matches played, and the six or seven metric fields from the structuring prompt. New data goes in new rows. You're not deleting old rows - the whole value of the system comes from seeing change over time.
Add three calculated columns that the LLM flagging system uses. A rolling five-match average for progressive carries per ninety, calculated from the last five entries for each player. A percentage change from the five-match rolling average to the current week's value. And a column for the competition positional average for that player's position - updated monthly from the competition-level FBref pull - which gives you the context column for assessing whether a player's metric is above or below typical for their position.
Those three calculated columns are the ones you're actually using for prop market decisions. Everything else is the data that populates them.
If spreadsheet formulas are unfamiliar, this is another LLM task. Describe what you need - "a formula that averages the last five non-blank values in column F for rows where column B matches the player name in cell A2" - and the model produces the formula. Paste it in, drag it down the column, done.
Step Four: The Weekly Flagging Prompt
Once the week's data is in the spreadsheet, the flagging step identifies which players have shown meaningful metric changes worth investigating for prop market implications.
Export your primary tracking sheet as CSV and paste it into the LLM with this prompt:
"I'm going to paste a CSV of player tracking data covering progressive carry and shot creation metrics for a set of footballers over multiple weeks. For each player, identify whether their most recent week's data shows a meaningful change relative to their five-week rolling average. Define meaningful as a change of fifteen percent or more in progressive carries per ninety, or ten percent or more in shot-creating actions from carries per ninety. For each player flagged, note the direction of change, the magnitude, the current value relative to the positional average I've included in the data, and whether the change has persisted across the last two data points or appeared only in the most recent entry. For players not showing meaningful change, do not include them in the output - I only want the flags. Format the output as: player name, metric changed, direction, magnitude, current vs positional average, single or sustained change."
The fifteen and ten percent thresholds are starting points. After a few weeks of running the system, you'll calibrate these based on the noise level in your specific player universe - some positions and playing styles produce higher natural week-to-week variation that requires a higher threshold to be meaningful, others are more stable and flag at lower thresholds. The calibration is worth doing after a month of output.
The "single or sustained change" column is the most important output for prop market decisions. A single-week metric drop might be a rotation decision, a tactical instruction for one match, or a sample size artefact from a low-minutes appearance. A sustained two or three week change is more likely to represent a genuine shift - injury recovery, role change, tactical evolution - that the prop market hasn't fully incorporated.
Translating Flags Into Prop Market Positions
The flag is the starting point for analysis, not the conclusion. The progressive carries article established the mechanism: a player whose carry rate has dropped meaningfully may have an over line in shots or key passes that the market set from a higher-carry baseline. A player whose carry rate has increased - perhaps following an injury return or a positional adjustment - may have an under line set from a lower-carry baseline.
The translation from flag to position requires two additional checks beyond the metric data.
First, the mechanism check. Why has the carry rate changed? The LLM can help here - paste the player's recent match reports with the same qualitative extraction prompt from the referee database article, looking specifically for mentions of the player's role, involvement, and positioning. A carry rate drop explained by a tactical instruction to stay deeper has different persistence expectations than one explained by a minor knock. The mechanism determines whether the change is likely to persist for the next two to three fixtures.
Second, the line check. Pull the current prop line for the relevant market. Compare it against the player's recent metric performance at the new baseline. The edge exists when the line reflects the old baseline and the metric data shows the new one. If the line has already adjusted - if it's already set lower following the carry rate decline - the opportunity has been priced and there's nothing to act on.
Both checks together take about fifteen minutes per flagged player. If the flag comes from the Monday data pull, you have until Friday - or Thursday for European fixtures - before the line has been processed by the full market. That window is the operational timeframe.
Automating the Weekly Pull: The Partial Solution
Full automation of the FBref pull requires Python and web scraping knowledge most non-coders don't have and shouldn't need to acquire for this purpose. There is a partial solution that reduces the manual work meaningfully without requiring any coding.
Google Sheets has an IMPORTHTML function that can pull tables from web pages directly into a spreadsheet cell. For FBref tables that are in standard HTML table format - which most of them are - the function pulls and refreshes the data automatically. The syntax is: =IMPORTHTML("url","table",table_number) where table_number is the index of the table on the page you want.
The limitation is that FBref's table numbering isn't always stable - the table index can shift when the page layout changes, requiring occasional formula updates. And the function pulls the entire table rather than the filtered subset you want, meaning you still need the LLM structuring step to extract the specific columns.
What IMPORTHTML automates is the navigation and copy-paste step. Instead of opening twenty player pages and manually copying tables, the spreadsheet fetches the raw data automatically on each refresh. You're still running the LLM structuring prompt and the flagging prompt. But the data collection step moves from forty minutes to under ten.
To implement it: ask the LLM to identify the correct table index for the possession table on a specific FBref player page URL you provide. Once you've confirmed the formula works for one player, replicate the structure for the rest of your primary tracking list. Each player gets a tab in the spreadsheet with their IMPORTHTML formulas, and a master sheet that aggregates the relevant columns using IMPORTRANGE.
That architecture is worth building even if it takes an extra two hours of setup. The long-term maintenance reduction is significant enough to justify it.
What Falls Outside the Dashboard
The dashboard tracks metrics available on FBref at the player level. It doesn't track information that would materially affect those metrics but isn't in the data - the manager's tactical instruction for a specific fixture, the presence of a specific opponent who suppresses carry attempts, the player's fitness status going into the match.
These inputs have to come from the other parts of the weekly workflow. The press conference transcript analysis covers fitness signals. The fixture screening tool covers tactical matchup variables. The dashboard's metric flags are one input into a decision that still requires those other inputs before it becomes a bet.
The failure mode to avoid is using a metric flag as a sufficient condition rather than a necessary one. A significant progressive carry decline is a reason to investigate a potential under on the player's key passes or shot-creating action prop. It isn't a reason to back the under without checking whether the decline is explained by a favourable matchup this week that might temporarily reverse it, or whether the line has already adjusted to reflect what the metric is showing.
The dashboard surfaces. The analysis decides. Same division as the fixture screening tool. Keep it clean.
Anyway. The setup is more involved than the weekly prompts that follow it. First month has a higher time investment. After that it's genuinely thirty minutes per week, spread across the Monday data pull and the mid-week flagging and line check. For anyone who's active in player prop markets for fullbacks and midfielders specifically - the positions the earlier articles identified as most mispriced from carry data - that investment has a clear and specific payoff.
The edge window on tracking data being underincorporated into prop pricing is a few years at most, probably less. The tool is most valuable now, while the gap between what's measurable and what's priced is still meaningful. Build it while that's true.
FAQ
Q: Which competitions have the best FBref data coverage for this workflow?
The Big Five leagues - Premier League, La Liga, Bundesliga, Serie A, Ligue 1 - have complete player-level tracking data on FBref going back several seasons. The Championship has reasonable coverage for most players but occasional gaps for lower-minutes appearances. Scottish Premiership data is patchier at the player level, particularly for possession metrics - the competition-level tables are complete but individual player pages sometimes have incomplete entries for smaller clubs. For anyone building this primarily for Championship and Scottish Premiership prop markets, expect to fill some gaps manually and build wider uncertainty into flags in those competitions.
Q: How do I handle players who move between clubs mid-season?
The mid-season transfer is the situation where carry-rate tracking is most likely to produce misleading flags. A player's metrics at Club A don't transfer cleanly to their expected contribution at Club B because the system, role, and teammates are different. When a tracked player transfers, reset their baseline rather than treating the new club's initial data as continuous with the old. Flag their first four to six matches at the new club as baseline-building rather than as data points for flagging. The LLM structuring prompt handles this cleanly if you add a transfer flag column to the spreadsheet and instruct the flagging prompt to exclude baseline-building entries from the change analysis.
Q: The IMPORTHTML function keeps breaking on some player pages. How do I fix it?
FBref uses JavaScript to render some tables dynamically, which IMPORTHTML can't access - it only reads the static HTML. When the function returns an error on a specific player page, it usually means that table is rendered dynamically rather than in static HTML. The fix is either switching to manual copy-paste for that specific player, or using a service like Sheets' IMPORTDATA function with a cached version of the page from a data intermediary. Ask the LLM: "The FBref page for [player URL] isn't working with IMPORTHTML. What alternative approaches exist for pulling tabular data from a JavaScript-rendered page into Google Sheets without writing code?" The model will produce two or three options with their tradeoffs. The manual copy-paste fallback is always available and for a small number of affected players it's the least friction path.
