Security at TribeMap

TribeMap analyses website visitor behaviour to show you which traffic is worth your money. That means running a script on your website and processing data on your behalf, so your security team is right to ask questions before deploying us.

This page sets out how TribeMap is built, hosted and operated, in the order a security review usually asks. If something isn't covered, email team@tribemap.ai and we'll answer.

1. Who builds TribeMap

TribeMap is built and operated by the founding team of Upscope, whose co-browsing product is used by security-conscious enterprises and which holds ISO 27001 certification and a SOC 2 report.

TribeMap is a separate product on separate AWS infrastructure, and it does not itself hold those certifications. But it is built by the same people, in the same access-controlled, CCTV-monitored office, under the same working practices that Upscope's ISO 27001 information security management system requires of them: multi-factor authentication on all accounts, credentials kept in a password manager, full-disk encryption on devices, security awareness training, and defined onboarding and offboarding for system access. Where this page describes how the team operates, that is the environment it describes.

2. What data TribeMap collects

From your website

Data	Detail
Page views	URL path, in sequence, with time on page
Interactions	Clicks, scroll depth, and a count of typing activity — never the contents of what was typed
Traffic source	Referrer, UTM parameters, ad click identifiers
IP address	Used at ingest to derive approximate location and filter bot traffic. Never stored — see below
Device	Browser, operating system, screen and viewport size
Visitor identifier	A random, first-party ID used to group one visitor's actions into a journey — see below

What we do not collect

• Names, email addresses, phone numbers or postal addresses of your visitors
• The contents of form fields, input boxes or text areas — the script never reads input values
• Keystrokes — typing is counted, never captured
• Passwords, session tokens or cookies belonging to your site or your authentication system
• Payment card or bank details

IP addresses are never stored. The visitor's IP is used in memory at the moment an event arrives, for three things: deriving an approximate city and country from a local geolocation database (the IP is not sent to any third-party lookup service), filtering datacenter and bot traffic, and rate limiting. There is no IP column anywhere in our database. If a visitor's browser blocks cookies, a salted one-way hash that includes the IP is used to keep a single day's events together; the salt rotates every 48 hours and is deleted after 72, so the hash cannot be linked across days or reversed.

Visitor identifier. A random UUID generated in the browser — not derived from device fingerprinting — stored in a first-party cookie scoped to your domain, expiring after 12 months. Each website gets its own identifier: the same person visiting two TribeMap-tracked sites has two unrelated IDs. There is no cross-site tracking.

URL and referrer handling. Marketing URLs sometimes carry sensitive values in query strings — reset tokens, invite links, occasionally an email address. We strip every query parameter except a defined allowlist (utm_* and the ad click identifiers gclid, fbclid, msclkid, yclid, li_fat_id, ref) and drop URL fragments and embedded credentials. This is applied in the browser before anything is sent, and applied again on our servers, so it holds even against a modified client.

Clicked text. To understand which buttons and links matter, the script captures the visible text of a clicked element, truncated to 100 characters, with automatic redaction of anything shaped like an email address, phone number, or long digit run before it leaves the browser.

No enrichment providers. We do not do IP-to-company reverse lookup and we do not use firmographic or identity enrichment services. Nothing about your visitors is sent to a data provider.

On the phrase "no PII." The data above can still qualify as personal data under GDPR, because behavioural data with a persistent identifier can relate to an identifiable individual even without a name attached. We don't hide behind the "anonymous analytics" label: we treat this as personal data, apply the protections on this page to it, and offer a Data Processing Agreement accordingly — see GDPR and data protection.

Account data. Separately, we hold what you give us to run your account: name, work email, company, billing details and login credentials.

3. The tracking script

The script runs in first-party context on your site, so it gets more scrutiny than anything else we ship. Specifics:

What it does

