Adobe Analytics User Management

Adobe Analytics access is controlled from the Adobe Admin Console. Centralize how product profiles, virtual report suites, and single sign-on groups are provisioned so the collaborator can work quickly without opening unnecessary data sets.

How Adobe Structures Access

Adobe Analytics uses a layered permissions model managed through the Adobe Admin Console. Understanding this architecture is critical for maintaining secure, compliant collaborator access.

Organizations and Product Profiles

• Organizations represent your company's Adobe Experience Cloud instance. All users, products, and entitlements roll up to this top level.
• Product profiles are the primary access control mechanism. Each profile bundles together permissions for specific report suites, virtual report suites, metrics, dimensions, and Adobe Analytics tools.
• Product instances connect product profiles to specific Adobe Analytics login companies, allowing you to segment access across different business units or brands.

Identity Management Layers

Adobe Analytics supports multiple identity types:

• Adobe IDs are personal accounts owned by the user. Use these for external contractors who manage their own credentials.
• Enterprise IDs are created and owned by your organization but managed by Adobe. These work well when you don't have federated identity infrastructure.
• Federated IDs connect to your corporate identity provider (Okta, Azure AD, OneLogin) via SAML SSO. Most enterprises use Federated IDs to maintain centralized control.

Track which identity type you assign to the collaborator's service account. Federated IDs require coordination with your IdP administrator to map groups correctly.

API and Technical Accounts

API access is separate from human user access:

• Adobe I/O integrations use Service Account (JWT) or OAuth Server-to-Server credentials for programmatic access to Analytics APIs, Data Warehouse, and Data Feeds.
• Adobe Developer Console is where you create and manage these technical accounts. Each integration can be scoped to specific Analytics permissions.
• Launch (Adobe Tags) publishing rights are tied to product profiles. If the collaborator needs to publish tags, ensure the profile includes the "Manage Publishing" permission.

Document which technical accounts belong to the collaborator separately from UI users. Technical accounts don't expire when a UI user is removed unless you explicitly revoke them.

Product Profile Permissions Matrix

Adobe Analytics product profiles contain granular permissions across multiple categories. Use this matrix to design collaborator-appropriate profiles.

Permission Categories Explained

Report Suite Tools govern access to administrative functions:

• All Report Suite Tools grants full administrative control. Reserve this for product profile admins only.
• Calculated Metrics allows creating custom metrics. Most collaborators need this for analysis work.
• Data Warehouse enables large data extracts. Grant only when the collaborator handles offline analysis or compliance exports.
• Code Manager provides access to download AppMeasurement libraries. Required for implementation consultants.

Analytics Tools control which applications users can launch:

• Analysis Workspace is the primary analytics interface. Most users need at least View access.
• Report Builder is the Excel add-in for scheduled reporting. Grant when the collaborator builds client dashboards.
• Activity Map shows in-page click analytics. Implementation teams need this; analysts typically don't.

Report Suite Permissions control data visibility:

• Metrics and dimensions can be selectively hidden per profile. Use this to restrict PII dimensions or sensitive conversion metrics.
• Cost/Revenue permissions gate access to financial data. Many collaborators should have these restricted unless explicitly required.

Virtual Report Suite (VRS) Permissions:

• VRS creation allows collaborators to segment data without duplicating report suites. Useful for multi-brand environments.
• Component curation lets users hide irrelevant metrics/dimensions from team members. Grant to senior analysts managing governance.

Account Types and Capabilities

System Administrators

System Administrators are assigned in the Adobe Admin Console, not within Analytics itself.

Capabilities:

• Manage all product profiles and user assignments
• Configure federated SSO and directory sync (SCIM)
• Access billing and contract information
• Create and assign product administrators
• View audit logs across all Adobe Experience Cloud products

When to assign: Keep System Admin rights restricted to IT leadership and your security team. The collaborator rarely needs this level of access.

Product Profile Administrators

