Find your metrics and visualise them
What are you trying to achieve?
First, consider why you deployed your devices, aka your end goal. This is usually to deliver some service, some ongoing benefit. Like a little child, keep asking "why?" until you're sure you've discovered the final business benefit. For example, maybe you're deploying temperature sensors... to measure energy consumption... to reduce energy wastage.... to save money... to increase company profitability.
Now think about the customer for that benefit - this might literally be your customer, or your stakeholders (for internal projects). Stakeholders are generally people who have a financial interest in something, and/or a responsibility to deliver it.
Now think about what metrics that customer needs to see in order to realise the benefit. You might want several metrics which take you through the stages to the final business benefit. For example, starting with temperature we can integrate to get "degree days" then use a conversion faction to get energy consumption in, say, kWh/day, then use a price factor to measure actual cost of that energy.
Then you might think about further analytics on that metric. A single number might be a good overall metric for the company, but it's likely that you customers will need to see it broken down by, say, place and time, in order to see "best performers", "worst offenders", etc. - e.g. which rooms are consuming the most energy, at what times? Are the numbers for this month better than last month? Is the German site performing better than the UK one? Is it correlated with weather or time of year?
Finally, you can think about how to pull of this together into a coherent or dashboard. And indeed, perhaps different dashboards for different customers. CEOs tend to like the big picture - maps and charts showing overall performance and whether things are getting better or worse. Operations or Customer Support teams might need a more detailed, actionable view with lists of specific areas or even devices that need the most urgent action. And Product teams will want to be able to see an aggregate of customer interactions and metrics which proxy customer satisfaction.
As a bonus, consider whether you'll want to set up any business processes which react to situations. For example, if the heating has been left on in a room overnight, do you want to notify someone?
Understand your data
Broadly, there are three kinds of data associated with your device, and DevicePilot easily ingests them all. Let's illustrate with the humble temperature sensor:
- Application data: in this example, clearly temperature is the only application data
- Management data: from each sensor, we might also receive its software revision, hardware revision, battery level, signal strength, uptime...
- Metadata: the above data comes live from the device as telemetry, but sometimes a device doesn't know important information about itself, like their location or their owner, which is important for management. This data therefore might sit in a separate database.
Although useful, these three definitions are fuzzy and overlap:
- Temperature readings from a temperature sensor are definitely application data, but they can have management value too, because if you're not getting temperature readings or they're wildly strong then you need to take action to manage the device
- If the devices are static in your application then you'll probably need to consider location to be metadata. But if your devices are designed to be mobile and have GPS, and to deliver your service value you need to know where they are, then you'll probably consider location to be application data.
Classic databases such as SQL or time-series really struggle to merge all these kinds of data into useful analysis, because some of it is fast moving and some not, some is sent regularly and some not. They often require you to rigidly classify your data into these categories upfront, which is hard to do when you're building your service for the first time.
Luckily, DevicePilot was built with superpowers for IoT analytics. Correlate metadata against telemetry? Or even telemetry against telemetry? No problem. Measure performance-against-time? Still no problem. You can even define performance in terms of time (like if a device has a 15 minute heartbeat, define 'up' as 'heard from in the last hour') and then measure that performance over time (e.g. percentage of uptime of all devices over the past week).
Get going
The good news is that you can do all of this in less time than it's taken to talk about it!
We recommend the following steps:
- Integrate your data with DevicePilot
- Explore your data - understand exactly what you're getting from your devices
- Set up filters to identify important states, e.g. "too hot"
- Create KPIs which are metrics-over-time, e.g. "across our estate, how often have things been too hot over the past week?"
- Build dashboards to report your KPIs as maps, charts, lists, etc.
You can do this in just 15 minutes, as shown in our video here.
No really, get going
Use the form below to book a demo and a rep will get you started with your own dashboards today.
Further reading
Getting started with dashboards
How much data do you really need for effective device management?
