BallparkTilbake

Feature Specification

Version 1.0 — 22 September 2026

This document defines the base functionality of the Ballpark platform under the license. It is the reference for the defect definition in the Platform Terms (§3.3) and the SLA (§3): behavior deviating from this appendix is a defect; functionality not described here is not. Client-specific deliverables produced as project work (campaign design, custom content, bespoke pages and game variants) are accepted at delivery under the project and are not part of this appendix.

Statements describe what functions do, verifiably. “Admin” means the platform’s admin application; “configured” means set up by the supplier; “self-service” means editable by client users in admin.

1. Campaign and calendar structure

  • A campaign contains a configurable number of games, each with a scheduled opening time.
  • Games open automatically at their scheduled time; no manual action or deployment is required. Games can also be opened manually from admin.
  • Unopened games display a locked state with their opening date in the participant view.
  • Campaign-level settings: name, description, participant identification mode, terms/privacy text references, leaderboard visibility, URL.
  • Campaigns and their games are publishable with scheduled or immediate start.

2. Games

  • Eight game engines: quiz, word scramble, memory, sorting (drag-and-drop), object matching, racing, slingshot, and luck (chance-based).
  • Each engine supports variants through configuration: number of rounds/questions, time limits, points awarded, game assets, intro text, instructions and intro image per game. Game content is configured by the supplier.
  • Post-game screen per game: score display and configurable content (offers, links, or return to front page).

3. Participant identification and registration

  • Two identification modes, selected per campaign:
    • Pseudonymous ID: participants are identified by a client-generated, campaign-scoped identifier delivered in the campaign URL. The platform holds no directly identifying personal data in this mode.
    • Contact-based signup: participants register with an email address (or phone number) and explicit consent.
  • Identifiers arriving by URL are removed from the address bar on landing and held in an httpOnly cookie bounded to the campaign period.
  • Consent capture at signup: one or more separate opt-in checkboxes per purpose, each stored with timestamp and the language version shown. Consent texts are managed per campaign in admin.
  • Registrations can be pushed to a client system via outbound webhook (§7).

4. Scoring and leaderboards

  • Scores are recorded per participant, per game and per campaign day, and aggregated per campaign.
  • Leaderboards display real-time rankings per game and for the overall campaign; visibility is configurable per campaign.

5. Prizes, offers and draws (self-service)

  • Client users create and update prizes and offers in admin: name, description, image, link URL, validity period — at any time, including while the campaign is live.
  • Prize draws are run from admin, per day and for the overall campaign: eligible participants are selected by configured criteria and winners drawn using cryptographically secure server-side randomness; the same applies to chance-based game outcomes. Draw results are stored with timestamp and the executing user.
  • Offer link clicks are tracked (§6).

6. Analytics

  • Admin dashboard showing, in near real time: visits, participation totals per campaign and per game, and offer click counts.
  • Participant and consent data (contact-based mode) is exportable from admin as CSV.

7. Integrations

  • SSO for admin users: SAML 2.0 and OIDC against the client’s identity provider, including IdP-initiated flow. Admin accounts exist by invitation or SSO provisioning only; no self-registration.
  • Outbound webhooks: select campaign events are delivered to client endpoints over HTTPS with OAuth2 client-credentials authentication and HMAC-signed payloads; guaranteed delivery via transactional outbox with retry; delivery log in admin. Events and endpoints configured per deployment.
  • Campaign domains: participant content served behind client-provided domains (CNAME); platform domains do not serve client campaign content.
  • The platform sends no email to participants and exposes no inbound integration endpoints.

8. Multilingual content

  • Participant-facing content (game content and intros, UI strings, consent texts) supports multiple languages per campaign; the participant view renders in the participant’s campaign language, with a configured fallback.

9. Administration and access

  • Role-based access per organisation: users see and manage only their own organisation’s campaigns; applies equally to partner users.
  • Significant admin operations (content changes, prizes, draws, user and access changes) are logged with user and timestamp.
  • Admin sessions use httpOnly cookies; admin authentication is passwordless (email one-time code or SSO).

10. Operation

  • Hosted on managed infrastructure operated by the supplier; monitored continuously with automatic alerting.
  • Automated database backups with point-in-time recovery.
  • Service levels per the Ballpark Platform SLA.