WhatsApp's in-app browser for iPhone kills the last link-tracking signal brands could see

WhatsApp is developing an in-app browser for iPhone that would open any link shared in a chat inside the app, extending a feature that launched for certain business links in May 2025. When enabled, the browser would open any link sent or received in the chat screen without switching to Safari.

The feature is not yet available to beta testers, but references appeared in WhatsApp's latest TestFlight build. A new settings option under Chats will let users choose whether links open inside WhatsApp or in their default browser, with a screen to clear cookies, cache and other browsing data.

This is the convenience angle everyone will report. The attribution angle is what matters.

The tracking problem no one is naming

The business-link version appeared in iOS beta in May 2025, requiring sites to use HTTPS and meet other technical requirements set by WhatsApp. That version kept brands inside a measurable environment. When a customer tapped a link in a WhatsApp campaign, the click opened in Safari or Chrome, where Meta's pixel could fire, UTM parameters could survive, and the referrer header said "WhatsApp".

Extend that to an in-app browser, and the signal chain breaks. In-app browsers on iOS are credited to the browser app under App Referrer, not to Web Referrer, and links opened in social apps have the same problem. When in-app browsers mask attribution, campaigns look unprofitable even when they are not, and attribution challenges are now the dominant mobile reality.

The WhatsApp Business API already lets brands track button clicks in approved message templates through Meta's template analytics, returning both total clicks and unique accounts that clicked for URL buttons in marketing or utility templates. But click-through rates are not natively trackable outside the API, and only API setups enable deep tracking of revenue and attribution models.

For brands not on the Business Platform, or using links in regular chats rather than template buttons, the only attribution path left was the browser itself. UTM tags, referrer headers, and pixels all depend on the link opening somewhere trackable. An in-app browser operated by WhatsApp, which cannot see which links are shared or opened due to end-to-end encryption, removes that option entirely.

What this does to the click-to-conversion path

Meta browser pixel attribution has degraded materially across 2024 and 2026 due to Apple App Tracking Transparency (around 60 to 65 per cent opt-out) and Safari Link Tracking Protection. 96 per cent of US iOS users opted out of ATT tracking, and a browser-only pixel now captures an estimated 70 to 80 per cent of true conversion events.

Now layer an in-app browser on top. The pixel can no longer reliably track iOS users who interacted with ads in-app, conversion data becomes incomplete, attribution windows shortened, and the detailed targeting that made these platforms powerful started degrading. The same mechanics apply when a WhatsApp link opens inside WhatsApp rather than Safari.

A user clicks an ad in Facebook, opens it in Facebook's in-app browser, views a product, then returns the next day in Safari to purchase, but the site does not recognise them, and analytics attribute the sale to organic search rather than the Facebook ad that drove it. Replace "Facebook" with "WhatsApp" and the mechanism is identical.

The difference is that WhatsApp campaigns sit inside a messaging flow where attribution was already harder to prove. Brands running Click-to-WhatsApp ads or sending broadcast campaigns through the Business API rely on downstream conversion tracking to justify the spend. Meta attaches referral data to an advertising-originated inbound message, and the WhatsApp Business Platform exposes that data through a webhook. But for links sent after that initial contact, once the conversation moves to regular chat or a customer shares a product link with a friend, the tracking stops unless the link itself carries attribution parameters that survive the journey.

An in-app browser that sits between the tap and the destination site makes that survival far less likely.

Why brands cannot opt out

The in-app browser will be optional, controlled by a setting under Chats. But brands do not control the setting. Customers do. If the feature ships as opt-in and a meaningful portion of iPhone users turn it on for convenience, every WhatsApp campaign will start splitting attribution between Safari (trackable) and WhatsApp's in-app browser (much harder).

The situation mirrors WhatsApp's scheduled messages, which arrived years after competitors but closed a workflow gap brands were filling with third-party tools. This closes an attribution gap that third-party analytics platforms and URL shorteners were built to solve.

66 per cent of consumers make a purchase after interacting with a brand on WhatsApp, but proving which interaction drove the sale becomes harder when the last trackable touchpoint disappears inside an encrypted messaging app with a built-in browser that the brand cannot instrument.

The tools that stop working

The WhatsApp marketing stack has adapted to every signal loss so far. URL shorteners with tracking (Bitly, Cutt.ly, custom domains) log the click when the shortened link resolves, before the browser matters. URL shortening reduces long URLs to branded or neutral short links, and click tracking captures user interactions with links including click count and time, but URL tracking requires shortening to be enabled first. That still works if the in-app browser requests the redirect. What breaks is everything downstream.

UTM parameters are tags added to a URL, and when someone clicks a URL with UTM parameters, those tags are sent back to analytics tools so you can track where traffic came from. But if the in-app browser does not pass a recognisable referrer, or if it strips parameters the way Safari's Link Tracking Protection strips click identifiers in Private Browsing, Mail, Messages and Instagram WebView, the UTM arrives intact but the session looks like a direct visit with no source.

The Meta pixel, already running in a browser environment made harder to track by Apple's App Tracking Transparency, Safari's tracking prevention, ad blockers and consent banners, now has to fire inside a browser controlled by Meta's own app. Between September 2024 and early June 2025, Meta's Android apps covertly tracked users' web browsing, even in incognito and VPN modes, by exploiting a local localhost channel, and the pixel sent data directly from browser to Meta's apps where users were already logged in. Meta stopped the behaviour by 3 June 2025.

Whether WhatsApp's iOS in-app browser operates under the same local architecture is unknown. WhatsApp says it cannot see links shared in the conversation and which ones users open, which is consistent with end-to-end encryption. But the browser itself, running inside WhatsApp, could theoretically communicate with WhatsApp's own services in ways Safari cannot, and brands would have no visibility into what gets logged.

What brands should do now

The feature is still in development. No beta testers have access yet, and WhatsApp will make the browser available to some beta testers in a future update, with no public release date given. That gives brands a window to pressure-test their attribution before it fragments further.

Run a baseline now. Measure how many conversions from WhatsApp campaigns you can currently attribute with confidence, using your existing mix of UTM tags, shorteners, pixels and server-side tracking. When the in-app browser ships and adoption starts, you will be able to quantify what you lost.

Double down on first-party data. Advertisers responded to reduced IDFA signals by shifting budget toward SKAdNetwork and investing in first-party data strategies through loyalty programmes and registered user bases. The same logic applies here. If you can tie a WhatsApp contact to a customer record before they click a link, you can match the purchase on the back end even if the in-browser attribution fails.

Use WhatsApp's own analytics where you can. Meta's template analytics counts button taps, and clicks are returned only for URL buttons and quick-reply buttons in templates categorised as marketing or utility. That is the one attribution source WhatsApp controls, and it is more likely to survive changes to the in-app browser than third-party pixels.

And prepare for the conversation to shift from click measurement to outcome measurement. Meta's GEM model now runs every ad auction with conversion data, not click data. The same will eventually apply to WhatsApp: what matters is whether the campaign drove a sale, not whether you can see the step in between.

The in-app browser makes that intermediate step harder to see. If your reporting is still built around click attribution, this change will hurt. If you have already moved to conversion modelling and probabilistic matching, you are better positioned. Either way, the last clean signal is about to disappear.