mandera is built on a privacy-first architecture. It collects website analytics without cookies, IP tracking, fingerprinting, or persistent identifiers.
This lets you gain actionable insights into visitor behavior while respecting user privacy — and without requiring cookie consent banners.
The following section explains how that works in practice: what data is collected, what is explicitly not collected, how AI crawler traffic is handled separately, where data is processed and stored, and how mandera aligns with applicable privacy regulations.
mandera’s analytics are designed around four privacy guarantees. These aren’t optional settings — they’re architectural decisions built into how the system works.
mandera does not set, read, or rely on browser cookies. Session identity is generated in browser memory when the page loads:
sessionId = Date.now().toString(36) + Math.random().toString(36).substr(2)
This ID exists only in JavaScript memory. It is never written to localStorage, sessionStorage, or a cookie. When the tab closes, the session ID is gone. There is no way to reconnect a returning visitor to a previous session.
This means every visit is independent. mandera cannot build user profiles, track visitors across sessions, or identify returning users.
mandera does not store IP addresses in its analytics tables. The visitor data model has no IP column — it’s not a matter of policy, it’s structurally absent.
Geographic data (country-level only) is derived from:
cf-ipcountry), Vercel (x-vercel-ip-country), Fastly, or Google App Engine add country headers. These are read without storing the underlying IP.Accept-Language header contains a locale code (e.g. en-US) from which the country can be inferred.No IP-to-location lookup is performed by mandera.
mandera does not use any fingerprinting techniques:
The only device information collected is parsed from the standard User-Agent string: browser name, OS name and version, and device type (desktop, mobile, tablet). This is standard HTTP metadata, not a fingerprint.
Nothing about a visitor persists between sessions:
The in-memory session ID is the only identifier, and it lasts only as long as the browser tab is open. On the server, sessions are cached for deduplication purposes with a 1-hour TTL and a maximum of 10,000 entries — after which they’re evicted.
This section explains the technical details of how mandera collects and processes analytics data — from the client-side snippet to server-side aggregation.
mandera’s tracking starts with a single JavaScript snippet loaded on your page. When it initializes, the following steps happen in sequence:
A visit is mandera’s equivalent of a session. Visits are defined without cookies:
Each visit record contains:
| Field | Description |
|---|---|
id | Auto-generated UUID |
propertyId | Which website property this visit belongs to |
location | Country code (from headers or locale, nullable) |
browserName | Browser name from User-Agent |
osName | Operating system name |
osVersion | Operating system version |
deviceType | Desktop, Mobile, or Tablet |
deviceVendor | Device manufacturer (if detectable) |
createdAt | Timestamp |
No IP address, email, username, or any personally identifiable information.
Each page within a visit creates a page record:
| Field | Description |
|---|---|
pageUrl | The page visited |
previousUrl | The referring page (internal or external) |
duration | Seconds spent on the page |
visitId | Link to the parent visit |
createdAt | Timestamp |
Duration is measured as the time between when the page loaded and when the visitor navigated away. Pages with less than 3 seconds of duration are excluded to filter out accidental clicks and rapid back-navigation. The exception is the final page before the tab closes — it’s always recorded regardless of duration.
Page views are not deduplicated per user (since users are anonymous). If a visitor views the same page three times in one session, that creates three page records. This is by design — deduplication would require persistent user identification.
Events track specific interactions:
| Field | Description |
|---|---|
eventName | Lowercase, alphanumeric + underscores, max 200 characters |
metadata | Arbitrary JSON object (optional) |
pageUrl | Where the event occurred |
visitId | Link to the parent visit (optional) |
createdAt | Timestamp |
Events are fired by custom JavaScript calls (ma_event), HTML data attributes (data-mandera-event), or automatic form submission tracking.
Heatmap data is collected in batches:
| Field | Description |
|---|---|
pageUrl | The page being tracked |
interactions | JSON array of click, scroll, and mousemove events |
browserInfo | Parsed browser and OS details |
location | Country code |
createdAt | Timestamp |
Each interaction records coordinates as percentages (not pixels), element metadata (tag, class, ID, truncated text), and viewport size. Interactions are batched client-side (every ~5 seconds) and sent as a single request. Multiple submissions from the same session are merged into one heatmap record.
When you view the Visitor Analytics dashboard, mandera computes aggregated metrics from raw visit and page records:
All metrics are computed on the fly from raw records. There is no pre-aggregated summary table — every dashboard view reflects current data.
The server maintains an in-memory cache to associate incoming requests with existing visits:
{propertyRef}:{sessionId}When the cache exceeds 10,000 entries, expired items are evicted. When it’s below that limit, the first 100 entries are spot-checked for expiry on each cleanup cycle.
A separate cache handles heatmap session deduplication with the same TTL and size constraints.
mandera automatically identifies AI crawlers and separates their traffic from human visitor analytics. Bot visits are logged in a dedicated data store and surfaced in AI Analytics, while human visitor data remains clean in Visitor Analytics.
The tracking snippet runs a bot check before any data is sent. Using a comprehensive bot detection library (isbot), it evaluates the browser’s User-Agent string. If the visitor is identified as any kind of bot (not just AI bots), tracking stops immediately — no page view, event, or heatmap data is sent.
This prevents all known automated traffic from appearing in Visitor Analytics.
For requests that do reach the server (because the bot bypasses client-side JavaScript or doesn’t execute it), the server performs a second check. The User-Agent is matched against patterns for known AI crawlers:
| Crawler Type | User-Agent Patterns |
|---|---|
| GPTBot | GPTBot, OAI-SearchBot |
| ChatGPT-User | ChatGPT-User |
| ClaudeBot | ClaudeBot, claude-web, anthropic-ai |
| PerplexityBot | PerplexityBot, Perplexity-User |
| Google-Extended | Google-Extended |
| Copilot | bingbot, msnbot |
Pattern matching is case-insensitive. If a match is found, the request is logged in the aiCrawlers table with the crawler type, page URL, User-Agent string, and timestamp. The request is then returned as successful without creating a human visit record.
Unrecognized AI crawlers that don’t match known patterns but are detected as bots by the general bot library are filtered out client-side and never reach the server.
Each detected AI crawler visit records:
This data powers the AI Crawler Activity, Indexed Pages, and AI Bots views.
If bot traffic were mixed with human analytics, metrics would quickly become unreliable:
By keeping these data streams separate, mandera ensures that Visitor Analytics reflects real human behavior, while AI Analytics provides a focused view into how AI systems interact with your content.
This section explains how mandera’s growth engine identifies and generates opportunities.
Unlike traditional analytics platforms that only display data, mandera continuously analyzes multiple connected data streams to detect patterns, gaps, and improvement potential. The goal is not reporting — it is structured opportunity discovery.
The growth engine evaluates signals from several components of the platform:
Visitor Analytics: Aggregated traffic data, user behavior patterns, page performance, engagement signals, and navigation flows.
AI Analytics: AI crawler activity, brand mentions, citation frequency, indexed pages, and visibility trends across monitored AI platforms.
Business Context: User-defined business goals, industry, target audience, region, and company description.
Website Structure & Content Signals: Crawled website structure, internal linking patterns, and publicly accessible page content.
SEO & External Signals (if available): Search engine data, backlink information, and keyword-related signals retrieved through connected integrations.
These signals are evaluated collectively to detect discrepancies, missed opportunities, underperforming assets, or emerging growth potential.
When relevant patterns are detected, mandera generates opportunity cards that include:
To prevent redundancy, semantic similarity detection is applied to avoid recommending duplicate or previously rejected opportunities.
Opportunity discovery is not static. Depending on configuration, the system reevaluates data at defined intervals (e.g., daily or weekly) and updates opportunities accordingly.
This ensures that growth suggestions reflect the current state of traffic, AI visibility, and business priorities.
This section explains which AI models mandera integrates and how data is processed when AI-powered features are used.
mandera integrates multiple large language models (LLMs) to enable prompt-based functionality within the platform. These models are used only in the context of user-initiated AI features.
Model selection may vary depending on system configuration, availability, performance considerations, and regional setup. The specific models in use may change over time.
mandera monitors AI crawler activity across major platforms as part of its AI Analytics module. These currently include:
Monitoring refers to crawler detection and visibility tracking. It does not imply that analytics data is shared with these providers.
External LLMs are currently used only for user-submitted prompts and prompt tracking features.
LLMs are not used to process raw visitor analytics data, session records, or tracking logs.
AI-powered features are triggered explicitly by user interaction. No background analytics data is automatically sent to external AI providers.
When a user submits a prompt (for example via Ask mandera), the following data may be transmitted:
mandera does not transmit:
Only the content explicitly submitted by the user, along with minimal structured system context necessary to generate a response, is included in an AI request.
When an AI feature is triggered, the following steps occur:
AI providers do not receive direct access to mandera’s databases and only process the data included in individual requests.
AI providers process requests in accordance with their respective privacy and security policies. Depending on the provider, processing may occur outside the European Union.
Where required, appropriate safeguards such as Standard Contractual Clauses (SCCs) or equivalent mechanisms apply in accordance with applicable data protection laws.
mandera does not permit AI providers to use submitted data for advertising purposes or independent analytics profiling.
This section explains how mandera processes incoming analytics data, where that data is stored, and which security and retention principles apply.
mandera stores five categories of data:
Country code, browser name, OS, device type, and timestamps. No IP address, no user identity.
Page URL, referrer URL, duration, and link to the parent visit.
Event name, optional metadata (JSON), page URL, and timestamp.
Page URL, interaction data (click/scroll/mouse coordinates as percentages, element selectors, viewport size), browser info, and country.
Crawler type, page URL, User-Agent string, and timestamp. Stored separately from human analytics.
Analytics data is stored indefinitely in the database. There is no automatic data expiration or scheduled cleanup for visit, page, or event records.
Heatmap data is limited to 500 recent records per property to keep queries performant. Older heatmap records are replaced as new data arrives.
The server-side session cache (used for visit deduplication) uses a 1-hour TTL with a maximum of 10,000 entries. This is purely in-memory and contains no personal data — only mappings from session keys to visit IDs.
mandera processes and stores data wherever the mandera instance is hosted. If you use mandera’s hosted service, data is processed on their infrastructure. If you self-host mandera, data stays entirely on your own servers.
mandera is designed, developed, and operated entirely within Europe. Every infrastructure layer — application code, hosting environment, data storage, and core AI integrations — is rooted in the European Union.
This architecture is not incidental. It is a deliberate decision to ensure regulatory clarity, operational sovereignty, and reduced dependency on non-European infrastructure providers.
If you use mandera’s hosted service, the platform runs on infrastructure provided by Hetzner, with hosting in Frankfurt, Germany.
This means:
Self-hosted deployments remain fully under the control of the hosting entity.
For AI-powered features, mandera integrates European AI providers where possible. This includes the use of models developed by Mistral AI.
Model selection may vary based on configuration and availability.
When European-hosted AI providers are used:
For hosted deployments:
mandera does not operate global multi-region replication outside the EU for analytics databases.
European infrastructure provides additional safeguards beyond technical privacy architecture:
Combined with mandera’s cookie-free, non-personal data architecture, this ensures a privacy model that is structurally European — not just legally compliant.
The GDPR applies to processing of personal data of EU residents. mandera’s approach:
mandera does not collect, store, or process personal data as defined by the GDPR:
Only the minimum data needed for analytics is collected: page URLs, referrer URLs, country code (from headers, not IP), browser and OS name, device type, and interaction coordinates for heatmaps. Form values and text inputs are never captured.
Since mandera does not process personal data and does not place cookies or similar technologies on the visitor’s device, explicit consent under GDPR Article 6 or Article 7 is not required for analytics tracking.
PECR (UK/EU) specifically regulates the use of cookies and similar technologies that store information on a user’s device. Since mandera:
PECR’s consent requirements for cookies and similar technologies do not apply. The tracking snippet runs entirely in memory and makes standard HTTP requests — it does not store or access information on the user’s device beyond the normal execution of JavaScript.
The CCPA gives California residents rights over their personal information, including the right to know what’s collected, the right to delete, and the right to opt out of the “sale” of personal information.
Since no personal information is collected or sold, the CCPA’s opt-out and deletion requirements are structurally satisfied.
Cookie consent banners exist to comply with regulations that require informed consent before placing cookies or processing personal data. mandera requires neither:
This means you can run mandera on your website without a cookie banner, consent popup, or opt-in mechanism and remain compliant with GDPR, PECR, and CCPA.