• Loads asynchronously and never blocks rendering. About 5 KB gzipped, with zero third-party dependencies.
• Observes navigation and interaction events. Beyond inserting its own script tag, it does not modify your DOM, inject content, or alter your site's behaviour.
• Does not read form field values or capture keystrokes. Password, email and search inputs are excluded from activity counting entirely.
• Reads no cookies or storage belonging to your application — the only cookie it touches is its own.
• Loads no further third-party scripts, pixels or trackers.
• Fails safe: events are batched and sent every 5 seconds; failed sends are re-queued for later batches in a bounded buffer, so under a prolonged outage the oldest events are dropped rather than the buffer growing without limit. If our service is unreachable, your site is unaffected.
• Bot filtering runs both in the browser (headless and automation signals) and on our servers (datacenter IP ranges). Detected bots are never given a cookie.

Storage, consent and opt-out

• The script sets exactly one cookie: _tbz_vid, first-party on your domain, containing only a random identifier, expiring after 12 months, with SameSite=Lax and Secure on HTTPS.
• There is no built-in consent API yet. If your consent framework requires it, load the script only after consent fires in your consent management platform — it is a single async script tag, so this is a one-line change in most CMPs.
• Setting localStorage.tribemap_ignore = "true" disables tracking completely for that browser: no cookie, no listeners, no network requests. We publish a self-serve page for this at tribemap.ai/ignore — useful for excluding your own team.
• Adding a tribemap-analytics-skip attribute to any element suppresses click-text and typing-activity capture for it and everything inside it.

Deploying it safely

• Endpoints to allowlist: code.tribemap.ai and sdk.tribemap.ai in script-src, api.tribemap.ai in connect-src. Nothing else is contacted.
• Content Security Policy: the script requires neither unsafe-inline nor unsafe-eval and contains no eval, document.write or dynamic code execution. Our own site runs it under a strict CSP.
• Ingest protection: events are accepted only for domains that have completed ownership verification, are schema-validated on receipt, and are rate-limited per site key and IP.

4. Infrastructure and hosting

• TribeMap runs on Amazon Web Services in the us-east-1 (N. Virginia) region, on Kubernetes. AWS data centres are independently certified for physical and environmental security (aws.amazon.com/compliance).
• Production is separate from development: different infrastructure, different databases, different credentials. Production data is not copied into development environments, and error monitoring for the two never mixes.
• No production data is stored on laptops or personal devices.
• Infrastructure is defined as code. Deployments are made only by the CI pipeline through a reviewed, protected release branch — humans do not push images to production by hand — and every release is a tracked commit that can be reverted.
• CI authenticates to AWS with short-lived OIDC credentials; there are no long-lived AWS keys in the deployment pipeline.
• Page crawling for AI context runs in our own headless-browser containers inside our private network — no third-party browsing service sees your pages.

Legal entity. TribeMap is operated by TribeMap Ltd, a UK company.

5. Encryption

• In transit: all traffic — visitor to collector, browser to dashboard — is served over HTTPS/TLS.
• At rest: data is encrypted at rest, as set out in our Privacy Policy.
• Secrets: credentials and API keys are injected through deployment configuration and are never committed to source control.
• Passwords: stored as salted bcrypt hashes (cost factor 12). Never stored in plain text and not recoverable by us — only resettable. Password-reset tokens are themselves stored hashed.

6. Access control

Your account

• Data is segregated per account and enforced server-side at the data-access layer on every request — including database-level integrity constraints that prevent one account's events from ever attaching to another's.
• Authentication is by email and password, or Google sign-in.
• Login, signup and password-reset endpoints are all rate-limited against brute-force and credential-stuffing attacks.
• Login sessions expire after 7 days.
• Each website and each billing account has owner and member roles; destructive actions — deleting a website, managing billing, removing members — are restricted to owners and enforced server-side.

Our access

• Production access is limited to the engineers who run the service — a team small enough that "least privilege" and "everyone" currently coincide, which we state plainly rather than dress up.
• Multi-factor authentication is required on all cloud infrastructure and company accounts.
• Administrative actions inside the product are recorded in an append-only activity log, including who did what and what changed.
• Access is removed as a defined offboarding step when someone leaves.

7. Application security

