Note: I tried to make all images on this page reasonably high-resolution. You're free to use them and remix or republish them in order to talk about TelemetryDeck. To download an image, drag it to your desktop.
TelemetryDeck is a service that lets you track events, called Signals, in your applications. Through statistical analysis, developers who use TelemetryDeck can see live user numbers, know what features are used most, get retention statistics, all the things that a good analytics package should provide. This is all done in a way that
Insights are incredibly versatile: They can count either Signals or Users (or, soon, sessions). They can be restricted to specific signal types, such as "the app launched" or "the user did x". They can be filtered by their metadata, e.g. only show signals from iOS, or a specific app version.
They can show a breakdown of all available values for a given metadata key; this makes it easy to e.g. show what percentage of an app's users have a feature enabled or which platform the app is used on the most.
Time-wise, insights can group their signals by hour, day, week or month, allowing for either fine-grained view or a good overview.
Finally, all insights can display their data as a table, as bar or line chart, or as a donut or pie chart. All this configuration can be changed and experimented with on the fly and allows developers who use TelemetryDeck to deep dive into their data quickly and easily.
There are other analytics packages for apps out there, but none that protect the app users' privacy. Most of them are well-known to gobble up all the data they can find about users of apps they are embedded in. By contrast, TelemetryDeck is anonymized in such a way that developers won't even have to throw up one of these annoying consent dialogs, because the collected data is not connectable to privately identifiable information.
Privacy is cool, and there are other analytics packages who have privacy as their goal. Only they are either not aimed at apps but at websites, or are very hard to use efficiently. As someone who is both and app developer and a server developer with lots of experience in privacy-first design and Big Data, I'm ideally positioned to bring something new to the table here.
The target audience for TelemetryDeck is small-ish developers who work in Apple's ecosystem. Right now you need a Mac or an iPhone to retrieve the Insights calculated from your app's Signal data, even though Signals can be sent from any platform.
Really big companies who already have their own custom-built analytics are not going to be as interested, but I'm hoping to delight indie developers and small and medium firms looking for a light-weight and quality solution with something that is specifically tailored for them.
Hi, I'm Daniel Jilg, born 1984, from Augsburg, Germany. I've been an iOS Developer for over 10 years, with my first app being one of the first 100 or so apps in the iOS App Store. At the same time, I've been a server developer for even longer, with over 15 years of experience with Vapor, Django, Rails, PHP, and other server stacks.
I’m super into space. If you are too, check out my talks about computers in space and calculating orbits of planetary bodies using Swift 🚀
The two most notable privacy-related products whose development I've lead are Keepsafe Browser and Cliqz Mobile, which now lives on as Ghostery for iOS. During development of the latter, I've learned a lot about how to do proper analytics with completely anonymized data. This, combined with a previous open source project of mine, a service to manage A/B testing for apps, lead to the development of TelemetryDeck. Development started around August 2020 and continues to this day.
TelemetryDeck neither receives nor stores any personal data about the users of apps that include the TelemetryDeck client.
Developers can include a hashed custom user identifier or hashed
identifierForVendor to detect recurring users,
or they can just use a random session identifier to recognize sessions without distinguishing returning users.
While in Beta, TelemetryDeck is completely free of charge. In return, I'm hoping for many comments, feedback and discussion in the Slack that will shape the service's future.
Once the service is launched publicly, there will be usage tiers based on the number of Signals received by TelemetryDeck. Among these will be a free tier to try out TelemetryDeck and for small businesses, a tier for medium-sized apps, and a tier for large-scale apps. Paid plans can be paid monthly or yearly.
There will also be a special tier for organisations that joined TelemetryDeck during the beta period. This is a free tier, not publicly available, that grants a lot more free signals.
If the number of received Signals exceeds your organization's plan, you will be notified. No Signals will be lost. I'll try to make this as fair-use as possible with this rule: If you exceed the signals per month twice in a row, you'll be upgraded to a higher plan.
The beta period will work in three phases:
In Phase 1, interested developers need to submit their email address to request a beta invite and will be manually approved. This allows me to control the number of people using the service while I'm still tuning the server performance. Everyone who applies (except, say, Parler) will eventually get a beta invite though, usually a few hours to a day after requesting it.
Phase 2 will be an open beta, sometime in the spring of 2021. In this phase, everyone who is interested is free to register and try out TelemetryDeck for free of charge, regardless of the amount of Signals they send. This will make sure I find all remaining issues and kinks in the system, and ensure things run smoothly.
Phase 3 is the public launch, which I expect to be around mid- to late-2021. Way ahead of the launch, existing beta developers will be notified of the payment plans and if they fall within the bounds of the very generous plans for grandfathered-in early users.
I'll do my very best to ensure users are migrated smoothly between the phases, and to communicate clearly what will happen ahead of time, so developers won't be surprised by any changes.