...
- Contact the IT Help Desk at [email protected] for questions and requests for support.
- Manage user access for the designated accounts, including when staff turnover occurs.
- Optional: Add a member of the IT Web Services team as backup, in the case that accounts are not properly transferred.
- Adhere to Data Privacy policies.
Structure
Google Analytics is organized in a hierarchy. Each organization can structure their Analytics accounts and properties based on their business needs and preferences. Analytics properties can be renamed and moved from one account to another if you have the Administrator or Editor role for both the source and destination accounts.
...
Structure | Rationale |
---|---|
One account for an Area | Area teams with dedicated communications and web support staff may want to retain more control over their analytics at a high level. This also makes it easier to control user access at an Area level for all connected sites. In the case of staff succession, this means updating one account vs multiple accounts. Properties can be created for each primary Division site and for any major project or initiative. |
One account per Division | Divisions with many distributed websites may prefer to manage their analytics properties and user access more closely. Additional access may be granted to Area offices and technical support as needed. Properties can be created for the primary Division site, major projects and initiatives, Division department or group sites, etc. |
Standalone accounts | For security and management purposes, Areas and Divisions can segregate major projects involving multiple institutions which may require access for external collaborators. Specialized websites with limited audiences may not need analytics support at an Area or Division level. In these cases, the individual owners can create and manage their own accounts and properties. Conference and event websites, PI websites, and internal staff sites may fall within this category. Other separate business units with different stakeholders may not want or need to share data or access across the organization. |
User Roles
Analytics access is determined by the user role and their respective permissions, which are summarized in the table below. Please check official documentation for the latest information.
Role | Permissions |
---|---|
Administrator | Full control of Analytics. Can manage users (add/delete users, assign any role or data restriction). Can grant full permissions to any user, including themselves, for any account or property for which they have this role. Includes permissions of the Editor role. |
Editor | Full control of settings at the property level. Cannot manage users. Can rename and move properties from one account to another if granted the Editor role at minimum for both the source and destination accounts. |
Marketer | Can create, edit, and delete audiences, conversions, attribution-models, events, and conversion windows. Includes permissions of the Analyst role. |
Analyst | Can create, edit, and delete certain property assets. Can collaborate on shared assets. Property assets include things like Explorations. Includes permissions of the Viewer role. |
Viewer | Can see settings, data, and reports; can change which data appears in reports (e.g., add comparisons, add a secondary dimension); can see shared assets via the user interface or the APIs. Cannot collaborate on shared assets. For example, shared Explorations can be viewed, but not edited, by those with a Viewer role. |
None | Typically shown at the account level. The user may have a role for a property within the account. |
Add, edit, and delete users
You can add users and modify access permissions at either the account or property level.
...