Frequently asked questions

You can delete your analytics data at any time. For this, you delete your organization in TelemetryDeck. This deletes the namespace of your organization and stops all ingestion into it.

You can also delete single months of your data in Organization Settings. We cannot delete the data of one app, one user or one installation.

Please keep two things in mind:

• Parts of your analytics data can remain in low-level backups for up to 3 months.
• Aggregated numbers that went into our public survey currently cannot be separated from that data set.

We do not use your data for advertising, tracking, cross-app or cross-customer matching, or profiling. We also can not do this: The data is anonymized, so it is simply not suitable for these purposes.

We also do not sell personal data. We have no personally identifiable information of any kind about the users of your apps.

We do use aggregated data for our own analyses. You can see the results in our survey. We reserve the right to do more analyses of aggregated customer data in the future, and to make them available to selected partners. These analyses focus on device information, operating system versions and how common they are. You cannot opt out of this aggregated data set.

When you use one of our SDKs in your app, our servers store this data:

• An anonymized user ID. It stays the same for one app installation, but nobody can trace it back to a person.
• The action, for example "App launched" or "Settings opened". You as the app publisher define these actions.
• A timestamp of the action, rounded to the hour. The server keeps your event time if the event arrives within 24 hours. Older events get the time of arrival minus 24 hours.
• Device metadata, for example system version, app version, build number, App Store or TestFlight, and device type. You find the full list of default parameters in our docs.
• Additional metadata that you define, for example "Number of items in the database".

Our servers never store IP addresses. Not in the database, not in log files, and also not anywhere else.

Not yet, but you can delete data by month. Since October 27, 2026, you find a screen in Organization Settings for this. It deletes single months of your analytics data. By the end of 2026, we want to allow our customers to set the value for Cold Storage Retention by themselves. This will be a new organization-wide setting that says something along the lines of "delete all analytics data as soon as it is older than x months".

Additionally, we will refine our backup strategy, so that we no longer store raw ingested data forever. Raw ingested data is fantastic for recovery, but it is impossible to remove individual customers from that data set. So we will find a better way to back up our analytics data, namespace by namespace. Then we can also delete data from backups.

No. Our storage works per month, not per app or per user. You can delete single months of your analytics data in Organization Settings. You can also delete your whole organization, which will delete all its analytics data.

If you need a clean start for one app, create a new app with a new app ID.

The stored events contain no value that links back to a device or an installation. So an end-user cannot ask us to delete their events.

No. Our server salts your clientUser value with a secret and hashes it, and we expect senders to salt and has the clientUser on their side as well, making sure neither party can restore the original user identifier. Only TelemetryDeck knows the secret. So you cannot compute the stored value, and we do not offer a lookup.

This is the core privacy principle of TelemetryDeck: nobody can match a stored event to a person. If you add identifying information to your events, for example in a parameter, you undermine this principle. In that case, our data privacy guarantees are void.

If you need a property like a license status in your insights, send it as a parameter with your events. Make sure that the value identifies no person.

No. For events from our app SDKs and from the Ingest API, the server does not read the IP address. No country or location value is added.

Only Website Analytics uses the IP address for a moment. It sends its events to the /v2/w/ endpoint. There, the server derives a country and a daily changing hashed identifier. The IP address is then discarded. You cannot turn off the country lookup for Website Analytics.

We don’t store IP addresses in logs or elsewhere of course.

No, TelemetryDeck does not store IP addresses. Not in our database, not in log files, not in backups, and also not at our infrastructure providers.

For apps that use our SDKs or send data directly to the Ingest API, our servers do not look at the IP address at all.

Only for Website Analytics (the Web SDK) is the IP address used for a short moment, and for two things:

• A hashed user identifier. The IP address, the app ID, the user agent and a salt that changes daily are combined and hashed with SHA-256. The same visitor is recognized within one day on one website, but not across days or across websites.
• A rough country and continent. The country code, continent and EU membership are derived from the IP address.

After this, the IP address is discarded. It is never written anywhere.

More details you find in our Privacy FAQ and our Privacy Policy.

