Corrections

How to report a CFBTrack data issue so it can be fixed quickly and cleanly.

The fastest correction reports are specific. CFBTrack pages often share data paths, so one clear report can fix more than one surface when it includes the exact page, the mismatch, and the expected value.

What this page covers

  • Send the exact URL

    A route-level report is easier to reproduce than a broad description of the problem.

  • Name the mismatch

    Say whether the issue is wrong data, stale data, a misleading label, or a broken interaction.

  • Include evidence when possible

    A screenshot, official source, or season/team reference helps narrow the fix path.

What to include in a correction report

The more precisely the issue is framed, the more likely it can be reproduced on the first pass. This is especially important on routes that support filters, tabs, and query-param state.

  • The full public URL, including relevant query parameters.
  • What the page currently shows and what you believe it should show instead.
  • Any supporting source, screenshot, or historical reference that clarifies the expected result.

What happens after you report it

Some corrections are route-local, while others require a shared data-path fix. When the same issue can affect multiple pages, the preferred fix is the shared source or formatter rather than a one-off hardcode on one team or one route.

  • Trust issues such as conflicting records, misleading times, or broken defaults are treated as high priority.
  • Shared data or formatting fixes are preferred over page-specific hardcodes.
  • If a source feed is missing data entirely, the safest fallback is used until the upstream data is available.

Best contact path

Use the contact page for the actual report so it reaches the site team. This corrections page exists to set expectations and help you package the report in the most useful format.

  • Use the contact page for data corrections, page bugs, and route behavior issues.
  • If the issue affects multiple URLs, include the clearest example first.
  • If a correction touches a future or in-progress season, note that explicitly.

Correction report template

A strong report should be short, reproducible, and tied to a public page. The most useful format is: URL, visible value, expected value, source or evidence, and whether the issue appears on one page or several related pages.

  • URL: include filters, tabs, and query parameters if they changed the result.
  • Current value: quote the team, player, game, or table row that looks wrong.
  • Expected value: include the corrected value and the season, week, or source context.
  • Evidence: link an official source, screenshot, or trusted reference when possible.

How fixes are prioritized

Corrections that affect trust, searchability, or repeated pages should be fixed at the shared source whenever possible. A single typo can be page-local, but a wrong team ID, stale venue, broken route label, or bad stat mapping usually needs a shared data or service fix.

  • Broken route access, misleading labels, and wrong records get priority over cosmetic issues.
  • Shared data problems should be fixed once, then verified on every page that reads that source.
  • When source data is unavailable, the preferred result is a clear fallback or hidden module instead of misleading filler.