Settings → Data & privacy is where an account decides how long each kind of visitor data is kept, what the tracking code collects on its site, and how to answer a visitor who asks to see or delete their data. It also lists the cookies the tracking code sets and your team’s sign-ins, and Suggest settings for my site proposes settings that fit where your visitors are and what kind of site you run.
Where it is, and who can change it
The page is in the Settings menu, under Data & privacy. It has four tabs — Data retention, What we collect, Visitor requests and Access & documents — with Suggest settings for my site at the right end of the tab bar.
| Who | What they can do |
|---|---|
| The account owner, Managers, and Members with Production access | Everything on the page. |
| Reporting users, and Members without Production access | See every setting, but not change it, and look up a person. They can’t download or delete a person’s data, use Suggest settings for my site, or see the team’s sign-ins. |
Roles are set on Team Members. Other screens lead here, or hold the very same setting:
- On Site profile, under Set on other pages, Visitor identity & profile and User-data retention link here.
- On Tracking Code, Privacy & compliance opens Consent handling, whose first line links to What we collect.
- The AI Chat’s How long transcripts are kept (What the assistant may see) is the same setting as Chat transcripts here.
Data retention: how long data is kept
One row per kind of data. Hover a row’s name for what it covers and how long it is kept today; hover its field for the range you can choose.
A period can only get shorter. A period you set deletes data sooner than Personyze would on its own, never later. Each field’s tooltip shows its range — anyone who needs longer contacts support. Chat transcripts is the one setting that can go past its default: 90 days unless you choose otherwise, anywhere from 1 to 730.
| Data | Default | What you can set |
|---|---|---|
| Known visitor profiles — profiles with an email, a CRM id or a Facebook id | 366 days | 30–366 days |
| Anonymous profiles — visitors known only by the pseudonymous visitor id in their browser’s cookie | 61 days | 7–61 days |
| Visit history — sessions, page views and events | Automatic (below) | 7–730 days, or Automatic |
| Form submissions | Keep | Keep, or 30–1,825 days |
| Survey and review answers | Keep | Keep, or 30–1,825 days |
| Email activity — the send log of your email campaigns, replies, and who opened or clicked | Keep | Keep, or 30–1,825 days |
| Chat transcripts | 90 days | 1–730 days — the same setting as on the AI Chat screens |
| Meeting bookings | 365 days | 1–365 days. Past the period, a booking’s name, email, phone and answers are blanked; the booking itself stays in your reports |
Keep means kept until you delete it. A number of days deletes each record that many days after it was made.
The 7-day wait
- A change that deletes more takes effect 7 days later. Before it saves, the page asks (This deletes data.) and says about how many records would go, counted by the same rule the nightly deletion uses.
- Until that date the row shows the change, the count and Cancel the change. Cancelled, nothing is deleted.
- Choosing another shorter period while one is waiting starts the 7 days again.
- A change that deletes less applies at once.
A nightly job does the deleting.
What “inactive” means for a profile
- Personyze’s default rule deletes a profile 366 days (61 for an anonymous profile) after its details last changed. Visits don’t reset that clock, so even a regular visitor whose details never change is deleted then.
- A period you set adds a second clock: a profile is also deleted once it has gone that long with no visit and no change to its details. The default rule keeps applying beside it, so a period never keeps a profile longer than the default rule would.
Profiles kept regardless
A profile that unsubscribed from one of your campaigns, withdrew email consent, or is marked “do not email” is not deleted for its age — neither by a period you set nor by Personyze’s default rule. Deleting it would lose the unsubscribe, and the next CRM import could email the person again as somebody new. The row’s tooltip says so. Deleting the person through Visitor requests still deletes the profile, and keeps the address blocked.
Visit history: Automatic
Automatic is Personyze’s own rule: the days your account is set to keep (5 by default), and always at least the newest 100,000 visits, however old — so a quiet site keeps its history. A number of days is a hard limit instead: older visits are deleted, however few are left.
Kept as they are
Three rows on the page are fixed:
| Row | Shown as | Why |
|---|---|---|
| Consent records, unsubscribes and SMS STOPs | Always kept | Proof that a person agreed, and every request to stop: consent records, unsubscribes from all your emails, your suppression list and SMS STOPs are kept for as long as your account exists, so a stop keeps being honored. |
| Report totals | For the life of the account | The counts and sums in your reports. They hold no personal data. |
| IP addresses | About 1.5 hours | An information row, not a setting — see below. |
IP addresses
An IP address is used when a visit arrives, to find the visitor’s country and city. It is kept only while the visit is active — about 1.5 hours — and never in visitor profiles. Consent records keep the IP as proof of consent. There is no IP setting to change: an address is never stored with a profile in the first place.
What we collect
What the tracking code does on your site. Each control saves as soon as you change it.
| Setting | What it does |
|---|---|
| Consent mode | The tracking code loads on every page but stores and sends nothing — no cookie, no request — until your cookie banner calls _S_T.consent.grant(). Off is the default: then your cookie banner keeps the whole snippet from running until the visitor agrees, as it does with your other tags. How to connect your cookie banner opens the instructions for Cookiebot, OneTrust, Usercentrics, IAB TCF and Google Consent Mode. |
| Global Privacy Control | Off by default. When on, a visit from a browser that sends the Global Privacy Control signal (Sec-GPC: 1 — Brave and DuckDuckGo send it, and Firefox with its setting on) is not tracked: Personyze records nothing from it and gives it no personalization. The tracking code still loads in that browser, so to keep it from storing anything before consent, use your cookie banner or Consent mode. |
| Clean recorded URLs | The parameters on this list are removed from the page addresses and referrers Personyze stores — in the query string and after the #. See below. |
| Cookie lifetime | How long the visitor-id cookie, stat_track_u_id, lasts: 30–730 days. Blank means the default, 730 days (2 years). A visitor who comes back after it has expired starts again as a new visitor. Its copy in localStorage expires with it; the opt-out cookie always lasts 730 days (cookie table). |
| Merge visitors to known users | When Personyze detects an identifier on the page — a customer key or an email — it merges the unidentified visitor into that known user, with their full history. |
| Send profile fields to the page | Profile fields become available to the page’s JavaScript, so a campaign can fill in details such as a first name. Anything sent to the page can be read by any script on it: leave this off if your campaigns don’t show profile fields. |
grant(). Consent mode has the details.Clean recorded URLs
A sign-in link with ?email=, a reset link with ?token=: personal details sometimes travel in a page address, and the stored address would keep them as long as the visit is kept.
- The list may start empty (Nothing is removed yet.) or with four names:
email,password,tokenandaccess_token. Add suggested adds whichever of those four are missing. - A name is letters, digits and
_ . - [ ], up to 64 of them, no spaces. Up to 30 names. - UTM names (anything starting
utm_) and click ids —gclid,gclsrc,gbraid,wbraid,dclid,msclkidandfbclid— are refused.
param() placeholder and for attribution. That is why UTM and click-id names are refused.Visitor requests
When a visitor asks what you hold about them, or asks you to delete it — a GDPR or CCPA access or erasure request — answer it here. Every look-up, download and deletion is written to the Request log, with who asked.
Find a person
- Search by email, CRM id or visitor id. Visitor ids can be negative; that is normal.
- The page lists every profile that matches: its Visitor id, what it Matched by, its email (masked), its CRM id, and when it was First seen and Last seen. What we hold counts the person’s data, kind by kind.
- When more than one profile matches, none is ticked. Tick the ones that are the person who asked — only those are downloaded or deleted.
- Form submissions, survey answers and campaign emails are found through a visitor profile, so those of a profile already deleted can no longer be found by address.
Download (JSON)
Download (JSON) gives a file with everything held about the ticked profiles, kind by kind — up to 1,000 rows of each.
Delete everything
- Tick the profiles that are this person, then Delete everything.
- Read what will be deleted and what is kept. Also block this email from future sends (recommended) is ticked: it puts the address on your suppression list, so a later import or CRM sync can’t email the person again as someone new.
- Type the identifier you searched for, and press Delete permanently. It can take up to a minute for a person with years of visits.
| What happens | To what |
|---|---|
| Deleted | The profile; its visits, page views and events, and the campaigns shown to them; form submissions; survey answers, and reviews and feedback they wrote; AI chat conversations; emails and messages your campaigns sent them, their replies and their email engagement; email consent records, and their per-campaign email states and unsubscribes; coupon redemptions; list memberships, interests, products viewed and articles read; meeting requests; push subscriptions; messages waiting to be sent. |
| Blanked, kept | Meeting bookings: name, email, phone and answers removed; the meeting stays in your reports. Orders: their email, customer id and link to the person are removed; the order keeps its amount, so revenue reports stay right. |
| Kept | The email suppression list, soft bounces and SMS STOPs — kept so this person is never emailed or texted again. |
If you untick the block but the person had unsubscribed, the address is blocked anyway — their unsubscribes were part of what was deleted — and the receipt says why.
The receipt lists what was deleted, with counts; what was kept, and why; and what a deletion can’t reach. A deletion that runs out of time says Not finished – run the delete again. and offers Run again, which finishes the rest.
The other delete buttons do the same thing
These run the same full, logged deletion, of that one profile:
- Imported user data → Find a person → Delete this person’s data
- Visitor Attributes → Individual user data — lookup & deletion → Look up user → Delete user
- Analytics → Visitors → Visitor profiles — Delete user (the bin icon) on a row
- Analytics → Visitors → Campaign audience → View users — Delete user on a user
- A campaign’s Performance step → Users → View users — Delete user on a user
Their confirmation says: “This profile’s email address goes on your suppression list, and the deletion is logged in Data & privacy › Visitor requests.”
DELETE /rest/users/where/… (REST API objects) deletes the visitor profile, not the visits, form submissions, chats or email activity. For a full erasure, use Visitor requests.Request log
Every look-up, download and deletion: When, the Request, who it was About, who it was Asked by, and the Result. The person is shown masked (for example j***@example.com): the log records that a request was made, never the data itself, and never keeps the full address.
Access & documents
Documents and links
- API keys — Manage API keys opens the API card on Integrations. Remove a key nobody uses any more.
- Privacy policy clause and cookie list — Open gives suggested wording for your privacy policy, the cookies to declare in it, and an opt-out switch you can put on your site.
- Data processing agreement (DPA) — Request our DPA opens an email to support. The DPA is sent on request.
Cookies the tracking code sets
| Name | Lifetime | Notes |
|---|---|---|
stat_track_u_id |
The account’s cookie lifetime (default 730 days) | Visitor id |
_stat_track_s_id |
Browser session | Session id |
stat_track_off |
730 days, even with a shorter cookie lifetime | Set only for visitors who opt out |
The tracking code also keeps a copy of each in the browser’s localStorage, under the same name. The copies of the visitor id and the opt-out expire with their cookie: an expiry stamp is stored beside each (<name>.exp), and an expired copy is ignored and removed. The full list, with the other entries in localStorage, is on Personyze client-side cookies.
Team sign-ins, last 90 days
Who of your team signed in to this account: When, Who, the IP address, and How — Panel, Single sign-on or API. Ten show at first; Show all lists the rest. Only users with full access see it.
Suggest settings for my site
Suggest settings for my site, at the right end of the tab bar, suggests the privacy settings that fit your site. A rules table chooses every suggestion, and every rule cites its regulator’s own page. The AI only explains the suggestions in plain words: it can’t invent a setting or a value.
What it asks
- Where your visitors are — prefilled from your own traffic of the last 30 days: the countries with at least 2% of your visits, with their shares. Remove any, or add one.
- Kind of site — from the scan of your site, when it has been scanned.
- Sensitive topics — Health, Children or Finance, optional.
- Cookie banner — whether your site asks visitors for consent to cookies, prefilled from what the scan found.
- Notes — anything else, optional. A sensitive topic it reads in them is taken into account, and the result says so.
The rules and their sources
| Rule, and its source | Applies when | What it suggests, and why |
|---|---|---|
| Keep emails and passwords out of stored page addresses FTC |
Every site | Clean recorded URLs: email, password, token, access_tokenA page address can carry what a visitor typed — an email, a password, a sign-in token — and it is stored with every visit. The FTC advises businesses to keep only the personal information they need. |
| EU and EEA: a time limit on personal data (GDPR) European Commission |
Visitors in the EU or the EEA | Form submissions, Survey and review answers and Email activity: 730 days Under the GDPR, personal data must be stored for the shortest time possible, and the European Commission says you should set time limits to erase or review it. Two years is this advisor’s starting point, not a figure from the GDPR; choose less if you need less. |
| EU and EEA: consent before tracking cookies Your Europe (EU) |
Visitors in the EU or the EEA | A step: make tracking wait for consent In the EU, some cookies — such as tracking cookies used for behavioural advertising, analytics or market research — need the visitor’s consent before they are set, so they cannot be set when the page first opens. |
| France: tracker lifetime (CNIL) CNIL |
Visitors in France | Cookie lifetime: 395 days France’s regulator, the CNIL, recommends that audience-measurement trackers last only as long as comparing audiences over time needs, such as 13 months. 395 days applies that benchmark to the visitor cookie. |
| UK: a time limit on personal data (UK GDPR) ICO |
Visitors in the United Kingdom | Form submissions, Survey and review answers and Email activity: 730 days The ICO says you must not keep personal data for longer than you need it, and that you need a policy setting standard retention periods wherever possible; the UK GDPR does not set specific time limits. Two years is this advisor’s starting point; choose less if you need less. |
| UK: consent before cookies (PECR) ICO |
Visitors in the United Kingdom | A step: make tracking wait for consent Under PECR, as the ICO explains it, you must get the visitor’s prior consent before using cookies and similar storage on their device, unless an exception applies. |
| California: honor Global Privacy Control (CCPA) California Privacy Protection Agency (CPPA) |
Visitors in the United States — the rule is California’s, for the businesses it names | Global Privacy Control: on Under California’s CCPA regulations (11 CCR §§ 7025–7026), a business that must comply with the CCPA, collects personal information online and sells or shares it must treat an opt-out preference signal, such as Global Privacy Control, as a valid request to opt out of the sale or sharing of that information. Turning this on goes further: a visitor who sends it is not tracked. |
| Quebec: profiling off by default (Law 25) Commission d’accès à l’information du Québec (CAI) |
Visitors in Canada | A step: make tracking wait for consent For visitors in Quebec: a business that collects personal information with technology able to identify, locate or profile a person must tell them, and may not switch those functions on by default — the person must be able to switch them on. |
| Brazil: consent for non-necessary cookies (ANPD) ANPD |
Visitors in Brazil | A step: make tracking wait for consent Brazil’s data protection authority (ANPD) says in its cookie guide that consent is the more appropriate legal basis for non-necessary cookies, such as those that track behaviour, and lists switching consent-based cookies off by default as good practice. |
| Health: keep who a visitor is apart from what they read FTC and HHS |
Sensitive topic: Health | Clean recorded URLs: adds name, phone, dobThe FTC and HHS warn that tracking on health websites can disclose sensitive health information, and that companies must monitor the health information that reaches third parties through tracking. Removing names, phone numbers and dates of birth from stored page addresses keeps them from being stored beside the pages a visitor read. |
| Children: parental consent (COPPA) FTC |
Sensitive topic: Children | A step: talk to your lawyer before personalizing for children In the US, as a general rule, operators must get verifiable parental consent before collecting personal information online from children under 13; certain, limited exceptions apply. |
The two years it suggests for form submissions, survey and review answers and email activity is Personyze’s suggestion, not a legal figure.
Applying the suggestions
- Only a change stricter than what you already have is suggested; a period you already shortened is never lengthened. When nothing is left: Your settings already match what these rules suggest.
- Tick the changes to keep and press Apply (it reads, for example, Apply 3 changes). A shorter retention period still gets the 7-day wait, and can be cancelled on Data retention until then.
- Consent mode is never switched on by the advisor. Where a rule calls for consent, it is shown under Steps only you can take — “Make tracking wait for your visitors’ consent: have your cookie banner hold the tracking code until the visitor agrees, or switch to consent mode and have the banner call grant().” — with Go to Consent mode, because switching it on before the banner is connected stops all tracking.
- If the AI can’t answer, you still get the suggestions, with each rule’s own reason.
Related
- Consent mode — Loading Personyze under a consent manager, and the two ways to wait for consent.
- GDPR compliance & opt-out — Opting a visitor out of tracking in code.
- Personyze client-side cookies — Every cookie and localStorage entry, and how long each lasts.
- What the assistant may see — The AI Chat’s data settings, transcripts included.
- Unsubscribe page and suppression list — Where a deleted person’s address is blocked.
- Book a Meeting — The bookings the Meeting bookings period blanks.
- Team Members — Who has full access, and who has Reporting only.
- REST API objects — The users object, and what its DELETE removes.