Verdacht analyticsverkeer onderzoeken zonder echte bezoekers weg te filteren

Behandel een onverwachte verkeerspiek eerst als een onderzoeksvraag. Zoek meerdere onafhankelijke aanwijzingen voordat u verkeer als spam of automatisering uitsluit. Een kort bezoek, buitenlandse herkomst of afwijkende browser is op zichzelf onvoldoende bewijs dat een echte bezoeker ontbreekt.

Het doel is een bruikbare analyse zonder de geschiedenis mooier te maken. Sommige geautomatiseerde bezoeken horen bij normale infrastructuur, zoals zoekcrawlers of controlesystemen. Andere signalen kunnen vervalste meetberichten zijn die de website niet eens bezochten. Die verschillen vragen een andere technische verklaring.

Bepaal welk signaal werkelijk afwijkt

Maak eerst duidelijk of de piek in paginaweergaven, sessies, aanvragen of netwerkverzoeken zit. Deze maten hoeven niet even sterk te veranderen. Een bot die pagina's opvraagt en een vervalst analytics-event veroorzaken niet noodzakelijk dezelfde sporen.

Vergelijk met de definitie van uw marketingresultaten. Als geldige aanvragen stabiel blijven terwijl paginaweergaven sterk stijgen, verandert mogelijk vooral de verkeersnoemer. Dat kan een dalende conversieratio verklaren zonder dat de werkelijke vraag afneemt.

Noteer beginmoment, omvang en getroffen pagina's. Onderzoek ook normale oorzaken: een persvermelding, gewijzigde campagne of een technische controle. Een ongebruikelijk patroon is een aanwijzing, geen sluitende classificatie.

Gebruik meerdere aanwijzingen naast elkaar

Kijk waar rechtmatig beschikbaar naar timing, frequentie, routes, technische kenmerken en zakelijke uitkomsten. Een reeks met een zeer vast interval kan automatisering suggereren. Eenzelfde padvolgorde op grote schaal kan aanvullend bewijs geven. Geen van beide zegt vanzelf of de activiteit schadelijk is.

De HTTP-specificatie RFC 9110 beschrijft onder meer het User-Agent-veld. Een meegestuurde naam is geen sterke identiteit: software kan een waarde kiezen. Baseer een uitsluiting daarom niet alleen op de bewering dat een verzoek een bepaalde crawler is.

Beperk onderzoek tot gegevens waarvoor passende toegang en een doel bestaan. Verzamel niet achteraf uitgebreide persoonsprofielen omdat een verkeersgrafiek onduidelijk is. Technische beheerders kunnen geaggregeerde bevindingen delen zonder ruwe loggegevens breed te verspreiden.

Maak onderscheid tussen crawlers en meetspam

Een legitieme crawler kan pagina's ophalen voor indexering. Een uptimecontrole kan regelmatig één adres bezoeken. Dat is geautomatiseerde activiteit, maar hoeft geen fraude te zijn. Voor een analyse van menselijke belangstelling kan een uitsluiting toch passend zijn, mits de definitie helder is.

Google beschrijft hoe Google-crawlers geverifieerd kunnen worden. De documentatie maakt duidelijk dat alleen een herkenbare naam niet de volledige verificatie is. Deze methode is specifiek voor Google-crawlers en identificeert niet iedere mogelijke bot.

Meetspam kan op een andere laag ontstaan, bijvoorbeeld door ongewenste of verkeerd geconfigureerde meetberichten. Controleer daarom de meetconfiguratie naast serveractiviteit. Het ontbreken van een overeenkomstig paginaverzoek kan richting geven aan onderzoek, maar vraagt kennis van hoe uw eigen meetketen werkt.

Reken een fictieve piek zorgvuldig door

Fictief voorbeeld: een weekrapport toont 10.000 paginaweergaven en 200 geldige aanvragen. Een plotselinge reeks van 3.000 weergaven is verdacht. Technisch onderzoek bevestigt dat 2.400 daarvan afkomstig zijn van een verkeerd ingestelde eigen controle en volgens de vaste definitie buiten het publieksrapport vallen.

De gecorrigeerde telling is 10.000 − 2.400 = 7.600 paginaweergaven. De overige 600 verdachte weergaven blijven voorlopig aanwezig omdat bewijs voor uitsluiting ontbreekt. Het rapport benoemt hun onzekere status apart.

De ruwe verhouding aanvragen per paginaweergave is 200 / 10.000 = 2%. Na de bevestigde correctie is zij 200 / 7.600 ≈ 2,63%. Dit is geen persoonsconversieratio: één persoon kan meerdere pagina's bekijken. De correctie verandert bovendien geen van de 200 werkelijk geregistreerde aanvragen.

De bedragenloze oefening toont waarom de naam van een ratio belangrijk is. Een aantrekkelijker percentage na uitsluiting bewijst geen betere marketingprestatie; de telbasis is aangepast.

Scheid bevestigde en voorlopige uitsluitingen

Bewaar een bronlaag en pas regels toe in een afgeleid overzicht. De gids over meetdata opschonen legt uit waarom een ongewijzigde bron en wijzigingslog nodig zijn. Noteer de technische onderbouwing en het aantal getroffen registraties.

Voor onzekere gevallen kunt u een gevoeligheidsanalyse tonen: één stand met de groep en één zonder. Label de tweede stand als scenario. Kies niet automatisch de variant met het gunstigste rendement of hoogste conversiepercentage.

Pas een regel ook toe op relevante eerdere perioden als de bron en definitie dat toelaten. Anders kan een daling na de correctie alleen een meetbreuk zijn. Zet de datum van de nieuwe regel zichtbaar bij de reeks.

Herstel de bron als het eigen verkeer is

Bij eigen monitoring, tests of dubbele tags is voorkomen beter dan elke maand opnieuw verwijderen. Laat de bevoegde beheerder de oorzaak herstellen en voer daarna een gerichte controle uit. Bewaar het hersteltijdstip en de verwachte verandering.

Controleer ook normale gevallen. Een filter op één breed technisch kenmerk kan behalve testverkeer echte gebruikers raken. Test daarom een bevestigd ongewenst geval en een toegestaan geval dat erop lijkt. Het doel is een specifieke uitsluiting, niet een zo groot mogelijke daling.

Als de oorzaak onbekend blijft, benoem dat eerlijk. Een ontbrekende verklaring maakt een patroon niet automatisch kwaadaardig. Een rapport met een afgebakende onzekerheid is beter dan een stellige beschuldiging op basis van één grafiek.

Vertaal de bevinding naar een besluit

Volg bij grotere afwijkingen de aanpak voor marketinganomalieën. Maak duidelijk welke bedrijfsbeslissing geraakt wordt en of uitstel nodig is. Een kleine afwijking in paginaweergaven vraagt mogelijk alleen een voetnoot; een vervalste aanvraagtelling kan de operationele planning raken.

Toon in het dashboard de belangrijkste correctie met datum en betekenis. De technische detailanalyse kan in een bevoegde bijlage blijven. Sluit het onderzoek af met een eigenaar voor preventie en een concrete hercontrole, zodat de volgende piek niet weer vanaf nul wordt onderzocht.

Bronnen en grenzen

• IETF: RFC 9110, HTTP-velden en hun betekenis.
• Google Search Central: Googlebot verifiëren, controle van specifieke Google-crawlers.

De cijfers en eigen controle zijn fictief. Deze gids biedt geen sluitende botdetector en verklaart geen werkelijke verkeerspiek zonder brononderzoek.