Tennis Match Dataset Quality Analyzer

Validate tennis match records you supply and receive dataset-quality findings plus descriptive historical player summaries. The Actor does not fetch records or predict performance, supply odds, recommend wagers or rank future skill.

This Actor is available on Apify and analyzes records you supply. Run another check for each new or corrected batch of match records before using it in a report or analysis.

On Apify's Free plan, a useful report costs $0.15, plus $0.005 per start event. At the default 512 MB memory, one useful report costs $0.155. Other plan tiers have different rates. Fixed demos and invalid-input diagnostics request no result event; a platform start charge can still apply. The examples below are synthetic and do not establish live source accuracy.

When Apify rejects input against the input schema, the Actor does not run. The diagnostics and partial reports below describe checks performed after the Actor starts.

Input

For the fixed synthetic demo, supply only { "demo": true }. It requests no result event; a platform start charge may still apply. Demo mode rejects supplied matches.

For your own records, omit demo or set it to false. This mode requests one report event on the platform when the report is useful. This copyable example contains a fictional synthetic match; demo: false selects the real analysis route even for fictional input:

{
  "demo": false,
  "matches": [
    {
      "namespace": "synthetic-example",
      "matchId": "demo-match",
      "playedOn": "2026-09-01",
      "winnerId": "demo-player-a",
      "loserId": "demo-player-b",
      "status": "completed",
      "surface": "hard",
      "bestOf": 3,
      "sets": [
        { "winnerGames": 6, "loserGames": 3 },
        { "winnerGames": 7, "loserGames": 5 }
      ]
    }
  ]
}

The only top-level fields are required matches and optional boolean demo. Real mode accepts 1–5000 rows and at most 2 MiB of serialized UTF-8 match-input JSON. Each row allows only these fields:

Field	Required	Accepted value
namespace	Yes	Nonempty source namespace, at most 100 characters.
matchId	Yes	Nonempty match ID, at most 100 characters; scoped to namespace.
playedOn	Yes	Proleptic Gregorian date in YYYY-MM-DD format, with a four-digit year 0000–9999.
winnerId, loserId	Yes	Nonempty distinct player IDs, each at most 100 characters.
status	Yes	completed, retired or walkover.
surface	Yes	hard, clay, grass, carpet or unknown.
bestOf	Yes	Integer 3 or 5.
sets	Yes	Array of 0–5 objects containing only integer winnerGames and loserGames, each 0–99; the scoring rules below further restrict validity.
tournamentId	No	String of at most 100 characters, including empty string; not null.

String lengths use JavaScript UTF-16 units. IDs and tournament IDs are checked for control characters and raw length, then trimmed. Required identifiers must remain nonempty and winner/loser IDs must differ after trimming. There is no case folding, fuzzy player matching or cross-provider merging. An omitted tournament ID and an explicitly empty ID remain distinct for duplicate comparison. Unknown fields or non-JSON values are invalid.

Supported scoring

Set scores use the overall match winner/loser orientation, so winnerGames may be lower in a set that the match winner lost. Standard completed tiebreak sets are 6–0 through 6–4, 7–5 or 7–6, in either orientation. Short sets, match tiebreaks and advantage-set formats are unsupported and are reported as issues instead of guessed valid.

A completed match must end immediately when the declared winner wins the best-of majority: two sets for best-of-three or three for best-of-five. Extra sets after the decision, incomplete matches and reversed overall winners are invalid.

A retired match may contain no sets, completed sets before retirement, or an unfinished final set consistent with standard scoring. Only the final set may be unfinished, and neither player may already have won the match. A walkover must contain zero sets. Retired and walkover records are counted separately and excluded from completed-match performance statistics.

Report and invalid rows

A useful report has schemaVersion: "1.0", reportType: "tennis_dataset_quality", status: "ok" or "partial", and useful: true.

• counts includes received, accepted, duplicates, invalid, completed, retired and walkover totals. received = accepted + duplicates + invalid always holds.
• acceptedMatchIds contains exact (namespace, matchId) identities. Player identities are also scoped to namespace; output is deterministically ordered.
• players includes completed-match sample sizes, wins, losses and win rates, plus separate bySurface buckets for hard, clay, grass, carpet and unknown. winRate is wins divided by the explicit completed-match count, or null at zero. Players present only in accepted retired/walkover records have zero completed matches and null rates.
• issues contains at most 100 issue codes and zero-based original rowIndexes; issuesTruncated indicates further findings. Counting continues after truncation.

