Felsökning

När det inte funkar.

Konkreta lösningar på vanliga installations- och driftsproblem. Klistra in det som matchar din symptombeskrivning, eller hoppa direkt till sektionen via menyn nedan.

"Loading the script violates the Content Security Policy"

Symptom
Du har klistrat in koden men inget händer. Browserns konsol visar något i stil med:
Loading the script 'https://sparlos.se/script.js' violates the
following Content Security Policy directive: "script-src 'self'".
Orsak
Din sajt skickar en Content-Security-Policy-header som bara tillåter skript från det egna domännamnet. Browsern vägrar därför ladda vår tracker. Det här är en sak du som sajtägare har slagit på (eller ärver via en hosting-leverantör som Vercel, Netlify eller Cloudflare Pages).
Lösning

Rekommenderat: lägg till sparlos.se *.sparlos.se i din CSP.

Bare apex + wildcard subdomän framtidssäkrar mot att vi flyttar trackern till en dedikerad subdomän (t.ex. cdn.sparlos.se eller events.sparlos.se) utan att du behöver röra din CSP igen.

Variant 1: Har du bara default-src?

En rad räcker. default-src är fallback för alla fetch-direktiv som inte är explicit satta.

Content-Security-Policy:
  default-src 'self' sparlos.se *.sparlos.se;

Variant 2: Har du explicita script-src och connect-src?

Vanligt på säkerhetsmedvetna sajter (Vercel-default, banker, vård). Då åsidosätts default-src per direktiv och du måste lägga till Spårlös i båda.

Content-Security-Policy:
  script-src 'self' sparlos.se *.sparlos.se;
  connect-src 'self' sparlos.se *.sparlos.se;
  • script-src tillåter att <script>-taggen laddas.
  • connect-src tillåter att trackern POST:ar event till /api/event. Utan denna laddas skriptet men varje pageview blockeras separat.
  • Använder du script-src-elem eller connect-src-elem explicit? Lägg till Spårlös där också, de override-ar script-src och connect-src i sin tur.

Var lägger du CSP-headern? I din web-servers konfig (nginx, Apache), i en middleware/route (Next.js, Express), eller i ett <meta http-equiv="Content-Security-Policy">-tagg i HTML-headen. Spelar ingen roll vilken metod, addresseringen är samma.

Föredrar du explicit protokoll (vissa security-policys kräver det)? https://sparlos.se https://*.sparlos.se fungerar identiskt på HTTPS-sajter. Bare-host-versionen ovan ärver protokollet från sidan, vilket alltid är HTTPS i prod.

