In the last segment, the focus was on controlling the amount of data to send. This segment will point out to you on some data that can put you and your company in legal situations if you include them in your telemetry.
App telemetry, is focused on the state of the app. You include in the logs and events information about the context where something was happening in the app. Since of-course there is a user aspect to the app, you’ll find yourself including information about that user.
For network requests, you may include everything in the headers in the span attributes, and may consider adding the response body as a log to the span.
Almost all your engineers will need access to the telemetry so they can analyze the features they are working on.
There is a very high chance that the data is not hosted inside your company, and you’ll rely on 3rd party providers for storing it.
Each of those 3 points on their own may not present a concern. If you start seeing a problem here then that’s good, if not, its ok.
Lets say your app has a login, as part of your tracing implementation on your networking layer, you recorded the login network span, so now you have the user’s token, and user information.
Even if you are using OAuth, a network request to load the user profile will end up storing user data in the logs.
From the 2nd point, all your engineers will have access to this data.
From point 3, this data now exists with a third party. This puts you in liability from a security and legal perspective. If the provider’s data is compromised for any reason, your customers’ data will also be compromised.
Legally liable because “Did you take the user’s consent before sending the data to a 3rd party?”
If your app is in e-commerce, your problem will be tenfold as you might include some data related to payments, and this has security standards on its own. Of course I’m not referring to Credit card data. That’s out of the question, and you shouldn’t even have those accessible in your code to even include them in a regular print().
General Data Protection Regulation, aka GDPR is very strict about user’s data. This includes any information that can directly identify a user, such as their name, email, or phone number, as well as information that can indirectly identify them, such as a userID that could be used to look up personal details. For example, if your website includes the user ID in the URL query to open a profile, then userID can identify a person.
All this kind of data is Called PII as in Personally Identifiable Information.
It all starts from what can you include in your telemetry and what you can’t. Being mindful on what to add will save you a lot of trouble.
See forum comments
This content was released on Oct 24 2025. The official support period is 6-months
from this date.
In this segment you’ll cover some of the legal aspects that might influence the kind of telemetry you’re tracking, and what info you can’t include in the attributes.
Download course materials from Github
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress,
bookmark, personalise your learner profile and more!
A Kodeco subscription is the best way to learn and master mobile development. Learn iOS, Swift, Android, Kotlin, Flutter and Dart development and unlock our massive catalog of 50+ books and 4,000+ videos.