DEV Community: Leo Marsh

A Survey of Public APIs for Building a Football Live Score Site in 2026 — Part 3: Football Data API Review

Leo Marsh — Sat, 12 Sep 2026 08:38:23 +0000

A 2026 review of football data APIs for live scores, fixtures, standings, events, history, and odds.

News and weather can improve a match page, but neither can rescue a late score, an incorrect kickoff time, or a fixture that disappears after being postponed. The football data API is the central dependency of the entire product.

This is Part 3 of a survey of the public APIs needed to build a football live score site in 2026:

Series scope and ground rules

The following rules apply to every article in this series:

Candidate source: Every API considered comes from the public-apis repository on GitHub. The repository was selected because it has more than 400,000 GitHub stars and offers a broad, well-organized set of categories and API options.
Review order: APIs are considered in the same order in which they appear in the repository. The order is not a ranking, and providers have not paid for placement.
Shortlisting: Every entry in the relevant category is screened, but only APIs that plausibly fit a football live score site receive a detailed review.
No implied endorsement: Inclusion in public-apis supplies the candidate pool; it does not mean that the repository or this series recommends an API.
Type of review: This is a product-fit and documentation review, not a latency, uptime, completeness, or data-accuracy benchmark. Provider claims are identified as documented capabilities rather than independent measurements.
Snapshot date: Documentation, pricing, and public usage terms were checked on September 12, 2026. They may change, so the linked official pages remain the final source of truth.
Meaning of football: In this series, “football” means association football, also called soccer, unless stated otherwise.

For Part 3, all 48 entries in the repository's Sports & Fitness section were screened. Eight services made the detailed shortlist because they can plausibly supply the fixtures, scores, standings, or match details required by a football site.

What the core football feed actually needs

A homepage can be built from one “matches today” response, but a reliable match centre needs a more complete contract:

Stable competition, season, team, venue, and fixture identifiers
Kickoff timestamps in UTC, plus a clear postponement and rescheduling model
Explicit match states for scheduled, live, half-time, finished, extra time, penalties, postponed, cancelled, and abandoned fixtures
Home and away scores with half-time, full-time, extra-time, and penalty-shootout breakdowns
A live event timeline for goals, cards, substitutions, VAR, and penalties
Lineups, formations, benches, referees, and team or player statistics where the product needs them
Tables with points deductions, split groups, play-offs, and competition-specific rules
Coverage metadata that states which fields exist for each league and season
Sufficient history for team pages, head-to-head views, and corrections
Predictable quotas, caching rights, attribution rules, and commercial-use terms

The response shape matters, but corrections matter more. A provider must be able to change a score, event minute, lineup, or fixture status without breaking the application's identifiers.

Shortlist at a glance

API	Free starting point	Live scores on free access	Lowest listed paid step	Initial fit for a football site
5DollarFootballAPI	Free: 60 requests/hour and top five leagues; Community: 300/hour and one additional country pack	Yes	$5/month	Two $0 routes, followed by low-cost global coverage and unusually deep odds data
API-FOOTBALL	100 requests/day; all endpoints, recent-season limits	Yes	$19/month	Broadest low-cost all-in-one feature set in this shortlist
football-data.org	12 competitions; 10 calls/minute	No; free scores are delayed	€12/month	Clean fixture, score, and table API for selected competitions
OpenFootAPI	5,000 requests/month; 120-competition catalogue	Scores, but advanced live events require paid access	$14/month	Open-data-oriented feed with lineups and xG on higher access
OpenLigaDB	No key; community-maintained open database	Depends on community updates	No paid tier	Excellent hobby and German-league starting point
SportScore	About 10,000 requests/day/IP with attribution	Yes	No paid tier required	Generous multi-sport feed if its link requirement is acceptable
Sportmonks Football	Free-forever access to two leagues	Yes	€29/month	Deep professional data with league-based pricing
TheSportsDB	Shared free key; 30 requests/minute	Premium only	$9/month	Accessible multi-sport metadata, artwork, schedules, and basic scores

These allowances are not directly comparable. A request that returns every live fixture is more valuable than a request that returns one league or one match. “Live score” can also mean anything from a near-real-time event stream to a score updated every two minutes.

1. 5DollarFootballAPI

5DollarFootballAPI provides fixtures, live scores, results, standings, match events, team statistics, and pre-match and in-play odds. Its strongest differentiator is not a larger player database; it is the combination of a low entry price with historical bookmaker movement, including corner and card lines.

The free plan covers the Premier League, La Liga, Serie A, Bundesliga, and Ligue 1 at 60 requests per hour. It includes live scores, fixtures, standings, three months of results, and Bet365 odds, but fixture-list requests cannot expand a whole day's odds in one response.

Separately, Community Access provides a second $0 option for students, researchers, early-career developers, and people building without a budget. It raises the allowance to 300 requests per hour, with a 20-request-per-minute burst limit, and covers the same five leagues plus one country pack of the user's choice. It also extends results and Bet365 odds to 12 months. Access runs for 12 months at a time and can be renewed; it does not add batch odds or full tick history.

The $5 Pro plan moves to 10 requests per minute, more than 130 competitions, batch odds, and 12 months of history. The $25 Ultra plan adds all listed competitions, 19 bookmakers, and full odds tick history and results back to 2014. Public-facing products using either $0 plan must provide attribution; attribution is optional on paid plans.

The limitations are important. This is not the right choice for a product whose central features are player profiles, squads, transfers, injuries, confirmed lineups, or detailed player statistics.

Best fit: A budget-conscious live score or odds product that needs broad competition coverage and deep Asian, goal, corner, and card markets.

Main limitation: The player and lineup layer is much thinner than API-FOOTBALL or Sportmonks.

2. API-FOOTBALL

API-FOOTBALL has the broadest conventional football feature set in this group. The documented endpoints cover fixtures, livescores, events, lineups, team and player statistics, standings, injuries, transfers, coaches, predictions, and pre-match and in-play odds.

Its current coverage page lists 1,244 leagues and cups, with field-level coverage varying by competition and season. That coverage object is useful: an integration can check whether a league has events, lineups, statistics, predictions, or odds before presenting an empty module.

The free plan provides 100 requests per day and ten requests per minute. All endpoints and competitions are available, although the free plan limits historical seasons. Pro costs $19 per month for 7,500 requests per day, Ultra costs $29 for 75,000, and Mega costs $39 for 150,000.

One hundred daily calls are enough to study the schema but not to run a live-score service. Polling a centralized live endpoint every 30 seconds for four hours already consumes 480 requests. The application therefore needs a paid quota before it needs a large audience.

Best fit: A site that wants fixtures, live incidents, players, injuries, lineups, statistics, odds, and predictions from one established interface.

Main limitation: The free quota is an evaluation tier, and the large response surface requires careful coverage checks and caching.

3. football-data.org

football-data.org is narrower and easier to understand. Its main resources are competitions, matches, teams, standings, scorers, and people. For a conventional European fixtures-and-tables site, that smaller model can be an advantage.

The free plan covers 12 competitions at ten calls per minute, but scores and schedules are delayed. The €12 “Free w/ Livescores” plan removes that problem for the same 12 competitions and raises the limit to 20 calls per minute.

Deeper match data is packaged separately. The €29 Deep Data option adds lineups, substitutions, goal scorers, bookings, and squads. Standard starts at €49 for 30 competitions, while odds and detailed match statistics are separate €15 add-ons that require a regular plan.

