The Linked/Not Linked classification is one of Apple's most scrutinised nutrition label fields. Declaring analytics as 'Data Not Linked to You' while calling setUserId(), identify(), or Sentry.setUser() misrepresents your data practices to every user who reads your App Store listing. Under GDPR Art.13 and Art.4(1), data is 'personal' the moment it can be linked to an identifiable person — calling setUserId() crosses that threshold and obligates accurate disclosure. Apple reviews this classification both during initial review and in response to user-filed reports.
Low because the mis-classification is a disclosure error rather than a data breach, but it creates cumulative legal and reputational risk when discovered during enforcement.
Audit every analytics call site for whether a user identifier is passed. Any call to setUserId(), identify(), alias(), Sentry.setUser(), or equivalent makes the corresponding data type 'Linked to You.'
If you want crash data classified as 'Not Linked to You', strip user IDs and emails before SDK initialisation:
// Do not pass user context to crash reporter
Sentry.init({ dsn: '...' }); // no setUser() call
Update your App Store nutrition labels and privacy policy to reflect the actual linkage. If users are logged in and analytics tracks their actions, the data is linked — no amount of internal anonymisation changes the classification if the link exists at ingestion.
ID: app-store-privacy-data.privacy-declarations.data-linked-classifications
Severity: low
What to look for: Count all relevant instances and enumerate each. Check whether collected data types are correctly classified as "linked to the user" vs. "not linked." Key signals: if the app has user accounts (any auth flow), analytics events sent with a user ID (setUserId(), identify(), alias(), custom user properties linking to an account) must be declared as "Linked to You"; crash reports sent without a user ID can be "Not Linked to You" — but check if the crash reporter SDK automatically includes device identifiers or session IDs; location data collected while a user is logged in is "Linked to You"; if Firebase Analytics setUserId() is called, all Firebase Analytics data becomes linked. Look for analytics.setUserId(), Amplitude.setUserId(), posthog.identify(), mixpanel.identify(), Sentry.setUser() — any of these makes the corresponding data type "Linked to You". In the privacy policy or store metadata, flag if analytics is declared as "Not Linked to You" while one of these calls exists.
Pass criteria: Data linked/not-linked classifications in store metadata or privacy policy are consistent with whether the app associates data with user accounts or identifiers. At least 1 implementation must be verified.
Fail criteria: Analytics, usage data, or device identifiers are declared as "Not Linked to You" while code calls setUserId() or equivalent, making them de facto linked.
Skip (N/A) when: App has no analytics or tracking SDKs; or no store metadata files are present for comparison.
Detail on fail: "Amplitude initialized with setUserId() in src/analytics/index.ts — usage data is linked to users, but privacy policy does not reflect this" or "Sentry.setUser() called with user email — crash data is linked to the user identity, not anonymous"
Remediation: Apple reviews linked/not-linked classification during nutrition label reviews and in response to user complaints.
Review the configuration in src/ or app/ directory for implementation patterns.