Product Profile Admins manage specific Analytics product profiles within the Admin Console.

Capabilities:

• Add/remove users to their assigned product profiles
• Edit product profile permissions (report suites, metrics, dimensions, tools)
• Cannot create new profiles or modify system-level settings
• Cannot access analytics data directly through this role

When to assign: Grant Product Profile Admin when the collaborator manages a team of analysts or handles user onboarding/offboarding for a specific brand or business unit.

Analytics Product Users

Standard users consume analytics data and build reports based on their assigned product profile.

Capabilities determined by product profile:

• View and analyze data in assigned report suites and VRS
• Create calculated metrics, segments, and dashboards
• Schedule and share reports
• Use API access if granted through product profile

When to assign: This is the default role for most collaborator engagements. Scope access via product profile permissions rather than elevating to admin roles.

Developer/API-Only Accounts

Technical accounts created in Adobe Developer Console for programmatic integrations.

Capabilities:

• Call Analytics 2.0 APIs for data extraction, reporting, and administration
• Access Data Feeds and Data Warehouse extracts
• Publish Adobe Launch properties (if configured)
• No UI access to Analytics unless also provisioned as a product user

When to assign: Use when the collaborator builds integrations, data pipelines, or automated reporting systems. Store credentials in a secure vault and rotate them according to your security policy.

Access Control Concepts

Data Minimization Through VRS

Virtual Report Suites allow you to create filtered views of data without duplicating report suite configurations.

Use VRS to:

• Restrict the collaborator to specific domains, subdomains, or app sections
• Hide PII dimensions (email, phone, address) while preserving aggregate analysis
• Apply processing rules and session definitions that differ from the base report suite
• Segment production vs. staging traffic so the collaborator only sees relevant data

Implementation pattern:

1. Create a VRS that filters to the collaborator's scope (e.g., specific brand, region, or date range)
2. Configure component curation to hide sensitive metrics/dimensions
3. Assign the VRS to a dedicated product profile
4. Grant the collaborator access to the profile, not the underlying global report suite

This approach satisfies data minimization requirements for GDPR, CCPA, and contractual data access clauses.

Report Suite Access Patterns

Adobe Analytics allows you to assign multiple report suites to a single product profile, or create one profile per report suite for tighter control.

Multi-suite profiles:

• Pros: Simplified administration, fewer profiles to maintain, easier to grant cross-brand access
• Cons: Risk of over-provisioning, harder to audit who sees what
• Use when: The collaborator manages analytics across multiple brands with similar sensitivity

Single-suite profiles:

• Pros: Granular control, clear audit trails, easier compliance documentation
• Cons: More profiles to manage, higher administrative overhead
• Use when: Report suites contain different data sensitivity levels (e.g., healthcare vs. marketing sites)

Recommendation: Start with single-suite profiles for the collaborator. Merge only when administration burden outweighs security benefits.

Metric and Dimension Restrictions

Product profiles allow you to selectively hide metrics and dimensions, even when granting access to a report suite.

Common restriction scenarios:

• Commerce data: Hide revenue, product, and transaction metrics for collaborators focused on traffic analysis
• PII dimensions: Block email, phone, ZIP code, and other personal identifiers unless specifically required
• Custom variables: Restrict access to eVars/props that contain sensitive business logic or customer segments

Implementation steps:

1. In the product profile, navigate to the report suite permissions
2. Under Metrics or Dimensions, switch from "Include All" to "Customize"
3. Uncheck metrics/dimensions the collaborator should not see
4. Document which restrictions apply and why in your access tracker