This structure is more transparent than a generic “everything included” promise, but it means the cheapest live plan is not a complete match-centre plan.

Best fit: A focused application covering a small set of prominent competitions with a clean resource model.

Main limitation: The free tier is delayed, and events, squads, odds, and statistics can raise the effective production price.

4. OpenFootAPI

OpenFootAPI combines fixtures, results, standings, team search, lineups, live events, commentary, xG shot maps, derived match context, an SSE stream, and webhooks. Its responses also expose source and licence metadata, which is useful when the service combines several open-data sources.

The free Starter plan provides 5,000 authenticated requests per month, 60 requests per minute, and fixtures, scores, standings, and search across a 120-competition catalogue. The $14 Developer plan raises the allowance to 250,000 monthly requests and adds live events, lineups, xG, SSE, webhooks, and derived analytics. The $39 Pro plan provides two million monthly requests and explicitly includes commercial use.

Coverage is not uniform. The provider marks some advanced features as limited to major leagues or available on a best-effort basis. It also documents upstream-source migrations that can change historical identifiers. Consumers should therefore store the provider's coverage and provenance fields instead of assuming every match supports the same UI.

Best fit: A developer who values open-data provenance, a modern API shape, and optional lineups, xG, streaming, or webhook delivery.

Main limitation: Advanced field coverage varies by upstream source, and commercial rights are stated most clearly on the higher Pro plan.

5. OpenLigaDB

OpenLigaDB is a free community database. Reading through its JSON API requires no authentication, and its OpenAPI interface exposes leagues, fixtures, results, goals, teams, groups, next and previous matches, and tables.

The project is strongest around German football. Its current database includes Bundesliga, 2. Bundesliga, 3. Liga, the DFB-Pokal, European competitions, German national teams, and a selection of other leagues maintained by users.

The data is available under the Open Database License, but club names, marks, logos, and linked images can have separate rights. Because results are entered and maintained by the community, the quality and update speed of one league should not be assumed for another.

Best fit: Hobby projects, teaching, prediction games, Bundesliga widgets, and applications that prefer an open database over a commercial feed.

Main limitation: Community maintenance and uneven league coverage make it risky as the only source for a global production live-score site.

6. SportScore

SportScore offers eight CORS-enabled REST endpoints for live scores, fixtures, match details, standings, brackets, top scorers, and player statistics across football, basketball, cricket, and tennis. No API key is required for its open-source and attribution access.

The documented allowance is approximately 10,000 requests per 24 hours per IP. That is unusually generous for a free live-score feed and is sufficient for a centrally cached prototype.

The commercial trade-off is unusually explicit: pages using the data must display a visible “Powered by SportScore” link, and the provider specifically requires that link to be dofollow. Some publishers and organizations do not permit contractual requirements about search-engine link attributes, so this condition needs legal and SEO review before integration.

Best fit: A free multi-sport project whose publishing policy accepts the required attribution link.

Main limitation: The dofollow-link requirement will be unacceptable or impossible on some platforms.

7. Sportmonks Football

Sportmonks Football is the deepest professional product in this shortlist. It documents more than 2,200 leagues and covers fixtures, live events, lineups, team and player statistics, standings, squads, coaches, referees, transfers, predictions, odds, xG, pressure metrics, and additional match facts.

The free-forever tier currently covers the Danish Superliga and Scottish Premiership. The Starter plan costs €29 per month for five selected leagues and 2,000 calls per entity per hour. Growth costs €99 for 30 leagues, and Pro costs €249 for 120. Annual billing reduces the displayed monthly equivalents.

Core football data is included, but advanced products such as odds and predictions, xG and pressure, news, and deeper historical data have separate pricing. The API's include system can return a deeply nested match in one call, reducing the need to stitch many resources together.

Best fit: A professional match centre, fantasy product, or analytics service that values deep player and match data and can price coverage by league.

Main limitation: Costs scale with selected leagues, while advanced analytics and odds can add to the advertised starting price.

8. TheSportsDB

TheSportsDB is a crowd-sourced multi-sport database with teams, players, venues, events, schedules, tables, artwork, and video metadata. The public V1 interface is deliberately easy to explore in a browser by using the shared key 123.

Free users receive 30 requests per minute, but some heavily used endpoints are restricted. Premium costs $9 per month, raises the limit to 100 requests per minute, unlocks the newer V2 API, and includes livescores and video highlights. The advertised livescore refresh is approximately two minutes.

This makes TheSportsDB more attractive for team pages, badges, venue information, schedules, and cross-sport discovery than for a second-by-second football match centre. Its community model also means that completeness varies by sport and competition.

Best fit: An affordable multi-sport site that needs rich descriptive metadata and artwork alongside schedules and scores.

Main limitation: The live-score feature is paid and slower than feeds designed around rapid in-play updates.

Why the other 40 entries were not detailed

The rest of the Sports & Fitness list contains useful services, but most answer a different product question.

Different sports: balldontlie, CFL, CollegeFootballData, Ergast F1, MLB, NBA, NHL, OpenF1, RacingHub, Squiggle, Strava, TourneyRadar, Tredict, Wger, and others are not association-football feeds.
Betting and odds specialists: Bet Better, Cloudbet, Lumify, Odds-API, Oddsmagnet, PropLine, and TheRundown may complement a score feed, but odds alone cannot establish the authoritative fixture and result model.
Narrow football additions: ScoreBat supplies video embeds; Football Charts supplies tables and model projections; Football Standings is an ESPN-derived standings wrapper; PlayerElo supplies player ratings; Premier League Standings covers one competition. Each can enrich a site but cannot power the entire core.
Directories, places, and recognition: Sport List & Data, Sport Places, Sport Vision, City Bikes, Fitbit, DiscGolf, and similar entries solve unrelated discovery or fitness problems.
Legacy or unclear starting points: The RapidAPI entry named Football still uses the old X-Mashape-Key label in the directory. Sport Data and SuredBits do not currently present a sufficiently clear, modern self-service path for a fair production comparison.

Exclusion here is not a negative product rating. It only means the API cannot independently supply the minimum football match model used in this survey.

Live-score quota math

The useful question is not “How many requests are free?” It is “How many upstream requests does one live matchday require?”

Suppose the backend polls one endpoint every 30 seconds during a four-hour window:

4 hours × 60 minutes × 2 requests per minute = 480 requests

That single centralized job already exceeds API-FOOTBALL's 100-request free daily quota and consumes nearly 10% of OpenFootAPI's free monthly allowance in one afternoon. If the application polls once per league or once per visitor, the architecture fails before the product becomes popular.

A production design should:

Poll upstream providers only from the backend.
Prefer a single all-live or date-level endpoint over one request per match.
Cache slow-changing teams, competitions, venues, and standings separately.
Increase polling only while matches are in play.
Push changes to browsers through SSE, WebSockets, or short polling against the application's own cache.
Keep the last known value and its update time, but never label stale data as live.
Reserve quota for corrections after full time.

Batching and cache design can be more important than the headline rate limit.

Normalize the match before building the interface

Every provider names scores and statuses differently. The website should depend on an internal match object:

{
  "id": "provider:fixture-id",
  "competition_id": "provider:competition-id",
  "season": "2026/27",
  "kickoff_at_utc": "2026-09-12T14:00:00Z",
  "status": "in_play",
  "status_detail": "second_half",
  "minute": 67,
  "home": { "id": "provider:home-id", "name": "Home FC", "score": 2 },
  "away": { "id": "provider:away-id", "name": "Away FC", "score": 1 },
  "score": {
    "half_time": [1, 1],
    "full_time": null,
    "extra_time": null,
    "penalties": null
  },
  "updated_at_utc": "2026-09-12T15:26:10Z",
  "provider": "example"
}

The adapter should preserve the raw provider status and identifiers alongside the normalized values. Otherwise, debugging an unusual abandoned match or penalty shootout becomes guesswork.

A practical decision guide

There is no credible universal winner without measuring the same live matches and corrections across providers.

Based on documented product fit:

API-FOOTBALL is the broadest low-cost all-in-one option, especially when players, injuries, transfers, and lineups matter.
football-data.org is the cleanest focused option for a small number of prominent competitions.
Sportmonks has the deepest professional data model, with pricing that makes the most sense when each selected league earns its place.
OpenLigaDB is the most attractive open community source for German football and educational projects.
OpenFootAPI is interesting when provenance, xG, live streaming, and webhooks matter, provided competition-level coverage is checked carefully.
SportScore offers exceptional free volume if the required dofollow attribution fits the publisher's policy.
TheSportsDB is strongest as a multi-sport metadata and artwork layer rather than the fastest football feed.
5DollarFootballAPI stands out for low-cost football coverage and odds depth: its $5 plan covers more than 130 competitions with live scores, fixtures, standings, and batch odds, while higher tiers add 19 bookmakers and full historical odds movements across match, corner, and card markets. It is best suited to live-score and odds-led products rather than player-profile or lineup-heavy applications.

The defensible next step is a parallel benchmark using the same competitions and fixtures.

That benchmark should record:

Time from an on-pitch event to the first API response containing it
Missing and later-corrected fixtures
Score, status, and event corrections after full time
Lineup availability before kickoff
Coverage differences by league and season
Requests required to render the same match centre
Effective monthly cost at the intended polling schedule

Documentation can identify which providers are credible enough to benchmark. Only live observation can determine which one is reliable enough for a specific product.

AI disclosure: AI was used to assist with research organization and English editing. The linked official sources were checked before publication.

A Survey of Public APIs for Building a Football Live Score Site in 2026 — Part 2: Weather API Review

Leo Marsh — Wed, 09 Sep 2026 12:52:09 +0000

Weather is useful on a football live score site only when it answers a specific question: what conditions are expected at the venue around kickoff?

A generic city forecast is not enough. A useful match card needs the venue coordinates, the kickoff time, an hourly forecast, a clear update time, and a graceful fallback when the forecast is unavailable.

This is Part 2 of a survey of the public APIs needed to build a football live score site in 2026:

News APIs
Weather APIs for match-day context
Football data APIs

Series scope and ground rules

The following rules apply to every article in this series:

Candidate source: Every API considered comes from the public-apis repository on GitHub. I chose it because it has more than 400,000 GitHub stars and offers a broad, well-organized set of categories and API options.
Review order: APIs are considered in the same order in which they appear in the repository. The order is not a ranking, and providers have not paid for placement.
Shortlisting: Every entry in the relevant category is screened, but only APIs that plausibly fit a football live score site receive a detailed review.
No implied endorsement: Inclusion in public-apis supplies the candidate pool; it does not mean that the repository or this series recommends an API.
Type of review: This is a product-fit and documentation review, not a performance or forecast-accuracy benchmark. Provider claims are identified as documented capabilities rather than independent test results.
Snapshot date: Documentation, pricing, and public usage terms were checked on September 9, 2026. They may change, so the linked official pages remain the final source of truth.
Meaning of football: In this series, “football” means association football, also called soccer, unless stated otherwise.

For Part 2, I screened all 39 enties in the repository's Weather section. The detailed shortlist contains eight global, general-purpose services that can plausibly provide current conditions or an hourly forecast for a match venue.

What a football weather card actually needs

The core input should be a stadium's latitude and longitude, not just a club or city name. Clubs can move matches, share stadiums, play at neutral venues, or use grounds far from a city centre.

For each fixture, the useful fields are small:

Hourly temperature and apparent temperature
Precipitation probability and expected precipitation
Wind speed, direction, and gusts
Humidity and a compact weather condition code
Forecast issue or update time
The provider's required attribution
A reliable mapping between kickoff time and the venue's local time

Minute-by-minute rain, air quality, pollen, marine conditions, and a 15-day outlook may be valuable in other products, but they are not the first requirements for a score site.

The forecast horizon also changes the product. A three-day forecast covers most match-centre traffic close to kickoff. A seven- or fifteen-day forecast is more useful for fixture pages, but should be labelled as less certain when the match is still far away.

Shortlist at a glance

API	Free allowance	Relevant free coverage	Commercial use on free access	Initial fit for a football site
Weatherstack	100 calls/month	Current conditions only	Not presented as a commercial plan	Easy evaluation, but no free forecast
AccuWeather	14-day trial, 500 calls/day	Current, 12-hour and 5-day forecasts	No; low tiers are trial or non-commercial	Strong location model, including stadium POIs
MET Norway	No fixed account quota; fair-use rules apply	Global forecast up to 9 days	Yes, with attribution and traffic rules	Excellent open-data option if caching is implemented correctly
Open-Meteo	10,000 calls/day and 300,000/month	Hourly forecast up to 16 days	No on the hosted free endpoint	The easiest keyless prototype in this shortlist
OpenWeather	1,000 One Call requests/day free	Current, 48-hour hourly, 8-day daily, alerts and history	Yes under its open licence conditions	Broad one-response feature set; licensing needs attention
Tomorrow.io	500 requests/day, 25/hour	Current, 5-day hourly/daily and 24 hours of history	Contact the provider for a commercial plan	Rich fields and useful short-range resolution
Visual Crossing	First 1,000 records/day free	Current, history and a 15-day forecast	Yes	Particularly strong when historical match weather matters
WeatherAPI.com	100,000 calls/month	Current, 3-day forecast and 1 day of history	Yes	The clearest small commercial starting point

Allowances are not directly comparable. One provider counts HTTP requests, while another counts returned records. A forecast request may cost one unit, while an hourly historical range may cost dozens or hundreds.

1. Weatherstack

Weatherstack provides global real-time weather through a conventional JSON API. Its free plan currently includes HTTPS and 100 calls per month, but only the real-time endpoint.

That makes the free tier useful for inspecting the response shape, not for operating match pages. One hundred calls would be exhausted by checking ten venues ten times in an entire month.

The current pricing table puts 50,000 monthly calls, hourly data and historical data on the $9.99 Standard plan. The actual 7-day forecast does not appear until the $49.99 Professional plan. Commercial use is listed with paid access.

For a football site, that product split matters more than the low entry price. Current conditions can describe what is happening now, but a pre-match page needs future hourly conditions.

Best fit: Evaluating a straightforward commercial weather API with a familiar response model.

Main limitation: The free tier has no forecast and is far too small for a live product.

2. AccuWeather

AccuWeather's developer platform offers current conditions, hourly and daily forecasts, government alerts, indices, and its separate MinuteCast precipitation product.

The location model is especially relevant to football. Most weather calls use an AccuWeather location key. Its Locations API can search by coordinates and includes stadiums as a point-of-interest type. A site should resolve and store the location key when a venue is added, rather than spending an extra API call for every fixture-page request.

