Trafficinator

Pragmatiskt verktyg för att generera analys‑trafik

analystestverktygmatomoga4

Varför jag byggde Trafficinator, hur det fungerar och hur du använder det för att säkert skapa realistisk webbtrafik för validering av analysimplementationer.

När man ofta levererar analysimplementationer behöver man till slut ett upprepbart sätt att skapa trafik som liknar verkligheten. Inte lasttester med 10 000 träffar per sekund — utan trovärdiga besök med varierande källor, UTM‑parametrar, user‑agents, sidvägar och tempo, så att du kan validera händelsemodeller, felsöka taggning och visa rapporter från början till slut.

Därför byggde jag Trafficinator.

Det är en liten, skriptbar trafikgenerator för analysingenjörer: förutsägbar när du vill, lagom kaotisk när du behöver, och försiktig så att den inte ställer till det. Den hjälper mig att verifiera Matomo/MTM‑upplägg (mitt standardval), GA4/GTM där det behövs, samt server‑side‑pipelines före och efter releaser.

Repository: https://github.com/Puttrix/Trafficinator

Nedan följer tankarna bakom, hur det fungerar på hög nivå och praktiska användningsmönster jag använder i vardagen.

Varför det finns

  • Validera end‑to‑end: Från tagg‑triggning → nätverksanrop → insamling → rapporter/instrumentpaneler.
  • Reproducera buggar: Generera exakt den väg + källa + enhetsmix som orsakade ett fel.
  • Migrerings‑paritet: Kontrollera mappning från UA/GA4 → Matomo med samma trafik‑seed.
  • Samtycke och integritet: Verifiera samtyckesstyrning, cookieless‑beteende och dataminimering.
  • Demo och utbildning: Så frön till rena dataset för workshops utan att klicka i timmar.

Designmål

  • Enkelt först: ett enda kommando skapar realistiska sidvisningar och valfria events.
  • Skriptbart: definiera scenarier som data (YAML/JSON), så kan de versionshanteras i Git.
  • Säkert som standard: hövligt tempo, slumpmässig jitter och skyddsräcken mot överbelastning.
  • Transparent: loggar med nog detaljer för att förstå vad som skickades och varför.
  • Portabelt: fungerar lokalt, i containers eller i CI/CD.

Hur Trafficinator fungerar (konceptuellt) Trafficinator går igenom en uppsättning “besök”. Varje besök simulerar en användarresa med:

  • En källprofil: direkt/hänvisning/UTM‑kombinationer (t.ex. utm_source=linkedin).
  • En enhetsprofil: desktop/mobil/surfplatta via rotation av user‑agent.
  • En vägplan: en sekvens av URL:er med vistelsetider och valfria event‑hooks.
  • Valfria geo‑hintar: t.ex. Accept-Language eller proxy‑headers om du styr kanten.

Under huven görs HTTP‑anrop (GET som standard) till angivna URL:er, med dina headers, query‑parametrar och fördröjningar. Om din analys laddas via en tagghanterare (Matomo Tag Manager, GTM) kommer tracker‑payloads att skickas naturligt när sidorna laddas; om du testar server‑side eller beacon‑endpoints direkt kan du även skicka konstruerade träffar i ett dedikerat steg.

Grundläggande användning

  1. Klona repot och läs README Repo: https://github.com/Puttrix/Trafficinator

  2. Konfigurera ett scenario Scenarier beskriver sidor, tempo och variation. En enkel (illustrativ) YAML kan se ut så här:

    # examples/launch-check.yml
site: https://example.com
visits: 25                 # hur många sessioner som ska köras
pace:
  minDelayMs: 800          # mellan sidvisningar
  maxDelayMs: 2500
sources:
  - type: direct
  - type: utm
    params:
      utm_source: linkedin
      utm_medium: social
      utm_campaign: q3_launch
  - type: referrer
    ref: https://news.ycombinator.com/
devices:
  - desktop
  - mobile
userAgents:
  desktop: ["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)…"]
  mobile:  ["Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)…"]
paths:
  - "/"
  - "/work"
  - "/about"
