Adobe Analytics stores years of visitor behaviour, IP-derived location and often customer IDs, and its export tools can move that data to warehouses, partners and public project links, so who can see and export it is a privacy decision as much as an access one. Adobe Analytics is managed through the Adobe Admin Console, where product profiles grant access to report suites, metrics, dimensions and tools, while Analytics itself holds data governance labels, IP handling settings and its own logs. This guide goes deeper than sign-in: it covers product profile design, the permission items that matter most for data exposure, API credentials, privacy labels for access and deletion requests, IP obfuscation and the Analytics logs. It is written for Analytics product admins, digital analytics and marketing technology teams, and the security and privacy teams that review them. For identity types, SSO, two-step verification and the Admin Console audit log, see the Adobe Admin Console Security guide.
This is an independent guide from NHI Mgmt Group, based on Adobe's public documentation as of November 2026. It is not sponsored or reviewed by Adobe. Product features change, so confirm settings against Adobe's current documentation.
Key takeaways
- Sign-in is set in the Admin Console. Federated ID, SSO and MFA apply to Analytics through the Admin Console; Analytics access itself comes from product profiles.
- Product admins have full access. Keep the Analytics product admin group small and use product profile admins for team leads who only manage membership.
- Some permission items move data out. Data Feeds Manager, Custom Data Warehouse Report, Share Project Links with Anyone, Web Service Access and MCP Access deserve their own narrow profiles.
- API access uses OAuth Server-to-Server. Credentials come from the Adobe Developer Console and inherit the product profiles where the developer is assigned.
- Label data before requests arrive. I1, I2 and S1 identity labels with ACC, DEL and ID labels decide what Privacy Service access and deletion requests return and anonymise.
How identity and access work in Adobe Analytics
Users authenticate through the Adobe Admin Console, so identity type (Federated ID is the strongest option where you run an identity provider), SAML SSO, two-step verification for non-federated users and session limits are configured there. Analytics access is then built from three layers:
- Product profiles: permission presets that product admins assign to users and user groups. To use Analytics at all, a profile needs at least one report suite and the Workspace Project Access item under Analytics Tools.
- Permission items: Report Suites, Metrics (custom events appear as "Custom Event 1-1000"), Dimensions (eVars appear as "Custom Conversion 1-250"), Report Suite Tools and Analytics Tools.
- User groups: assign profiles to Admin Console user groups, ideally synced from your directory, so joiners and leavers follow HR changes. See the Joiner-Mover-Leaver Guide.
Because metrics and dimensions are permission items, a profile can hide a dimension that carries a customer ID or email hash from users who do not need it. Design profiles around data sensitivity, not only around team names.
| Profile pattern (ours) | Report suites | Items included | Items excluded |
|---|---|---|---|
| Analyst | Team's suites | Workspace Project Access, standard metrics and dimensions | Identity-bearing dimensions, Data Feeds, Data Warehouse, sharing with anyone |
| Data engineer | Named suites | Data Feeds Manager, Custom Data Warehouse Report, Data Sources Manager | Security, Report Suite Mgmt |
| Implementation | Named suites | Processing Rules, Classifications, Code Manager, Exclude By IP Address | Data export items |
| Privacy | All suites | Data Governance & Privacy Labeling UI Access | Data export items |
| API integration | Only what the integration reads | Web Service Access plus required metrics and dimensions | Admin and labeling items |
Admin roles and privileged access
Adobe documents two admin levels for Analytics in the Admin Console:
- Product admins: full access to Adobe Analytics, including every report suite and admin tool.
- Product profile admins: can add or remove users in a profile and assign profiles to user groups, but cannot change the profile's permission items or use Analytics in full. Adobe suggests them for team leads who manage team access.
The permission items below are the ones we treat as privileged, from Adobe's Analytics Tools and Report Suite Tools pages.
| Permission item | What it grants (Adobe docs) | Why it is sensitive (ours) |
|---|---|---|
| Security | Security Manager under Company settings | Changes company security settings |
| Web Services / Web Service Access | Web Services under Company settings / use of the API | Programmatic access to data |
| Logs and Logs - Web Services | Admin, All admin, Logs / logs through the 1.4 API | Visibility of activity, useful to an intruder covering tracks |
| Data Feeds Manager | Data Feeds area under Admin | Bulk hit-level export to external destinations |
| Custom Data Warehouse Report | Data Warehouse tool | Large, granular exports |
| Data Repair API | Access to the Data Repair API | Changes stored data |
| Share Project Links with Anyone | Read-only Workspace projects for people without Analytics access | Data leaves the licensed user base |
| MCP Access | Access to the Adobe Analytics MCP server; required for all users, including product admins | Lets AI assistants query Analytics as the user |
| Report Suite Mgmt | Report Suite Manager to create report suites | Changes collection scope |
| Hide Report Suites | Hide any report suite, regardless of report suite access | Can hide data from other users |
- Name the product admins: two or three people, reviewed quarterly (our cadence), each also governed by the Admin Console's admin roles.
- Delegate with product profile admins: team leads manage membership without changing what a profile grants.
- Split export rights: put Data Feeds Manager, Custom Data Warehouse Report and Share Project Links with Anyone in a separate profile with an owner and a business reason.
- Govern AI access: grant MCP Access only through a dedicated profile, so you can see who can connect assistants to Analytics. See the MCP Security Guide.
- Review profiles, not only people: check each profile's permission items yearly, since a single added item widens access for every member.
Integrations, API tokens and service accounts
Analytics API credentials
The Analytics 2.0 API uses credentials created in the Adobe Developer Console. Adobe's API guide lists OAuth Server-to-Server for server-to-server use and OAuth user authentication, and states that JWT authentication was deprecated and supported only until 1 January 2025. Any remaining JWT-based integration needs moving to OAuth Server-to-Server.
- Add the developer first: a product profile admin sets the permission items on an Analytics product profile and adds the developer under the profile's Developers tab before the API client is created.
- Create the project: in the Developer Console, in the correct organisation, create a project, add the Adobe Analytics API and choose OAuth Server-to-Server.
- Scope by profile: a developer's API access reflects the combined permissions of every profile where they have developer access, so use a profile built for that integration, not a broad one.
- Store the client secret in a secrets manager and rotate it on a schedule you set (ours: at least yearly and when owners change).
- Record ownership: project name, owner, purpose, report suites and the profile it uses.
Other non-human access paths
| Path | Credential or setting | Control (ours) |
|---|---|---|
| Data feeds | Destination accounts and locations configured in Data Feeds | Use your own controlled storage, restrict Data Feeds Manager, review destinations quarterly |
| Data Warehouse scheduled reports | Delivery destinations | Restrict Custom Data Warehouse Report; review recipients |
| Legacy 1.4 API web services | Web Services under Company settings | Inventory remaining users, migrate to 2.0 with OAuth |
| Legacy Report Builder | User sign-in from Excel | Grant only to users who still need it |
| MCP server | MCP Access permission item | Dedicated profile, logged and reviewed |
See the Machine-to-Machine OAuth (Client Credentials) Guide, the Secrets Management Guide and the Non-Human Identity (NHI) Guide.
Privacy labels, IP handling and deletion
Data governance labels
Analytics labels decide how Privacy Service access and delete requests treat each variable. Adobe advises customers, as data controllers, to decide labels with their legal teams. Access the labeling screen through the Data Governance & Privacy Labeling UI Access item.
| Label | Meaning (Adobe docs) |
|---|---|
| I1 | Directly identifiable: name, email address |
| I2 | Indirectly identifiable: loyalty number, CRM ID |
| S1 / S2 | Precise geo-location (100 metres or less) / broad geo-fence area |
| ACC-ALL / ACC-PERSON | Return in all access requests / only where an ID-PERSON match shows the hit came from the data subject |
| DEL-DEVICE / DEL-PERSON | Anonymise in hits containing the specified ID-DEVICE / ID-PERSON; requires I1, I2 or S1 |
| ID-DEVICE / ID-PERSON | Field holds a device ID / an authenticated user ID used to find a data subject; requires I1 or I2 |
Assigning ID-DEVICE or ID-PERSON means choosing a namespace, which becomes the namespace value in Privacy Service API requests; visitorId and customVisitorId are reserved. Deletion keeps reports consistent rather than removing rows: props and commerce eVars become random strings starting "Data Privacy-", the visitor ID becomes a random 128-bit value, MCID, custom visitor ID and IP addresses are cleared, URL parameters are removed and latitude and longitude are reduced to about 1 km. Purchase ID is not deleted by default, so label it if it could link a purchase to a person.
ACC-ALL can expose shared-device data to anyone who used that device, so prefer ACC-PERSON where you collect an authenticated ID.
IP handling
In Report Suites, Edit Settings, General, General Account Settings, the IP Obfuscation setting offers Disabled, Obfuscate IP address (a hashed string) and Remove IP address (a placeholder after geo-lookup, the default for new report suites). Obfuscation is permanent and applies across Analytics, including Data Warehouse. A separate checkbox, "Replace the last octet of IP addresses with 0", runs before geo reports are populated. Check that older report suites are not still on Disabled, and update bot rules and IP exclusions that rely on full addresses. Web SDK data can also be obfuscated at the Edge Network in the datastream.
Avoid sending emails or names into props and eVars at all. See the Data Minimisation guide, the Consent Management Guide: Cookies, CMPs and GPC and the GDPR Compliance Guide for Security Teams.
Logging and detection
Analytics keeps three logs under Admin, All admin, Logs, alongside the Admin Console audit log that records profile and admin changes:
- Admin Log: changes administrators make in Admin Tools, searchable by criteria and date range.
- Usage and Access Log: report usage per user, Workspace open, create, update, unshare and delete actions, successful and failed logins, admin actions, security setting changes and API method calls. Filter by date, login, IP address, report suite ID, event type and keyword, and download as a tab-delimited file.
- Report Suite Change Log: report suite changes made outside Admin Tools, including changes by Adobe representatives or Customer Care (FTP classification uploads are not included).
Set your own retention: export the logs on a schedule and keep them in your SIEM for as long as your policy requires.
| Signal (ours) | Source | ATT&CK |
|---|---|---|
| User or developer added to a profile with export, Security or MCP Access items | Admin Console audit log | T1098 Account Manipulation |
| New or changed data feed or Data Warehouse destination | Admin Log | T1530 Data from Cloud Storage |
| Spike in API method calls from one credential | Usage and Access Log | T1213 Data from Information Repositories |
| Failed logins followed by success from a new IP | Usage and Access Log; identity provider logs | T1078.004 Cloud Accounts |
| IP obfuscation or privacy labels changed | Admin Log, Report Suite Change Log | T1098 Account Manipulation |
Metrics: number of Analytics product admins; users holding data export items; API projects with a named owner and OAuth Server-to-Server; report suites with IP obfuscation set to Remove or Obfuscate; variables carrying ID data with complete labels; days of logs held in the SIEM.
Hardening baseline
- Fix identity in the Admin Console first: Federated ID with SSO and phishing-resistant MFA at the identity provider, following the Adobe Admin Console Security guide.
- Inventory: list product admins, profile admins, profiles with their items, Developer Console projects, data feeds and scheduled Data Warehouse reports.
- Redesign profiles: build profiles around data sensitivity, move export items into separate profiles, and pilot with one team before moving everyone.
- Move APIs to OAuth Server-to-Server with one project and one profile per integration.
- Label variables: apply I1, I2 and S labels, then ACC, DEL and ID labels, with your privacy team; test an access request in a non-production report suite.
- Set IP handling on every report suite; changes are permanent for new data, so agree the setting before switching.
- Restrict sharing and AI access: limit Share Project Links with Anyone and MCP Access to dedicated profiles.
- Export logs weekly at minimum and alert on the signals above.
Roll back a profile redesign by reassigning the previous profile to the user group; keep the old profile disabled, not deleted, until the pilot is signed off.
Common misconfigurations
- Everyone a product admin: product admin used as a convenience role, giving full Analytics access to people who only need reports.
- One all-items profile: a single profile with every report suite, metric, dimension and tool, assigned to most users.
- Broad developer profiles: API credentials inheriting the combined permissions of several wide profiles.
- Unreviewed data feeds: feeds still delivering hit-level data to destinations nobody owns.
- Labels missing on ID variables: customer IDs stored in eVars without ID-PERSON and DEL labels, so deletion requests miss them.
- Older report suites with full IP addresses: IP Obfuscation left on Disabled from an earlier setup.
- Public project links by default: Share Project Links with Anyone granted to every analyst.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | CIS Controls v8.1 |
|---|---|---|
| Product profiles and group-based access | AC-2, AC-6 | Control 5, Control 6 |
| API credentials | IA-5 | Control 5 |
| Admin and usage logs | AU-2, AU-6 | Control 8 |
| Privacy labels, IP handling and deletion | PT-2, SI-12 | Control 3 |
Practitioner checklist
- Users sign in through Federated ID and SSO with MFA at the identity provider.
- Two or three named Analytics product admins; team leads use product profile admin.
- Profiles designed around data sensitivity, with identity-bearing dimensions restricted.
- Data export, sharing and MCP Access items held in separate, owned profiles.
- All API integrations on OAuth Server-to-Server, one project and profile each, secrets vaulted.
- Data feeds and Data Warehouse destinations inventoried and reviewed quarterly.
- ID variables labelled with I, ACC, DEL and ID labels, tested with an access request.
- IP Obfuscation set to Remove or Obfuscate on every report suite.
- Analytics logs and Admin Console audit log exported to the SIEM.
Standards and references
- Adobe: Analytics product profiles
- Adobe: Analytics Tools permissions
- Adobe: Report Suite Tools permissions
- Adobe Developer: Analytics 2.0 API guides
- Adobe: Data Privacy labels for Analytics variables
- Adobe: General Account Settings
- Adobe: Analytics logs
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Adobe Admin Console Security · SaaS Security Guide · Machine-to-Machine OAuth (Client Credentials) Guide · GDPR Compliance Guide for Security Teams