Yes. The DPA is part of our Terms of Service of March 6, 2026. It applies for as long as you use the service. You can read it at telemetrydeck.com/dpa. The German text at telemetrydeck.com/avv is binding. The English text is a convenience translation.

The DPA states that TelemetryDeck is not a processor under Art. 28 GDPR, because we process only anonymized data. On request, we can send you a signed copy.

Since April 2026, TelemetryDeck’s code and data run fully on cloud infrastructure from Hetzner. We use the Hetzner data centers in Falkenstein, Germany, and Helsinki, Finland.

So your data is processed in accordance with German and European data protection law, and it is stored exclusively on European soil.

Our privacy policy also lists data centers from other hosting providers and other countries. We only use those on request for enterprise customers with additional requirements.

Our terms allow the use in apps and services for children. In fact, TelemetryDeck is designed for apps in highly regulated industries, and apps for children are one of our core target groups.

We cannot give legal advice. We also cannot give a binding confirmation for Apple's Kids Category or Google Play Families. Please check these rules with your lawyer.

Especially for highly vulnerable groups, we’d like to add that it is your responsibility to make sure that you do not manually add any identifying information to the parameters of events that you send, because these are not automatically anonymized.

TelemetryDeck supports multi-platform integration! All TelemetryDeck Events are sent via HTTP POST request, so you can send them from a web page, or any other app for any platform. For websites we provide a single line of code so you can get started instantly, and our SDKs are super lightweight and help you send signals from the get-go.

We're providing SDKs for Swift, Kotlin, JavaScript, and more!

If you would like to see other client packages, open an issue or (if you want to be particularly awesome) maybe write one yourself and share it with us and the community? Here's a spec document to get you started.

The SDK code included in your app is licensed under a modified MIT License with a removed attribution clause. This means you can use it in any project without restriction, and you do not have to attribute it.

Yes. Write to support and name the app ID and the target organization.

The transfer moves only the app ID. The historical analytics data stays in the old organization. New events go to the new organization.

After the transfer, the app shows up in your views within 10 minutes. Event routing follows within 30 minutes, because of caching.

On the free plan, we process events in a round-robin style. New events show up between once an hour and once a day.

To see if events wait for processing, open Organization Settings → Namespace Status.

On paid plans, events show up in near real time.

Sometimes you’re not seeing events arrive in your dashboard. Here are some things you can check to find out what’s going on:

1. Test mode: Our SDKs try to detect your app being run inside a development environment and will automatically tag these events as Test Mode Events. To see those, switch to Test Mode in the TelemetryDeck Dashboard. If you’re not seeing production events, check if you need to disable Test Mode again.
2. Paid vs Free Plan: Only our paid plans show data in real time. If you have a free plan, you might need to wait up to a day for your events to be processed. We process data in a round-robin style for all our free customers.
3. On Device Caching: Our SDKs include a cache for outgoing events to prevent the device from using too much network and battery. This means events are going out in batches, and you might see events arrive later, especially if you have a low number of customers, or a low number of events being generated by your app.
4. App Updates: It might take a while for an update to your app being installed by your end users. Only then can they send any data to TelemetryDeck.
5. Real Time Data: Even if you are a paid customer, there might be occasional slowdowns on our indexing servers that process data into your namespace. You can check the processing status by navigating to Organization Settings → Namespace Status.

We recommend Ingest API v3. The rules below apply to v2 and v3. When you send events directly to the Ingest API, our server adds only a few fields:

• If the event has no sessionID, the server generates a new random sessionID for this event.
• If the event has no receivedAt property, the server sets it to the current date and time.
• If the event has no isTestMode property, the server sets it to "false".
• The server adds the property TelemetryDeck.API.Ingest.version with the value of the API version you used.

For these events, our server does not look at the IP address at all. So no country, continent or other location value is added. We use the IP address only for Website Analytics, which sends its events to the "/v2/w/" endpoint.

Yes. Events that you send directly to the Ingest API are treated the same way as events from our SDKs. The same security, deletion and contractual commitments apply.

One difference is important: Our SDKs salt and hash the clientUser value already on the device. Then our servers salt and hash it a second time, for complete anonymization. If you send events directly to the Ingest API, the on-device step is missing. So it is your responsibility that no identifying data gets into the clientUser property.

