Steam Review Mix Change Review

Compare the observed vote mix in an authorized export of recommendation records from one Steam game. The Actor counts supplied positive and negative recommendations for 14 completed UTC days, then compares the first seven days with the last seven days. It outputs aggregates only.

The Actor does no Steam requests, scraping, API-key access or upstream Actor runs. Bring your own authorized records. Do not combine different games, snapshots or differently filtered populations in one input. A caller-declared label is not source verification.

Try the original demo

{"mode":"demo"}

This exact input is the Console prefill, API example and sample. The omitted-input default resolves to the same original synthetic fixture: 28 self-created recommendation-shaped records over September17–30,2026. The first period contains12 positive and2 negative votes; the recent period contains2 positive and12 negative votes. Negative share changes from2/14 to12/14, a rise of approximately71.428571 percentage points. The demo works independently of today's date and has no custom report event. Platform startup can still apply. Altered demo records, dates or labels are rejected; use review mode for custom data.

The fixture and custom example were created for this project, with no Steam records or review text. Their permission is described in LICENSE-DEMO.txt.

Review supplied records

{
  "mode": "review",
  "asOfDate": "2026-09-30",
  "dataRightsConfirmed": true,
  "sourceContext": "Caller-declared English-language export",
  "reviews": [
    {"recommendationid":"example-1","timestamp_created":1789646400,"voted_up":true}
  ]
}

The single-record illustration above is insufficient for a paid comparison. samples/custom-input.json contains the complete original28-record owned example for a useful custom run.

Input fields:

• mode: demo (default) or review.
• reviews: required explicit array in review mode, at most5000 records. Entire JSON input must fit1MiB measured as UTF-8. Each useful record needs nonempty string recommendationid, integer Unix UTC seconds timestamp_created from0 through253402300799, and boolean voted_up. IDs are exact strings; no casefolding, trimming, number conversion or aliases. Other record fields are ignored.
• asOfDate: required real YYYY-MM-DD in review mode. It is the inclusive final date, and its entire UTC day must already have elapsed. The window is the14 days from00:00:00 on date minus13 days through23:59:59 on the final date. Baseline is the first7; recent is the last7. Earliest allowed final date is1970-01-14. Current UTC day and future dates are rejected.
• dataRightsConfirmed: must be exactlytrue in review mode. Set it only when authorized to process the input. Authorization is caller-declared, not independently verified.
• sourceContext: optional single-line capture/filter label of1..200 characters. Include no reviewer identifiers, personal information or review text. It appears only as caller-declared and unverified. It does not establish capture time, filtering or completeness.

Unknown root fields are rejected. A typo cannot fall through to a paid default.

What the report means

REPORT.json and the single default Dataset item contain the same packet. It includes14 UTC daily observed positive/negative counts, two fixed-period counts and nullable negative shares, signed recent-minus-baseline percentage-point difference, absolute difference and the20pp threshold. A comparison is useful only if each period has at least10 resolved observed reviews. A valid no-change result is useful. When either period is insufficient, thresholdMet isnull, not a causal verdict.

Negative share is observedNegative / (observedPositive + observedNegative), in0..1. Difference is (recent share - baseline share) *100, in percentage points. The20pp boundary uses exact integer cross multiplication; negative and positive changes both qualify by absolute size. A zero denominator producesnull share and delta.

Exact duplicate IDs with equal timestamp and vote count once, even if ignored source fields differ. If one ID has conflicting timestamp or vote values, the entire input produces a nonuseful invalid diagnostic. Missing/unusable IDs are excluded and counted. Missing, fractional, out-of-range or nonnumeric timestamps are unresolved. Nonboolean votes remain unresolved, never converted to negative. Valid dated rows outside the window are excluded and counted. Daily unresolvedVoteRows include valid in-window timestamps with unknown votes. Timestamp/vote counters apply to distinct usable IDs; invalidIDRows counts excluded raw rows. Coverage counters overlap where a row has both invalid timestamp and invalid vote; duplicateRowsExcluded is a separate raw-row count.

Daily zeros mean zero resolved supplied observations for that day. The report keeps all-source day totals, capture time, filters and population completeness unknown. A filtered export cannot establish population-wide vote changes. The Actor does not infer review bombing, coordination, fraud, game quality, viral reach or causes. There is no review-text sentiment analysis, reviewer profiling or statistical significance claim.

No supplied recommendation ID, author field, review text or row-level source record enters the report, Dataset or checkpoint. The checkpoint retains only the aggregate packet and hashes. Caller-declared sourceContext is the sole optional input label copied to output.

Price and output access

The proposed platform event steam_review_mix_review_completed costs$0.10 per useful custom report, at most one event per run. The startup event is$0.00005, separate from this custom event. Dataset item fee is0. Native configuration and billing acceptance require separate validation before publication.

Original demo, invalid input, insufficient/all-unknown data and unfunded diagnostics have0 custom events. A useful comparison that does not cross the20pp threshold still costs one event. Local non-PPE use is explicitlylocal_unpriced; this is not proof of platform billing.

Before any useful report facts enter Dataset, KVS or checkpoint, capacity must fund the full report event after startup and prior fees. Integer micro-USD arithmetic rejects subunit/fractional shortfalls. Budget0 or below-unit capacity returns a diagnostic with no useful day or period facts.

REPORT.json and Dataset are saved and read back identically before charging. Their immutable billing metadata is prechargepending; CHECKPOINT is the authoritative final receipt (confirmed, no_custom_fee, local_unpriced or charge_unknown). The packet does not pretend the fee was already confirmed when saved.

Same-run replay requires matching input/profile/report hashes. Completed replay verifies actual Dataset content and count. An absent REPORT can be restored from the exact bound checkpoint only when Dataset matches; a conflicting REPORT is never overwritten. Missing or mismatched Dataset fails honestly without append or another fee. A missing checkpoint with retained REPORT, Dataset or confirmed event count fails closed. Uncertain publication is reconciled only against the exact existing row. Unknown charge responses or a persisted charge-pending checkpoint are never retried blindly. Human/operator investigation may be needed to settle ambiguous billing, without rerunning the event.

Minimal local development

Node24.22.1 and pinned Apify SDK3.7.2 are the sole runtime stack. The lock retains the prior dependency graph except for the targeted basic-ftp 6.2.1 security override and the root Node engine metadata. The shipping runtime has no CSV, HTTP, HTML parser or AI dependency.

npm test runs built-in Node tests for literal vote arithmetic, source exclusions, privacy, pricing boundaries and replay failure cases. npm run sdk-test -- -RootSlotGranted -Case exact is a separate bounded SDK harness; use that flag only after an actual resource slot is granted. Before importing the SDK, it requires an absolute SKU-only CRAWLEE_STORAGE_DIR and checks the actual resolved base. It never purges shared/default storage. SDK tests use a local charge endpoint stub and do not prove native settled ledger or clean Docker execution.

The Actor uses256MiB memory,120-second timeout and no Standby. There is no dashboard, account database, alerting, acquisition or automatic scheduling. Formal independent QA/Market and native Input/Dataset/Actor Output recognition remain release gates; source preparation alone does not establish those passes.