Normalized exact duplicates count once. Property order alone does not create a conflict. Any malformed row with a readable identity quarantines the entire identity group, including valid siblings. Conflicting valid rows also quarantine their whole group; no last-write winner is selected. Independent valid identities remain usable. Accepted rows with invalid or duplicate rows produce partial status; all-invalid input produces an unbilled diagnostic with bounded counts, issue codes and indices, subject to the platform pricing checks below.

The report returns identifiers and aggregates without echoing full match rows or tournament IDs. It describes the supplied history and does not certify source rights, accuracy or representativeness. Input is unchanged. Malformed whole-input structure or size yields a bounded diagnostic, while individual malformed records remain visible in quality findings.

Actor integration and delivery

This published Actor uses Node 22 and Apify SDK 3.7.2. You can also run the same package locally for development. Install locked dependencies with npm ci, then use npm start with local Apify input storage. Local execution requests no result event. The package makes no source-provider calls and uses no credentials, proxies, child Actors or cross-run storage.

For the fixed synthetic example, supply only:

{ "demo": true }

Demo mode rejects extra snapshots or matches; supplied customer data is never processed as a free demo. Demo reports carry isDemo: true and dataProvenance: "fixed_synthetic_demo". For real mode supply the JSON input shown above, with optional demo: false; the report is marked isDemo: false, dataProvenance: "user_supplied". These labels describe the input origin, not verified source rights or accuracy.

A useful real input produces exactly one default Dataset report, including useful partial results. On the platform, that report requests one result-found event at the buyer's readable configured event price. Inspect the Actor's configured pricing before running and optionally set Max total charge sufficient to cover the report plus any platform start charge. A verified unset limit permits the one-report delivery; an explicit zero prevents a paid report. Unreadable or inconsistent run-limit settings fail safely before paid delivery. The runtime verifies pricing, exact remaining allowance and named counters before analysis and again before the paid write. Every platform Dataset write, including demos and diagnostics, requires consistent confirmed pay-per-event pricing and an absent or numeric-zero default Dataset item price. Free, pay-per-result, rental, unknown or inconsistent pricing models are unsupported and fail without a Dataset write. An empty event-price table alone does not prove that writing is free. Local development continues without result billing.

When the supported PPE/free-item pricing and transport checks pass, malformed or all-invalid input receives an unbilled diagnostic, retaining bounded counts, issue codes and row indices when available. It omits source IDs, field values and raw exception text. A known insufficient budget stops normally. Broken pricing, budget state, SDK operations or unexpected computation errors fail the run. “Unbilled” means no result event is requested; a platform start charge may already apply.

Download the complete nested report from the Dataset link in the run output. The Dataset is the delivery authority; there is no mandatory OUTPUT or cache write after paid delivery. The SDK writes the row before requesting its linked charge, so a paid row records billing.settlement: "unconfirmed_at_write". A successful run verifies the SDK receipt and an increase of exactly one in the named result-found counter. A failed push or unreadable receipt leaves delivery and settlement unknown: data may exist and a charge may have occurred. The Actor does not retry that write. For the pinned SDK, it sets the actual API HTTP client to zero retries and verifies that the default Dataset uses that same client before each write; an unreadable or different transport blocks delivery. Inspect that run's Dataset and charged event counts before another analysis.

Each new run is a new analysis and can incur a new result event. There is no cross-run idempotency promise. Automatic resurrection is unsupported: if the same run already records a result event, the runtime refuses another report and directs you to its existing Dataset. This check cannot resolve a previous Dataset write with a zero or unavailable result counter; do not automatically resurrect or rerun a failed delivery.

Local tests use synthetic fixtures and guarded SDK transports. The pure algorithms and SDK runtime have independent local acceptance; cloud release acceptance remains outstanding. Future release gates include an approved price decision, a bounded real cloud run with Dataset/event readback, real-source provenance, icon upload/readback and a complete Store listing. Local tests do not establish market demand, profitability or cloud acceptance.