Wat er gebeurt met een app-link die je opent in Instagram en TikTok: 74,000 doorverwijzingen gemeten

Deze cijfers komen uit de doorverwijzingslogs van een slimme-linkdienst: één URL die een telefoon naar de App Store of Google Play stuurt. Elke keer dat een link in een sociale app wordt geopend, serveren we een kleine pagina die de bezoeker aan de store overdraagt, en die pagina meldt wat er daarna gebeurde. Hieronder staat wat die meldingen zeggen, hoe we ze gemeten hebben en waar de meting ophoudt.

De data

Twee dingen vallen al op vóór elke analyse. De apps van Meta sturen veel meer verkeer dan TikTok. En op Android komt meer dan driekwart van alle bezoeken binnen via een in-app browser, niet via Chrome.

Hoe de pagina meldt wat er gebeurde

Als een link in een in-app browser wordt geopend, doet de pagina drie dingen en stuurt voor elk ervan een beacon:

• auto: bij het laden start ze de overdracht naar de store (iOS: location.replace naar de App Store-URL; Android: een intent://-URL die de native Play Store-app opent).
• exit: de pagina wordt verborgen (Page Visibility API). Dat is het beste signaal dat een webpagina heeft dat iets anders, waarschijnlijk de store, het scherm heeft overgenomen.
• stuck: de pagina is 2.2 seconden na de overdracht nog zichtbaar, dus toont ze een reservekaart met een storeknop, een tip „open in je browser” en een knop om de link te kopiëren.

Een webpagina kan de App Store of de Play Store niet zien. Alles hieronder is afgeleid uit deze drie signalen, en het deel over de beperkingen zegt waar die afleiding niet meer klopt.

Bevinding 1: ongeveer 1 op de 11 Android-bezoeken via Meta is een preload die niemand zag

In de 30 dagen tot 12 oktober gedroeg een duidelijke groep Android-sessies zich zoals geen menselijk bezoek zou doen: de pagina laadde, de overdrachtstimer liep nooit, en de pagina werd 29 tot 31 seconden later vernietigd. Geen auto, geen stuck, geen tik. iOS liet niets vergelijkbaars zien.

Dat is de vingerafdruk van de in-app browser van Instagram en Facebook die een link in een feed vooraf laadt, verborgen houdt en weggooit als de gebruiker verder scrolt. De pagina voerde ons JavaScript uit, dus het bezoek werd gelogd. Niemand heeft er ooit naar gekeken.

We hebben het criterium getoetst aan sessies die duidelijk menselijk waren: 0 van de 17,606 sessies waarin de store 2–3 s na de overdracht opende, voldeden eraan, en 0 van de 244 sessies waarin iemand op de storeknop tikte ook niet.

Het aandeel schommelt per week: 6.8% in de laatste week van die periode, daarvoor 8.8%, 10.6% en 10.0%. Het concentreert zich ook waar betaalde Instagram-campagnes lopen: 72% van de preloads in de periode kwam van één link achter een grote Instagram-campagne.

Sinds 16 oktober classificeert de pagina dit zelf tijdens het draaien: ze meldt een preload in plaats van een exit als ze sterft na minstens 20 s zonder ooit getoond te zijn. Dit heeft ze sindsdien opgevangen:

Die telling tijdens het draaien is een ondergrens. Een preload die sterft zonder enig script uit te voeren laat geen beacon achter, en de regel tijdens het draaien is strenger dan de historische reconstructie.

Waarom het ertoe doet. Als je klikken telt bij je doorverwijzing, is ruwweg één op de 13 Instagram-Android-„klikken” nooit door een mens gezien. Je klik-naar-installatie-verhouding voor dat kanaal ziet er slechter uit dan ze is, en een campagnedashboard op basis van ruwe doorverwijzingshits overschat het bereik met ongeveer zoveel.

Bevinding 2: TikTok weigert de Play Store afhankelijk van de webview die het gebruikt

In TikTok op Android verlaat een deel van de bezoekers de pagina nooit: de overdracht gaat af en TikTok toont zijn eigen dialoog („The action cannot be completed”). Het gebeurt niet bij elke link, en wekenlang leek het van de link af te hangen. Dat doet het niet. Het hangt af van de in-app browser die TikTok voor die bezoeker gebruikt, en die verraadt zijn user-agent:

Een sessie telt als geslaagd wanneer de overdracht afging en de pagina verborgen werd, en als mislukt wanneer de reservekaart verscheen. Het percentage is geslaagd / (geslaagd + mislukt), per toestel en per dag:

De vergelijking die de doorslag geeft, houdt de link en de dag gelijk, want de verhouding tussen formaten verandert van week tot week:

Zelfde link, zelfde doorverwijzingscode, zelfde dag: de ene webview laat de store openen en de andere meestal niet. Eigen domeinen maakten in de data over 90 dagen geen verschil. TikTok documenteert de dialoog niet, en ook niet wat hem veroorzaakt of welke gebruikers welke webview krijgen, dus de opsplitsing per user-agent is alles wat er is.

Waarom het ertoe doet. Geen enkele URL-vorm lost dit op: de intent://-uitbraak en een gewone https://play.google.com-URL krijgen dezelfde weigering. Wat je wel kunt doen, is de uitweg niet verstoppen: toon in TikTok meteen de instructies „openen in browser” en een kopieerknop, in plaats van na een time-out.

Bevinding 3: op iOS opent de App Store over de in-app browser heen

Op Android wordt de pagina na de overdracht in de meeste sessies verborgen, meestal 1 tot 3 seconden later. Op iOS in Instagram en Facebook gebeurt dat vaak niet, ook al ging de overdracht in bijna elke sessie af:

Als twee derde van de iOS-bezoekers echt vastzat voor een zichtbare reservekaart met een knop „Open de App Store”, zou een flink deel erop tikken. Dat doen ze niet: 0.9% van de iOS-paginaladingen in Instagram en 0.4% van die in Facebook tikken op de knop. Er is ook geen iOS-versie waarop het wél „werkt”:

De verklaring die past, is dat in Instagram en Facebook op iOS de App Store over de in-app browser heen verschijnt zonder die naar de achtergrond te sturen. De pagina blijft de hele tijd „zichtbaar”, dus visibilitychange en pagehide gaan nooit af, ook al kijkt de bezoeker naar de App Store.

Waarom het ertoe doet. Elke metriek die een geopende store afleidt uit het verdwijnen van de pagina van het scherm, klopt niet op iOS. We toonden klanten vroeger een percentage „store-bereik” dat precies zo was opgebouwd, en het vertelde 10 van de 12 betalende klanten dat werkende links kapot waren. We hebben het verwijderd. Op iOS zit het betrouwbare installatiesignaal aan de kant van de store: campagnerapporten in App Store Connect, met een provider token (pt) en een campagnetoken (ct) op de App Store-URL.

Kleinere dingen die we onderweg hebben gemeten

• De Play Store verschijnt traag op Android. In Instagram-Android-sessies waarin de overdracht afging, werd de pagina 0–1 s na het bezoek verborgen in 1,061 sessies, 2–3 s erna in 2,596 en 4–8 s erna in 1,273 (7 dagen). Een timer van 2 seconden die controleert „werkte het?” gaat bij een groot deel van de echte successen af voordat de store verschijnt. Onze eigen funnel telde die als mislukt, tot we een exit tot 8 s na de overdracht nog lieten meetellen.
• Het echte foutpercentage is klein. In 7,357 Instagram-Android-sessies, herbouwd over 3 dagen begin oktober, kwam het patroon „overdracht, daarna niets” voor in 1.9% van de sessies, en 24.3% van die bezoekers tikte binnen 3 minuten opnieuw op de link. Bezoekers bij wie de reservekaart verscheen, tikten in 5.4% van de gevallen opnieuw, ongeveer zoals bezoekers bij wie de store opende (4.6%): de meeste van die „mislukkingen” waren geen mislukkingen.
• Een verplichte tik kost het grootste deel van het verkeer. Voordat de pagina de overdracht bij het laden startte, toonde ze een kaart met een storeknop. Over 30 dagen leverden 10,523 in-app bezoeken 2,119 tikken op: ongeveer 80% van de bezoekers bereikte de store nooit.

Methode

• Bron. Elk bezoek aan een slimme link en elk beacon van de overdrachtspagina wordt weggeschreven naar Cloudflare Workers Analytics Engine, met het platform, de in-app browser (uit de user-agent), het soort gebeurtenis en een tijdstempel tot op de seconde. Bezoekers van wie de user-agent zich als bot, crawler of linkvoorbeeld-ophaler meldt, worden apart gehouden en zijn uit elk cijfer hier weggelaten.
• Sessies. Analytics Engine heeft geen paginalading-id, dus sessies worden herbouwd door een bezoek te koppelen aan de beacons met dezelfde link, hetzelfde land, dezelfde stad, dezelfde user-agent en dezelfde in-app browser binnen het volgende uur, tot het volgende bezoek met dezelfde sleutel. Ongeveer 98% van de beacons wordt aan een bezoek gekoppeld.
• Preloads (bevinding 1). Historisch criterium: geen overdracht, geen reservekaart, geen tik, en een exit 20 s tot 15 min na het bezoek. Criterium tijdens het draaien sinds 2026-10-16: de pagina meldt een preload als ze sterft na minstens 20 s zonder ooit getoond te zijn en haar overdrachtstimer nooit liep (of ze verborgen laadde). Het beacon draagt een ondertekend token voor eenmalig gebruik, zodat het niet opnieuw afgespeeld kan worden om een echt bezoek te wissen.
• TikTok (bevinding 2). Sessies gesleuteld op link, toestelmodel, TikTok-appversie en dag. Formaatregel: musical_ly_-versie met punten → A; anders JsSdk → B; anders C. Bezoekers vanaf hostingnetwerken worden apart geteld en buiten de tabel gehouden. De hermeting over 30 dagen gebruikt hetzelfde script als de oorspronkelijke analyse over 90 dagen.
• Totalen gebruiken het steekproefinterval van Analytics Engine (2–4% van de rijen staat voor meer dan één gebeurtenis). Sessietabellen tellen rijen.

Beperkingen

• We zien de store nooit. „Verborgen” is een benadering van „de store ging open”. Het gaat ook af als de bezoeker van app wisselt of de telefoon vergrendelt.
• Tijdstempels zijn tot op de seconde, en sessies zijn reconstructies. Twee snelle ladingen vanaf hetzelfde toestel kunnen samenvallen.
• Concentratie. Een paar grote links domineren sommige periodes: één Instagram-campagne is goed voor 72% van de preloads over 30 dagen, en twee links dragen het grootste deel van de TikTok-sessies. Daarom bestaan de tabellen met dezelfde link.
• Niets hiervan is op een fysieke telefoon gecontroleerd. Het gedrag is afgeleid uit wat pagina's melden. De iOS-verklaring in bevinding 3 is degene die bij de data past, niet iets wat we hebben zien gebeuren.
• Het verkeer is het onze. Dit zijn de bezoekers van de apps die onze links gebruiken, sterk gewogen naar Instagram- en Facebook-campagnes in een handvol landen. Een andere mix geeft andere percentages, al zouden de mechanismen dezelfde moeten zijn.
• Preloads die nooit JavaScript uitvoeren zijn onzichtbaar. 12% van de Android-paginaladingen in Instagram stuurt helemaal geen beacon, en een deel daarvan is waarschijnlijk ook een preload.

Wat je eraan kunt doen

1. Start de overdracht bij het laden. Een pagina die op een tik wacht, verliest de meeste in-app bezoekers. Houd de handmatige knop als reserve, alleen getoond als de overdracht zichtbaar mislukte.
2. Gebruik op Android `intent://` met `S.browser_fallback_url`. Een https://play.google.com-URL in een webview opent de Play Store-website, die zonder inloggen niets kan installeren.
3. Geef een trage store de tijd. Wacht minstens 3 s voordat je besluit dat de overdracht mislukte, en tel een late exit nog steeds mee.
4. Toon in TikTok meteen de uitweg: „··· → Openen in browser” en een knop om de link te kopiëren. Geen enkele URL-wijziging laat de weigering van TikTok verdwijnen.
5. Tel Meta-preloads niet als klikken. Als je klikken rapporteert vanaf een doorverwijzing, reken er dan op dat 2–9% van de Android-bezoeken via Instagram en Facebook pagina's zijn die niemand zag.
6. Meet installaties bij de store, met campagnelinks van App Store Connect (pt + ct) op iOS en de Play Install Referrer op Android, niet met paginagebeurtenissen.

Wij bouwen onestore.link, dat standaard alle zes voor elke link doet, en de data hierboven komt uit de doorverwijzingslogs ervan.

Vragen en antwoorden