Glossary
Every metric and term in Satsu, defined in one place. The same definitions power the tooltips and “?” explainers inside the product — what you read here is what the dashboard says.
Web analytics
How Satsu stays cookielessSessions
A session groups the pageviews of one visit. Instead of a cookie or stored ID, Satsu derives a fingerprint on the server from the site, the visitor's IP, their browser, and the day — and that fingerprint changes at midnight. Nothing identifying is ever stored on the device, and a returning visitor tomorrow is a new visitor by design. This is why Satsu needs no cookie banner.
Visitors
Visitors counts unique people, derived from the same daily-rotating fingerprint as sessions. Within one day, repeat visits by the same person count once; because the fingerprint rotates at midnight, the same person tomorrow counts as new. Slightly higher visitor counts than cookie-based tools are expected — that's the privacy trade, not a bug.
Pageviews
Pageviews count every page load, including repeat views of the same page. The ratio of pageviews to visitors is a quick read on depth: close to 1 means people leave after one page; higher means they move through the site.
Bounce rate
The share of sessions that viewed exactly one page and triggered nothing else. A high bounce rate isn't automatically bad — a blog post can answer the question on the first page — but on landing and product pages it usually means the page didn't match what the visitor came for.
Visit duration
The average time between the first and last signal of each session. It's measured from real activity, not an idle timer — a tab left open in the background doesn't inflate it. Single-page visits with no further signals contribute zero, so this number reads best together with bounce rate.
Custom events
Custom events are the actions you decide to measure — signups, purchases, plan upgrades — fired with a single call to the tracker. They carry a name and optional properties, and no personal data. Goals build on them: define a goal on an event name and conversion tracking comes for free.
Sources
Sources shows where visits come from, two ways. Channels group arrivals by kind — search engines, AI assistants, social, referral links, and Direct for visits with no referrer information at all. Referrers name the exact sites that linked to you. AI is its own channel because assistant traffic behaves differently — and clicking any row filters the whole dashboard.
Live
Live shows visitors active in the last minute, based on lightweight heartbeats the tracker sends while a page is open. Presence is held in memory and expires within seconds — it is never written to the analytics store and never counts against your event quota.
AI suite
The AI suite explainedAI traffic
AI traffic measures how AI assistants send people to your site: which assistants (ChatGPT, Claude, Perplexity, …) referred how many visitors, what share of all sessions had at least one AI touch, and the external clicks whose source the browser hid. Assistant answers are becoming a first-class acquisition channel — this tile is where you see whether that's happening to you.
AI-influenced
A session counts as AI-influenced when at least one of its arrivals came from an AI assistant — including visits that started elsewhere and returned via an assistant later. It's a reach measure, deliberately wider than the AI channel's first-source count: it answers how much of your traffic AI touches at all.
AI crawlers
Counts AI bots observed loading your tracker: live fetches, where an assistant pulls a page because a human just asked, and bulk crawlers sweeping for training or search indexes. It's deliberately framed as a sampled signal — AI bots don't execute scripts and fetch inconsistently, so real crawling is higher and a zero proves nothing.
Live fetches
Live fetches come from the assistants' user-triggered bots (ChatGPT-User, Claude-User, …): a real person asked something and the assistant fetched your page to answer. That makes them the most valuable crawl signal — your content is being read into live AI answers, moments before a human sees them.
Crawlers
Bulk crawlers (GPTBot, ClaudeBot, PerplexityBot, …) sweep sites to build training data and assistant search indexes. They don't mean a human saw your content — but being crawled is the precondition for showing up in AI answers later. Robots.txt controls which of them you allow.
AI citations
Citation monitoring asks the assistants the questions your customers would ask, then records the verdict per prompt: cited (your URL linked), mentioned (named but not linked), or absent. Each positive verdict stores the assistant's actual wording as proof. Ranking in AI answers is the new page one — this tells you whether you're on it.
Visibility
Visibility is the share of all citation checks in which an assistant names your site, whether cited with a link or merely mentioned. It's the one-number trend to watch: rising visibility means assistants increasingly carry you in their answers; the per-prompt verdicts below show exactly where you're absent.
Performance & Core Web Vitals
The performance audit explainedCore Web Vitals
Core Web Vitals are the industry-standard metrics for real-user experience: LCP for loading, INP for responsiveness, and CLS for visual stability. Search engines use the field data — real visitors, not lab tests — as a ranking signal. Satsu collects them anonymously from your actual traffic, so these numbers are the ones your ranking is judged on.
Performance audit
Runs Lighthouse, the open-source page-speed tool, against your pages in a controlled lab environment and grades speed on a 0–100 score, with the biggest fix opportunities ranked by estimated savings. Lab conditions are reproducible, which makes them ideal for before/after comparisons — the Web Vitals tab shows what real visitors experience. 90 and above counts as fast.
Lighthouse
Lighthouse is the open-source auditing engine that powers most page-speed tools, including Chrome DevTools and PageSpeed Insights. It loads each page in a controlled browser, measures the lab metrics, and turns them into the 0–100 performance score. Satsu runs it against your pages on a schedule so regressions surface without anyone remembering to test.
Lighthouse score
The Lighthouse performance score condenses lab metrics — LCP, TBT, CLS, FCP and Speed Index among them — into one weighted 0–100 number, the same grade Chrome DevTools and PageSpeed Insights report. 90 and above counts as fast, 50–89 as needs work, below 50 as slow. Treat it as a compass, not a target: fixing the listed opportunities is what moves it.
Lab data
Lab data comes from loading your pages in a controlled environment with a fixed device and network profile. Because conditions never change, two runs are comparable — perfect for checking whether a fix worked. What it can't tell you is how real visitors experience the site; that's field data, on the Web Vitals tab.
Field data
Field data is collected from real visits: actual devices, networks, and behavior. It's the ground truth for user experience and the data search rankings judge Core Web Vitals on. The trade-off is noise — traffic mix shifts move the numbers — which is why lab data exists for controlled comparisons. Satsu collects field data anonymously, without cookies.
p75
A p75 value means 75% of visits were at least this fast — the same statistic Core Web Vitals ratings are based on. It is deliberately stricter than an average: a handful of fast visits can't mask many slow ones, and a single outlier can't ruin the number either.
Largest Contentful Paint (LCP)
Largest Contentful Paint measures how long the biggest visible element — usually a hero image or headline — takes to appear after navigation. It is one of the Core Web Vitals and a search ranking signal: under 2.5 s counts as good, above 4 s as poor. Slow LCP usually points to a slow server, render-blocking assets, or oversized images.
Interaction to Next Paint (INP)
Interaction to Next Paint measures the delay between a user interaction — a click, tap, or key press — and the next visual update. It replaced First Input Delay as a Core Web Vital in 2024: under 200 ms counts as good, above 500 ms as poor. High INP means long JavaScript tasks block the main thread; in lab audits, where no real interactions exist, TBT stands in for it.
Cumulative Layout Shift (CLS)
Cumulative Layout Shift scores how much visible content unexpectedly moves while the page loads — the effect that makes you click the wrong button. It is a Core Web Vital: under 0.1 counts as good, above 0.25 as poor. Common causes are images without dimensions, injected banners, and late-loading fonts.
Time to First Byte (TTFB)
Time to First Byte measures the time from requesting a page to the first byte of the response arriving — network plus server processing. It caps every other speed metric, since nothing can render before the first byte. Under 800 ms counts as good, above 1.8 s as poor; high TTFB points to a slow backend, missing caching, or distant servers.
Total Blocking Time (TBT)
Total Blocking Time sums every stretch during load in which JavaScript occupies the main thread long enough (50 ms or more) that the page can't respond to input. It is the lab proxy for real-user responsiveness (INP), because a lab run has no real interactions. Splitting bundles and deferring non-critical scripts brings it down.
First Contentful Paint (FCP)
First Contentful Paint measures when the first text or image renders — the moment the visitor sees the page is alive. It usually moves together with LCP; a large gap between the two means the shell renders fast but the main content lags. Render-blocking CSS and slow servers are the usual suspects.
Speed Index
Speed Index scores how quickly the visible part of the page becomes complete during load, computed from a video capture of the render. Unlike single-moment metrics such as FCP or LCP it captures the whole loading progression: content that pops in late anywhere above the fold pushes it up. Lower is better.
Time to Interactive (TTI)
Time to Interactive marks the point at which the page has rendered its main content and the main thread has been quiet long enough to reliably handle input. A large gap between FCP and TTI means visitors see a page that looks ready but doesn't respond yet — usually the cost of heavy JavaScript.
Accessibility
The accessibility audit explainedAccessibility audit
Renders your pages in a real browser and runs the axe-core engine against each one, checking the machine-testable WCAG 2.1 AA criteria — the standard accessibility laws like the European Accessibility Act (BFSG) reference. The verdict is the legal headline; the issue list tells you exactly which elements to fix. Automated checks cover a large share of real-world barriers, but full conformance also needs manual review.
WCAG 2.1 AA
The Web Content Accessibility Guidelines define how websites must work for people with disabilities; level AA is the bar referenced by most accessibility laws, including the European Accessibility Act (in Germany: BFSG), in force since June 2025. Satsu checks the machine-testable AA criteria with the axe-core engine. A pass covers the automatable part — full conformance also needs manual review.
axe-core
axe-core is the most widely used open-source accessibility testing engine; browser devtools and most a11y tools build on it. It inspects the rendered page — not just the HTML source — and reports violations mapped to WCAG criteria with the exact element selector. Its results are conservative by design: what it flags is virtually always a real defect.
Perceivable
One of the four WCAG principles: information must be presentable in ways all users can perceive. Typical failures are images without alt text, low-contrast text, and media without captions — barriers for visitors using screen readers or with low vision.
Operable
One of the four WCAG principles: every function must work without a mouse. Typical failures are controls that can't be reached by keyboard, missing focus indicators, and content that traps focus — barriers for visitors with motor impairments, and an annoyance for power users.
SEO audit
Crawls your site the way a search engine does — following links, reading robots rules and sitemaps — and checks every page for on-page basics, crawlability blockers, broken links, and page-weight problems. Findings are ranked by severity so the critical, ranking-relevant issues surface first. Re-runs on a schedule, so regressions show up before they cost traffic.
On-page SEO
On-page factors are the signals each individual page sends to search engines: unique titles and meta descriptions, one clear H1, canonical URLs, and structured data. They are the cheapest SEO wins — fully under your control, machine-checkable, and fixable without touching content strategy.
Crawlability
Crawlability covers everything that decides whether a search engine reaches and indexes your pages: robots.txt rules, sitemaps, redirect chains, noindex flags, and broken links. A page that can't be crawled can't rank — crawl issues silently cost traffic you never see.
Link health
Checks every internal and external link the crawl finds: broken targets, dead external references, and redirect chains. Broken internal links are critical — they leak ranking signal and strand visitors — while long redirect chains slow navigation and burn crawl budget. External links breaking over time is normal; this catches it before visitors do.
Performance (SEO)
The SEO-relevant slice of page speed: oversized HTML, missing compression, and render-blocking scripts or styles. These are cheap, structural fixes — distinct from the full Performance audit, which measures how fast pages actually load. Slow, heavy pages get crawled less and rank worse, so this category catches the basics first.
Privacy & GDPR
The GDPR audit explainedGDPR audit
Renders your pages and captures what they really do: third-party trackers, cookies set before consent, externally-loaded fonts, data transfers to non-EU servers, and missing legal pages. These are the violations behind most GDPR warning letters and fines. Each finding comes with a concrete fix; guidance only, not legal advice.
Trackers
Trackers are third-party scripts — ad pixels, analytics, social embeds — that process visitor data and typically share it with their provider. Under the GDPR they need informed consent before they load; a tracker firing before the consent banner is the classic violation. Fewer trackers also means less consent UI and a faster page.
Fonts
When a page loads webfonts from a third-party server, every visitor's IP address is sent there before any consent can happen. German courts have ruled exactly this — a font loaded from US servers — an actionable GDPR violation. The fix is mechanical: download the font files and serve them from your own domain.
Data transfer
When a site loads resources from third-party servers — fonts, CDNs, embeds — visitor IP addresses travel there too. Transfers to countries outside the EU need a legal basis under the GDPR; German courts have treated even a Google Fonts load from US servers as an actionable violation. Self-hosting third-party assets closes the issue.
Transparency
The GDPR requires visitors to be told what data is processed and by whom — in practice: a reachable privacy policy. German-market sites additionally need an imprint (Impressum). Missing or unreachable legal pages are trivially detectable, which makes them a favorite target for automated warning letters.
Security
The security audit explainedSecurity audit
Checks the security posture a browser can see: response headers, TLS configuration, cookie flags, mixed content, and information disclosure. These are the same checks attackers run first — they're fully automated and reveal soft targets. Everything found is config-level fixable, no code rewrite required.
Security headers
Security headers are instructions the server sends with every response — Content-Security-Policy, Strict-Transport-Security, X-Frame-Options and friends — that activate browser-side protections against script injection, clickjacking, and protocol downgrades. They are one-line server config with outsized effect, which is why every security scanner checks them first.
Transport
Covers how traffic is encrypted in transit: every page served over HTTPS, http:// requests redirected, and HSTS telling browsers to never try plain HTTP again. Without HSTS, a first visit over an untrusted network can be intercepted before the redirect happens — one header closes that window.
Content
Mixed content means an HTTPS page loads some resources — scripts, images, styles — over plain http://. Browsers block the most dangerous cases and mark the page as not fully secure for the rest; an attacker on the network can tamper with anything unencrypted. The fix is serving every resource over https.
Disclosure
Information disclosure covers what your responses reveal about the stack: server and framework version headers, verbose error pages, exposed build files. None of it is an exploit by itself, but it tells attackers exactly which known vulnerabilities to try. Suppressing the headers costs one config line.