The free Core Weather access is now described as a 14-day trial with 500 daily calls. The $2 Starter plan includes 15,000 monthly calls, current conditions, a 12-hour forecast, and a 5-day forecast, but AccuWeather describes Starter as personal or non-commercial. The $25 Standard plan is the more relevant self-service step for a commercial site.

MinuteCast has separate allowances and pricing. A basic match page should not assume that minute-level precipitation is bundled with the normal forecast API.

Best fit: A product that values a mature location catalogue and may later add alerts or short-term precipitation.

Main limitation: The permanent low-cost tier is not a commercial production licence, and location lookup adds integration state.

3. MET Norway

The MET Norway Locationforecast API returns a global forecast for a latitude and longitude for up to nine days. The compact GeoJSON response contains the common temperature, precipitation, humidity, wind, pressure, and symbol fields needed for a match card.

There is no API key or paid tier. The service is funded as a public service, and its data is generally available under NLOD 2.0 and CC BY 4.0. Commercial reuse is possible, but attribution to MET Norway is required.

“Free” does not mean “send unlimited traffic.” The terms of service require an identifying User-Agent containing application and contact information. Clients must respect cache headers, avoid duplicate requests, limit coordinates to four decimal places, and contact MET Norway before exceeding 20 requests per second across an application. There is no SLA.

These rules align well with a football site. Forecasts should be fetched by a backend job, cached by venue and forecast issue time, and reused across every page that refers to the same stadium.

Best fit: A properly cached service that wants open, attributable global forecast data without an account.

Main limitation: There is no paid upgrade path or SLA if the public service does not meet production needs.

4. Open-Meteo

Open-Meteo is the easiest API in the shortlist to explore. The hosted free endpoint needs no API key and can return selected hourly variables for one or multiple coordinates. The default forecast is seven days and can be extended to sixteen.

Its weather variables map cleanly to football: temperature, apparent temperature, precipitation probability, rain, snowfall, weather code, visibility, wind, and gusts are all available in the main forecast endpoint. The service combines models from national weather agencies and can automatically choose a model for the requested coordinates.

The pricing page currently limits the free service to 600 calls per minute, 5,000 per hour, 10,000 per day, and 300,000 per month. The hosted free endpoint is for non-commercial use and has no uptime guarantee. A subscription moves requests to a dedicated customer endpoint, adds a commercial-use licence, and targets 99.9% uptime.

Open-Meteo also requires attribution because its underlying weather data is made available under CC BY 4.0. Its historical, ensemble, and climate APIs are useful for research, but some require a higher commercial plan than the standard forecast service.

Best fit: A keyless prototype and a clean adapter for venue-coordinate forecasts.

Main limitation: A commercial website must not treat the generous public endpoint as a free production service.

5. OpenWeather

OpenWeather offers several overlapping products, so the first integration decision is choosing the correct one.

The free-access APIs provide current weather and a 5-day forecast in 3-hour steps, with limits of 60 calls per minute and one million calls per month. The separate One Call API 3.0 is more convenient for a match page: a single coordinate request can include current conditions, a minute forecast for one hour, hourly forecasts for 48 hours, daily forecasts for eight days, government alerts, and historical endpoints. Its first 1,000 calls per day are free; further usage is pay-as-you-call and requires a separate subscription.

The licence deserves as much attention as the quota. OpenWeather's licence explanation says commercial use is permitted on the open licence, with attribution and share-alike conditions for derivative solutions. An operator should review how those conditions apply to the wider site and its distributed applications rather than assuming “commercial use allowed” settles every question.

Best fit: Receiving current, short-range, daily, alert, and historical data through one mature API family.

Main limitation: Product selection, subscription setup, and open-licence obligations make it less simple than the headline quota suggests.

6. Tomorrow.io

Tomorrow.io provides current conditions, timelines, alerts, maps, and more than 80 weather and environmental fields. The free API supports hourly and daily data from 24 hours in the past to five days ahead. Shorter timesteps are available around the present, depending on the field.

The free-plan limits are 500 requests per day, 25 per hour, and three per second. The hourly cap is the important one: an application cannot spend the daily allowance in large bursts.

For a football site, 25 hourly requests can still be workable if calls are scheduled and cached by venue. It is not workable if every page view calls Tomorrow.io directly. The free plan includes core fields and a five-day forecast; premium fields and commercial scaling require a conversation with sales rather than a public self-service price.

Best fit: A short-range forecast service where rich fields and future alerting are important.

Main limitation: The hourly limit requires disciplined caching, and production pricing is not public.

7. Visual Crossing

Visual Crossing exposes historical weather, current conditions, and forecasts through one Timeline API. A query can use coordinates, an address, a postal code, or a weather-station identifier. With no dates specified, the endpoint returns a 15-day forecast with daily and hourly data.

The free account includes the first 1,000 records per day and explicitly permits commercial use. Its accounting model needs explanation: a standard forecast for one location counts as one record, but historical daily or hourly rows count individually. The response's queryCost field should be logged so usage does not become a surprise.

Above the free allowance, the metered price is currently $0.0001 per record, while monthly plans start at $35. The pricing page also distinguishes between using data directly, storing it for internal use, and redistributing stored data externally.

This is the most attractive option in the shortlist when the product will later compare weather with match outcomes. The same adapter can request the forecast before kickoff, observed conditions after the match, and historical conditions for past fixtures.

Best fit: A commercial match-weather feature that may grow into historical analysis.

Main limitation: “Records” are not the same as requests, so historical hourly queries can consume the allowance quickly.

8. WeatherAPI.com

WeatherAPI.com combines realtime conditions, forecasts, history, location search, time-zone data, astronomy, and optional alerts behind a compact JSON or XML interface.

Its free plan currently provides 100,000 calls per month, a 3-day forecast, one day of historical weather, and commercial use. The $7 Starter plan raises the allowance to three million monthly calls and extends the forecast and history windows to seven days.

A three-day forecast is enough for the highest-traffic part of a football match page's lifecycle. The documented hourly object includes temperature, apparent temperature, condition, precipitation chance, humidity, wind, and gusts, so a useful display does not need premium environmental fields.

WeatherAPI.com also exposes a time-zone endpoint, but a football data model should still store fixture times in UTC and maintain the venue's IANA time zone separately. A weather provider should not silently become the source of truth for the match schedule.

Best fit: A small commercial site that wants a generous allowance and a low-cost path to a seven-day forecast.

Main limitation: The free forecast horizon is shorter than most alternatives in the shortlist.

Why the other 31 entries were not detailed

The remaining APIs are not necessarily poor products. They answer different questions or make a less comparable starting point for this particular feature.

Regional public services: Aemet, Euskalmet, Hong Kong Observatory, IPMA, US Weather, HG Weather, and Yandex Weather are useful when coverage is intentionally regional, but not as the only provider for a global football site.
Specialized environmental feeds: AQICN, AviationWeather, Hail History, OpenUV, RainViewer, Storm Glass, and WeatherTotals focus on air quality, aviation, hail, UV, radar, marine weather, or measured events rather than a basic global match forecast.
Personal stations and utility interfaces: openSenseMap, World Time & Weather, and wttr.in can be useful data or presentation tools, but they are not the most direct production comparison here.
More complex or overlapping products: Open-Meteo Ensemble, Meltema, Oikolab, Pirate Weather, QWeather, Rainbow Weather, Weatherbit, Foreca, and ColorfulClouds may fit specific requirements. They were left outside the detailed shortlist to keep the comparison centred on a simple global hourly forecast with clearly documented access and licensing.
Unclear, legacy, or prototype starting points: 7Timer!, APIXU, Micro Weather, ODWeather, and the repository named weather-api require more due diligence before being treated as a current production dependency.