Yes. We recommend Ingest API v3. The required fields are appID, clientUser and type. The API returns a 422 error when a field is missing or wrong.

There are no rate limits. We still recommend that you send events in batches. Single requests keep the radio of the device busy and drain the battery. Our SDKs do this batching for you.

The ingest host nom.telemetrydeck.com is located in Helsinki, Finland.

A TelemetryDeck Event is the most basic building block in the TelemetryDeck analytics ecosystem. Every time an event happens in your app, you can send an event using the TelemetryManager.send(...) function.

Events have a type which is the name of the signal such as TelemetryDeck.Navigation.pathChanged, a user which is a String representation of a hashed user identifier, plus a parameters which are various metadata, such as TelemetryDeck.Device.operatingSystem, TelemetryDeck.RunContext.language, or custom metadata you want to deliver with each event.

Events are the raw data that is being interpreted by your analytics.

For sure! Contact us at info@telemetrydeck.com and we'll help you find the perfect solution for your needs!

You can upgrade your plan at any time, and we'll prorate the price difference. The system will also auto-upgrade you if you go over your included events too many times in a row.

That depends a lot on the number of users you have, the type of your app (websites are way less chatty), and how much data you're collecting. When you send a TelemetryDeck event every other line in your code, your usage will be higher than if you only send one at app launch.

A good starting point is Number of Usersｘ30. You can also play around with our Pricing Calculator for a better estimation.

Welcome to the analytics journey! Our recommendation is to start with the smallest paid plan and add only the most basic analytics. This will allow you to estimate your costs better.

If you use more data than is covered by the smallest plan, it will auto-upgrade after two months.

Even though TelemetryDeck’s paid plans include a max number of events per month, we won’t stop collecting data at that point, but you will be upgraded to a higher plan if you cross that threshold two months in a row.

However, to protect against runaway processes, very large spikes, and other unforeseen consequences, there are also restriction limits: if you send over 20 times the amount of events included in your paid plan, your account will stop collecting any data until the end of the month. Events sent to our APIs will be discarded in that mode and are not recoverable.

This is of course very drastic, so we’ll send multiple warning emails before you reach that point.

We recommend one TelemetryDeck App per codebase. This makes it easy for you to separate different concerns and dashboards so you're just analyzing the code that you want at one time.

Additional apps don't incur any extra costs because they are grouped under your Organization, and the Usage dashboard will show you which apps use the most of your included evens.

Congrats, you're featured on the App Store! If your spike is temporary, you'll probably run into your plan limit, and if you are way over your limit, we may decide to pause processing your data for a bit.

However, one single spike won't increase your costs. To make sure we're growing organically with you, we'll only upgrade your plan if you're over the limit two months in a row.

Also, talk to us, we'll find something.

We'll warn you at 80% and 100% usage via email, but events are still ingested. We'll upgrade your plan to the next fitting plan if this happens for two months in a row.

In TelemetryDeck plans, retention is the period of time where we keep your data actively loaded on our calculation servers to be ready for your queries. If you have 24 months of retention, you can display and query all data from 24 months ago to today.

Data outside this time period is not deleted, but it gets unloaded from our calculation servers and kept in cold storage, where it can be retrieved if the included retention time in your plan changes.

Personal access tokens are available on all paid plans. You need a token to run queries against the TelemetryDeck API.

On the free plan, upgrade first. Then the feature appears in your dashboard.

No, you will not lose data if you go from a more expensive to a cheaper or free plan. There are however two things to keep in mind: retention and restrictions.

Retention is how long we keep data on our live calculation servers so that you can run queries against it. If your plan has 24 months of retention, you can query any data that that time period. Data collected before that time is not gone, but it is not accessible to you. If you switch from a plan with 24 months to one with 3 months retention, you will lose access to a lot of your data. If you switch back to a paid plan, this data will be available to you again.

Restrictions are the maximum number of events your organization can receive on your account before the system will stop collecting data for you. On free plans, because there are no automatic upgrades, your account gets restricted immediately after you reach the included number of events, meaning that data collection is stopped and and incoming data is discarded. This data is actually lost and can’t be recovered, which is why we’ll warn you once you use up 80% of that budget.