De wachtende tracker¶

Niet alle volgtechniek komt meteen in actie. Een deel wacht. Op een scroll, op verstreken tijd, op een klik, op het accepteren van consent, op een schermovergang. Bij het laden van de pagina lijkt er dan weinig aan de hand, terwijl het echte gedrag pas later begint. Dat is geen toeval. Veel scripts zijn met opzet zo gebouwd, om de pagina snel te laten laden en om pas te vuren wanneer er iets te meten valt over een echte gebruiker.

Voor mijn werk is dat het verschil tussen een oppervlakkig en een eerlijk beeld. Een meting die stopt zodra de pagina staat, ziet de brave helft van het verkeer. De wachtende helft blijft onzichtbaar. En juist die wachtende helft is vaak het interessantst, want daar zit de techniek die op gedrag reageert.

Waarom de eerste seconde bedriegt¶

Wie alleen de eerste seconde na het laden meet, ziet de brave helft en mist de wachtende. Dat geeft een te gunstig beeld en het is een makkelijke manier om jezelf voor de gek te houden. De afwezigheid van een tracker in seconde één is geen bewijs dat hij er niet is.

Het probleem verergert doordat de uitkomst overtuigend oogt. Een korte meting levert een korte lijst en een korte lijst leest als "het valt mee". De meting bevestigt de hoop van wie hem uitvoert. Precies daarom is dit een valkuil en geen toeval. De redenering sluit aan bij Een mislukte meting is geen schone app: een leegte in de meting is een uitspraak over de meting zolang je niet hebt gecontroleerd of je lang genoeg keek.

Er zit ook een technische reden achter de vertraging. Moderne pagina's laden hun code in fasen. Eerst komt het zichtbare deel, de tekst en de opmaak, zodat de bezoeker snel iets ziet. Zwaardere scripts worden pas daarna opgehaald, of pas wanneer een gebeurtenis ze aanroept. Analytics- en advertentiecode hangt vaak in die tweede golf. Voor de gebruikerservaring is dat verstandig, want de pagina voelt sneller. Voor mijn meting betekent het dat de eerste seconde structureel het lichtste beeld geeft dat er bestaat. Wie daar stopt, meet met opzet het gunstigste moment.

Waar de techniek op wacht¶

Uit het lezen van veel verkeer komt een klein aantal terugkerende triggers naar voren. Ik noem ze op bewijsniveau afgeleid, omdat ik ze herken aan het moment waarop het verkeer losbarst. De broncode van elk script lees ik daarbij zelden.

• Consent. Veel tags vuren pas na het accepteren van een cookiebanner. Weigeren of niets aanklikken geeft een ander beeld. Zie Cookies weigeren scheelt echt, maar reken er niet blind op.
• Scroll en tijd. Session-recording en sommige analytics starten na de eerste interactie of na een paar seconden op de pagina. Zie Session-recording legt je scherm-interactie vast, en maskering moet je bewijzen.
• Inloggen. Achter een login zit vaak verkeer dat de uitgelogde bezoeker nooit ziet.
• Schermovergang. In apps vuurt een deel van de techniek pas bij de tweede of derde schermwissel.

Hoe ik lang genoeg meet¶

Mijn antwoord is simpel van vorm en streng in de uitvoering. Ik laat een opname lang genoeg lopen en ik gedraag me als een gewone bezoeker. Ik vermijd de scanner-aanpak die na één seconde klaar is. Concreet houdt dat een vaste volgorde in:

1. Start de opname voordat de app of pagina opent. 2. Laat de pagina volledig laden en wacht daarna bewust nog een aantal seconden zonder iets te doen. Dit vangt de trackers die op verstreken tijd wachten. 3. Scroll rustig naar beneden, in stappen, zodat lazy-loading en scroll-triggers echt afgaan. 4. Voer de handeling uit die de dienst verwacht: inloggen, doorklikken naar een tweede scherm, een keuze maken. 5. Herhaal dit per toestemmingsmodus, zodat ik het gedrag zonder consent, na weigeren en na accepteren los kan vergelijken. Zie Meet zoals een bezoeker, niet zoals een scanner.