• All code is version-controlled and reviewed before reaching production, with continuous integration running type checks, linting and the test suite on every change. Dependency versions are pinned with enforced lockfiles.
• We build against the OWASP Top 10: all database access goes through an ORM with parameterised queries, request payloads are schema-validated, and authorisation is enforced server-side at the data layer — never only in the interface.
• The crawler that reads your public pages carries SSRF protections: private and internal address ranges are blocked.
• Error monitoring scrubs request data for credentials, passwords and tokens before anything leaves our servers.
• Production customer data is not used in testing.

8. AI processing

TribeMap uses large language models to classify visitor intent and write the briefings and dossiers in the product.

• What is sent: the behavioural data in section 2 — page paths, sequence and timing, referrer and UTM source, device type, and approximate city/country. IP addresses are never sent to a model. Neither are emails, names, or anything typed by a visitor — we never collect those in the first place.
• Providers: OpenAI and Google (Gemini), via their APIs. Under both providers' API terms, submitted data is not used to train their models.
• Internal AI debugging payloads are automatically purged after 7 days.
• Outputs are stored against your account only, never pooled across customers.
• No automated decision-making producing legal or similarly significant effects on an individual. Intent scores are commercial signals for your marketing team, not decisions about a person.

9. GDPR and data protection

• Roles. For visitor data collected through your site, you are the data controller and TribeMap is your data processor. We process it only to provide the service.
• DPA. We enter into a Data Processing Agreement on request — email team@tribemap.ai.
• Data subject rights. We assist you in responding to access, erasure, rectification and objection requests from your visitors.
• International transfers. Data is hosted in the United States; transfer safeguards are set out in our Privacy Policy.
• No secondary use. We do not sell customer or visitor data, share it with advertising networks or data brokers, or build cross-customer profiles of individuals. Visitor identifiers are scoped to a single website by construction.
• Consent. The lawful basis for tracking your visitors is yours to establish, and deployment sits within your own consent framework. Section 3 covers the technical hooks to implement it.

10. Sub-processors

Sub-processor	Purpose	Data involved
Amazon Web Services	Hosting, storage, databases	All service data (us-east-1)
OpenAI	Visitor-intent classification, report generation	Behavioural visitor data — no IPs, no emails
Google	AI processing (Gemini), optional sign-in	Behavioural visitor data; sign-in identity if you use it
Stripe	Subscription billing	Billing details
Postmark	Transactional and report email	Customer name and email
Sentry	Error monitoring	Error reports and request metadata, credential-scrubbed
Better Stack	Log management	Application logs, sanitised

Card details are handled entirely by Stripe and never reach TribeMap servers.

We will update this page before adding or changing a sub-processor. If you need change notifications for your vendor register, email team@tribemap.ai and we'll add you to the notice list.

11. Retention and deletion

• Visitor behavioural data is retained for the life of your account so your map keeps its history.
• Deleting a website from your account deletes all of its visitor data — visits, events, classifications and uploaded assets.
• On account closure, your data is deleted, excluding records we're legally required to keep (billing records for tax purposes).
• Short-lived by design: fingerprint salts live 72 hours; internal AI debug payloads live 7 days.
• You can request export or deletion at any time via team@tribemap.ai.

12. Security incidents

Our incident process is: contain, assess scope and impact, remediate, notify, review.

• Notification. We notify affected customers within 48 hours of confirming a breach involving their data — ahead of your own 72-hour regulator notification window under GDPR.
• Notifications state what happened, what data was involved, what we've done and what we recommend you do.
• Every incident is followed by a root-cause review, and the fix is tracked to completion.

13. Reporting a vulnerability

Email team@tribemap.ai. We'll acknowledge within 2 working days and keep you updated.

We ask for 90 days before public disclosure. We won't pursue legal action against researchers acting in good faith who don't access, modify or destroy other users' data, degrade the service, or use social engineering against our team or customers.

14. Questions from your security team

If you have a security questionnaire, a DPA to sign, or questions this page hasn't answered, send them to team@tribemap.ai — we complete vendor security questionnaires.