Data privacy and PII best practices

Overview

Privacy in analytics isn't one setting. It's a habit, applied every time someone adds an event.

Intempt gives you the controls: consent categories, data subject requests, role-based access, per-user privacy records. What enters the system is still your decision. This guide covers how to make that decision well.

Four principles hold the rest together:

How it works

Phase 1: Design and collection

Everything cheap happens here. A field you never send needs no governance, no classification, and no deletion request.

What counts as PII

Personally identifiable information is anything that identifies a person on its own, or does so when combined with something else. The obvious cases are names and email addresses. The less obvious ones cause more trouble.

Classifying risk before you track

Intempt collects data as events and as attributes on user and account profiles. The privacy risk lives almost entirely in the attributes you attach, not in the event itself.

📘 Good to know

Intempt's position on highly sensitive data is that it shouldn't reach the platform at all. If a field in that row is genuinely required for a business process, that process belongs in your own systems, not in your analytics.

Do

• Use internal IDs. Identify users with a stable, non-identifying ID. See Why a single profileId matters.
• Keep a tracking plan. In Intempt the Events page is the plan: every event, its type, its sources, and how often it fires. See How to create an event tracking plan.
• Track value moments. Map events to activation, engagement, monetization, or retention rather than to every click.
• Describe every attribute. The Attributes page has Description and Example columns. An attribute nobody can explain is one nobody can govern.

Don't

• Don't send high-sensitivity fields. Not hashed, not encrypted, not "temporarily."
• Don't use email as an identifier. Email addresses change. Treat them as an attribute for contacting someone, never as the key that identifies them.
• Don't put PII in event names. An event called signup_jane@acme.com is a permanent identifier in your schema, and it's unfixable after the fact.
• Don't send unreviewed free text. Search boxes and form fields collect whatever users type, and users type their own names into search boxes.

Phase 2: Governance and access

Once data is in the project, the question changes from what you collect to who can see it.

Hide sensitive attributes

Every attribute on the Attributes page has a Status of Visible or Hidden. Hiding an attribute keeps it out of the default view without deleting the data or breaking anything that depends on it. Use it for anything in the Moderate row above.

See Managing attributes.

Separate environments

A project is a data silo. Every event, segment, and report belongs to exactly one project, and every query runs against one project at a time.

Use separate projects for production and testing, and never load real user identifiers into a test project. Note that the Free tier is limited to one project, so this needs Pro or above.

See Organizations & projects.

Grant the narrowest role that works

Intempt has two independent role systems: organization roles govern billing, members, and org settings; project roles govern the data inside one project. Where a preset doesn't fit, build a custom role scoped to either level and grant only the objects that role needs.

Start people at the minimum and add on request. It's much easier than taking access away later.

See Access management.

Review access on a schedule

The audit log records every action of consequence with actor, action, target, outcome, and severity. Retention runs from 7 days on Free to 730 days on Enterprise. Filter it by actor to see what one account did, or export to CSV for a security review.

See Security & Trust Center.

Phase 3: Monitoring and maintenance

Tracking drifts. A field that was safe when it shipped starts carrying names when someone repurposes it.

Review on a cadence

Every quarter, check three things:

1. New tracking. Which events and attributes were added since the last review, and did any of them introduce PII?
2. Drift. Has an existing field started collecting something it didn't before? Free-text fields are the usual culprit.
3. Dead weight. Which attributes are unused? Deprecate them. Every field you remove is one you never have to govern again.

If you find PII where it shouldn't be

1. Stop the source. Fix the tracking call so nothing new arrives. This is the only step that stops the problem growing.
2. Restrict what's there. Set the attribute's Status to Hidden and confirm which roles can still reach it.
3. Filter it out of analysis. Events in Intempt are immutable. Create a Created event that applies a condition excluding the affected records, and use that in reports instead of the original.
4. Tell the people who need to know. Legal and compliance decide whether this is reportable. That call isn't yours to make alone.
5. Write down what changed so the same field doesn't come back next quarter.

Use cases

1. A new event ships with a user_email property because it was convenient. Fix the tracking call, hide the attribute, and create a filtered event for reporting.
2. An analyst asks for access to a project containing customer phone numbers. Build a custom role that grants the objects they need and excludes that attribute.
3. Your team is planning instrumentation for a new feature. Walk the PII checklist during the design review, before any code is written.
4. A quarterly review shows 40 attributes, 12 of which no report has used in six months. Deprecate the 12.
5. A search-query property starts showing up with people's names in it. Stop capturing the raw query, hide the attribute, and filter the affected events out of reporting.
6. You're setting up a staging environment and need somewhere safe to test tracking. Create a second project and use synthetic identifiers only.
7. Legal asks which attributes in the project count as personal data. Filter the Attributes page by Status and Description to produce the list.
8. A user asks to be deleted. Submit an erasure request, then opt them out so new events stop arriving. See Managing DSR.

Where to go next

• PII checklist
• Protecting user data
• Managing attributes
• Access management
• Security & Trust Center