iF Totem Data Health
DB
loading…
Totems
Reporting
Data gap
Offline
Inactive

Integrity diagnostics

Is the data 100% intact? Every check runs live against the database. Each finding lists every affected case (devices, branches, cameras, values), the root cause and the fix — with ready-to-review SQL where it applies. The Excel export contains one sheet per finding with all cases.

Totems overview

ON/OFF · OTS · Viewers · Touch — last connection & last event per totem

Player and camera ids, latest connection and latest event per category, with date and time — green ≤2d, amber ≤7d, red older, gray never. ⇄ scrolls sideways · ⇅ scrolls down, header stays pinned

ON/OFF status

Connection state of every totem player and every VStands tablet in one place — ON means a heartbeat inside the online window. ON devices are listed first.

SLA

Official service-level reports — Totems covers totem availability and Analytics the analytics results. Each report shown is always the latest published version: browse it right here or download it as Excel.

Support tickets

Service desk activity for the fleet — incidents and requests, resolution rate and MTTR (mean time to resolution). Indicators count incidents only; every ticket ever seen is kept on record here even after it leaves the service desk's reporting window.

Incidents by category

Incidents by branch (top 15)

Tickets by status

Incidents opened per month

All tickets

VStands overview

Own category — tablets live outside totems by rule

Every VSTANDS tablet with its cms id and connection state, with date and time — green ≤2d, amber ≤7d, red older, gray never.

Unlinked devices

Players & cameras not linked to any totem (VStands excluded by rule)

Devices with no branch assigned: their cms id, type, connection state and last data. The ones flagged working — invisible have a recent heartbeat but show up on no dashboard — assign them a branch first.

Touch analytics

Totems with a player — touch history only, no OTS/viewers

Every totem with an assigned player and how much touch analytics it has produced: sessions and history interaction items. Sorted by volume; totems with 0 are the ones whose touch layer never reported.

Data cleaning

Cleanup backlog derived from the checks above — each task with its live case count, why it matters, and the SQL to review and run. P1 affects analytics correctness today; P2 is catalog consistency; P3 is cosmetic.

Status breakdown

Each totem has one detailed status; each status rolls up into one state. Click any row to list those totems.

ⓘ  How is status determined?
Status reads the player heartbeat and camera viewer activity only — not touches. Heartbeat is an exact timestamp, while Last touch and Last viewer come from separate analytics pipelines. Because those feeds upload on their own cadence, a totem that just went offline can still show a last-touch date after its final heartbeat — this is a reporting-lag artifact, not activity after disconnection (see the DQ signals section below).

All totems

BranchLicenceRetailerRegionStatus HeartbeatLast viewerLast touch

1 · Feed coverage & freshness

Volume, distinct branches, distinct units, date range and staleness per source feed.

2 · Field quality & integrity

Blank and malformed values inside the rows that did arrive.

Region values (metadata)

Device position field

3 · Orphan & mismatched records

Rows in the stats feeds whose unit has no record in the device metadata. Informational: camera ids without a device record are expected — cameras get unassigned and reassigned, and their history stays under the previous feed id.

4 · Device & camera gaps

Totems missing a camera

Totems missing a player

5 · DQ signals

Informational — pipeline-lag artifacts. They do not affect health status.

Touch dated after last heartbeat (pipeline lag)