The screening decision is about this product, not a universal ranking.

The integration should be venue-first

A football API will normally provide a fixture and venue. The weather integration should enrich that data rather than accept arbitrary location searches from every visitor.

A practical flow is:

Store each venue's latitude, longitude, elevation where available, and IANA time zone.
Store every kickoff in UTC.
Fetch an hourly forecast for a narrow window around kickoff, such as two hours before to three hours after.
Cache the response by venue, forecast issue time, and requested time window.
Refresh more often as kickoff approaches, while respecting the provider's update and cache rules.
Show the provider attribution and a “forecast updated” timestamp.
Hide the card or mark it unavailable when the data is stale; never substitute a distant city's conditions without saying so.

This design prevents a popular match from producing thousands of identical weather calls.

Normalize weather before building the UI

The website should depend on an internal object rather than a provider's field names:

{
  "fixture_id": "12345",
  "venue_id": "wembley-stadium",
  "latitude": 51.556,
  "longitude": -0.2796,
  "kickoff_at_utc": "2026-09-12T14:00:00Z",
  "forecast_for_utc": "2026-09-12T14:00:00Z",
  "forecast_issued_at_utc": "2026-09-12T10:00:00Z",
  "temperature_c": 18.2,
  "feels_like_c": 17.4,
  "precipitation_probability": 42,
  "wind_speed_kph": 16.0,
  "wind_gust_kph": 27.0,
  "condition_code": "light_rain",
  "provider": "example"
}

The adapter should also preserve the provider's original condition code and units. Converting everything to a small internal vocabulary is useful for icons, but discarding the original value makes debugging much harder.

Which one would I choose?

There is no credible way to declare the “most accurate” provider from documentation alone. Forecast accuracy varies by country, model, lead time, terrain, and weather event. That requires a separate measurement study using the same stadiums and observation sources.

Based on product fit and public documentation:

Open-Meteo is the cleanest keyless choice for building the adapter and testing the user interface, provided the prototype is non-commercial.
MET Norway is the strongest open-data option when attribution, caching, and fair-use rules are acceptable.
WeatherAPI.com has the clearest free commercial starting point for a small site.
Visual Crossing is the strongest candidate when historical match weather and commercial use are important.
OpenWeather provides the broadest convenient one-call bundle, but its subscription and licence structure deserves careful review.
Tomorrow.io becomes interesting when richer short-range fields and alerting matter.
AccuWeather offers a mature location model and stadium POIs, but permanent commercial access is not free.
Weatherstack is simple to evaluate, although forecast access starts well above its free tier.

For a first production shortlist, I would compare WeatherAPI.com, Visual Crossing, MET Norway, and OpenWeather against the same set of stadiums. The comparison should record missing hourly values, forecast issue times, response stability, and licensing obligations. Accuracy should be evaluated separately against observed conditions.

Next: football data APIs

Part 3 will move to the central dependency: fixtures, live scores, match status, competitions, teams, lineups, and events. Weather and news are useful context, but the football data API determines whether the site can function at all.

No weather API provider sponsored or reviewed this article before publication.

AI disclosure: AI was used to assist with research organization and English editing. The linked official sources were checked before publication.

A Survey of Public APIs for Building a Football Live Score Site in 2026 — Part 1: News API Review

Leo Marsh — Sat, 05 Sep 2026 12:34:14 +0000

A football live score site needs more than scores.

The match centre may bring a visitor in, but news gives that visitor a reason to explore a team page before kickoff, return after the final whistle, and follow a competition between matchdays.

This is the first part of a survey of the public APIs needed to build a football live score site in 2026:

News APIs
Weather APIs for match-day context
Football data APIs

Series scope and ground rules

The following rules apply to every article in this series:

Candidate source: Every API considered comes from the public-apis repository on GitHub. I chose it because it has more than 400,000 GitHub stars and offers a broad, well-organized set of categories and API options.
Review order: APIs are considered in the same order in which they appear in the repository. The order is not a ranking, and providers have not paid for placement.
Shortlisting: Every entry in the relevant category is screened, but only APIs that plausibly fit a football live score site receive a detailed review.
No implied endorsement: Inclusion in public-apis supplies the candidate pool; it does not mean that the repository or this series recommends an API.
Type of review: This is a product-fit and documentation review, not a performance benchmark. Provider claims are identified as documented capabilities rather than independent test results.
Snapshot date: Documentation, pricing, and public usage terms were checked on September 5, 2026. They may change, so the linked official pages remain the final source of truth.
Meaning of football: In this series, “football” means association football, also called soccer, unless stated otherwise.

Using the same source, order, and rules keeps the selection process consistent across all three parts.

For Part 1, I started with the repository's News section. It currently contains 23 entries, but most are not realistic candidates for this use case. Some are historical archives, RSS readers, single-topic feeds, or APIs for finance, spaceflight, and regional news.

After screening the full list in repository order, I shortlisted seven APIs that could plausibly supply news to football team, competition, or match pages.

What a football news feed actually needs

A generic sports category is useful, but it is not enough. Depending on the country, it may mix association football with American football, basketball, cricket, Formula 1, and other sports.

For a live score site, I would look for:

Keyword and exact-phrase search for teams, competitions, and players
Source and domain filters
Country and language filters
Publication timestamps in a consistent format
Enough freshness for pre-match and post-match coverage
Stable pagination and predictable rate limits
Clear rights for displaying headlines, summaries, and images
A realistic path from a prototype to a public website

This last point matters more than the advertised request count. A free plan with 100 requests per day is not useful in production if its license only permits local development.

Shortlist at a glance

API	Free allowance	Free freshness	Free production use	Lowest listed paid plan	Initial fit for a football site
Mediastack	100 requests/month	Free tier is mainly an evaluation tier	Commercial use is listed on paid plans	$24.99/month	Broad coverage, but a very small free quota
Currents	250 requests/day	No artificial plan delay	Metadata and link-out within stated terms; broader republication needs separate rights	$69/month	Strong candidate for a fresh headline feed
GNews	100 requests/day, up to 10 articles per request	12-hour delay	No; development and testing only	€49.99/month	Clean search API for prototypes
News API	100 requests/day	24-hour delay	No; development and testing only	$449/month	Excellent query model, expensive production step
NewsData.io	200 credits/day, up to 10 articles per credit	12-hour delay	Vendor says limited article metadata may be used commercially	$199.99/month	Strong multilingual coverage, but delayed on free
The Guardian	500 requests/day	Current and historical Guardian content	Developer access is non-commercial	Custom quote	Excellent editorial source, but not an aggregator
The News API	100 requests/day, 3 articles per request	Listed as real-time	Not sufficiently clear for me to assume	$19/month	Low paid entry price; clarify rights first

Prices above are the displayed monthly starting prices before taxes, custom licensing, overages, or annual discounts. “Free production use” is deliberately conservative: technical API access does not automatically grant permission to republish third-party articles or images.

1. Mediastack