Testing: After applying restrictions, log in as the collaborator (or use Adobe's "Login As" feature if available) to verify hidden elements don't appear in Analysis Workspace.

Team and Organization Structure

Single-Tenant vs. Multi-Tenant Strategies

Single-tenant (one organization per legal entity):

• Simplest to manage
• Clear ownership and billing boundaries
• Best for most client-collaborator relationships

Multi-tenant (collaborator manages multiple client organizations):

• Requires separate Adobe accounts per client
• No cross-organization visibility without re-authentication
• Use when the collaborator serves multiple clients with Adobe Analytics

For collaborator engagements: Keep the collaborator's service account in your organization. Don't create separate orgs unless required by compliance or contractual terms.

Product Context Segmentation

Adobe allows product profiles to be scoped to product contexts (previously called "login companies").

When to use:

• Your organization has multiple Adobe Analytics login companies (rare, typically legacy migrations)
• You need to completely isolate access between business units at the authentication level
• Different legal entities share an Adobe organization but require separation

Most implementations: Use a single product context and rely on VRS, report suite permissions, and component restrictions for segmentation.

SSO and SAML Integration

Federated Identity Setup

Adobe Admin Console supports SAML 2.0 federation with enterprise identity providers.

Supported IdPs:

• Microsoft Azure AD
• Okta
• OneLogin
• PingFederate
• Any SAML 2.0 compliant provider

Setup requirements:

1. Configure your IdP as a SAML application pointing to Adobe's SSO endpoint
2. In Adobe Admin Console, link your domain and configure the SAML integration
3. Map IdP user attributes (email, first name, last name) to Adobe attributes
4. Test with a non-production account before rolling out to collaborators

Collaborator implications:

• Federated users authenticate through your corporate SSO
• Password resets and MFA are managed in your IdP, not Adobe
• User lifecycle (creation, suspension, deletion) can be automated via SCIM

SCIM-Based Directory Sync

Adobe supports SCIM (System for Cross-domain Identity Management) for automated user provisioning.

What SCIM automates:

• User creation when added to IdP groups
• Product profile assignment based on group membership
• User deactivation when removed from IdP groups
• Attribute updates (name, email changes)

Implementation pattern for collaborators:

1. Create an IdP group representing the collaborator's engagement (e.g., "Analytics-CollaboratorX-Analysts")
2. Map that group to an Adobe product profile in Admin Console SCIM configuration
3. Add the collaborator's service account to the IdP group
4. SCIM automatically provisions the Adobe user and assigns permissions

Benefits:

• Onboarding and offboarding happen through familiar IAM workflows
• Reduced risk of orphaned accounts
• Clear audit trail in both IdP and Adobe Admin Console

Cautions:

• Manual changes in Adobe Admin Console may be overwritten on next sync
• Always update the IdP group first, then validate in Adobe
• Document SCIM mappings so future administrators understand the automation

Group-Based Access Control

Even without SCIM, you can map SSO groups to product profiles manually.

Workflow:

1. Configure group mappings in Adobe Admin Console under Identity → Directories
2. Assign product profiles to groups instead of individual users
3. Manage collaborator access by adding/removing them from IdP groups

Advantages:

• Centralized access control through your IdP
• Easier quarterly access reviews
• Aligns with least-privilege and joiner/mover/leaver processes

Documentation requirements:

• Maintain a mapping table showing which IdP groups grant which Adobe product profiles
• Note the mapping in collaborator onboarding documentation
• Review mappings quarterly to catch unused groups or stale assignments

API Access and Authentication

Adobe Analytics APIs

Adobe provides several API types for programmatic access:

Analytics 2.0 API:

• Modern REST API for reporting, segments, calculated metrics, and administration
• Requires Adobe Developer Console project with Analytics API enabled
• Supports OAuth Server-to-Server (preferred) or Service Account (JWT, deprecated 2025)

Analytics 1.4 API:

• Legacy SOAP-based API, still supported but not recommended for new integrations
• Use only when integrating with tools that don't support 2.0

Bulk Data APIs:

• Data Warehouse API for scheduled extracts
• Data Feeds API for raw clickstream exports
• Requires separate permissions in product profiles

Creating Technical Accounts for Collaborators

OAuth Server-to-Server (current standard):

1. Navigate to Adobe Developer Console (console.adobe.io)
2. Create a new project or select an existing one
3. Add the Analytics API service
4. Configure OAuth Server-to-Server credential
5. Assign the project to a product profile with appropriate Analytics permissions
6. Provide the collaborator with:
   • Client ID
   • Client Secret
   • Organization ID (IMS Org ID)
   • Technical Account Email

Security best practices:

• Store credentials in a secure vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
• Rotate credentials annually or when the collaborator engagement ends
• Use separate technical accounts for different integration types (reporting vs. data feeds vs. admin API)
• Apply principle of least privilege: grant only the API scopes actually required

Service Account (JWT) - Legacy:

If you're still using JWT (deprecating 2025):

• Generate a public/private key pair
• Upload the public certificate to Adobe Developer Console
• Provide the collaborator with the private key, client ID, client secret, and technical account ID
• Plan migration to OAuth Server-to-Server before Adobe's sunset date

API Permission Scoping

Adobe Developer Console projects inherit permissions from assigned product profiles.

Reporting API access:

• Requires product profile with access to desired report suites
• Respects metric/dimension restrictions
• VRS access depends on product profile assignments

Admin API access:

• Requires "Web Services Access" permission in product profile
• Can create/modify segments, calculated metrics, VRS (if profile allows)
• Cannot modify user permissions (use Admin Console APIs for IAM tasks)

Data Feeds/Data Warehouse:

• Requires explicit Data Feeds or Data Warehouse tool permission
• Separate from UI access; grant only when programmatic bulk exports are required

Best practice: Create a dedicated product profile for the collaborator's API integrations. Don't mix API and UI user permissions in the same profile.

Rate Limits and Quotas

Adobe Analytics APIs enforce rate limits to protect platform stability:

• Analytics 2.0 Reporting API: 12 requests per 6 seconds per user (120 requests/minute effective limit)
• Bulk endpoints: Lower limits, typically 5-10 requests per minute
• Admin API: Varies by endpoint, generally more permissive than reporting API

For collaborator integrations:

• Implement exponential backoff and retry logic
• Cache responses when appropriate
• Use the Analytics 2.0 multiple-report-suite feature to reduce API calls
• Monitor rate limit headers in API responses

Quota overages: Contact Adobe Client Care if the collaborator requires higher limits. Document business justification and expected usage patterns.

Audit Logging and Monitoring

Admin Console Audit Logs

The Admin Console provides comprehensive audit logs for all user management actions.

Events logged:

• User invitations, additions, and removals
• Product profile assignments and changes
• SSO configuration modifications
• API credential creation and rotation
• System administrator role changes

Access audit logs:

1. Navigate to Adobe Admin Console
2. Select your organization
3. Go to Settings → Audit Logs
4. Filter by user, event type, or date range
5. Export to CSV for compliance storage

Retention and compliance:

• Adobe retains audit logs for 2 years in the UI
• Export logs quarterly (or more frequently) for long-term archival
• Include exports in your SOC 2, ISO 27001, or GDPR compliance documentation
• Tag collaborator-related events for easy retrieval during audits

Analytics Usage Logs

Adobe Analytics tracks user activity within the analytics interface:

Admin → Logs → Usage & Access:

• Records report requests, segment creations, and dashboard activities
• Shows which users accessed which report suites and when
• Useful for identifying dormant accounts or unusual access patterns

Admin → Logs → Server Calls:

• Tracks server call volume by report suite
• Helps identify runaway tracking implementations
• Not user-specific, but useful for monitoring collaborator-managed properties

Compliance use cases:

• Demonstrate the collaborator only accessed permitted report suites
• Identify potential data exfiltration (unusual volume of Data Warehouse requests)
• Support "right to access" requests by showing when collaborator accounts touched personal data

API Call Logging

Adobe Developer Console projects include basic request logging:

Available in Developer Console:

• Daily request counts per API endpoint
• Error rates and status code distributions
• Not detailed per-request logs

For detailed API audit trails:

• Implement logging in your application layer
• Log all API requests, responses, and the user/service account context
• Store logs in your SIEM (Splunk, Datadog, AWS CloudWatch)
• Alert on anomalous patterns (e.g., sudden spike in Data Warehouse API calls)

Collaborator-specific monitoring:

• Tag API calls from collaborator integrations with a distinct identifier
• Set up alerts for failed authentication attempts
• Review API usage monthly to ensure it aligns with scope of work

Access Requests at a Glance

• Onboard the collaborator by inviting the shared service account to the correct organization and assigning an Analytics product profile. Follow the steps in Add User Access.
• Adjust permissions when scopes change, such as adding new report suites or enabling Customer Journey Analytics. Reference Update Access & Roles for the required toggles.
• Offboard or pause access if an engagement ends or legal requires suspension. Remove User Access documents the deactivation workflow and audit exports.

Add, Update, Remove at a Glance

• Add: Invite the collaborator via Admin Console, attach the correct product profile, and confirm virtual report suite visibility lines up with data minimization rules.
• Update: Expand or reduce report suite lists as brands launch or pause. Adjust tool permissions (e.g., enable Report Builder) only when explicitly needed. Coordinate SSO groups so changes persist.
• Remove: Revoke the product profile, delete the user if policy requires, and rotate any Adobe I/O credentials tied to the collaborator. Archive the Admin Console audit log.

Platform Notes and Practical Steps

• Product profiles drive everything: Each profile bundles report suites, virtual report suites, and tool access. When you add or update a user, confirm the profile matches the data set the collaborator should see, especially if sensitive commerce or PII metrics live in separate VRSs.
• Admin Console + Analytics UI pairing: Adding a user in Admin Console is only step one. Open Analytics → Admin → User Management to verify the product profile mapped correctly and that Workspace/Report Builder toggles are on or off as intended.
• SSO group hygiene: Many enterprises sync IdP groups to product profiles. Adjust the group membership first, then validate in Admin Console to avoid the next SCIM sync undoing your manual edits.
• Audit-ready evidence: Save the Admin Console Audit Log entry plus a screenshot of the user's assigned profiles after every add/update/remove. If the collaborator manages Launch or Adobe I/O credentials, note which keys were rotated and where they are stored.

Roles to Maintain

• Product Profile Administrators who can edit Analytics profiles and virtual report suites. At least one client-side owner plus the collaborator point of contact.
• Analytics Users for day-to-day analysis. Align report suite access with data minimization policies and enable only the tools (Workspace, Report Builder, Data Warehouse) each persona needs.
• Developer/API Accounts for integrations, Launch publishing, or bulk data pulls. Map credentials to service accounts rather than individuals wherever possible.

Best Practices for Team Access Management

Principle of Least Privilege

Grant the minimum permissions required for the collaborator to complete contracted work.

Decision framework:

1. Identify the specific tasks in the statement of work
2. Map tasks to required report suites, metrics, dimensions, and tools
3. Create or select a product profile that matches this scope exactly
4. Grant access for the engagement duration only, not indefinitely

Common over-provisioning mistakes:

• Granting "All Report Suite Tools" when only Analysis Workspace is needed
• Providing access to all report suites when work is scoped to one brand
• Enabling Data Warehouse for collaborators who only build dashboards

Review cadence: Audit collaborator permissions quarterly. If scope has narrowed or engagement has shifted, downgrade access accordingly.

Separation of Duties

Avoid granting both administrative and analytical access to the same account when possible.

Pattern for large engagements:

• Collaborator Admin Account: Product profile administration, minimal analytics access
• Collaborator Analyst Accounts: Named analysts with analytics access, no admin rights
• Collaborator Technical Account: API/service account for integrations, no UI access

Benefits:

• Clearer audit trails
• Reduced blast radius if credentials are compromised
• Easier to implement maker-checker controls for sensitive actions

Time-Bound Access

Set explicit expiration dates for collaborator access.

Implementation options:

• Calendar reminders to review and renew/revoke access
• IdP group membership with automated expiration (if your IAM supports it)
• Contract-based triggers (offboard 30 days after contract end date)

Documentation: Note the expected access end date in both the Admin Console user notes field and your internal access tracker.

Service Accounts vs. Individual Logins

Use service accounts when:

• Multiple collaborator team members need identical access
• API integrations require stable credentials
• You want to avoid churn from individual employee turnover

Use individual logins when:

• You need to attribute actions to specific people for compliance
• Collaborator team members have different skill levels or scopes
• Your data processing agreements require named individuals

Hybrid approach: Service account for shared analytics access, individual accounts for Product Profile Admins who make permission changes.

Common Access Issues and Solutions

Issue: User Can't See Expected Report Suites

Symptoms:

• Collaborator logs in but sees "No report suites available"
• Specific report suites missing from dropdown

Resolution steps:

1. Verify the collaborator accepted the Admin Console invitation email
2. Check that the product profile includes the report suite permissions
3. Confirm the product profile is assigned to the correct product context (login company)
4. If using VRS, ensure the base report suite is accessible and the VRS is shared
5. Clear browser cache and cookies, then re-login
6. Use Admin Console "View User Details" to see exactly which profiles are assigned

Prevention: After adding users, log in as them (or use "Login As" feature) to verify visibility before notifying them.

Issue: SSO Login Fails or Loops

Symptoms:

• Redirect loop between Adobe and IdP
• "Not authorized" error after SSO authentication
• User lands on Adobe ID login instead of SSO

Resolution steps:

1. Verify the user's email domain matches a claimed domain in Admin Console
2. Check IdP application configuration (ACS URL, Entity ID, attribute mappings)
3. Confirm user exists in IdP directory and has the application assigned
4. Review IdP logs for SAML assertion errors or authorization failures
5. Test with a non-production user to isolate configuration vs. account-specific issues

Prevention: Document your SAML configuration (especially attribute mappings) and test SSO with new users before granting production access.

Issue: API Credentials Return 403 Forbidden

Symptoms:

• OAuth or JWT authentication succeeds, but API calls return 403
• "Insufficient privileges" or "Access denied" messages

Resolution steps:

1. Verify the Adobe Developer Console project is assigned to a product profile with Analytics API access
2. Confirm the product profile includes the necessary report suite permissions
3. Check that "Web Services Access" permission is enabled in the product profile
4. For Admin API calls, ensure the profile has administrative permissions for the requested resource type
5. Review API request headers for correct IMS Org ID and Authorization token
6. Test with a known-working report suite to isolate permission vs. configuration issues

Prevention: Create API-specific product profiles with clearly documented permissions. Test API access with a sample script before deploying to production.

Issue: VRS Doesn't Appear for Collaborator

Symptoms:

• Virtual Report Suite created but not visible to collaborator
• VRS visible to admins but not to assigned users

Resolution steps:

1. Verify the VRS is not set to "Hidden" in its configuration
2. Confirm the VRS is tagged/shared with the correct user groups
3. Check that the collaborator's product profile includes the base report suite
4. Ensure component curation in the VRS doesn't hide all components
5. Verify the VRS is associated with the same product context as the user's access

Prevention: When creating VRS for collaborators, explicitly tag them and test visibility before communicating availability.

Issue: Changes Made in Admin Console Don't Appear in Analytics

Symptoms:

• Product profile changes don't reflect in Analytics permissions
• User still has access after being removed from profile

Resolution steps:

1. Wait 15-30 minutes for changes to propagate (Adobe caches permissions)
2. Have the user log out and log back in to refresh session
3. Clear browser cookies and local storage
4. Check Admin Console Audit Log to confirm the change was saved
5. Verify you're not experiencing an Adobe system incident (check status.adobe.com)

Prevention: Communicate to collaborators that permission changes may take up to 30 minutes to take effect. Plan access revocations with buffer time.

Issue: Collaborator Can't Create Calculated Metrics or Segments

Symptoms:

• "Save" button is greyed out or missing
• "You do not have permission to create" error message

Resolution steps:

1. Verify the product profile grants "Calculated Metric Creation" permission
2. Confirm "Segment Creation" permission is enabled if creating segments
3. Check that the user isn't trying to save to a shared folder they don't own
4. Ensure the user has edit (not just view) access to the report suite
5. Verify the user has publish permissions if trying to share company-wide

Prevention: Document which roles can create vs. edit vs. publish calculated metrics/segments. Grant creation permissions explicitly when onboarding analysts.

Security Recommendations

Multi-Factor Authentication (MFA)

Adobe's MFA capabilities:

• Adobe ID users can enable MFA through their Adobe account settings
• Federated ID users inherit MFA from your corporate IdP
• Enterprise ID users can have MFA enforced at the organization level

For collaborator accounts:

• Require MFA for all human users (not service accounts)
• If using Adobe IDs, verify MFA is enabled before granting production access
• For Federated IDs, confirm your IdP MFA policy applies to the collaborator's account
• Document MFA status in your access tracker

Service account exception: API/technical accounts don't support interactive MFA. Protect these with secret rotation policies and IP allowlisting where possible.

Credential Rotation

Human users:

• Rotate passwords every 90 days (if not using SSO)
• Federated ID users follow your corporate password policy
• Force password reset when a collaborator employee leaves their organization

Service accounts:

• Rotate OAuth client secrets annually
• Rotate JWT certificates/private keys annually (or before JWT deprecation deadline)
• Rotate API keys whenever a collaborator developer with access to credentials departs

Implementation:

• Add credential rotation tasks to your recurring IAM calendar
• Use secret management tools (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) to automate rotation where possible
• Test integrations after credential rotation to ensure seamless transition

IP Allowlisting

Adobe Analytics supports IP address restrictions for added security.

Where to configure:

• Admin Console → Settings → IP Address Restrictions
• Applies to UI logins and API access
• Can specify individual IPs or CIDR ranges

For collaborator access:

• Request the collaborator's office/VPN IP ranges
• Configure allowlist to permit only those ranges
• Test with the collaborator before enforcing globally
• Document IP ranges in access tracker for future reference

Limitations:

• IP allowlisting may conflict with remote work or traveling collaborators
• Federated SSO + IP allowlisting provides strong layered security

Data Loss Prevention

Prevent accidental or malicious data exfiltration:

1. Restrict Data Warehouse and Data Feeds access unless explicitly required for the engagement
2. Monitor API usage for unusual bulk export patterns
3. Limit calculated metric/segment publishing to prevent exposing hidden data through loopholes
4. Use VRS component curation to hide sensitive metrics even from users with report suite access
5. Enable audit logging and review quarterly for anomalous downloads or API activity

Incident response:

• Define what constitutes unauthorized data access for your organization
• Plan response workflow: detect, contain (revoke access), investigate (audit logs), notify (legal/compliance)
• Include collaborator access in your regular security reviews and tabletop exercises

Contractual and Compliance Alignment

Before granting access:

• Confirm Data Processing Agreement (DPA) is signed
• Verify collaborator agrees to your data retention and deletion policies
• Check if GDPR, CCPA, HIPAA, or other regulations impose specific access controls
• Document legal basis for sharing data with the collaborator (legitimate interest, contract, consent)

During the engagement:

• Limit collaborator access to data categories specified in the DPA
• Use VRS and metric/dimension restrictions to enforce contractual boundaries
• Export audit logs showing the collaborator only accessed permitted data

After the engagement:

• Remove access per DPA timelines (typically within 30 days of contract end)
• Confirm the collaborator has deleted any local copies of data per your agreement
• Retain audit logs per your compliance retention schedule (often 6+ years)

Governance Checklist

Use this checklist to maintain compliant, secure collaborator access throughout the engagement lifecycle.

Onboarding (before granting access):

• Data Processing Agreement signed and filed
• Collaborator's identity type determined (Adobe ID, Enterprise ID, Federated ID)
• Product profile created or selected with principle of least privilege
• Virtual Report Suites configured if data minimization is required
• SSO/SCIM mappings documented if using federated identity
• MFA confirmed enabled for human users
• API credentials generated and stored in secure vault if required
• Access expiration date recorded in tracker and calendar
• Collaborator's contact information (email, escalation phone) obtained

Quarterly reviews (every 90 days during engagement):

• Confirm collaborator access still aligns with active contract/SOW
• Review Analytics Usage & Access logs for unexpected activity
• Verify SSO group memberships remain appropriate
• Check for dormant accounts (no logins in 60+ days) and offboard if appropriate
• Confirm product profile permissions haven't crept beyond original scope
• Export and archive Admin Console audit logs
• Review API usage and rate limit patterns for anomalies
• Validate IP allowlist ranges if configured

Offboarding (when engagement ends):

• Remove collaborator from product profiles in Admin Console
• Delete user entirely if policy requires (vs. just removing permissions)
• Revoke all API credentials (OAuth, JWT, tokens)
• Remove from SSO/SCIM group mappings
• Rotate any shared credentials the collaborator had access to
• Export final Admin Console audit log showing removal
• Transfer ownership of any dashboards, calculated metrics, segments created by collaborator
• Confirm collaborator has deleted local data copies per DPA
• Archive all access documentation (invite email, permission changes, removal confirmation)
• Update access tracker to mark engagement closed

Annual compliance:

• Review all Adobe Analytics access against current contracts
• Audit product profile permissions for drift from documented standards
• Validate audit log retention and archival processes
• Test SSO/SAML integration and review IdP-Adobe mappings
• Review and update credential rotation schedules
• Confirm IP allowlists reflect current collaborator environments
• Train team on any Adobe Admin Console changes from the past year
• Update internal documentation for new Adobe features or deprecations

Incident response readiness:

• Document which collaborators have Data Warehouse/Data Feeds access
• Maintain emergency contact list for rapid collaborator access revocation
• Test your ability to quickly export audit logs and user access reports
• Define thresholds for anomalous API usage or data access
• Include Adobe Analytics in your security incident response playbook

Related Documentation

• Add User Access - Step-by-step guide for inviting collaborators and assigning product profiles
• Update Access & Roles - How to modify permissions, report suites, and tool access during the engagement
• Remove User Access - Offboarding workflow including audit log exports and credential rotation
• Adobe Admin Console Help - Official Adobe documentation for enterprise administration
• Adobe Analytics Administration Guide - In-depth coverage of Analytics-specific settings beyond user management
• Adobe Developer Console Documentation - Technical account and API credential management

Additional Resources

• Adobe Admin Console: adminconsole.adobe.com
• Adobe Developer Console: console.adobe.io (for API credentials)
• Adobe Status Page: status.adobe.com (check for system incidents affecting access)
• Adobe Analytics Administration: Analytics → Admin within the UI
• Adobe Community Forums: experienceleaguecommunities.adobe.com (peer support for access issues)
• Adobe Client Care: Contact for rate limit increases, complex SSO issues, or access bugs

Document which identity provider groups map to each Analytics product profile and review them quarterly. Track expirations for temporary access granted to auditors or partner agencies and set reminders to revoke. Archive Admin Console audit logs and Workspace change history in your compliance repository alongside contract artifacts. Confirm that the collaborator's service account stays in your incident communications list so the collaborator receives system health and maintenance notices.