Telemetry

Telemetry is a powerful feature that’s a core component of a  Application Monitoring service. If you’re wondering why telemetry should matter to you, then look no further – read on to learn more about telemetry, how it works, and why it matters.

Definition of Telemetry

Telemetry is the automatic recording and transmission of data from remote or inaccessible sources to an IT system in a different location for monitoring and analysis. Telemetry data may be relayed using radio, infrared, ultrasonic, GSM, satellite or cable, depending on the application (telemetry is not only used in software development, but also in meteorology, intelligence, medicine, and other fields).

In the software development world, telemetry can offer insights on which features end users use most, detection of bugs and issues, and offering better visibility into performance without the need to solicit feedback directly from users.

How Telemetry Works

In a general sense, telemetry works through sensors at the remote source which measures physical (such as precipitation, pressure or temperature) or electrical (such as current or voltage) data. This is converted to electrical voltages that are combined with timing data. They form a data stream that is transmitted over a wireless medium, wired or a combination of both.

At the remote receiver, the stream is disaggregated and the original data displayed or processed based on the user’s specifications.

In the context of software development, the concept of telemetry is often confused with logging. But logging is a tool used in the development process to diagnose errors and code flows, and it’s focused on the internal structure of a website, app, or another development project. Once a project is released, however, telemetry is what you’re looking for to enable automatic collection of data from real-world use. Telemetry is what makes it possible to collect all that raw data that becomes valuable, actionable analytics.

The following diagrams demonstrate some typical uses of Telemetry:

• MQ Telemetry Transport message containing energy usage data sent to service provider.
• MQ Telemetry sends CONTROL COMMANDS based on analysis of energy usage data.
• For more information, see the following use case: Telemetry use case: Home energy monitoring and control

• MQ Telemetry sends Health Data to your Hospital & Doctor.
• MQTT message alerts or feedback can be sent based on analysis of Health Data.
• For more information, see the following use case: Telemetry use case: Home patient monitoring

• A simple card transaction is sent to the bank’s server.
• MQ Telemetry identifies the one person from the thousands, alerting the customer that their card has been used.
• MQ Telemetry can use the simplest input of information, and locate that individual.

Benefits of Telemetry

The primary benefit of telemetry is the ability of an end user to monitor the state of an object or environment while physically far removed from it. Once you’ve shipped a product, you can’t be physically present, peering over the shoulders of thousands (or millions) of users as they engage with your product to find out what works, what’s easy, and what’s cumbersome. Thanks to telemetry, those insights can be delivered directly into a dashboard for you to analyze and act on.

Because telemetry provides insights into how well your product is working for your end users – as they use it – it’s an incredibly valuable tool for ongoing performance monitoring and management. Plus, you can use the data you’ve gathered from version 1.0 to drive improvements and prioritize updates for your release of version 2.0.

Challenges of Telemetry

Telemetry is clearly a fantastic technology, but it’s not without its challenges. The most prominent challenge – and a commonly occurring issue – is not with telemetry itself, but with your end users and their willingness to allow what some see as Big Brother-esque spying. In short, some users immediately turn it off when they notice it, meaning any data generated from their use of your product won’t be gathered or reported.

That means the experience of those users won’t be accounted for when it comes to planning your future roadmap, fixing bugs, or addressing other issues in your app. Although this isn’t necessarily a problem by itself, the issue is that users who tend to disallow these types of technologies can tend to fall into the more tech-savvy portion of your user base.  According to Jack Schofield, can result in the dumbing-down of software. Other users, on the other hand, take no notice to telemetry happening behind the scenes or simply ignore it if they do.

It’s a problem without a clear solution — and it doesn’t negate the overall power of telemetry for driving development — but one to keep in mind as you analyze your data.

Telemetry Tutorials and Additional Resources

For more information on telemetry and how to make it work for your development process, check out these resources and tutorials:

• Windows Azure: Telemetry Basics and Troubleshooting
• Instrumenting Your App for Telemetry and Analytics
• Software Project Telemetry
• Payload Services
• Telemetry Dashboard Documentation – Mozilla
• Building a Scalable Geolocation Telemetry System in the Cloud using the Maps API