Elke stap heeft één doel: de techniek de trigger geven waarop ze wacht, zodat ze zichtbaar wordt in de opname.

Een tijdlijn uit een HAR halen¶

Om te controleren of mijn geduld iets opleverde, zet ik het verkeer op een tijdlijn. Ik reken elk request terug naar het aantal seconden na het eerste request en kijk wat er ná de eerste seconde nog bij kwam. Dat maakt de wachtende trackers zichtbaar als groep.

import json
from datetime import datetime

def laat_verlopen(pad, na_seconden=1.0):
    with open(pad, encoding="utf-8") as f:
        entries = json.load(f)["log"]["entries"]

    tijden = [datetime.fromisoformat(e["startedDateTime"].replace("Z", "+00:00"))
              for e in entries]
    t0 = min(tijden)

    laat = {}
    for e, t in zip(entries, tijden):
        offset = (t - t0).total_seconds()
        if offset > na_seconden:
            host = e["request"]["url"].split("/")[2].lower()
            laat.setdefault(host, []).append(round(offset, 1))

    print(f"Hosts die pas na {na_seconden}s begonnen:")
    for host, momenten in sorted(laat.items(), key=lambda x: min(x[1])):
        print(f"  {host}: eerste contact op {min(momenten)}s ({len(momenten)}x)")

laat_verlopen("meting.har")

Wat hier uitrolt, is precies de lijst die een opstart-meting had gemist. Een host die pas op seconde acht voor het eerst contact maakt, was in seconde één onzichtbaar. Zie het contact met dat gehost verkeer op zichzelf niet als bewijs van een tracker, want een naam of host is nog geen bewijs. Zie Een naam in de code is nog geen tracker. De tijdlijn vertelt me wanneer ik moet kijken, de duiding komt daarna.

De drempel van één seconde is bewust ruw. Ik gebruik hem om de wachtende groep als geheel zichtbaar te maken, en daarna verfijn ik. Vaak zie ik in de momenten-lijst clusters ontstaan: een golf rond het accepteren van consent, een golf na de eerste scroll, een golf na het inloggen. Die clusters koppel ik terug aan mijn eigen handelingen, die ik met tijdstempels heb bijgehouden. Zo verandert een platte lijst van hosts in een verhaal over welke handeling welke techniek wakker maakte. Die koppeling is het verschil tussen weten dat er iets laat vuurde en weten waaróm het laat vuurde.

Bewijsniveau: gemeten tot welk punt¶

De belangrijkste discipline die uit dit stuk volgt, is dat bij elke "0 gevonden" de vraag hoort: gemeten tot welk punt? Een leeg resultaat na een cold-start van drie seconden en een leeg resultaat na een ingelogde sessie van twee minuten met scrollen zijn totaal verschillende beweringen. De eerste is zwak, de tweede is sterk.

Die vraag stel ik niet als formaliteit. Ze bepaalt hoe hard de conclusie is. Twee onderzoekers kunnen dezelfde app meten en tot tegengestelde uitspraken komen, puur doordat de een na drie seconden stopte en de ander twee minuten doorging. Zonder de reikwijdte erbij zijn hun "0 gevonden" niet te vergelijken. Met de reikwijdte erbij zie je meteen dat de ene meting een flauwe aftasting was en de andere een serieuze test.

Daarom noteer ik bij elke uitkomst de reikwijdte van de meting: hoe lang liep de opname, welke handelingen deed ik, in welke toestemmingsmodus, hoe ver klikte ik door. Een bevinding is pas gemeten binnen die grenzen. Alles buiten die grenzen blijft onbekend. Een ingelogde, doorgeklikte meting is daarmee rijker dan een snelle cold-start, omdat ze de wachtende techniek de kans geeft zich te tonen. En pas als die kans er was, betekent een lege lijst iets.

Zie ook Meet zoals een bezoeker, niet zoals een scanner, Session-recording legt je scherm-interactie vast, en maskering moet je bewijzen en Een mislukte meting is geen schone app.