Plausible User Management

Plausible grants access per site and supports granular roles for collaborators. Use this hub to coordinate how the collaborator is invited, updated, and removed across your privacy-focused analytics infrastructure.

Access Requests at a Glance

• Add User Access covers inviting the service account and picking the right role.
• Update Access & Roles explains how to adjust site sharing, roles, and metrics permissions.
• Remove User Access documents the deprovisioning workflow.

How Plausible Structures Access

Plausible uses a site-based permission model where each website has its own access controls. There's no centralized "organization" concept; instead, each site operates independently with its own team and roles.

Site Invitations and Ownership

Site Owner

• The user who created the site (usually via billing account)
• Cannot be changed or transferred
• Has all administrative privileges
• Can invite others to the site with specific roles
• Can remove the site and all its data (irreversible)

Site-Level Access

• Each site can be shared with multiple users
• Each user receives a specific role per site
• A user can have different roles on different sites
• Staging and production sites remain completely separate

Implication for Collaborators: When granting access, you must invite the collaborator to each site individually. There's no way to grant "all sites" access globally.

Role Hierarchy

Administrator (Full Access)

Complete control over the site:

Configuration:
✓ Change site settings (domain, timezone, data retention)
✓ Manage goals and custom properties
✓ Configure integrations (Slack, webhooks, email reports)
✓ Delete the entire site and its data
✓ Transfer billing ownership (if they're also the billing owner)

Team Management:
✓ Invite new members to the site
✓ Change roles for existing members
✓ Remove members from the site
✓ View all team members and their roles

Analytics Access:
✓ View all reports and dashboards
✓ Access all metrics (including revenue if ecommerce is configured)
✓ Export data to CSV
✓ Embed dashboard (public/private links)
✓ Access Stats API with site API key

Privacy & Data:
✓ Configure IP anonymization settings
✓ Set data retention policies
✓ Delete historical data
✓ Manage cookie consent settings

When to grant Administrator:

• Full implementation and setup projects
• Managing integrations and webhooks
• Configuring goals and custom properties
• Data governance and retention management
• When the collaborator needs to invite others to the site

Viewer (Read-Only)

Limited to viewing analytics data:

Analytics Access:
✓ View all reports and dashboards
✓ Filter by date range and segments
✓ View goals and conversion data
✓ Export visible data to CSV (if enabled by Admin)

Limitations:
✗ Cannot create or modify goals
✗ Cannot configure integrations
✗ Cannot access site settings
✗ Cannot invite or remove team members
✗ Cannot access Stats API (no API key)
✗ Cannot change data retention or privacy settings
✗ Cannot delete data

When to grant Viewer:

• Executive stakeholders reviewing performance
• Client teams consuming reports but not configuring
• Compliance-friendly read-only access
• Post-implementation support (analysis only)
• Temporary audit or assessment access

Permissions Matrix

Plausible Cloud vs. Self-Hosted

Plausible Cloud (plausible.io)

• User management via web UI only
• No server access required
• Automatic updates and maintenance
• Built-in GDPR/privacy compliance features
• API rate limits enforced (varies by plan)
• Data stored on Plausible's servers (EU or US region)

Self-Hosted (Community Edition or Enterprise)

• User management via web UI and database/environment variables
• Requires server administration access (SSH, Docker, database)
• Self-managed updates via Docker images
• Full control over data residency and storage
• No API rate limits (self-managed infrastructure)
• Additional access layers to track:
  • SSH access to the server
  • PostgreSQL/ClickHouse database credentials
  • Docker container access
  • Environment variable configuration
  • Backup and disaster recovery access

Access Management Differences:

Add, Update, Remove - Lifecycle Overview

Add User Access

When to Add:

• Collaborator begins analytics implementation project
• New team member joins for reporting and analysis
• External consultant requires dashboard access
• Stakeholder needs visibility into specific site metrics

Prerequisites:

• Approved access request with justification
• Defined scope (which sites, which role)
• Confirmation of data access constraints (PII, revenue metrics)
• NDA and security attestation (if required)

Implementation Steps:

1. Determine Site Scope

   • List all sites the collaborator needs access to:
     • Production domains
     • Staging environments
     • Development sites
     • Regional sites (if applicable)

2. Choose the Right Role

   • Administrator if:
     • Setting up goals, custom properties, or integrations
     • Configuring tracking implementation
     • Managing team access or data retention
   • Viewer if:
     • Only analyzing data and viewing reports
     • No configuration changes needed
     • Compliance requires read-only access

3. Invite to Each Site

   • Log in to Plausible as the site owner or an existing administrator
   • Navigate to Site Settings → People
   • Click Invite Member
   • Enter collaborator's email address
   • Select role: Administrator or Viewer
   • Click Send Invitation
   • Repeat for each site in scope

4. Collaborator Accepts Invitation

   • Collaborator receives email invitation
   • Clicks link to accept
   • Creates Plausible account (if first time) or logs in
   • Site appears in their site list with assigned role

5. Verify Access

   • Have collaborator log in to confirm access
   • Verify they see only the intended sites
   • Test that role permissions work as expected:
     • Administrator: Try creating a test goal, then delete it
     • Viewer: Confirm cannot access Settings tab

6. Document the Grant

   • Screenshot Site Settings → People showing the collaborator
   • Note the role and effective date
   • File in IAM tracking system or compliance folder

Update User Access

When to Update:

• Implementation phase completes; downgrade from Administrator to Viewer
• New sites launch and require the collaborator's involvement
• Scope expands to include goal configuration (upgrade to Administrator)
• Seasonal campaign sites no longer needed (remove access)

Implementation Steps:

1. Navigate to Site Settings

   • Log in as site owner or administrator
   • Go to the site requiring a role change
   • Navigate to Site Settings → People

2. Change the Role

   • Find the collaborator in the team list
   • Click the role dropdown next to their name
   • Select new role: Administrator or Viewer
   • Change takes effect immediately

3. Add/Remove Sites

   • To add site access: Invite the collaborator to the new site (same process as initial add)
   • To remove site access: Click Remove next to collaborator's name in People tab

4. Verify the Change

   • Have collaborator log in and confirm updated permissions
   • Test new capabilities (or lack thereof)
   • Ensure removed sites no longer appear in their site list

5. Document the Update

   • Screenshot updated People tab
   • Note previous role, new role, and justification
   • Update IAM tracking spreadsheet

Common Update Scenario:

Implementation Phase (Months 1-2):
- mysite.com (production): Administrator
- staging.mysite.com: Administrator

Post-Implementation (Month 3+):
- mysite.com (production): Viewer
- staging.mysite.com: Remove Access

Rationale: Goals and tracking configured; ongoing work is analysis only

Remove User Access

When to Remove:

• Contract or engagement ends
• Collaborator changes companies
• Security incident requires immediate revocation
• Dormant account (no login for 90+ days)

Pre-Removal Checklist:

• Identify all sites the collaborator has access to
• Note any goals or custom properties they configured
• Check for any integrations they set up (webhooks, Slack notifications)
• Verify if they used Stats API (check for API key usage)

Implementation Steps:

1. Remove from Each Site

   • Log in as site owner or administrator
   • Navigate to each site the collaborator has access to
   • Go to Site Settings → People
   • Click Remove next to the collaborator's name
   • Confirm removal
   • Repeat for all sites

2. Rotate API Keys (if applicable)

   • If the collaborator had Administrator access, they could access the site's Stats API key
   • Navigate to Site Settings → Visibility
   • Scroll to Stats API section
   • Click Regenerate API Key
   • Update any integrations using the old key

3. Review and Transfer Assets

   • Goals: Goals remain after user removal (no owner concept)
   • Custom Properties: Properties persist (document which ones they created)
   • Integrations: Verify Slack/webhook integrations still function
   • Shared Links: Revoke any shared dashboard links created by the collaborator

4. Verify Complete Removal

   • Collaborator should no longer see sites in their account
   • API calls with old API key (if rotated) should fail
   • Confirm collaborator cannot access shared dashboard links (if revoked)

5. Final Documentation

   • Export or screenshot People tab from all sites (showing removal)
   • List any API keys rotated
   • Document goals/properties created by the collaborator (for future reference)
   • File evidence in compliance folder

Platform-Specific Considerations

Privacy-First Philosophy

Plausible is built with privacy as a core feature:

No Cookies by Default

• Plausible doesn't use cookies for tracking
• Complies with GDPR, CCPA, PECR without cookie banners
• No personal data or PII is collected by default

Implications for Access Management:

When granting access, clarify what data the collaborator can see:

• Page views, referrers, countries: Always available (anonymized)
• Revenue metrics: Only if ecommerce tracking is configured
• Custom properties: May contain PII if misconfigured - verify compliance

Data Access Constraints:

If your compliance framework restricts PII access:

• Grant Viewer role (cannot configure custom properties that might capture PII)
• Document that collaborator must not add tracking for sensitive user data
• Review goals and properties quarterly to ensure no PII leakage

Per-Site Scope is the Norm

No Global Organization Concept:

Unlike Mixpanel or Segment, Plausible doesn't have "organizations" with centralized access control:

• Each site is independent
• You must invite the collaborator to each site individually
• A collaborator could theoretically have access to 50 sites from 50 different owners

Best Practices:

1. Create a Site Inventory:

   Site	Domain	Environment	Collaborator Role	Notes
   Production	mysite.com	Production	Viewer	Post-implementation support
   Staging	staging.mysite.com	Staging	Remove	No longer needed
   Mobile App	app.mysite.com	Production	Viewer	iOS/Android combined

2. Use Consistent Naming:

   • Help collaborators identify sites: "Acme Corp - Production" vs. "Acme Corp - Staging"
   • Include environment in site name if using multiple

3. Review Site Access Quarterly:

   • Collaborators accumulate site access over time
   • Periodically audit: "Does the collaborator still need access to all 15 sites?"

Self-Hosted Additional Access

For self-hosted Plausible instances, collaborators may need server-level access:

Server Access (SSH):

• Required for: Updating Plausible, viewing logs, database backups
• Grant only to: DevOps, platform administrators
• Track separately from Plausible UI permissions

Database Access (PostgreSQL/ClickHouse):

• Required for: Manual queries, troubleshooting, data exports
• Grant read-only credentials when possible
• Document database users separately from Plausible UI users

Docker Container Access:

• Required for: Restarting services, viewing logs, configuration changes
• Grant to: Platform administrators
• Use Docker user groups to limit access

Example: Separate Credentials Tracking:

## Collaborator: jane@agency.com

### Plausible UI Access:
- mysite.com: Administrator
- staging.mysite.com: Administrator

### Server Access (Self-Hosted):
- SSH: jane_limited@plausible-server (read-only logs)
- PostgreSQL: plausible_readonly (SELECT only)
- Docker: Member of docker-logs group (view logs only)

### Offboarding Actions:
1. Remove from Plausible sites
2. Revoke SSH access: sudo deluser jane_limited
3. Drop PostgreSQL user: DROP USER plausible_readonly;
4. Remove from Docker group: sudo deluser jane_limited docker-logs

API Access and Automation

Stats API

Plausible provides a Stats API for programmatic access to analytics data:

API Key Location:

• Each site has its own API key
• Navigate to Site Settings → Visibility → Stats API
• Click Generate API Key (site administrator required)

API Access Control:

• Only Administrators can generate and view the API key
• Viewers do not have API access
• API key provides same access as Administrator role (read all metrics)

Security Considerations:

When granting Administrator access:

• Collaborator can access and copy the Stats API key
• They can use this key to programmatically query all site data
• API access persists even if you later downgrade them to Viewer

Rotation Workflow:

When removing an Administrator who had API access:

1. Navigate to Site Settings → Visibility
2. Scroll to Stats API section
3. Click Regenerate API Key
4. Copy the new API key
5. Update any integrations:
   • Custom dashboards (Grafana, Databox)
   • Data pipelines to warehouses
   • Automated reporting scripts
   • Third-party BI tools

Document API Usage:

Maintain an inventory:

Event and Goal Metadata

While Plausible is primarily a pageview analytics tool, goals track conversions:

Goals Configuration:

• Only Administrators can create and modify goals
• Goals persist after Administrator access is removed
• Document which goals were created by each collaborator

Custom Properties (Enterprise Feature):

Custom properties allow tracking additional dimensions:

• Configured by Administrators only
• Can potentially capture PII if not carefully designed
• Review properties quarterly for compliance

Best Practice:

When granting Administrator access:

Collaborator: jane@agency.com
Access: mysite.com - Administrator
Restrictions:
- Do NOT configure custom properties that capture user IDs, emails, or PII
- All goals must align with documented conversion tracking plan
- Consult data governance team before adding new properties

Security and Compliance

GDPR and Privacy Compliance

Plausible is designed to be GDPR-compliant by default:

Data Processing Agreements (DPA):

• Plausible Cloud: DPA available for Enterprise customers
• Self-Hosted: You are the data controller; no DPA with Plausible needed

Collaborator Data Access:

When granting access, consider:

• Viewer: Can see aggregated, anonymized data only (typically safe)
• Administrator: Can configure tracking that might capture PII (requires care)

Document Data Access:

## Data Access Log

**Collaborator:** jane@agency.com
**Site:** mysite.com
**Role:** Administrator
**Data Accessible:**
- Aggregated page views (no PII)
- Country, device, browser data (anonymized)
- Custom property: "Plan Type" (not PII)
- Revenue data: Ecommerce total (no individual transactions)

**PII Restrictions:**
- Must not configure custom properties capturing emails, user IDs, or names
- Must not enable IP address logging
- Reviewed by: Data Protection Officer (John Doe) on 2024-01-15

Access Reviews and Audit Trail

Quarterly Access Reviews:

1. Generate Site Access Report:

   • For each site, export or screenshot Settings → People
   • List all users, roles, and last activity (if available)

2. Review Against Contracts:

   • Is the collaborator still working on this project?
   • Does their role still match their responsibilities?
   • Can any Administrators be downgraded to Viewer?

3. Take Action:

   • Remove access to completed projects
   • Downgrade over-provisioned roles
   • Add access to new sites as needed

4. Document:

   • File quarterly review report
   • Note all changes made
   • Schedule next review (90 days out)

Audit Trail Limitations:

Plausible does not provide a detailed audit log of who did what:

• No native "activity log" feature
• Changes (goal creation, team invitations) are not tracked
• Self-hosted: Enable application logging for partial audit trail

Workaround:

Maintain manual documentation:

• Screenshot People tab before/after each change
• Email confirmations to collaborators documenting access changes
• IAM ticket with timestamps and approvals
• Store in compliance folder for retention period

Multi-Factor Authentication (MFA)

Plausible Cloud:

• MFA is not yet available as of 2024 (check roadmap for updates)
• Rely on strong password policies and email-based verification

Self-Hosted:

• Implement MFA via reverse proxy (e.g., Nginx with Authelia, oauth2-proxy)
• Protect Plausible application behind SSO gateway that enforces MFA

Compensating Controls:

Without native MFA:

• Require strong passwords (16+ characters)
• Use password managers for collaborators
• Monitor for suspicious logins (unusual countries, times)
• Rotate API keys quarterly

Governance Checklist

Onboarding Checklist

For each new collaborator:

• IAM ticket created with approval
• Site access scope defined (list all sites)
• Role determined per site (Administrator vs. Viewer)
• Data access constraints documented (PII restrictions)
• Collaborator signed NDA (if required)
• Invitation sent to each site
• Collaborator accepted all invitations
• Collaborator verified access works
• Screenshot People tab from each site
• Evidence filed in compliance folder
• API key usage documented (if Administrator)
• First access review scheduled (30/60/90 days)

Quarterly Review Checklist

Every 90 days:

• Export/screenshot People tab from all sites
• Compare against active contracts
• Identify unused access (collaborator inactive on site)
• Review Administrator roles:
  • Still configuring goals/properties?
  • Can be downgraded to Viewer?
• Verify site access aligns with current scope:
  • Remove access to completed projects
  • Add access to new sites
• Check API key usage (if applicable):
  • Still needed?
  • Should be rotated?
• Document all changes
• Update IAM tracking spreadsheet
• Schedule next review

Offboarding Checklist

When a collaborator departs:

• List all sites with collaborator access
• Document goals/properties created by collaborator
• Remove collaborator from each site:
  • Site 1: Removed
  • Site 2: Removed
  • Site 3: Removed
• Rotate API keys for sites where collaborator had Administrator access:
  • Site 1: API key rotated
  • Site 3: API key rotated
• Update integrations using old API keys
• Self-hosted: Remove server access:
  • SSH access revoked
  • Database user dropped
  • Docker group membership removed
• Screenshot People tab from all sites (showing removal)
• Document rotated API keys
• Email confirmation to:
  • Collaborator
  • Project stakeholders
  • Compliance/security team
• File all evidence in compliance folder
• Update IAM tracking spreadsheet
• Close IAM ticket

Roles to Maintain

Administrator

Grant when:

• Collaborator needs to configure goals, properties, or integrations
• Setting up initial tracking implementation
• Managing site settings or data retention policies
• Requiring Stats API access for custom integrations

Review periodically:

• After implementation completes, consider downgrading to Viewer
• If no configuration changes in 90+ days, likely over-provisioned

Viewer

Grant when:

• Collaborator only needs to analyze data and view reports
• Post-implementation ongoing support (no config changes)
• Executive stakeholder periodic performance review
• Compliance requires read-only access

Use as default:

• Start with Viewer unless Administrator is explicitly justified
• Upgrade to Administrator temporarily when needed, then downgrade

Billing Owner (Site Owner)

Maintain with:

• Client finance or IT team
• Avoid granting to external collaborators (cannot be transferred easily)

Note:

• Only the billing owner can delete the site permanently
• Billing owner always has full Administrator permissions
• Plan ahead: If collaborator creates sites, they become permanent owner

Evidence to Retain

For compliance (SOC 2, ISO 27001, GDPR):

Per Access Change:

• Screenshot of Site Settings → People before change
• Screenshot after change
• Email invitation or removal confirmation
• IAM ticket with approval and justification

Quarterly:

• Full site access inventory (all sites, all users, all roles)
• Review notes: who was reviewed, what changed, why
• API key rotation log (if applicable)

Storage:

• Organize by year and ticket: /compliance/plausible/2024/IAM-XXXX/
• Retain for compliance period (typically 7 years)
• Backup to secure, access-controlled location

By maintaining disciplined access governance for Plausible, you ensure privacy-compliant analytics while supporting collaborator productivity and maintaining a clear audit trail for regulators and stakeholders.