Een doodgewone Nederlander opent ‘s ochtends de weer-app, plant ‘s middags een reis, scrolt ‘s avonds over Marktplaats. Bij elk van die handelingen vertrekt er, voordat je de advertentie ziet, een berichtje naar een advertentieveiling. Daarin staat je advertentie-ID, je locatie, je telefoonnetwerk en je taal. Honderden partijen bieden mee en zien dat profiel. Dit is wat ik bij drie Nederlandse apps zelf heb vastgelegd, en wat ik niet kon vastleggen, eerlijk uit elkaar gehouden.
Het werkt zo onzichtbaar dat niemand het merkt. Je vraagt of het gaat regenen, en in diezelfde seconde wordt je toestelprofiel een veiling in geschoten waar advertentiebedrijven op bieden. Niet de weersinformatie is het product. Jij bent het. En het kost je, gemeten, je databundel en je accu, terwijl je dacht dat je gewoon het weer checkte.
Ik heb het verkeer van drie alledaagse Nederlandse apps onderschept en ontcijferd, het toestel uitgelezen tot op de simkaart, en de app-code uit elkaar getrokken. Hieronder staat per app de keten: wat vertrekt, waarheen, en wat het voor jou betekent.
“Laat Mick maar praten, het zijn maar advertenties…” De reactie die ik het vaakst krijg.
| Wie | Wat | Waarheen |
|---|---|---|
| Je toestel praat met een advertentie-exchange, voor de meeste apps PubMatic OpenWrap. Die exchange veilt jouw advertentieplek door aan honderden bieders. | Een bid-request met je advertentie-ID, je locatie, je netwerkcode, je carrier, je taal en je toestemmingsstatus. Het volledige profiel dat je toestel aanbiedt, ongefilterd. | Naar de exchange en alle meebiedende partijen. En, zo blijkt uit gelekte broker-lijsten, een deel belandt bij databrokers die uit de veiling oogsten. |
De korte versie
- Bij het laden van een advertentie stuurt je toestel een bid-request met je advertentie-ID, locatie en netwerkgegevens naar een advertentieveiling. Ik ving en ontcijferde die bid bij Buienalarm en Marktplaats.
- De app stuurt het volledige toestelprofiel ongefilterd door. Geen anonimisering, geen afweging per veld of een waarde mee mag.
- De gegevens belanden aantoonbaar bij databrokers: 9292, Marktplaats en VI staan in de gelekte Gravy-lijst van een databroker die uit de bidstream oogst.
- Het kost je data en accu. Bij een advertentiezware app als Marktplaats ging in mijn meting ongeveer 85% van het dataverbruik tijdens gebruik naar de advertentie- en trackinglaag. Bij een schone utility als 9292 was dat ongeveer 1%.
- Wat je kunt doen: reset je advertentie-ID, schakel advertentiepersonalisatie uit, en weiger toestemming waar dat kan. Het verlaagt de waarde van wat er wordt doorgestuurd.
Keten 1 · Buienalarm: het weer als lokaas
Je opent de app om te zien of je droog thuiskomt. Buienalarm (van Infoplaza) toont je de regengrafiek, en laadt daarbij een advertentie. Op dat moment bouwt het toestel een OpenRTB-bid en stuurt die naar PubMatic OpenWrap (ow.pubmatic.com). Ik heb die bid onderschept en ontcijferd.
In de bid zit de advertentie-ID (device.ifa), plus land, netwerkcode (mccmnc), carrier, taal en locatie, samen met de IAB-toestemmingsstring en de package-naam van de app. Het volledige profiel dat je toestel aanlevert, ongefilterd de veiling in.
Toon de velden in de bid-request
| Veld | Wat het over je prijsgeeft |
|---|---|
| Wie je bent | |
| device.ifa | je advertentie-ID, een uniek nummer dat je toestel identificeert |
| user.ext.eids | de Infoplaza-PPID: een cross-app identiteit die een reset van je advertentie-ID overleeft |
| app.bundle | de package-naam van de app (org.yoki.android.buienalarm) |
| app.publisher.id | de PubMatic-publisher die de advertentieplek aanbiedt |
| Waar je bent | |
| device.geo | je locatie; op een echt toestel je precieze breedte- en lengtegraad |
| device.country | je land |
| device.carrier | je telefoonmaatschappij |
| device.mccmnc | je netwerkcode (land plus operator) |
| device.ip | je IP-adres |
| Welk toestel | |
| device.make / model | merk en model van je telefoon |
| device.os | besturingssysteem en versie |
| device.ua | de user-agent, een kenmerk van app en toestel |
| device.lmt | de "Limit Ad Tracking"-stand; in mijn capture stond die uit |
| Wat je toestemde | |
| user.ext.consent | je IAB TCF-toestemmingsstring, zelf een persoonsgegeven |
| regs.ext.gdpr | of de AVG van toepassing is (1 = ja) |
| Welke advertentieplek | |
| imp.tagid | de advertentie-eenheid, bijvoorbeeld /7571/Buienalarm_NL/.../BannerFooter |
Uit de gedecrypteerde OpenRTB 2.5-bid van Buienalarm en Marktplaats. Op een echt toestel staan in deze velden jouw werkelijke waarden; in mijn emulator-capture deels testwaarden (zie de eerlijke grens hierboven).
De last is ook in volume zichtbaar. In een gebruikssessie ging 87% van alle netwerkverzoeken en 54% van alle bytes naar de advertentie- en trackingketen, tegenover ongeveer 0,2 MB echt weerverkeer. Je betaalt databundel om advertenties op te halen, niet om het weer te zien.
Waar het heen gaat (gemeten)
De bid gaat naar PubMatic (OpenWrap), een advertentie-exchange. Vanaf daar wordt jouw plek doorgeveild aan de meebiedende partijen, die elk het profiel zien. Buienalarm staat daarnaast in de gelekte Gravy-lijst: een databroker die uit de bidstream oogst, doorgaans zonder dat de uitgever het weet.
Toon de gecontacteerde advertentiepartijen
| Partij | Endpoint | Rol |
|---|---|---|
| De veiling | ||
| PubMatic OpenWrap | ow.pubmatic.com/openrtb/2.5 | de advertentieveiling in je toestel |
| Boden mee en zagen je profiel (uit de veiling) | ||
| Xandr (AppNexus) | via de veiling | biedende SSP/DSP |
| Criteo | via de veiling | biedende DSP |
| GroupM | via de veiling | biedende inkooporganisatie |
| Improve Digital | via de veiling | biedende SSP |
| Index Exchange | via de veiling | biedende SSP |
| Magnite (Rubicon) | via de veiling | biedende SSP |
| Direct door je toestel gecontacteerd (identiteitskoppeling) | ||
| Xandr | ib.adnxs.com | cookie-sync |
| Index Exchange | dsum-sec.casalemedia.com | cookie-sync |
| TripleLift | eb2.3lift.com | cookie-sync |
| Equativ | rtb-csync.smartadserver.com | cookie-sync |
| Andere demand, direct | ||
| Google Ad Manager | pubads.g.doubleclick.net | advertentieserver en cookie-matching |
| Meta Audience Network | web.facebook.com/adnw_sync2 | demand van Facebook |
| Outbrain | b1t-dubdc2.outbrain.com | native advertenties en tracking |
| Teads | static.teads.tv | video-advertenties |
| Toestemming (per app) | ||
| Didomi | sdk.privacy-center.org | toestemmingsbeheer bij Buienalarm |
| Sourcepoint | in-app CMP | toestemmingsbeheer bij Marktplaats |
| Usercentrics | api.usercentrics.eu | toestemmingsbeheer bij 9292 |
Waargenomen in de gedecrypteerde Buienalarm-capture (de meest complete); Marktplaats toont dezelfde structuur via PubMatic OpenWrap plus een Prebid Server. De biedende partijen komen uit de seatbid van de veiling.
Keten 2 · Marktplaats: scrollen kost je de helft van je bundel
’s Avonds op de bank, even over Marktplaats scrollen naar een tweedehands fiets. Bij elke listing en in de feed laadt de app advertenties, en stuurt het toestel bid-requests naar PubMatic OpenWrap, met een Prebid Server ernaast. Ook deze bid heb ik gevangen en ontcijferd: dezelfde structuur, advertentie-ID plus het volledige device-profiel.
Maar bij Marktplaats is de kosten-kant het scherpst. Ik mat het dataverbruik twee keer onder identieke omstandigheden: een keer met de advertentiedomeinen toegestaan, een keer geblokkeerd. Het verschil is de pure advertentie-overhead.
Wat het je bundel kost (gemeten)
Tien minuten scrollen kostte met advertenties ongeveer 15 MB, zonder de advertentiedomeinen ongeveer 2 MB. Het overgrote deel van wat de app je bundel kost tijdens gebruik, ongeveer 85%, is de advertentie- en trackinglaag. De listings die je zoekt zijn een kleine fractie. Een deel van die 85% is de zichtbare advertentie zelf (het gratis-app-model), een deel is onzichtbare bied- en trackingoverhead die jou niets oplevert. De harde ondergrens van pure tracking-calls was ongeveer 5%.
Keten 3 · 9292: de schone app die toch in de broker-lijst staat
’s Middags je trein plannen met 9292, de OV-reisplanner van Infoplaza. En hier wordt het verhaal genuanceerder, want 9292 is juist schoon in verbruik: in mijn meting was maar ongeveer 1% van het dataverkeer klassieke advertentie-/trackingdata. Een OV-utility eet je bundel niet op zoals een feed-app dat doet. Dat is het eerlijke contrast: niet elke app is een bundelvreter.
En tóch staat 9292 in de gelekte Gravy-lijst van de databroker. Dat is de kern van keten 3: een app kan relatief licht zijn in verbruik en tegelijk je gegevens bij een broker laten belanden. 9292 is bovendien het anker dat de broker-lijst verbindt met de Infoplaza-familie, dezelfde uitgever als Buienalarm.
Het mechanisme-onderscheid (streng)
Er zijn twee manieren waarop je gegevens bij een broker komen, en die horen niet op een hoop. De ene is bidstream-oogst: een broker als Gravy verzamelt uit de advertentieveiling, doorgaans zonder dat de uitgever het weet. De andere is een ingebouwde SDK: bij sommige apps (zoals de jRustonApps-weerserie) zit een locatie-SDK uit de X-Mode/Sense360-familie die de uitgever zelf heeft ingebouwd. Het eerste overkomt de uitgever, het tweede is een keuze van de uitgever.
De status van 9292 blijft eerlijk: het staat in de Gravy-lijst en het ad-verkeer is waargenomen, maar de eigen bid met de 9292-package heb ik niet gevangen. Daarvoor zou ik een geroot toestel nodig hebben. Dus 9292 staat op lijst-vermelding plus waargenomen verkeer, niet op een eigen ontcijferde bid.
Keten 4 · Buienradar: dezelfde markt, andere route
’s Ochtends even Buienradar (van RTL Nederland, sinds de overname onder DPG Media) openen om te zien of je droog wegkomt. Ook hier laadt de app een advertentie. Maar als je nu naar het netwerkverkeer kijkt, mist er iets: er vertrekt geen zichtbare bid-request uit je toestel. Geen PubMatic, geen veiling-in-je-telefoon. Het toestel praat voor advertenties alleen met Google.
Dat lijkt schoner, en op één punt is het dat ook. Maar het is vooral een andere route. De advertentieveiling draait niet in je toestel maar server-side bij Google (Ad Manager, Open Bidding); jij ziet alleen de winnaar. Je profiel wordt niet zichtbaar de ether in geschoten, het wordt bij Google verhandeld, daar waar je het niet kunt onderscheppen.
En “schoner” betekent hier niet “zonder identifier”. De app leest gewoon je advertentie-ID, vraagt achtergrondlocatie (met geofencing, waarschijnlijk voor regen-alarm, maar het blijft een brede toestemming) en omarmt Google’s nieuwe advertentie-API’s (Topics, Attribution). De advertentiebeelden komen via LemonPI, een Nederlands platform voor dynamische advertenties uit Eindhoven.
Wat erbij komt: een eigen meetlaag (uit de APK)
Buienradar draagt boven op Google nog een laag die de andere apps niet zo hebben: een eigen, door DPG en RTL gehoste meetpijplijn (Snowplow) die je schermgedrag, je scrollen en je locatie-context vastlegt, plus Kantar NMO, het Nationaal Media Onderzoek, dat een gebruikers-ID naar Kantar stuurt voor de kijkcijfers. Toestemming loopt via OneTrust, met de IAB-toestemmingsstring plus Google’s eigen partnerlijst, achter de bekende betalen-of-toestemmen-muur.
Toon de diensten en endpoints van Buienradar
| Dienst | Endpoint | Rol |
|---|---|---|
| Advertenties (Google) | ||
| Google Ad Manager | googleads.g.doubleclick.net | server-side veiling en advertentieserver |
| IMA SDK | imasdk.googleapis.com | video-advertenties |
| OMID | in de Google-SDK | viewability-meting |
| Privacy Sandbox | Android-API | Topics, Attribution en de advertentie-ID |
| LemonPI | *.lemonpi.io | dynamische advertentiebeelden (via Google) |
| Toestemming | ||
| OneTrust | mobile-data.onetrust.io | CMP: IAB TCF v2 plus Google Additional Consent |
| DPG Media | c.dpgmedia.net | betalen-of-toestemmen-muur en config |
| Meting (eerste-partij, DPG en RTL) | ||
| Snowplow | nl-rtl-prod1.collector.snplow.net | schermgedrag, scroll, locatie-context (DPG-schema's) |
| Firebase | crash en remote config; analytics standaard uit | |
| Kantar NMO | nmortlendpoint.2cnt.net | kijkonderzoek, stuurt een gebruikers-ID |
| Overig | ||
| Usabilla | sdk.out.usbla.net | feedback en enquêtes (VS) |
| Swrve | *.swrve.com | engagement- en push-campagnes |
| Bitmovin | licensing.bitmovin.com | videospeler |
| RTL-account | account.rtl.nl | login en identiteit |
| Opvallende permissies | ||
| Achtergrondlocatie | Android | plus geofencing (regen-alarm of profilering) |
| Install-referrer | Play Store | installatie-attributie |
Uit de statische analyse van de APK (apktool plus jadx), gekruist met mijn eigen netwerkcapture. Géén PubMatic, Prebid, Meta, Outbrain of Criteo aangetroffen: de inventaris bevestigt de Google-only architectuur.
Nog één: VI
VI (Voetbal International) doet iets dat de andere niet zo openlijk doen: het stuurt je advertentie-ID rechtstreeks naar een databedrijf. In mijn capture ging je advertentie-ID naar Lotame (crwdcntrl.net), een Data Management Platform dat profielen over apps en sites heen bouwt, georkestreerd via het Nederlandse advertentienetwerk Next Day Media. Daarnaast meet VI je mee met comScore, serveert advertenties via Google Ad Manager, en draait de eigenlijke veiling via een Prebid Server bij Magnite. VI staat ook in de Gravy-lijst. Wat ik hier zag is dus niet alleen een veiling, maar een rechtstreekse levering van je identifier aan een profielenbouwer.
Waarom je dit niet op je eigen toestel kunt zien
Er zit een ongemakkelijke kant aan dit onderzoek: je kunt zelf bijna niet controleren wat je apps versturen, en dat is zo ontworpen.
Sinds Android 7 (2016) vertrouwen apps voor hun beveiligde verbindingen standaard alleen de certificaten van het systeem, niet die jij als gebruiker zelf installeert. Wie het bid-verkeer wil meelezen wordt genegeerd, tenzij je je toestel “root”, en dat verzwakt de beveiliging van je telefoon juist. Dat geldt voor het bid-verkeer van Buienalarm, Marktplaats en VI; VI zet er bovendien code-pinning overheen. De keten die je gegevens doorverkoopt is daarmee precies de keten die je niet mag inzien.
Daarom legde ik het gedrag vast op een emulator en mat ik de Nederlandse identiteit los op een echt Odido-toestel. De plek waar dit zichtbaar wordt is een ingerichte testopstelling, niet je eigen telefoon, en dat is precies het punt.
Wat je kunt doen · Trek de stekker uit het profiel, niet uit de app
- Reset je advertentie-ID en schakel advertentiepersonalisatie uit in de Android-instellingen. Het breekt de koppeling tussen je gedrag en een vast nummer.
- Weiger toestemming waar dat kan. Herken een betalen-of-toestemmen-muur als een keuze die je mag afslaan.
- Dien een inzageverzoek (AVG artikel 15) in bij de exchange en de brokers, om te zien welke gegevens zij aan je advertentie-ID koppelen.
- Weet welke apps je bundel opeten. De feed- en content-apps doen dat onevenredig; de utilities zijn vaak licht. Je hoeft ze niet weg te gooien, wel bewust te gebruiken.
Hoe hard is elke laag?
| Bevinding | Hardheid | Beste bron |
|---|---|---|
| Buienalarm stuurt RTB-bid met identifier + profiel | hard | eigen gedecrypteerde bid |
| Marktplaats stuurt RTB-bid met identifier + profiel | hard | eigen gedecrypteerde bid |
| Marktplaats ~85% verbruik is ad-laag (in-sessie) | hard | eigen twee-runs-meting |
| 9292 ~1% ad-laag (schone utility) | hard | eigen twee-runs-meting |
| 9292 / Marktplaats / VI in databroker-lijst | hard | Gravy-lijst (404 Media) |
| VI stuurt advertentie-ID naar Lotame (DMP) | hard | eigen capture (crwdcntrl.net) |
| Buienradar Google-only, veiling server-side | hard | eigen capture + statisch |
| Bid onvangbaar zonder root (systeem-CA) | hard | NSC-analyse + Android-docs |
| NL-waarden organisch op echt toestel | redenering | baseline + bewezen gedrag |
| 9292 eigen bid (package-niveau) | open | vereist geroot toestel |
| Buienradar / VI overhead-percentage | open | vereist schone WiFi-meting |
| Maand- en accu-impact cumulatief | schatting | doorrekening met aannames |
Methode (voor wie het zelf wil nalopen)
Het toestelprofiel (Bewijs A) is read-only van een fysiek toestel gelezen met getprop: model SM-A528B, simkaart-netwerkcode 20416 (Odido), taal nl-NL, geen enkele hook. Het gedrag (Bewijs B) is op een Android-emulator vastgelegd met mitmproxy als onderschepper, met een veld-voor-veld-analyse op de ontcijferde OpenRTB-bid; elke bid is gecontroleerd tegen de package die hem hoort te versturen. De grens is bepaald met statische analyse van de network_security_config van elke app. Een onafhankelijke verificatielaag herscoorde alle captures met een strengere tool en zette overclaims terug; geen enkele bevinding is als gebonden bewijs op een echt toestel geclaimd. De overhead is gemeten met een twee-runs-vergelijking (met en zonder advertentiedomeinen) onder identieke omstandigheden.
Wat nog open staat (onderzoeksagenda)
Een eerlijk onderzoek laat zien waar het ophoudt. Dit zijn de open einden, en wat elk ervan vergt om te sluiten.
- Het overhead-percentage van Buienradar en VI. De architectuur is bekend (Buienradar veilt server-side bij Google, VI levert je advertentie-ID aan Lotame), maar een schoon “zoveel procent van je bundel”-getal heb ik er niet voor. Mijn twee testruns waren niet gelijk van lengte, en een deel van het advertentieverkeer liep over een protocol (QUIC) dat mijn meetpunt passeert. Dat sluiten vergt een meting over wifi met de radio actief, twee gelijke runs.
- De eigen bid van 9292 op package-niveau. 9292 contacteert wel PubMatic en Google, en staat in de Gravy-lijst, maar een eigen ontcijferde bid met de 9292-package heb ik niet. Daarvoor is een geroot toestel nodig.
- De koppeling op een echt toestel (de NL-identiteit in de bid). Dat een precieze locatie en je advertentie-ID de veiling in gaan, is aangetoond. Dat op jouw eigen toestel jouw unieke advertentie-ID met de Nederlandse netwerkwaarden in één bid samenkomt, vergt root, en dat heb ik bewust niet op mijn dagelijkse toestel gedaan.
- De andere kant van de keten (inzageverzoeken). De brug tussen “ik zag het de veiling in gaan” en “een broker bevestigt dat hij het heeft” loopt via een AVG artikel 15-verzoek met de advertentie-ID van een echt toestel. De brieven liggen klaar (PubMatic, Lotame, Eskimi, Datasys, Infoplaza); versturen kan alleen met een echte identiteit.
- De accu- en maandkosten. De data-overhead is hard gemeten; de vertaling naar accuslijtage en een maandtotaal is een doorrekening, geen meting. De energiemeting zelf was ruis omdat de testopstelling de radio idle hield.
Bronnen en verantwoording
- Databroker-lijst (Gravy). Geëxtraheerd en gepubliceerd door 404 Media uit de Gravy Analytics-hack (januari 2025), 12.372 apps, door mij gefilterd op Nederlandse packages en uitgevers (19 NL-treffers, waaronder 9292, Marktplaats en VI). Een vermelding betekent dat de app-data in de Gravy-dataset opdook via de advertentieketen, niet per se een directe relatie tussen de app-maker en Gravy.
- X-Mode / Outlogic-lijst. Uit het Xoth-onderzoek van ExpressVPN, bron voor het SDK-mechanisme bij de jRustonApps-serie.
- Systeem-CA sinds Android 7. Android Developers, network security configuration (
developer.android.com/privacy-and-security/security-config) en de Android Developers Blog, juli 2016. - Context. De Databroker Files (netzpolitik.org en BR) en de FTC-orders tegen Mobilewalla en Gravy Analytics, december 2024.
- Standaarden. OpenRTB 2.5 (IAB Tech Lab) voor de bid-structuur, IAB TCF voor de toestemmingsstring.
- Genoemde partijen. Lotame is een Data Management Platform (
crwdcntrl.net); Next Day Media een Nederlands advertentienetwerk; LemonPI een Nederlands platform voor dynamische advertenties uit Eindhoven. Rollen geverifieerd via openbare bedrijfsbronnen.
De technische bevindingen (de gedecrypteerde bids, het toestelprofiel, de overhead-metingen) zijn eigen metingen uit juni 2026, gehasht bewaard en reproduceerbaar. De databroker-vermeldingen komen uit de bovengenoemde openbare bronnen.