Location dashboards & analytics: operational KPIs from position data, in the BI tool you already use
Location systems produce a constant stream of position events. The value is in a small set of operational KPIs that people check and act on. We define those KPIs with you, normalise the event data from your RTLS, RFID or IoT platform, and deliver it into the BI tool your business already uses. Vendor-neutral: we sell no hardware, no BI licences and no analytics platform.
What a location dashboard should show
Short answer: the few measures that change a decision on the floor, in the ward or in the yard, not a moving dot on a map. Which ones matter depends on the operation, but most programmes draw on the same six families:
| KPI | The question it answers | Built from |
|---|---|---|
| Utilisation | How much of the time are assets, vehicles, rooms or bays actually in use, and where is spare capacity hiding? | Zone presence and movement or in-use states, set against shifts and calendars |
| Dwell time | How long do items, orders, patients or trailers wait in each zone or process step, and where does waiting build up? | Zone enter and exit events, joined to order, job or visit records |
| Flow & bottlenecks | Which routes, transitions and handovers slow the process down, and when? | Zone-to-zone transitions, path counts and queue lengths over time |
| Search time | How long do people spend looking for tools, carts, equipment or stock that the system could locate? | Last-known location and find requests, compared with a baseline you measure before go-live |
| Safety & geofence events | Where and when do people and vehicles enter restricted zones, and what happened next? | Geofence breaches, proximity events and alarm acknowledgements |
| Cold chain & condition | Did temperature-sensitive goods stay within limits in every zone, and for how long were they exposed? | Sensor readings joined to location and custody, with excursion time per zone |
Each KPI should have a named owner and a stated decision it supports. If nobody can say what they would do differently when a number moves, it does not belong on the dashboard.
From position events to your BI tool
Raw location data is noisy, vendor-specific and far too granular for reporting. The work between the radio system and the report is where most dashboard projects succeed or fail.
- Capture: pull events from the location platform through the vendor's API, message stream or webhooks, or through middleware or an IoT platform that already aggregates several systems.
- Normalise: map every source into one event schema (what, where, when, how confident), translate vendor zone names into your own site hierarchy, remove duplicates and jitter, and align clocks with your business systems.
- Derive: turn positions into business events such as zone entry and exit, dwell, transitions and in-use states, then join them to orders, jobs, work orders or patient visits from your WMS, MES, ERP or EMR.
- Deliver: stream events for alerts and live views, or load them on a schedule into your data warehouse or lakehouse for reporting. Many sites need both, fed from the same model.
For the systems on the other side of the integration, see the integrations hub. For the design and build of the data pipeline itself, see build & integration.
Why vendor-neutral dashboards matter
Location technology changes faster than reporting does. A site may start with RFID portals, add UWB for vehicles and BLE for people, then replace one of them after a few years. If every report is built on one vendor's data structures, each of those changes means rebuilding the reports and losing comparable history.
- Swap the radio layer, keep the reports: a new system needs a new connector into the data model, not a new set of dashboards.
- Several technologies, one view: RFID reads, RTLS positions and sensor readings land in the same schema, so a KPI can draw on all of them.
- Your definitions, not the vendor's: utilisation or dwell is calculated the way your operation defines it, and the logic is documented.
- Your data, your history: the event history sits in your own platform and stays usable after a contract ends.
What we deliver
| Deliverable | What you get | Why it matters |
|---|---|---|
| 1 · KPI definition workshop | A short, agreed list of KPIs, each with a written definition, owner, target audience, refresh rate and the decision it supports | Stops the project from turning into a wall of charts nobody acts on |
| 2 · Data model | A vendor-neutral event schema and site hierarchy (site, building, zone, asset type), derived tables for dwell, transitions and utilisation, and data-quality rules | The layer that survives a change of radio vendor or BI tool |
| 3 · Dashboard build or specification | Dashboards built in your BI tool, or a detailed specification with mock-ups and metric logic for your own BI team to build | Fits your licensing, security model and in-house skills |
| 4 · Handover | Documentation of sources, transformations and metric logic, a walkthrough for report owners, and a list of known data-quality limits | Your team can run, change and trust the numbers without us |
We work alongside your BI, data and OT teams rather than around them. Where your team prefers to build, we stop at the data model and specification and review the result.
BI platforms Dylan has delivered location dashboards in
Our founder, Dylan Austin, has delivered location dashboards in each of the platforms below, including in roles before TRACIO was incorporated in May 2026. This is personal delivery experience. It is not a list of TRACIO client projects, and TRACIO is not a partner or reseller of any of these vendors.
- Microsoft Power BI
- Tableau
- Grafana
- Qlik
- Looker / Looker Studio
- Excel / SharePoint reporting
If your organisation reports in something else, the approach is the same: the data model and KPI definitions carry over, and the build follows your platform's conventions.
What we don't do
- We don't sell BI licences, location hardware or an analytics platform of our own, and we take no commission from anyone who does.
- We don't lock dashboards into a TRACIO-hosted environment. They are built in your tenant, or specified for your team to build.
- We don't publish KPI numbers before they have been checked against your own data. Where location data quality isn't good enough to report on, we say so and fix that first.
Engagement and fees
Dashboard work is scoped and priced up front, either on its own or as part of a wider programme. See How we work & fees for engagement models, or book a scoping call to talk through your data sources and reporting stack.
Frequently asked questions
Which BI tool should our location dashboards be built in?
Usually the one your business already reports in, so location KPIs sit next to the production, warehouse or clinical numbers people already trust. Our founder, Dylan Austin, has personally delivered location dashboards in Microsoft Power BI, Tableau, Grafana, Qlik, Looker / Looker Studio and Excel / SharePoint reporting, including before TRACIO was incorporated. If you have no standard yet, we compare options against your users, data platform and licensing before anything is built.
Why not just use the RTLS vendor's own dashboard?
The vendor console is the right place to monitor the location system itself: tags, anchors, batteries and coverage. It is a weaker place for business KPIs. It shows one vendor's data, defines metrics the vendor's way, and rarely joins cleanly with WMS, MES, ERP or EMR records. We usually keep the vendor console for system health and build the business KPIs in your BI tool.
Should location data reach our BI tool by streaming or in batches?
It depends on how quickly someone has to act. Geofence and safety alerts and live floor views need streaming. Utilisation, dwell trends and weekly operations reviews work well on scheduled batch loads into your data warehouse. Many sites use both: a streaming path for alerts and a batch path for reporting, fed from the same normalised event model.
What happens to our dashboards if we change RTLS or RFID vendor?
If the dashboards are built on a vendor-neutral data model, you replace the connector that maps the new system's events into that model, then re-validate the numbers. The KPI definitions, reports and history stay. That is the main reason we separate the radio layer from the reporting layer.
Do you sell BI licences or a TRACIO analytics platform?
No. We sell no BI licences, no location hardware and no platform of our own, and we take no vendor commissions. Dashboards and data models are built in your environment, or specified for your team to build, and you own them at handover.
Dylan Austin · Founder & principal advisor
Two decades in RTLS and RFID, including BLE, UWB, Wi‑Fi and industrial IoT, on both the vendor and the buyer side, from technical sales through implementation. Dylan founded TRACIO Limited in May 2026 to offer that experience independently, and leads every engagement personally.
Background and engagements before TRACIO → How the independence holds →
Last updated: