LED display proof of play should help a buyer answer a specific question: which approved content was recorded as playing, on which player or screen, and during which period? Start by agreeing what the report measures. A schedule shows intent; a player log records a software event; an observation of the physical display provides different evidence. Do not treat these as interchangeable, and do not turn a play count into an audience count without a separate measurement method.
This guide is for retail marketing teams, venue owners, media operators and integrators specifying campaign reporting for an LED display installation. It focuses on the evidence and workflow to request before buying a content-management solution or launching a campaign. Reporting features depend on the selected platform, player and configuration; they are not an automatic capability of every LED screen.
Define the claim before choosing the report
Broadsign’s documentation describes digital proof of play as records of content playout on media players. Its documented campaign reports are based on player logs. This is a useful starting definition, but a buyer still needs to ask how the proposed system creates, collects and interprets those records.
Write the intended claim in plain language. For example: “The reporting system recorded the approved asset on the assigned player during the agreed campaign window.” Then identify any stronger claim that also matters, such as confirming the physical display was showing the correct image. Specify the additional evidence needed for that claim instead of assuming it is contained in the first report.
Agree what counts as a play. Ask whether the platform records a start, a completion, an elapsed duration or another event. Clarify treatment of interrupted videos, repeated still images, layout changes and content occupying only part of the screen. Use the vendor’s documented definitions in the acceptance plan, with any project-specific counting rule made explicit.
For a simple internal announcement, a modest verification process may be enough. A paid media campaign may need a more detailed record and review process. Define the requirement from the reporting decision and the consequences of missing evidence, not from the number of charts in a software demonstration.
Keep four kinds of evidence separate
The following distinctions help a procurement team ask better questions. The exact data available must be demonstrated with the proposed system.
On smaller screens, swipe horizontally to view all columns.
| Evidence | Useful question it answers | What not to infer from it alone |
|---|---|---|
| Approved schedule | What was intended to run and where? | That the scheduled content actually played |
| Player playout record | What event did the player record for an asset? | That the physical LED surface showed a correct image throughout |
| Player screenshot or rendered preview | What image was available at the capture point and time? | That downstream equipment and the physical screen were functioning continuously |
| Physical display observation | What was visibly present during the observation? | That the whole campaign ran correctly outside that interval |
A reporting design can combine these records, but it should retain their different meanings. Ask where a screenshot is captured in the signal chain. A software-rendered image is not a photograph of the physical LED surface. Conversely, a photograph of a working screen does not provide a complete history of playback events.
Keep network health separate as well. A player communicating with its server is useful operational information, but it is not the same claim as correct campaign delivery. The LED display remote monitoring checklist can help define the health signals that should accompany, rather than replace, the campaign record.
Map the player to the physical screen
Create a location register before the campaign starts. Connect the reporting identifier to the site, physical screen, orientation, active content area and responsible contact. If a player supplies multiple outputs or several screens show a shared feed, agree the reporting unit explicitly. One player event should not silently become several independently verified screen events.
Use stable identifiers in addition to convenient display names. A name such as “Entrance Screen” can become ambiguous when a second entrance opens or equipment is moved. Preserve the history when a player is replaced, and record when the new mapping becomes effective. Reports spanning that change should remain understandable.
Record the content identifier and revision, not only a filename that can be reused. Marketing should be able to distinguish the approved campaign asset from a revised version or a local-language variant. Include the relevant content area when a screen carries several messages at once. This prevents a record for one region being described as a full-screen takeover.
Confirm the visual layout before counting delivery. A file may be correctly identified while being cropped or scaled in an unintended way. Use the content resolution and aspect-ratio guide to connect asset approval with the actual LED canvas.
Specify the minimum usable reporting record
Ask for a sample export during evaluation. Review it with the person who will reconcile the campaign, not only with the software administrator. A report is useful when a reviewer can trace a result back to its definition, source and exceptions.
For this project, consider requesting the following fields where the platform supports them:
- Campaign identifier and approved asset revision.
- Player identifier and mapped physical screen or output.
- Event time and the time zone used by the report.
- Event definition, recorded duration and completion status where available.
- Campaign window and report filters.
- Time the data was received or last updated, where available.
- Missing-data, excluded-event and correction notes.
Treat this as a requirement list, not a claim that every platform exposes every field. If a field is absent, decide whether another record can answer the same question. Record the limitation in the proposal rather than discovering it after the first campaign report is due.
Xibo’s reporting documentation illustrates why configuration matters: its documentation includes controls for statistics collection and aggregation, as well as scheduled reporting. Buyers should therefore verify the enabled collection settings and report detail in their own proposed deployment. Naming a platform is not enough to establish how a particular installation will report.
Make time and missing data visible
Agree whether campaign windows are expressed in each site’s local time or a shared reference time. Include the time zone in exports and review how the platform handles clock changes where relevant. A report boundary should not depend on the reviewer’s browser settings without that behaviour being understood.
Ask the vendor to explain offline behaviour. Does the player continue the agreed content when disconnected? Are records retained locally, and under what documented limits? When connection returns, how are late records added to reports? Test the required behaviour in a controlled evaluation environment; do not assume every player uses the same mechanism.
Separate “no recorded play” from “no data received yet.” Neither should be silently converted into the other. Agree how long a report remains provisional, who reviews gaps and how corrected reports are identified. Keep the original and revised reporting periods traceable.
A simple reconciliation note might say: “Records for this screen are pending after a connection interruption; the campaign total is provisional.” That is more informative than presenting a clean total with an unexplained gap. It also avoids claiming that a lack of received data proves the physical screen was off.
Use physical spot checks for a clearly limited purpose
An observation of the actual screen can confirm content appearance at that time and location. Decide when such checks are useful: initial campaign launch, a revised asset, a changed content layout or an investigated discrepancy. Record the asset, location, observation time and what the reviewer could actually see.
Do not present a single photograph as proof of continuous operation. If continuous physical verification is a requirement, ask the proposed provider to explain its observation method, coverage, failure detection, blind spots and retained evidence. Evaluate that service separately from basic player logging.
Arrange any observation or recording through the venue’s approved process. Keep people and unrelated private information out of the evidence where practical, and agree access and retention with the responsible organisation. This article does not recommend installing cameras indiscriminately or collecting audience data to satisfy a playback requirement.
Treat image appearance and play counts as related but distinct acceptance checks. A reported play can still require investigation if the visible content is wrong. The incident report template provides a way to record observations and actions without prematurely assigning a cause.
Run an acceptance exercise before the first live campaign
Use a small set of unmistakable test assets and a documented schedule. Ask the integrator to demonstrate the ordinary path from approval to player delivery, playback record, export and review. Confirm that the report identifies the intended player, asset revision and time window.
Then agree a few controlled exception scenarios relevant to the project. These might include a content revision, an authorised schedule change, delayed data receipt or a player reassignment. The purpose is to see how the reporting workflow explains an exception, not merely whether the software produces a total.
For each scenario, record the expected evidence, actual result and any limitation. Avoid interrupting a production campaign or disconnecting operational equipment solely to conduct an unplanned test. Schedule the exercise with the responsible teams and the vendor’s supported method.
Include a report handover demonstration in the commissioning and handover checklist. An operator should be able to generate the agreed export, identify a provisional interval and find the person responsible for resolving a discrepancy. Save those steps with the system documentation.
Agree ownership, retention and commercial scope
Assign responsibility for content approval, location mapping, reporting configuration, evidence review and exception closure. These may belong to different organisations. Clarify whether the display supplier provides only hardware or whether software, reporting integration and continuing support are included in the offer.
Ask about report access, export formats, available history, archive arrangements and what happens when a licence or support service ends. Choose retention from the project’s review needs and applicable organisational requirements; do not assume an unlimited history is part of the base service.
Keep commercial decisions separate from technical records. A missing or disputed event may require investigation before the parties decide whether replacement exposure or another remedy is appropriate. The reporting tool should make the evidence clearer, not invent an agreement about how that evidence will be valued.
What to include in a proof-of-play enquiry
For an LED display proof-of-play requirement, send KSSdisplay the number and type of screens, planned sites, content formats, campaign windows and proposed content-management platform if one is already selected. Describe the reporting claim you need, the review frequency and whether physical-screen observations are also required.
Include a sample of the report your team expects and identify who will operate the system. Ask for a clear division between display hardware, player or CMS functionality, third-party services and integration work. Use the KSSdisplay project enquiry form to discuss those inputs and confirm the available scope, rather than assuming reporting functions from the screen specification alone.
Frequently asked questions
Is proof of play the same as proof that people saw the advert?
No. A playback record and an audience measurement answer different questions. Do not describe recorded plays as viewers, impressions or engagement unless a separate, clearly explained measurement method supports that claim.
Can a screenshot prove the physical LED screen was working?
That depends on where the image was captured. A player screenshot documents the image at its capture point, not necessarily the downstream display surface. A physical-screen observation is different evidence and is limited to its coverage and time.
Does every LED controller provide campaign reports?
No universal assumption is safe. Ask the supplier to identify the player, CMS or reporting service responsible for the function and demonstrate the required output with the proposed configuration.
What should a report show when records arrive late?
Use the agreed provisional and correction process. Identify the affected screen and interval, disclose incomplete data, and preserve a traceable revised report when additional records become available.
