How Experience Management Control Works Behind the Scenes

The CMS is the control center—a centralized application (usually cloud-hosted) where content is uploaded, organized, scheduled, and distributed.

Key functions: - User interface for content creators and network managers - Media asset storage and organization - Scheduling engine for determining what plays when - API layer for integration with external systems - Analytics collection and reporting

The CMS doesn't typically store media files directly. Instead, it stores references to content in a Content Delivery Network (CDN) or object storage system optimized for large file distribution.

When you upload a video to an experience management platform, the CMS processes it (transcoding, validation, thumbnail generation), stores it in the CDN, and records metadata about the content. This metadata—not the file itself—travels through the control system.

Media players are the endpoints that connect to displays and render content. They range from purpose-built hardware (BrightSign, SPARC players) to commercial PCs to system-on-chip displays with embedded players.

Key functions: - Content playback (video, images, web, apps) - Local content caching - Schedule execution - Status reporting - Display output (HDMI, DisplayPort, SDI)

Players maintain persistent connections to the CMS to receive commands and report status. When connectivity is lost, properly designed players continue operating from cached content and schedules.

SPARC players are designed with edge computing capabilities—they can execute complex logic locally without constant cloud connectivity, making them more resilient than players dependent on cloud control.

CDNs are distributed networks of servers that deliver content efficiently to players worldwide.

How it works: 1. Content is uploaded to origin storage 2. CDN replicates content to edge servers globally 3. Players download from nearest edge server 4. Content is cached locally on the player

This architecture means a content update published in New York can reach players in Tokyo, London, and Sydney almost simultaneously—each downloading from a nearby server rather than crossing the planet.

CDNs also provide bandwidth efficiency. A 1GB video file uploaded once can be downloaded by 10,000 players without multiplying origin bandwidth by 10,000. The CDN absorbs that distribution load.

The operator clicks "Publish" in the CMS interface. This triggers a series of events:

1. Validation: The CMS verifies the content is complete and properly formatted 2. Schedule creation: A new schedule entry is created with content references and timing rules 3. Distribution planning: The CMS determines which players need the update based on targeting rules (all players, specific groups, specific locations, etc.)

This happens in milliseconds—no content files are transferred yet.

Players need to know an update is available. This happens via persistent connections:

WebSocket connections: Modern platforms maintain always-on connections between players and the CMS. When an update is published, the CMS pushes a notification immediately—no polling delay.

MQTT messaging: Some platforms use MQTT, a lightweight publish-subscribe protocol designed for IoT devices. Players subscribe to topics (their group, location, etc.) and receive messages when updates are published.

Fallback polling: If real-time connections fail, players fall back to periodic polling—checking every few minutes for updates. This is less efficient but ensures eventual consistency.

SPARC uses WebSocket connections with automatic reconnection and MQTT fallback, ensuring updates reach players within seconds under normal conditions and minutes if connectivity is degraded.

Upon receiving a schedule update, the player determines what new content is needed:

1. Manifest comparison: Player compares new schedule's content list against local cache 2. Download planning: Missing content is queued for download 3. CDN retrieval: Content downloads from nearest CDN edge server 4. Verification: Downloaded files are verified (checksum, format validation) 5. Cache update: Verified content is stored in local cache

This process runs in the background—current content continues playing uninterrupted. Only when all required content is cached locally does the player begin executing the new schedule.

Smart systems prioritize downloads based on when content is scheduled to play. Content needed in 5 minutes downloads before content needed in 5 hours.

With content cached locally, the player executes the schedule:

1. Time check: Player compares current time against schedule entries 2. Content selection: Active content for current timeslot is identified 3. Playback queue: Content is loaded into the playback engine's queue 4. Rendering: Media is decoded and rendered to the display output 5. Logging: Playback events are logged for proof-of-play reporting

The player continuously monitors the schedule, switching content automatically as timeslots change. Daypart transitions, campaign start/end dates, and override rules are all handled locally.

Live takeover allows operators to override scheduled content instantly:

1. Operator initiates takeover in CMS 2. Override command pushed to all affected players via WebSocket 3. Players immediately preempt current content 4. Override content (pre-cached or streaming) displays 5. When override ends, players resume scheduled programming

The entire sequence can complete in under 2 seconds on a well-designed platform. SPARC's live takeover capability is used by stadiums for instant replay, corporate networks for executive broadcasts, and emergency systems for life-safety messaging.

Critical environments integrate experience management with emergency alert systems:

CAP/IPAWS: Common Alerting Protocol messages from the Integrated Public Alert and Warning System can trigger automatic content overrides.

Fire/Life Safety: Integration with building management systems triggers evacuation messaging when alarms activate.

Weather: API integration with weather services can trigger weather-specific content or emergency warnings automatically.

These integrations require careful design to ensure reliability. SPARC supports multiple integration methods with fallback paths to ensure emergency messages always reach screens.

Players continuously report their status:

- Connectivity: Network connection state, latency, bandwidth - Hardware: CPU/memory usage, storage capacity, temperature - Playback: Current content, playback state, error counts - Display: Connected display status (via CEC/DDC when supported)

The CMS aggregates this telemetry into dashboards and alerting systems. Operators can see at a glance which players are online, what they're showing, and whether issues need attention.

SPARC's monitoring includes predictive analytics—identifying patterns that suggest impending hardware failure before screens go dark.

Proof of play provides auditable records of what content displayed, when, and where:

- Detailed logs of every content playback event - Timestamps, duration, player identification - Content verification (confirming correct content played) - Export capabilities for compliance and billing

This data is essential for advertising verification, regulatory compliance, and content effectiveness analysis. It answers the question: "Did my content actually play as scheduled?"

SPARC provides real-time proof of play data via API, enabling integration with advertising platforms and custom reporting systems.

When connectivity is lost, players must continue operating:

Local cache: All scheduled content is stored locally, enabling playback without cloud access.

Local scheduling: Schedule logic executes on the player, not in the cloud. The player knows what to play at what time without asking the CMS.

Automatic sync: When connectivity restores, players automatically sync with the CMS—downloading missed updates and uploading logged events.

SPARC players are designed for extended offline operation—days or weeks if necessary. Edge computing means sophisticated logic continues executing locally, not just simple playlist playback.

Enterprise deployments implement redundancy at multiple levels:

Cloud redundancy: CMS platforms run across multiple availability zones. SPARC's infrastructure automatically fails over between regions.

Player redundancy: Critical displays can have backup players that activate if the primary fails.

Content redundancy: Content is replicated across multiple storage locations.

Network redundancy: Professional installations often have backup network paths (cellular failover, dual ISPs).

The goal is eliminating single points of failure. Any component can fail without the network going dark.

Every SPARC capability is available via API. The web interface is just one client of these APIs. This enables:

- Deep integration with existing enterprise systems - Automated content workflows - Custom management interfaces for specific use cases - Programmatic network control at scale

Organizations can build experience into their business processes rather than treating it as a standalone silo.

SPARC players are intelligent edge devices, not dumb terminals:

- Complex scheduling logic runs locally - Data processing and transformation on the player - Integration with local data sources - Reduced dependency on cloud connectivity

This architecture enables capabilities that cloud-dependent systems cannot match—real-time responsiveness, reliable operation in low-connectivity environments, and scale without proportional cloud costs.

SPARC's synchronisation technology enables frame-accurate multi-display playback:

- Network-based sync without specialized hardware - Works across distributed locations - Adaptive algorithms for varying network conditions - Essential for immersive displays and synchronised experiences

Synchronisation is built into the core architecture, not bolted on as an afterthought.