events:
  - when: path == "/work"
    send: click:cta

  3. Kör Beroende på verktygets gränssnitt (se repo‑README för korrekta flaggor):

    # Kör med ett scenario
trafficinator run examples/launch-check.yml

# Eller via Docker om det erbjuds
docker run --rm -v "$PWD:/app" ghcr.io/puttrix/trafficinator run /app/examples/launch-check.yml

Vad som kommer ut

  • Konsolsammanfattning av varje besök: källa, enhet, sidor, tid på sidan.
  • Valfria strukturerade loggar (JSON/CSV) för vidare analys.
  • Om aktiverat: summering av statuskoder och grundläggande timing för snabb hälsokoll.

Vanliga scenarier jag använder

  1. Kampanj‑QA före lansering

    • Så några dussin sessioner med mix av utm_source/utm_medium.
    • Verifiera att sessioner och konverteringar attribueras korrekt i rapporter.
    • Dubbelkolla stavning, versaler och oavsiktliga overrides.

  2. Samtyckesgränser

    • Kör en batch med samtycke, en utan.
    • Bekräfta dataminimering, lagring och händelsesuppression enligt policy.

  3. Migreringsparitet: GA4 → Matomo

    • Generera ett fast seed‑scenario och mata båda pipelines.
    • Jämför nyckelmetrik och händelseegenskaper för att validera mappningen.

  4. Vägbaserad felsökning

    • Sikta på problematiska flöden (t.ex. /checkout → /thank-you).
    • Använd långsammare tempo och mer detaljerade loggar för att fånga intermittenta fel.

Tips för trovärdig trafik

  • Slump med räcken: jitter i fördröjningar och rotera user‑agents, men inom rimliga gränser.
  • Håll volymerna mänskliga: dussin/hundratal — inte tusental — om du inte verkligen behöver last.
  • Separera staging vs prod: olika scenarier, olika API‑nycklar/containers vid behov.
  • Märk testtrafik: lägg till en igenkännbar UTM som utm_campaign=qa_ÅÅÅÅMMDD.

Matomo‑fokus Jag validerar oftast Matomo genom att ladda riktiga sidor som i sin tur laddar Matomo Tag Manager (denna sajt använder matomo.surputte.se). Behöver jag testa specifika händelse‑payloads eller server‑side‑enrichers kompletterar jag sidvisningar med explicita anrop till Matomos Measurement API och återanvänder samma besöks‑ID för sammanhängande sessioner.

Säkerhet och etikett

  • Respektera robots och rate limits. Även på egna domäner — var hövlig.
  • Undvik att belasta tredjepartsdomäner som dina sidor refererar till.
  • Om du måste testa i större skala, synka med drift/observability först.

FAQ F: Kör Trafficinator JavaScript som en headless‑browser? S: Fokus ligger på HTTP‑nivå och pragmatisk realism. För SPA/DOM‑tunga flöden som kräver JS‑exekvering, kombinera med headless‑tester för några guldvägar och använd Trafficinator för bulk och repeterbar seedning.

F: Kan jag peka den mot server‑side‑taggningens endpoints? S: Ja — att skicka direkta träffar är användbart för låg‑nivåtester. Se till att du inte förorenar produktionsdata och att samtyckesregler speglas.

F: Kan jag köra i CI? S: Ja. Checka in scenarier och kör små batcher på PR:er för att fånga regressioner (t.ex. saknade rutter, trasiga omdirigeringar eller tagg‑villkor).

Tankar framåt

  • Förstklassig scenariotemplating och variabler.
  • Inbyggda rapportsammanfattningar (t.ex. bounce rate, vägspridning) från loggar.
  • Valfritt headless‑läge för SPA‑flöden.

Avslutning Trafficinator finns för att göra validering av analys mindre tedious och mer tillförlitlig. Det är litet med flit, spelar fint med Matomo‑först‑stackar (och GA4 vid behov) och är lätt för kollegor att ta till sig.

Kika på koden och exemplen här: https://github.com/Puttrix/Trafficinator

Har du idéer, problem eller önskemål — öppna ett issue i repot eller pinga mig på LinkedIn. Happy testing!