research
What in-app ad traffic actually does on a landing page
In-app ad networks have turned into a real channel for DTC brands over the past year. I spent years at AppLovin and Vungle before Lutiq, on the ad network side of this traffic. This is what it looks like when it lands on a DTC brand's page.
We went through the session recordings and heatmaps for five landing pages that got almost all of their traffic from in-app placements, meaning ads shown inside mobile apps and games. Three things stood out:
- About a third of visitors were on tablets, mostly iPads, and standard analytics counted most of them as desktop.
- On four of the five pages, 81% to 90% of visitors never scrolled past the first screen.
- 55% to 70% of taps landed on things that weren't links, mostly the hero photo.
So for this traffic, the next step has to be visible on the first screen, on phones and on tablets.
It behaves differently from someone who found you on Google or clicked an Instagram ad from a brand they already follow. It opens in a webview inside another app, often a game, and on these pages a third of it came from tablets.
What we looked at
Five landing pages for one DTC apparel brand's collection campaign. 99.6% of their traffic came from in-app placements bought through AppLovin. We used the pages' session recordings (scroll, taps and outcome for each visit) and the heatmaps (scroll reach and tap targets), and parsed each page's HTML so we could match taps to links. The recordings cover late August and early September 2026.
A third of the traffic was tablets
On every page, 35% to 40% of visits came from devices with viewports 700 to 1,200 pixels wide, and most of those were iPads. Since iPadOS 13, Safari on iPad asks for the desktop version of sites by default and sends a user agent that looks like a Mac, so any tool that classifies devices by user agent files iPads under desktop. When the brand's reporting switched to classifying by device, the same traffic came out at about 63% phones, 32% tablets and 6% desktop.
And the tablets behaved differently:
| Device | Click-through to the store | Store visit within 7 days | Repeat visitors |
|---|---|---|---|
| Phones | 6.1% | 0.38% | 26% |
| iPads | 5.4% | 0.34% | 31% |
| Android tablets | 3.4% | 0.27% | not measured |
iPad visitors were more likely to have been there before, but they clicked through less, and that held on four of the five page designs. I think that says more about who's in iPad in-app placements than about the layout.
There was one real layout problem, though. Viewports between 441 and 700 pixels wide (iPads in split view and small Android tablets) clicked through at 3.2%. At that width the page fell back to its phone layout with a full-width hero photo, which pushed both the headline and the button below the fold.
Most visitors saw only the first screen
On four of the five pages, 81% to 90% of visitors never scrolled past one screen. The recordings also show what scrolling predicted. On the main collection page, among visitors still there at five seconds, the ones who had scrolled into the second quarter of the page went on to click through 46% of the time. The ones still on the first screen clicked through 4% of the time.
On that page, the main button started about 816 pixels down on a 714-pixel phone screen, so just below the fold. The page that did best on click-through had three linked product tiles in its first screen. Click-through isn't everything, though. Those tiles sent shoppers to individual product pages, and over the following weeks that page turned fewer visitors into buyers than a page that sent them to the collection (early signals for landing page tests).
Half the taps went nowhere
55% to 70% of taps landed on things that weren't links: the hero photo, the corners of the header and the headline text. People tapped whatever looked tappable, and in the recordings it shows up as repeated tapping, four to eight taps in a row.
The worst page in the set had this problem built in. It asked visitors to pick an option, and every option opened a pop-up instead of going to the store. People tapped a lot and almost nobody got anywhere. Click-through was 1.0%.
Clicks came late, and most people left early
The median time to click was 7.7 seconds on the main collection page, 12.6 seconds on a page with more to browse, and 26 to 37 seconds on a quiz page and the selector page. 70% to 95% of clicks happened after the five-second mark, and by then most visitors had already left.
So the first screen has to make the next step obvious for the people who decide in a few seconds, and still work for the smaller group that reads before clicking.
Links that open a new window can break in a webview
One recording showed a visitor tapping a button 34 times with nothing happening. They bought from the store directly about two hours later. The page's outbound links had target="_blank", and some in-app browsers don't reliably open new windows. Page builders and HTML validators sometimes add that attribute to external links automatically, so check the page as it actually renders, including what your templates add.
After removing it, the share of recorded sessions with that dead-tap pattern dropped from 7.8% to 2.8% overnight. But the share of people who clicked and then arrived at the store stayed at about 81% before and after, so we can't say it changed purchases. We kept the fix because it costs nothing. If you make a change like this, check that store arrivals moved too, and look at clicks second.
In-app browsers keep their own cookies
The in-app browsers inside Facebook and Instagram keep a separate cookie store from Safari and Chrome. A cart built in the in-app browser stays there. If your page pushes the shopper out to their main browser on a product or collection link, the cart doesn't come with them.
There are ways to ask the app to open the system browser, like Android intents and some undocumented URL schemes on iOS. They're best effort. The app decides whether to honor them, and they can change without notice. If you use one, do it on a prepared checkout link after the cart is built and confirmed, and fire it straight from the tap. Then measure each step separately: the tap, the handoff attempt, the page going to the background, the fallback and whether the shopper got where they were going.
Session recordings lose part of this traffic
Upload failures cut off 12% of phone recordings and 21% of tablet recordings, and 45% to 48% of all recordings ended on the recorder's idle timeout while the visitor was still on the page. So what people do after the first few seconds is under-observed, and more so on tablets.
What I'd change on any page getting in-app traffic
- Put the next step in the first screen, on phones and tablets: the button, the product and the price.
- Make the hero photo and product tiles links that go where the button goes.
- Test at 441 to 700 pixels wide as well as phone and desktop widths, and keep the sticky button on tablets.
- Classify devices by viewport before you conclude that desktop visitors behave differently. User agents will count iPads as desktop.
- Drop
target="_blank"from outbound calls to action on pages that get webview traffic. - Keep the cart and checkout in one browser. If you do hand off to the system browser, hand off a prepared checkout link.
- Judge the first screen before anything else. Anything dynamic that kicks in after five seconds only reaches a minority of visitors.
A few caveats
This is one brand and one traffic source, and the recordings cover a few weeks. Recording coverage varied by page and device, as I described above. The device-level numbers are store visits and click-through, not attributed purchases.
FAQ
Why do iPads show up as desktop in analytics?
Since iPadOS 13, Safari on iPad asks for desktop websites by default and identifies itself with a Mac-style user agent, so tools that classify devices from the user agent count those visits as desktop. Classifying by screen size or touch support separates them. A common client-side check is a Mac platform that reports touch points: navigator.platform === 'MacIntel' && navigator.maxTouchPoints > 1.
Does target="_blank" break links in in-app browsers?
It can. Some in-app browsers don't reliably open new windows or tabs, so the tap looks like it does nothing. On landing pages that get in-app traffic, I'd open calls to action in the same window.
Why does my cart disappear when a shopper leaves the Instagram or Facebook browser?
The in-app browser and the phone's main browser keep separate cookies, so a cart saved in one isn't visible in the other. Keep the purchase path in one browser, or hand off a prepared checkout link.
How much in-app ad traffic scrolls?
On these pages, 10% to 19% of visitors scrolled past the first screen, depending on the page. I'd design as if the first screen is all most visitors will see.
Related
- Early signals for landing page tests: which on-page signals predicted purchases on this same traffic
- This tracking tag didn't fire until 8 to 58 seconds into the visit
- Two ways people buy from an ad
- Apple, WWDC 2019: Introducing desktop-class browsing on iPad
I'm Colin Behr, co-founder of Lutiq. Before Lutiq I spent years in mobile ad tech at AppLovin, Vungle and Branch. Lutiq predicts which on-brand landing page to show each paid click and measures the lift against a live holdout. The figures in this post are our own, from one brand's campaign in August and September 2026, and the brand isn't named.