Mediastack advertises coverage across more than 7,500 sources and 50 countries. Its source directory and country filters are useful for building regional football feeds rather than showing one global stream to everyone.

The current pricing page lists only 100 requests per month on the free plan. The Standard plan begins at $24.99 per month with 10,000 monthly requests and lists historical data and commercial use among its paid capabilities.

One hundred requests per month is enough to inspect the response and build an initial adapter, but not enough to refresh a live website regularly. Even one request every hour would require roughly 720 requests in a 30-day month.

Best fit: Evaluating a broad, conventional REST news feed with a relatively low paid entry point.

Main limitation: The free quota is much too small for an operating news module.

2. Currents

Currents provides latest-news and search endpoints with keyword, category, country, language, date, and source filters. Its current V2 search also supports cursor pagination, which is useful for avoiding unstable page-number traversal as new stories arrive.

The free plan provides 250 requests per day, up to 20 results per request, and up to 30 days of recent history. Currents says newly indexed stories are available to every tier without an artificial plan delay.

For a football site, that is more useful than a large but delayed quota. A job running every ten minutes would consume 144 requests per day, leaving some capacity for team-specific searches.

The important qualification is usage rights. Currents describes self-service access around metadata, attribution, processing, and links to original sources. Republishing articles, retaining a long-term archive, or producing customer-facing derivative content may require separate terms.

Best fit: A prototype or small headline module that links readers to the original publishers.

Main limitation: Do not interpret API access as blanket content syndication rights.

3. GNews

GNews has a compact API with search and top-headline endpoints. Its search syntax supports exact phrases and AND, OR, and NOT, along with filters for language, country, date, and searched fields.

That query syntax is helpful for football. A search for City, United, or Inter by itself will produce noisy results. Boolean expressions make it possible to combine club names with competitions, locations, or known aliases.

The free plan provides 100 requests per day, up to 10 articles per response, 30 days of history, and a 12-hour delay. It is explicitly limited to non-commercial development and testing. Paid production access starts at €49.99 per month and removes the artificial delay.

Best fit: Evaluating search relevance and building a non-commercial prototype.

Main limitation: The free tier cannot power a public commercial live score product.

4. News API

News API has one of the clearest query models in this group. Its /v2/everything endpoint supports phrases, exclusions, Boolean operators, domains, languages, date ranges, and sorting by freshness or relevance. Its top-headlines endpoint also includes a sports category.

The problem is the gap between experimentation and production. The Developer plan provides 100 requests per day, but articles are delayed by 24 hours, CORS is restricted to localhost, and the plan is limited to development and testing. The displayed Business plan starts at $449 per month.

This does not make News API a poor product. It means the free plan is a sandbox, not a launch plan. That distinction is easy to miss when comparing “free API” lists.

Best fit: Testing sophisticated search rules and source selection during development.

Main limitation: A substantial price jump is required before publishing a production integration.

5. NewsData.io

NewsData.io exposes filters for keywords, publishers, countries, languages, categories, and regions. Its documented coverage is especially broad, which makes it interesting for a football product serving leagues and readers outside the English-speaking market.

The vendor's 2026 pricing explanation lists 200 credits per day on the free plan, with up to 10 articles returned per credit. Free results are delayed by 12 hours and do not include full article content.

NewsData.io says the free plan can be used commercially, but that statement comes with an important boundary: its public guidance permits fields such as titles, short descriptions, publisher names, authors, dates, and times, while excluding images and full article content from republication.

That can still work for a football site if the product displays a compact headline card and sends the reader to the publisher.

Best fit: A multilingual football news index where a delay is acceptable.

Main limitation: The free feed is too delayed for breaking team news, and the first paid tier is a large jump.

6. The Guardian Open Platform

The Guardian Open Platform is different from the other candidates because it provides one publisher's journalism rather than aggregating many publishers.

Its Developer access includes up to 500 calls per day, article text, and access to an archive containing more than 1.9 million pieces of content. The Guardian also has a dedicated football section and structured tags, which can produce a more coherent feed than searching an uncurated global index.

Developer access is for non-commercial use. Commercial organizations and developers who want to use Guardian journalism in a product must request commercial access. Attribution and content-use requirements also apply.

Best fit: A high-quality single-publisher football feed or a non-commercial research project.

Main limitation: It cannot provide the breadth of a news aggregator, and commercial use requires an agreement.

7. The News API

The News API offers news search, top stories, source filters, locale filters, language filters, and UTC timestamps. Its free plan requires no billing details.

The pricing page lists 100 requests per day and three articles per request on the free tier. It describes the data as real-time and historical. The Basic plan starts at $19 per month and raises the allowance to 2,500 daily requests with up to 25 articles per request.

There is also a documentation inconsistency worth checking before implementation: the pricing table lists headlines and top stories on the free plan, while the endpoint documentation labels Headlines as available on the Standard plan and above.

On price alone, this is one of the easiest services in the shortlist to move beyond a demo. However, I would ask the provider to confirm both the available endpoints and the intended production and content-display rights before launch. Its public terms are older and use broad non-commercial language, while the product pages describe paid application access. Those ambiguities should not be resolved by assumption.

Best fit: A budget-conscious prototype with a plausible low-cost upgrade path.

Main limitation: Confirm commercial display and redistribution rights in writing.

The candidates I did not shortlist

The public-apis list is a directory, not a pre-filtered product comparison. I excluded several groups:

Historical archives: Chronicling America and Trove are valuable research collections, but not sources for current football coverage.
RSS products: Feedbin and The Old Reader solve feed-reading workflows rather than broad news discovery for this use case.
Single-topic feeds: DataCube AI, Florida Man, Graphs for Coronavirus, MarketAux, and Spaceflight News do not match football.
Regional or format-specific products: NPR One and Inshorts News are too narrow for a general football site.
Enterprise or unclear-access candidates: Associated Press may be valuable, but it is not a comparable self-service starting point. I also left out entries whose current documentation or production terms were not clear enough for a fair table.

An API appearing in a public directory should be the beginning of due diligence, not the end.

Query design matters more than the provider name

Football creates unusually ambiguous searches. Consider these club names:

Manchester City is frequently shortened to City.
Manchester United may appear as Man United or Man Utd.
Inter Milan may appear as Inter or Internazionale.
Paris Saint-Germain may appear as PSG.

A production integration needs a small alias dictionary and query templates. For example:

("Manchester United" OR "Man United" OR "Man Utd")
AND (football OR "Premier League" OR UEFA)

For a match page, include both teams and the competition:

("Arsenal" AND "Liverpool") AND (football OR "Premier League")

Do not rely only on category=sports. Retrieve a slightly broader candidate set, then rank or filter it using known team, competition, player, and venue aliases.

Normalize the response before building the UI

Each provider uses different field names, but the website should depend on one internal shape:

{
  "id": "provider:article-id",
  "title": "Example headline",
  "summary": "Short provider-supplied description",
  "url": "https://publisher.example/article",
  "image_url": null,
  "source_name": "Publisher",
  "published_at": "2026-09-05T12:00:00Z",
  "language": "en",
  "provider": "example"
}

Keeping a provider adapter between the API response and this model makes it possible to change suppliers without rewriting every team and match page.

It also creates one place to implement:

Canonical URL normalization
Duplicate-title detection
Missing-image fallbacks
UTC timestamp parsing
Source attribution
Provider-specific cache rules

A note on article images and full text

An image URL in an API response is not automatically a license to copy or permanently host that image. The same applies to full article content.

For a football live score site, the safest default product is often:

Display the headline.
Display only the summary or thumbnail allowed by the provider's terms.
Credit the publisher.
Link directly to the original article.
Store only what the applicable agreement permits.

Before launch, review both the API provider's terms and the underlying publisher rights. This is a product requirement, not a detail to postpone until after integration.

Which one would I choose?

There is no honest overall winner without testing live result relevance and confirming the intended license.

Based on the public documentation alone:

Currents has the most interesting free-tier shape for a fresh, lightweight headline feed.
NewsData.io is attractive for multilingual discovery and limited commercial metadata use, if a 12-hour delay is acceptable.
The News API has the lowest displayed paid entry price, but I would clarify its usage rights first.
GNews has a clean query language for testing football search logic.
News API offers mature search controls but has the largest visible jump to production pricing.
The Guardian is the strongest option when editorial consistency matters more than source breadth.
Mediastack is easy to understand, although its free quota is an evaluation allowance rather than a usable site quota.

My practical shortlist for a prototype would be Currents, GNews, NewsData.io, and The Guardian. Before choosing one for production, I would run the same team-and-competition query set against each candidate, measure freshness and duplicates for at least seven days, and obtain explicit confirmation of the intended display rights.

That live comparison is a separate benchmark. This survey answers the question that comes first: which APIs are credible enough to test?

Next: weather APIs for match-day context

Part 2 will review weather APIs from the same public-apis repository. The goal is not to turn a score site into a weather app. It is to determine whether temperature, rain, wind, and historical match-day conditions can be added reliably without introducing an expensive or fragile dependency.

No news API provider sponsored or reviewed this article before publication.

AI disclosure: AI was used to assist with research organization and English editing. The linked official sources were checked before publication.

How I Track Anonymous-to-Signed-In User Journeys Without Third-Party Cookies

Leo Marsh — Thu, 03 Sep 2026 10:38:47 +0000

Most analytics tools can tell you that someone visited /pricing and that someone else created an account.

The useful question is whether they were the same person.

I wanted to answer questinos like these in a Laravel application:

Which landing page led to a real signup?
Did the visitor read the documentation before registering?
Was the first visit from search, a referral, or a campaign?
Which pages appaer in successful journeys?

I did not need cross-site tracking, advertising profiles, or a full recording of everything a visitor did. I also did not want a third-party analytics script controlling the data model.

So I built a small first-party journey tracker. Public pages send a deliberately limited page-view beacon. When the visitor later signs in, the application links the recent anonymous journey to the authenticated account.

This article explains the design, the parts I intentionally left out, and one important warning: not using cookies does not make analytics consent-free or automatically privacy-compliant.

The model: two random IDs

The browser keeps two opaque identifiers:

visitor_id  -> persists between visits
session_id  -> lasts for the current browser session

The visitor ID lives in localStorage. The session ID lives in sessionStorage.

Neither contains an email address, database ID, IP address, or encoded user information. They are simply random strings used to join events.

Here is a simplified version:

function randomId() {
  return crypto.randomUUID().replaceAll('-', '').slice(0, 24);
}

function storedId(storage, key) {
  let value = storage.getItem(key);

  if (!/^[a-z0-9]{24}$/.test(value || '')) {
    value = randomId();
    storage.setItem(key, value);
  }

  return value;
}

const existingSession = sessionStorage.getItem('journey_session');
const visitorId = storedId(localStorage, 'journey_visitor');
const sessionId = storedId(sessionStorage, 'journey_session');
const isEntry = existingSession === null;

localStorage lets the browser recognize a later visit without adding a cookie to every HTTP request. sessionStorage gives each browsing session a separate boundary.

That distinction matters. A person may first arrive from search, return from a newsletter a week later, and finally register. I want both the first-touch source and the most recent acquisition source, not one value constantly overwriting the other.

Send less data than you can

The browser knows far more than this system needs. The easiest way to reduce privacy and security risk is not to collect unnecessary fields in the first place.

My page-view payload contains:

The two random IDs
The page path and route name
The page title
Whether this is the first view in the session
The external referrer host and path
An allowlist of standard UTM parameters

It does not contain:

IP addresses stored by the application
Full user-agent strings
Browser fingerprints
Full URLs with arbitrary query strings
Email addresses or account details on anonymous requests

The query-string rule is particularly important. URLs often contain password-reset tokens, checkout session IDs, email addresses, search terms, and other values that should never be copied into an analytics table by accident.

Instead of sending location.href, I send location.pathname and explicitly select the campaign parameters I understand:

const query = new URLSearchParams(location.search);
const data = new FormData();

data.append('v', visitorId);
data.append('s', sessionId);
data.append('e', isEntry ? '1' : '0');
data.append('p', location.pathname);
data.append('t', document.title);
data.append('us', query.get('utm_source') || '');
data.append('um', query.get('utm_medium') || '');
data.append('uc', query.get('utm_campaign') || '');

if (document.referrer) {
  const referrer = new URL(document.referrer);
  data.append('rh', referrer.hostname);
  data.append('rp', referrer.pathname);
}

navigator.sendBeacon('/analytics/hit', data);

sendBeacon() works well here because the browser can transmit the small payload without delaying navigation. The endpoint returns 204 No Content and never needs to render anything.

Keep public page views stateless

My public marketing pages are edge-cacheable. Creating a Laravel session for every anonymous page view would add a Set-Cookie header and make that caching model harder to reason about.

The page-view endpoint therefore sits outside the session middleware group. It accepts the random browser identifiers but does not start a Laravel session.

Route::post('/analytics/hit', AnalyticsHitController::class)
    ->middleware('throttle:analytics')
    ->name('analytics.hit');

The route is rate-limited independently from login and contact forms. Analytics traffic should not consume a visitor's allowance for an unrelated feature.

The server validates every field even though the script generated it:

private function validId(string $id): bool
{
    return preg_match('/^[a-z0-9]{24}$/', $id) === 1;
}

private function cleanPath(string $value): string
{
    $withoutFragment = explode('#', trim($value), 2)[0];
    $path = explode('?', $withoutFragment, 2)[0];

    return mb_substr(
        str_starts_with($path, '/') ? $path : '/',
        0,
        191,
    );
}

Client-side filtering is a convenience. Server-side filtering is the boundary.

I also normalize referrer hosts, reject malformed values, cap string lengths, and treat redirects from authentication and payment providers as part of the existing journey rather than a new acquisition.

Two tables are enough

The first table stores one row per random visitor:

Schema::create('analytics_visitors', function (Blueprint $table) {
    $table->id();
    $table->char('visitor_id', 24)->unique();
    $table->foreignId('user_id')->nullable()->constrained()->nullOnDelete();
    $table->timestamp('first_seen_at');
    $table->timestamp('last_seen_at');

    $table->string('first_landing_path', 191)->nullable();
    $table->string('first_source', 96)->nullable();
    $table->string('first_medium', 48)->nullable();

    $table->timestamp('last_touch_at')->nullable();
    $table->string('last_landing_path', 191)->nullable();
    $table->string('last_source', 96)->nullable();
    $table->string('last_medium', 48)->nullable();
});

The second table is the event stream:

Schema::create('analytics_page_views', function (Blueprint $table) {
    $table->id();
    $table->char('visitor_id', 24);
    $table->char('session_id', 24);
    $table->foreignId('user_id')->nullable()->constrained()->nullOnDelete();
    $table->string('path', 191);
    $table->string('route', 96)->nullable();
    $table->boolean('is_entry')->default(false);
    $table->string('source', 96)->nullable();
    $table->string('medium', 48)->nullable();
    $table->string('campaign', 191)->nullable();
    $table->timestamp('viewed_at');

    $table->index(['visitor_id', 'viewed_at']);
    $table->index(['session_id', 'viewed_at']);
    $table->index(['user_id', 'viewed_at']);
});

The visitor row makes acquisition reports cheap. The page-view rows preserve the actual sequence.

I keep first touch and last touch separate. First touch answers "How did this person originally find the site?" Last touch answers "What brought them back before conversion?" Mixing the two produces confident-looking reports that answer neither question well.

Link the journey only after authentication

Anonymous page views keep user_id as null. An authenticated page includes a second beacon to a session-protected route:

Route::post('/analytics/identify', AnalyticsIdentifyController::class)
    ->middleware('auth')
    ->name('analytics.identify');

The browser sends the same visitor and session IDs, plus the normal CSRF token. The server gets the account from the authenticated Laravel session. It never accepts a user ID supplied by JavaScript.

DB::transaction(function () use ($request, $visitorId, $sessionId) {
    $now = now('UTC');
    $userId = $request->user()->id;

    DB::table('analytics_visitors')
        ->where('visitor_id', $visitorId)
        ->update([
            'user_id' => $userId,
            'last_seen_at' => $now,
        ]);

    DB::table('analytics_page_views')
        ->where('visitor_id', $visitorId)
        ->whereNull('user_id')
        ->where('viewed_at', '>=', $now->copy()->subDays(30))
        ->update(['user_id' => $userId]);

    DB::table('analytics_page_views')
        ->where('visitor_id', $visitorId)
        ->where('session_id', $sessionId)
        ->update(['user_id' => $userId]);
});

The 30-day boundary is deliberate. A permanent visitor ID on a shared computer is weak evidence that activity from six months ago belongs to the person signing in today.

Even within 30 days, this association is best-effort attribution, not identity proof. I would never use it for authorization, fraud decisions, security alerts, or anything that materially affects a person.

For a product with frequent shared-device use, I would avoid retroactive visitor-level linking entirely or introduce an explicit visitor_user_links table with time ranges. The data model should admit uncertainty rather than hide it.

Handle race conditions explicitly

The identify request and the first page-view beacon can arrive in either order.

If identification arrives first, the visitor row may exist before its acquisition fields are populated. If the page view arrives first, it initially has no user ID.

The two endpoints therefore need to be idempotent:

Both may create the visitor row with insertOrIgnore.
The hit endpoint fills first-touch fields only when they are still empty.
The identify endpoint backfills recent anonymous views.
New page views copy the user ID already associated with the visitor.
Updates run inside transactions where ordering matters.

This is the kind of race that almost never appears in manual testing and eventually appears in production.

Retention is part of the feature

Analytics tables quietly become permanent archives unless deletion is designed from the start.

I use a scheduled task to delete old page views and remove stale anonymous visitor rows:

Schedule::call(function () {
    $cutoff = now('UTC')->subDays(400);

    DB::table('analytics_page_views')
        ->where('viewed_at', '<', $cutoff)
        ->delete();

    DB::table('analytics_visitors')
        ->whereNull('user_id')
        ->where('last_seen_at', '<', $cutoff)
        ->delete();
})->daily();

The correct duration depends on the product and the questions the data is meant to answer. The important part is choosing a duration rather than inheriting "forever" as an accidental default.

Deletion and access workflows should also account for journey data once it has been associated with a user.

Cookie-free does not mean consent-free

This architecture avoids third-party cookies and third-party analytics scripts. It does not avoid browser storage: localStorage and sessionStorage are storage technologies too.

Rules vary by jurisdiction and purpose. For example, the UK Information Commissioner's Office states that storage-and-access rules can apply to web storage, including localStorage, whether it is used in a first-party or third-party context.

Reference: ICO guidance on storage and access technologies

So "we do not use cookies" is not a legal strategy. Document what is stored, why it is stored, how long it lasts, whether consent is required, and how a person can exercise applicable choices and rights. Get advice appropriate to the regions you serve.

Privacy-conscious engineering is not about finding a different browser API and declaring victory. It is about purpose limitation, data minimization, retention, access control, and honest communication.

What this small system gives me

With two identifiers, two tables, and two endpoints, I can reconstruct a journey like this:

organic search
  -> landing page
  -> pricing
  -> documentation
  -> sign in
  -> dashboard

I can connect acquisition to real product outcomes without sending browsing data to an advertising network or copying sensitive query strings into a generic analytics platform.

The system is intentionally boring. It does not record the mouse, fingerprint the browser, or guess who somebody is across devices. It collects enough information to answer a small set of product questions and stops there.

That constraint is the feature.

Disclosure: This article was written with AI assistance and edited from a real Laravel implementation.

The first thing I check before trusting any dataset

Leo Marsh — Sun, 30 Aug 2026 07:42:02 +0000

Every dataset I've ever received came with a description. Almost none of them matched the data.

Not because anyone was lying. The person who wrote the README usually described the dataset as it was supposed to be, or as it was six months ago. The data itself has been quietly drifting since then.

So before I compute a single mean, I run the same short ritual. It takes five minutes and has saved me from shipping wrong conclusions more times than I can count.

1. Count the nulls, then count the fake nulls

df.isna().sum() is the obvious step. The less obvious one is looking for values that mean null but aren't encoded as null:


python
suspects = ["", " ", "-", "N/A", "NA", "null", "None", "0", "-1", "9999"]
for col in df.select_dtypes("object"):
    hits = df[col].isin(suspects).sum()
    if hits:
        print(f"{col}: {hits} suspicious values")

A column with 0% nulls and 30% dashes is a 30%-null column. The mean you'd compute on it is fiction.

2. Look at the distribution, not the summary

df.describe() tells you the mean is 42. It does not tell you that half the rows are exactly 0 and the other half are around 84. Those are very different datasets with the same summary statistics.

df["value"].value_counts().head(10)
df["value"].plot.hist(bins=50)

The value_counts() call is the underrated one. If a continuous column has a single value appearing thousands of times, that value is almost always a default, a cap, or a placeholder — not a measurement.

3. Check the time column against your assumptions

If there's a timestamp, I always ask three questions:

- What timezone? The README says UTC. Is it? Check whether "daily" events cluster around midnight or around 8am — that tells you more than the docs.
- Is it complete? Group by day and count rows. Gaps and sudden drops usually mean an ingestion failure, not a real-world quiet day.
- Is it monotonic where it should be? created_at should never be later than updated_at. Yet it often is.

daily = df.groupby(df["ts"].dt.date).size()
print(daily.describe())
print(daily[daily < daily.median() * 0.5])  # suspiciously thin days

Why this matters

None of this is sophisticated. That's the point. The expensive mistakes in analysis rarely come from choosing the wrong model — they come from feeding a correct model data that doesn't mean what you think it means.

Five minutes of paranoia up front is much cheaper than explaining to someone why last month's numbers were wrong.

What's your first check when a new dataset lands on your desk? I'd genuinely like to add to this list.