Om du inte kan följa lösningen
Om CSP är låst av IT och du inte kan ändra: använd vår WordPress-plugin (proxy-läge serverar skriptet via din egen domän), eller självhosta skriptet på samma domän som din sajt (ladda ner script.js en gång, serva från https://din-sajt.se/script.js; connect-src till sparlos.se måste fortfarande vara tillåtet).

Adblockers blockerar trackern

Symptom
Du själv ser inga pageviews när du besöker din sajt, men kompisar utan adblocker gör det. Browser-konsolen visar typiskt net::ERR_BLOCKED_BY_CLIENTscript.js eller /api/event.
Orsak
uBlock Origin, AdGuard, Brave Shields, Privacy Badger och NoScript matchar kända analytics-hostnamn (inklusive sparlos.se) på sina blocklistor. Det är ironiskt eftersom vi är cookie-fria, men de listorna är konservativa och matchar på domännamn snarare än beteende.
Lösning

För WordPress-sajter: använd vår WordPress-plugin med proxy-läge på (default). Skriptet och event-endpointen serveras då via din egen domän, vilket adblockers inte kan matcha utan att blockera hela din sajt.

För andra ramverk: bygg själv en reverse proxy:

# Next.js / Vercel: src/app/sparlos/script.js/route.ts
export async function GET() {
  const upstream = await fetch('https://sparlos.se/script.js');
  return new Response(await upstream.text(), {
    headers: {
      'content-type': 'application/javascript',
      'cache-control': 'public, max-age=3600',
    },
  });
}

Plus en parallell route för /sparlos/event som proxar POST till https://sparlos.se/api/event med visitorens IP i x-forwarded-for-headern (vi behöver den för länderslookup, slänger den direkt efter).

Om du inte kan följa lösningen
Acceptera bortfallet. Internationell undersökning: ~30-40% av tech-publik kör adblocker, 10-15% bland generell publik. Om din målgrupp INTE är utvecklare/tech är förlusten under 15%, vilket fortfarande slår GA4 + cookie-banner som tappar 30-60% mobil.

Skriptet laddas men ingen data syns på dashboarden

Symptom
Du har installerat skriptet, det syns i view-source, browsern laddar det utan fel, men dashboarden visar 0 sidvisningar.
Lösning

Gå igenom listan i denna ordning:

  1. Kontrollera site_id. Öppna view-source och leta upp <script data-site="...">. Site-ID:t måste matcha det som visas på din sajts inställningssida i Spårlös. Vanlig miss: klistrar in fel sajts kodsnutt.
  2. Vänta 30 sekunder och reloada. Dashboarden uppdateras inte i realtid utan polling var 5:e sekund. Första pageview ska dyka upp i Live-vyn inom 30 sek.
  3. Aktiverat DNT eller GPC? Vi respekterar Do Not Track och Global Privacy Control både på klient- och serversidan. Om DU har det aktiverat i din browser räknas inte dina besök. Testa i en annan browser eller stäng av DNT/GPC tillfälligt för verifiering.
  4. Använder du en bot-likadan User-Agent? Vår bot-filter dropar GPTBot, ClaudeBot, headless Chrome, Playwright och 50+ andra. Om du testar med curl eller en automation-tool räknas inte requesten.
  5. Klicka "Testa installation" på snutten. Vi har en knapp på sajtens inställningssida som faktiskt går ut och hämtar din hemsida för att verifiera att kodsnutten är där OCH att vi har sett pageview-events från ditt site_id den senaste timmen.
  6. CSP eller adblocker? Se sektionerna CSP och Adblockers ovan.
  7. Localhost? Se Test på localhost nedan. Vi bailar default på localhost och privata IP-adresser.
  8. Path-blocklist? Om du har konfigurerat path-blocklist i sajtens inställningar och din testsida matchar ett mönster (t.ex. /admin/*) ignoreras requesten silent.

Cloudflare WAF eller rate limit blockerar event

Symptom
Skriptet laddas, en del events kommer fram men inte alla. Eller du ser 403 Forbidden / 429 Too Many Requests i Network-fliken för /api/event.
Orsak
Cloudflare Bot Fight Mode, en WAF-regel eller en rate-limit-regel träffar event-requesten. Vanligaste orsaken: en regel som blockar cross-origin POST-requester eller en aggressiv bot-detection som taggar trackern som "challenge-required".
Lösning
  • Allow-lista sparlos.se som origin i din WAF.
  • Om du har en rate-limit-regel på /api/event (varför skulle du det? det är vår endpoint, inte din), ta bort den.
  • Bot Fight Mode: lägg till en bypass-regel för Spårlös-trackerns User-Agent Sparlos-Uptime/1.0 (om du också använder uptime-monitor mot din egen sajt).
  • Cloudflare Workers: om du har en worker som modifierar requests, kontrollera att den inte stripar x-forwarded-for eller cf-connecting-ip headers (vi använder dem för länderslookup).

Trackern fungerar inte på localhost

Symptom
Du utvecklar lokalt mot http://localhost:3000 eller liknande och ingen pageview kommer fram.
Orsak
Trackern har en localhost-guard som bailar default. Det skyddar dig från att tankarna din produktions-dashboard med utvecklings-trafik som inte är representativ.
Lösning
Lägg till data-include-localhost="true" på script-taggen under utveckling:
<script defer
  data-site="DIN_SITE_ID"
  data-include-localhost="true"
  src="https://sparlos.se/script.js">
</script>

Glöm inte ta bort attributet innan deploy till prod. Annars riskerar du ditt teams localhost-test-trafik att räknas mot din månadskvot.

SPA med hash-routing (/#/route) räknar bara start-sidan

Symptom
Du driver en SPA byggd med React Router HashRouter, Vue HashHistory eller liknande. Dashboarden visar bara / oavsett vilken sida besökaren är på.
Orsak
HashRouter-URLer som /#/cart har alltid location.pathname === '/'. Vi har en safeguard som detekterar #/-mönstret och använder hash som pathname istället, men den triggas bara på hashchange-event.
Lösning

Modern SPA (React Router v6+ med BrowserRouter, Vue Router 4 med createWebHistory, Next.js, SvelteKit, Nuxt) hookar vi automatiskt via pushState/replaceState/popstate. Du behöver inte göra något.

För HashRouter eller andra exotiska patterns: anropa manuellt vid varje navigation:

window.sparlos = window.sparlos || {};
// Vid varje navigering i din SPA:
window.sparlos.pageview && window.sparlos.pageview();

För cart-drawer-pattern (modal som ändrar UX men inte URL), trigga ändå en pageview om du vill mäta interaktionen som en sida. Eller använd goal-tracking på en thanks-redirect-URL.

WordPress: alla sidor visas som /

Symptom
Du har installerat WordPress-pluginen, trafiken syns på dashboarden, men ALLA pageviews har sökväg / oavsett vilken sida besökaren faktiskt är på.
Orsak
WordPress är konfigurerat med "Vanliga" permalänkar (?p=123-URL:er). Då har varje sida tekniskt sökväg / i URL:en och vår tracker har inget annat att gå på.
Lösning
WordPress admin → Inställningar → Permalänkar → välj "Inläggsnamn" eller liknande, klicka Spara. Vår plugin visar en gul varning på sin egen inställningssida när vi detekterar att du kör Vanliga permalänkar, så den ska vara lätt att hitta.

Spårlös visar färre besökare än GA4

Symptom
Du kör Spårlös och GA4 parallellt och Spårlös visar 10-30% färre unika besökare.
Orsak
Inte en bug. Tre normala skillnader:
  • Vi filtrerar bort fler bottar. GA4 räknar trafik från GPTBot, headless Chrome, scrapers och liknande som riktiga besökare. Vi tar bort dem på ingest. Typisk skillnad: 5-15% av rå-trafiken.
  • Vi länkar inte besökare över dagar. Vår visitor-hash roterar dygnsvis (privacy-design). Om samma person besöker din sajt på måndag och tisdag är det 2 unika besökare hos oss, 1 hos GA4 (som lagrar persistent visitor-ID i cookie).
  • Vi respekterar DNT och GPC. GA4 räknar trafik från användare som har Do Not Track aktiverat. Vi gör det inte. Liten effekt (~5%) på generell publik, större på tech.
Lösning
Detta är inget att fixa. Det är skillnaden mellan privacy-first räkning och ad-tech räkning. Konsekvent är viktigare än "rätt" talet. När du börjar mäta med Spårlös är det den baseline du följer trender mot. Inga analytics-verktyg ger exakt samma siffror, inte ens GA4 mellan två fastigheter.

Sätter Spårlös cookies på besökarens enhet?

Symptom
Du ser en cookie i din browser och tror den är från oss, eller du behöver bekräfta för din compliance-person att vi verkligen inte sätter någon cookie.
Orsak
Vi sätter INGA cookies på besökarens enhet. Den enda cookien Spårlös sätter är authentication-cookien sparlos_session, och den sätts BARA när DU loggar in på dashboarden på sparlos.se. Den hamnar aldrig på dina besökares enheter eller din sajts domän.
Lösning

Öppna devtools på din sajt: Application → Cookies → https://din-sajt.se. Inga cookies med "sparlos" eller liknande ska finnas.

Cookies du ser kommer från andra källor: WordPress (wordpress_logged_in_*), Cloudflare (__cf_bm), Stripe (__stripe_mid på checkout-sidor), Google reCAPTCHA, Facebook Pixel, etc. Spårlös bidrar med noll.

Tracka subdomäner och flera sajter

Symptom
Du har blog.din-sajt.se och app.din-sajt.se som separata subdomäner och vill spåra dem antingen som EN sajt eller som SEPARATA.
Lösning

Som en sajt: använd SAMMA data-site="..." i kodsnutten på alla subdomäner. Sökvägar hamnar i samma dashboard, sortering visar var användarna landar oavsett subdomain.

Som separata sajter: skapa varsin sajt i Spårlös (med unik site_id per subdomain) och använd respektive ID. På Starter och uppåt är antalet sajter obegränsat så detta kostar inget extra.

Cross-subdomain visitor-tracking sker INTE oavsett vilken approach du väljer. Vår visitor-hash inkluderar site_id, så samma besökare som rör sig mellan blog.din-sajt.se och app.din-sajt.se räknas som två olika unika besökare. Det är medvetet (privacy-design).

Fortfarande inte löst?

Mejla [email protected] med en beskrivning av symptomet, vilken browser och version, och om möjligt en screenshot av Network-fliken. Vi svarar inom 24 timmar arbetsdag.

Tillbaka till dokumentationen

Sluta skicka data till USA. Börja idag.

Få samma insikter som från Google Analytics. Utan banner, utan cookies, utan juridisk huvudvärk.

Felsökning · Spårlös installation och kända problem | Spårlös