Treat SDK telemetry as opt-in, or at least as local only by default, and collect counters about SDK behavior rather than content from the customer's application. Document every field, offer a single switch that turns it off, and never send credentials, payloads or user identifiers.
Why customers care
An SDK runs inside someone else's product and often inside their regulated environment. Telemetry that leaves the process is a data flow their security and privacy teams must assess. Surprise telemetry is a common reason an SDK gets blocked in review.
The Go toolchain gives a useful public example. Its documentation says that by default telemetry data is kept only on the local computer, and users may opt in to uploading an approved subset. It documents three modes, local (the default), on and off, with commands to switch between them. Whatever you think of the design, it shows the pieces worth copying: a stated default, a single control, and a published list of what can be uploaded.
What is reasonable to collect
| Data | Verdict | Reason |
|---|---|---|
| SDK version, language and runtime version | Reasonable | Helps you plan deprecations |
| Count of calls per endpoint | Reasonable | Shows which features matter |
| Error codes and counts | Reasonable | Finds bugs, no content |
| Latency histograms | Reasonable | Performance work |
| Request and response bodies | Never | Customer data |
| API keys, tokens, headers | Never | Credentials |
| User IDs, emails, IP addresses of end users | Avoid | Personal data |
| Hostnames and file paths | Avoid | Can reveal internal systems |
Steps to design telemetry responsibly
- Write the purpose first. If a field does not answer a question you have, do not collect it.
- Choose the default. Off is simplest. Local only, as in the Go example, lets users inspect what would be sent before agreeing.
- Provide one documented switch, an environment variable and a config option, that disables all telemetry, and honour it before any network call.
- Aggregate in the SDK. Send counts and buckets, not individual events with timestamps that could be correlated.
- Publish the schema. List each field, its type and why you collect it, and version the list.
- Keep it off the critical path. Telemetry failures and timeouts must never slow or break a customer's request.
- Treat adding a field as a notable change and record it in the changelog, since it may require a customer to re-review.
Contracts and questionnaires
Customers will ask whether the SDK sends data to you. A one page answer helps: what is sent, when, how to disable it, where it is stored and for how long. The same page shortens security questionnaires. For related thinking on contract language, see the guidance on data use clauses.
Quick check
Is anonymous telemetry exempt from privacy review?
No. Customers still need to know what leaves their environment. Anonymous does not mean unreviewed, and identifiers can sometimes be combined to single someone out.
What if telemetry is down?
The SDK should drop the data silently and carry on. Telemetry must never block or fail a customer's API call.
Safeguard's SBOM and dependency scanning can show customers which SDK versions are deployed, and its compliance and evidence automation helps keep the data flow documentation current. See the free scan.
Sources
Last reviewed: 19 October 2026.
