Het meeste verkeer van je app gaat niet naar de app

Twee getallen uit één sessie¶

Ik heb het netwerkverkeer van een advertentie-gedreven app vastgelegd tijdens gewoon gebruik. Openen, kijken, scrollen, sluiten. Daarna heb ik elk verzoek toegewezen aan een bestemming: de eigen backend van de app, of de advertentie- en trackingketen.

De uitkomst staat in het grondveld bij deze notitie in genereer_sporen.py: in één gebruikssessie ging 87 procent van de netwerkverzoeken en 54 procent van de bytes naar de advertentieketen, tegen een fractie echt verkeer. De weersverwachting, de zoekresultaten, de reistijd, dat alles paste in de rest.

Dat is één sessie op één app. Ik presenteer het als zodanig, en ik trek er geen landelijk gemiddelde uit. Wat het getal wel doet, is een verhouding zichtbaar maken die je op je scherm nooit ziet. Je opende een app om iets te weten. Het toestel besteedde het grootste deel van zijn verbindingen aan iets anders.

Waarom de teller en de weegschaal uiteenlopen¶

Twee getallen over dezelfde sessie, 87 en 54, en ze zeggen elk iets anders. Dat verschil is de interessantste kant van de meting.

Het aantal verzoeken telt gesprekken. Elk biedverzoek, elke pixel, elke synchronisatie van een herkenningsnummer is een aparte verbinding, met een eigen naamopzoeking, een eigen TLS-handdruk en een eigen antwoord. Die gesprekken zijn klein en talrijk.

Het aantal bytes weegt lading. Daar tellen de advertentiebeelden mee, en ook de kaartjes, de foto's en de JSON van de app zelf. Beeld is zwaar, een biedverzoek is licht.

Dus: de advertentielaag domineert het aantal gesprekken sterker dan het aantal bytes. Voor je databundel is 54 procent de eerlijke maat. Voor je batterij en voor de snelheid waarmee de app opent, is 87 procent de eerlijke maat, want elke losse verbinding kost een radiocyclus, een handdruk en wachttijd. Een telefoon die honderd korte gesprekken voert, werkt harder dan een telefoon die één groot bestand binnenhaalt.

Wie dit in een rapport zet, moet daarom altijd zeggen wat hij telde. Verzoeken en bytes zijn twee meetlatten, en ze geven twee verschillende antwoorden op de vraag hoe zwaar de advertentielaag weegt.

Wat er in die verzoeken zit¶

De verzoeken zijn klein en toch de kern van de zaak. Bij Buienalarm en Marktplaats ving ik de biedaanvraag op die al bij het laden van de advertentie vertrekt, met het reclamenummer van de telefoon, de locatie, de netwerkcode en de provider erin (GROND bij je-toestelprofiel-gaat-de-veiling-in-voordat-je-iets-aanraakt in genereer_sporen.py). Het volledige toestelprofiel, voordat de gebruiker iets had aangeraakt. Zie Je toestelprofiel gaat de veiling in voor je iets aanraakt en Je hele toestelprofiel gaat in een keer de veiling in.

Die 87 procent bestaat dus grotendeels uit verkeer dat jouw kenmerken vervoert. Het is geen bijproduct van de advertentie. Het is de handel zelf, en de advertentie is er de zichtbare afloop van. Zie Je toestelprofiel is de hoofdmoot van wat een app verstuurt.

Eén advertentieplek levert bovendien meer verbindingen op dan je zou denken, want het biedverzoek wordt uitgezonden naar iedereen die op het veilingplatform mag meebieden. In een echte bid-respons uit één app zaten zeven biedende partijen, en zes daarvan staan ook in de partnerlijst van een totaal andere app (onverwante-apps-delen-dezelfde-veiling in mick_bodies.py). Zie Onverwante apps sturen je profiel dezelfde veiling in.

Wat de gebruiker ervoor betaalt¶

Drie rekeningen lopen door, en de gebruiker ziet geen van drie.

De eerste is je bundel. Ruim de helft van de bytes in die sessie ging naar de advertentieketen. Op een prepaid bundel of in het buitenland is dat gewoon geld.

De tweede is je batterij. De radio van een telefoon is duurder dan het scherm bij korte, verspreide verbindingen. Honderden losse verzoeken houden de radio wakker. Dat de advertentielaag het aantal verbindingen domineert, is gemeten. Hoeveel milliampère-uur dat precies kost, heb ik niet gemeten, en ik doe daar dus geen uitspraak over.

De derde is tijd. Een app die eerst een veiling moet doorlopen voordat het scherm compleet is, opent langzamer. De biedstroom kent daar zelfs een veld voor, tmax, de maximale tijd waarbinnen een bieder mag antwoorden. De gebruiker wacht dat venster uit.

Hetzelfde patroon op het web, met eigen cijfers¶

Op websites heb ik de ketenomvang breed kunnen meten, en daar staat de verhouding tussen een lichte en een zware site scherp op papier.

Op 1.718 Nederlandse overheidssites (scan van 14 juli 2026) is de mediaan 2 externe ontvangers, het gemiddelde 3,2, het negentigste percentiel 7 en het maximum 38 (diep.json, overheid_1718/C_ketenomvang).

Op 32 commerciële sites uit de NPI-scan van 18 juli 2026 is de mediaan 36, het gemiddelde 37,8, het negentigste percentiel 75 en het maximum 87 (diep.json, npi/C_ketenomvang).

De mediaan aan de commerciële kant ligt daarmee ver boven die aan de overheidskant. Het bevestigt het beeld uit de app-sessie: waar een verdienmodel aan de aandacht hangt, hangt er een keten aan het verkeer. Zie De ontvangers die in geen enkel verwerkingsregister staan en De sectoren die het meest zouden moeten waken, verdienen aan tracking.

Let op dat dit twee verschillende metingen zijn. De 87 en 54 procent komen uit één app-sessie. De medianen komen uit browserscans van sites. Ze wijzen dezelfde kant op, en ze zijn geen bewijs voor elkaar.

Waar deze meting ophoudt¶

Vijf grenzen, en ze horen alle vijf in het rapport.

Ten eerste is het één sessie op één app. Een tweede sessie op dezelfde app kan anders uitvallen, want welke veilingen er lopen en hoeveel advertenties er laden, hangt af van het moment.

Ten tweede meet ik het vertrek. Wat er daarna tussen servers gebeurt, valt buiten beeld. Een exchange kan een verzoek doorverkopen aan een andere exchange. Elk getal dat ik noem is daarom een ondergrens. Zie Elke browsermeting is een ondergrens.

Ten derde is de toewijzing per verzoek een oordeel. Een CDN-domein dat zowel afbeeldingen van de app als creatieven voor de advertentie levert, valt in beide emmers te leggen. Ik houd de app-emmer ruim bij twijfel, zodat het advertentiecijfer eerder te laag uitvalt dan te hoog.

Ten vierde trek ik het achtergrondverkeer van het toestel eraf voordat ik iets aan de app toeschrijf. Zonder die aftrek reken je de app aan wat het besturingssysteem deed. Zie Een mislukte meting is geen schone app.

Ten vijfde vuurt niet alles bij opstart. Een deel van de keten komt pas na scrollen, doorklikken of het starten van een video. Meet je één seconde, dan meet je te weinig. Zie Niet alles vuurt bij opstart, sommige trackers wachten op jou en Meet zoals een bezoeker, niet zoals een scanner.

Dat het anders kan, is gemeten¶

De sterkste tegenwerping tegen deze notitie is dat de zware laag er nu eenmaal bij hoort. Die tegenwerping is weerlegd door een meting. In dezelfde reeks zat een app die nul netwerkverkeer maakte. Alles bleef op het toestel, de lijst met verstuurde verzoeken bleef leeg (een-app-kan-volledig-lokaal in mick_bodies.py). Zie Een app kan volledig lokaal, zonder een enkele netwerkcall en Geen internet-permissie, geen probleem.

Eén schone app maakt de advertentiestack bij een andere app een keuze van een mens. Technische noodzaak valt als verklaring af zodra het tegenvoorbeeld op tafel ligt.

Wat je hier morgen mee doet¶

Als gebruiker, in tien minuten. Kijk op Android onder Instellingen, Netwerk en internet, Dataverbruik welke apps het meeste verbruiken, en zet daar mobiele data uit voor de apps die je alleen op wifi nodig hebt. Op iOS staat dezelfde lijst onder Mobiel netwerk. Zet daarna in je browser en in je apps de locatiepermissie op "alleen tijdens gebruik". Dat verkleint de lading van elk biedverzoek dat toch vertrekt.

Als je kunt kiezen tussen apps, kies de app zonder advertentielaag, ook als je ervoor betaalt. Reken het eens uit: een euro per maand tegenover ruim de helft van je verbruik in die app en een profiel dat de veiling in gaat.

Als onderzoeker of functionaris gegevensbescherming: leg één sessie van je eigen app vast met een onderscheppende proxy, meet eerst het toestel in rust om het systeemverkeer eraf te kunnen trekken, en rapporteer daarna twee getallen naast elkaar, het aandeel verzoeken en het aandeel bytes. Zeg erbij welke domeinen je aan welke emmer toewees. Een rapport met één percentage en zonder toewijzingsregel is niet na te rekenen, en dan is het geen bewijsstuk. Zie Label elke bevinding op bewijsniveau.

En als je een app bouwt: dit getal is een bouwkeuze die je kunt terugdraaien. De verhouding tussen functie en overhead staat in je eigen HAR-bestand, vanmiddag nog te maken. Wie hem nooit heeft bekeken, weet niet wat hij zijn gebruikers laat betalen.