Apple has added tester criteria and new public link metrics to TestFlight, letting developers restrict beta invitations by device type or OS version and see, for the first time, how many people viewed a public link, how many accepted, and how many were turned away for not meeting the criteria. For a beta programme, that’s a genuinely new visibility layer. Public links have always been the easiest way to distribute a beta widely — drop a link in a newsletter, a Slack community, or a support ticket — but until now there was no way to tell whether a flood of “testers” was actually engaging with the build or just tapping a link and never opening the app. A team could see 500 acceptances and assume a healthy beta cohort, when in reality a large share never installed, and an even larger share installed once and never opened it again.
This matters most for teams that rely on public beta links as an acquisition channel in disguise — using TestFlight to soft-launch a feature to a broad, self-selected audience before a full release. Without funnel visibility into the invite-to-active-tester path, it’s easy to mistake link clicks for genuine engagement, and to greenlight a feature based on a beta cohort that never actually used it seriously.
Data Points to Track
- Public link views versus acceptances, to establish a baseline conversion rate for the link itself, separate from anything that happens inside the app
- Tester-criteria rejection count, so you can see how many potential testers were filtered out by device or OS restrictions and whether that’s shrinking your funnel more than expected
- Time from acceptance to first app open, since a long delay (or no open at all) signals a tester who joined but never really engaged
- Session count and days-active per beta tester, compared against your production app’s early-retention benchmarks, to judge whether the beta cohort is representative
- Distribution channel for the link (newsletter, community, support flow, paid promotion), tagged via a unique link per channel, so acceptance and engagement rates can be compared across sources
Setup Steps
- Generate a separate public TestFlight link per distribution channel rather than one link shared everywhere, so the new view/accept metrics can be broken out by source.
- Set tester criteria deliberately — matching the device and OS mix of your actual target audience — rather than leaving the beta open to everyone, so the rejection metric reflects a real filter rather than noise.
- Instrument a first-open event inside the build tagged with a beta cohort identifier, so TestFlight’s acceptance numbers can be joined against real in-app engagement data.
- Compare beta cohort session and retention metrics against production baselines for the equivalent early-lifecycle window, not against the whole existing user base.
- Review the acceptance-to-active-tester ratio before every beta cycle, and treat a low ratio as a reason to tighten distribution rather than just recruiting more testers.
Actionable Insights
The combination of Apple’s link-level metrics and your own in-app engagement data turns “how’s the beta going” into an answerable question rather than a gut check. A high acceptance rate with a low first-open rate points to a distribution problem — the wrong audience or the wrong channel — while a healthy open rate with weak session depth points to a product problem worth fixing before a wider release. Tracking this by channel also tells you which distribution sources reliably deliver testers who actually use the app, which is worth knowing well beyond the current beta: it’s a preview of which acquisition channels are likely to convert once the feature ships broadly.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert