iOS App Analytics Without Tracking: A Decision Guide
iOS app analytics can use a no-tracking declaration, though server events may count as collection; compare store reports, local counts, and campaign postbacks.
A no-tracking declaration can coexist with app measurement when the app’s practices meet Apple’s tracking definition
- A no-tracking declaration and a “Data Not Collected” disclosure answer different questions.
- App Store Connect reports store acquisition, app usage, sales, and subscriptions.
- On-device event counts stay on-device; events sent to a server can count as collected data when they remain accessible beyond real-time request service.
- SKAN can report campaign attribution through postbacks; Airbridge decodes mapped SKAN 4.0 values when its SDK and setup conditions are met.
iOS app analytics can answer different growth questions through store reports, product events, and campaign-attribution postbacks. Apple defines tracking by how data is linked or shared, while App Store privacy details separately cover data collection. That means an app can collect analytics data without using it for tracking, and a no-tracking approach can still involve an SDK or server-side data collection.
For a small subscription team, start with the question behind the dashboard. “Which store page turns into downloads?” belongs in App Store Connect. “Which paywall leads to a trial?” calls for product-event measurement. “Which campaign drove attributed installs?” fits a privacy-preserving campaign-attribution route such as SKAN, with reporting and integration requirements of its own.
“No tracking” and “no data collected” are separate answers
Apple’s definition of tracking focuses on linkage and use. It describes tracking as linking user or device data from your app with data from other companies’ apps, websites, or offline properties for targeted advertising or advertising measurement, and also includes sharing data with data brokers. ATT permission is required on iOS 14.5 or later when an app tracks users or accesses their device’s advertising identifier.
Apple’s separate App Privacy Details definitions define when data is collected. “Collect” means transmitting data off the device so the developer or a third-party partner can access it longer than needed to service that request in real time. A server-side analytics event may therefore count as collected data even when it stays tied only to your own app and never feeds cross-company advertising.
| Question | What you are checking | Example for a subscription app |
|---|---|---|
| Does this use count as tracking? | Whether app or device data is linked with outside-company data for targeted advertising or advertising measurement, or shared with a data broker. | Linking an app user’s activity with data from another company’s apps to target an ad falls within Apple’s tracking definition. |
| Does this count as data collection? | Whether data leaves the device and remains accessible to the app developer or a partner longer than the real-time request needs. | Sending a paywall-view event to your analytics server and retaining it for a funnel report is collection under Apple’s definition. |
| Is it local-only measurement? | Whether event information stays on the user’s device and is not transmitted off-device. | Counting paywall views locally to display a total inside a developer-only diagnostic screen keeps that event data on-device. |
The same event can be collected without being used for tracking. For example, a server may receive a trial-start event, associate it with an internal account, and report total trial starts to the product team. That is still a data-flow and disclosure question, even if the team uses it only to improve its own app and never combines it with outside-company data for ad targeting.
A third-party analytics SDK does not decide the answer by itself. The SDK’s actual behavior matters: the data types it reads, the information it sends, its recipients, the purposes applied to that data, and whether it links data across other companies’ services. Apple says developers must include the practices of third-party partners whose code they integrate when completing App Store privacy information.
What App Store Connect Analytics can answer
Apple’s App Store Connect Analytics dashboard reports store acquisition and app performance measures, including impressions, product-page views, downloads, redownloads, and conversion rate. These figures help answer whether people who see the listing visit its page and whether store exposure turns into downloads.
| Growth question | App Store Connect report that helps | What the result means |
|---|---|---|
| Are people finding the listing? | Impressions and product-page views | How often the app icon appeared in the App Store and how often the product page was accessed. |
| Does the store page convert? | Conversion rate, downloads, and pre-orders | Whether store impressions translate into downloads or pre-orders under Apple’s metric definitions. |
| Are people returning to the app? | Usage metrics such as sessions and active devices | The level of app use among the App Store users included in Apple’s usage reporting. |
| Are subscribers purchasing? | Sales and subscription metrics | Proceeds, in-app purchases, paying users, trial starts, renewals, conversion, and monthly recurring revenue metrics available for the app. |
| Is the app having stability issues? | Crash and usage metrics, with detailed reports in Xcode | Store-level crash counts and a route to more detailed crash reports for diagnosis. |
Apple’s App Store Connect performance metrics reference makes app metrics available after at least five first-time downloads or pre-orders. Its usage metric definitions require at least five active devices in the selected date range and base usage totals on users who opt in to share analytics.
Read the definitions for the metric selected in App Store Connect Analytics. Store downloads, completed installations, and app-side first launches are different counting events. Usage reports cover the reporting population described by Apple; keep that scope beside any comparison with app-side event totals.
When local or first-party event measurement becomes data collection
For an on-device event counter, the app can update local totals such as “paywall viewed” or “trial button tapped” and use those totals for a local diagnostic view. That approach can help an engineer verify that an interaction fires and can help a team inspect broad event counts on a test device.
Sending an event to your own server can let a small team compare onboarding completion or trial starts across users, app versions, or acquisition cohorts, depending on what fields the implementation records. It also puts transmitted data, server access, retention, and any later sharing into the privacy review because “first-party” describes who operates the service, not whether information left the device.
Use this inventory before adding local analytics, a first-party backend, or a vendor SDK:
- Event: Name the behavior you need to measure, such as
paywall_viewed,trial_started, orsubscription_renewed. - Purpose: Write the decision the event supports, such as comparing trial starts between two onboarding versions.
- Payload: List each value sent with the event, including timestamps, product identifiers, campaign fields, and event properties.
- Identifier: Record whether the event is associated with an account, device, advertising identifier, or another identifier.
- Destination: Trace where the data goes: local storage, your server, an SDK provider, an ad channel, or more than one destination.
- Access and retention: Name who can access each copy and how long it remains accessible.
- Use and sharing: Record whether the data is used for product analysis, advertising, personalization, app function, or a further recipient’s purpose.
- Privacy declaration: Reconcile the actual flow with the tracking and data-collection disclosures your app submits.
Keep event collection proportional to the decision. A trial_started event can support a trial-start total, while a richer event with account and campaign fields may support cohort analysis. If the team only needs the total number of trials, collecting extra fields adds data-handling work without adding an answer to that immediate question.
What campaign attribution and mapped SKAN 4.0 conversion data can report
Apple describes AdAttributionKit as technology advertisers can use to attribute in-app ad campaigns and mobile web ads while maintaining user privacy. The ad channel sends Airbridge the conversion value in a SKAN 4.0 postback after the random timer starts.
SKAN 4.0 sends a fine conversion value from 0 to 63 and a coarse value of “low,” “medium,” or “high.” For example, a subscription team might map an early milestone such as trial start to a value, then interpret received postbacks using that campaign mapping.
The three conversion windows cover days 0–2, days 3–7, and days 8–35 after install; each window has its own randomized postback timer, which begins 24 hours after that window closes.
| SKAN 4.0 element | What it gives the team | Practical consequence |
|---|---|---|
| First postback window | Conversion information from days 0–2 after install | Useful for early actions, such as reaching onboarding or an initial paywall milestone, if mapped and eligible. |
| Second postback window | Conversion information from days 3–7 | Extends the observation period for later early-lifecycle behavior. |
| Third postback window | Conversion information from days 8–35 | Extends campaign measurement into a later post-install period. |
| Fine and coarse values | A mapped numeric value or a broader low, medium, or high value | Interpret the value through the conversion-data mapping and the value available in the postback. |
| Randomized delivery timer | Each timer starts 24 hours after its conversion window closes | The delivery time varies after the window closes, so campaign teams should plan around the postback schedule. |
Airbridge decodes a SKAN 4.0 conversion value into event data using the configured conversion-data mapping and displays the resulting attribution data in its dashboards. That makes Airbridge one option for teams that want mapped SKAN postback reporting in a campaign dashboard.
The app must have a supported Airbridge iOS SDK version, the user’s device must run iOS 16.1 or later, the ad channel must support SKAN 4.0, and the postback data tier must be Tier 1, Tier 2, or Tier 3. Depending on user action and eligibility, SKAN 4.0 may return one, two, or three postbacks.
Airbridge’s Core Plan setup workflow includes installing its iOS SDK as part of campaign measurement setup. The app team still evaluates the SDK’s data practices, purposes, and destinations, then completes its own App Store privacy information accordingly.
Product-event measurement answers app-defined questions such as onboarding or paywall interactions, while SKAN postbacks report mapped campaign-attribution data.
Choose the route by the question you need to answer
A measurement setup can combine more than one route, because store acquisition, app reliability, product behavior, and campaign attribution are different questions. Choose the least complex route that can produce the answer your team needs today, then add another only when a real decision depends on it.
| Your immediate question | First route to use | Data path | Integration and privacy point |
|---|---|---|---|
| Did App Store exposure turn into product-page views and downloads? | App Store Connect Analytics | Store reporting | Apple’s acquisition metrics include impressions, product-page views, downloads, redownloads, and conversion rate. |
| Are people using the app, and what are the broad usage or sales trends? | App Store Connect usage, sales, and subscription metrics | Apple’s App Store reporting | Review sessions, active devices, sales, and subscription measures together to understand reported app use and monetization. |
| Is the app slow, hanging, or crashing? | MetricKit, App Store Connect crash metrics, and Xcode crash reports | Performance and crash diagnostics | Use MetricKit for app-performance questions; Apple’s crash counts and Xcode reports cover crash reporting. |
| Are users reaching onboarding steps, viewing a paywall, or starting trials? | Explicit product-event measurement | Local-only counts or events sent to a server, depending on the design | Choose local counts for on-device inspection or server events for shared cohort analysis, based on the data flow your question needs. |
| Which campaign drove attributed installs and mapped post-install activity? | SKAN 4.0 or a compatible campaign-attribution workflow | Conversion values and postbacks across the documented windows | Confirm channel support and select the post-install value your campaign report needs to interpret. |
| Which reporting setup supports mapped SKAN values in Airbridge? | Airbridge SKAN reporting | Channel postbacks | Airbridge Core Plan campaign setup uses the iOS SDK. |
A practical early setup could use App Store Connect for listing and subscription baselines, a small set of product events for trial-funnel questions, and SKAN for campaign attribution where eligible channels support it. Airbridge can fit the campaign branch when the team wants configured SKAN 4.0 conversion values decoded into dashboard event data and accepts the iOS SDK setup. The same team can keep a no-tracking declaration only when its actual data use meets Apple’s tracking definition; it should describe collection separately based on the data flow.
FAQ
Can App Store Connect Analytics report acquisition and subscription metrics?
Yes. App Store Connect provides store acquisition, usage, sales, and subscription reporting, including impressions, product-page views, downloads, sessions, purchases, and subscription metrics. Its usage figures apply to users who opt in to share analytics, and availability depends on Apple’s reporting thresholds.
Does “no tracking” mean I can select “Data Not Collected”?
No. “No tracking” concerns Apple’s definition of cross-company data linkage for advertising or sharing with data brokers, while “collect” concerns eligible data transmitted off-device and accessible beyond real-time request service. A first-party server can collect app analytics without using them for tracking.
What setup does Airbridge document for multiple SKAN postbacks?
Airbridge’s documented Core onboarding uses an app SDK. Its SKAN 4.0 guide lists iOS, SDK, channel, and data-tier conditions for multiple postbacks. Follow that documented integration path; it does not establish that every SKAN reporting architecture requires an MMP SDK.
Does SKAN show every user’s paywall and subscription journey?
No. SKAN reports campaign attribution through conversion values and postbacks, with conversion windows and randomized delivery timing. A team that needs detailed product-funnel events must choose a separate event-measurement design and review its data flow.
Before release, have the app’s privacy owner reconcile the actual payload, identifiers, recipients, retention, and advertising use with Apple’s App Privacy Details. A product label such as “first-party” or “no tracking” is a starting description; the implemented data flow determines the disclosure.
Get Started Free
See how these criteria hold up on the real thing.
