Finally! For the first time EVER, yes, EVER, Google Analytics has made a change to it’s access controls and user permissions. Some may think Google Analytics user permissions is not a very sexy topic, but this is going to make a big difference to those that manage Google Analytics accounts.
There are two big changes to user permissions.
First, there are now three different types of user permissions: Manage Users, Edit, and View.
The second major change is that permissions can now be applied at various “levels” of the Google Analytics hierarchy (Account, Property and Profile).
Let’s start by looking at the new permissions.
New Google Analytics User Permissions
Gone are the generic Administrator and User roles in Google Analytics. There are now three types of user permissions:
Edit: This is basically the same as the old Google Analytics Administrator. A user with Edit permissions can make administrative changes and view report data. This means that a user with Edit permissions can add/edit and delete accounts, properties, profiles, filters, goals, etc. However, a user with Edit permissions can not add/edit and delete users.
Users with Edit access can also view reports.
View: A user that has View permissions can only view data. That’s it, they can’t change any setting. This is the same as the old Google Analytics User type.
Manage Users: This is a light-weight type of administrative permission. Someone that can manage users has the ability to add/delete users and assign permissions. That’s it. This does not include editing settings or viewing report data. They can just add and delete users in the account.
You’ve probably noticed that the big change is that managing users has been decoupled from from the major administrative functions. I think this recognizes that many technical account administrators should not be managing users. That’s probably a function of marketing.
If the new user permissions were the only way to control user acess then these changes would not be such a big deal. Probably more of a G+ post rather than a full blog post :)
The big news is that you can now apply the above permissions at the various levels of a Google Analytics account hierarchy.
Setting Permissions at Different Levels
This is where the real power of the new user permissions comes into play.
Google Analytics is organized in a hierarchy of Account, Property and Profile. A property (also called a web property) is really a source of data. It could be a website or a mobile app. A profile is a combination of data (from a property) and settings that you apply to that data (filters, goals, etc). There are also some settings at the Account and Property level (account linking, Remarketing, etc.).
All reports exist at the profile level.
Here’s how it looks:
User permissions is now a setting at each part of the hierarchy. So when you view the account settings, property settings, or profile settings you will have a Users tab with a list of all users and their settings at that level of the hierarchy.
Here’s is the User Permissions settings page for a web property:
Notice in the screen shot above a few users have no permissions and the comment “Permissions assigned at profile level”. This means that these users don’t have ANY permissions at the Property level but they do have some permissions at the Profile level.
When you apply permissions at one level of the hierarchy they will cascade down to lower parts of the hierarchy.
That’s why there are some users in the image above that have “None” for their permissions – they were not assigned any permissions at the Account or Property level. They were only assigned permissions at the profile level.
It’s really important to understand that last point.
Lower parts of the hierarchy will inherit permissions from upper parts of the hierarchy. If a user has Edit permission at the Account level, they will also have Edit permissions for all of the properties and profiles within the account.
Also note as you move down the hierarchy from accounts to properties to profiles you can not reduce a user’s permissions.
This is another important concept to understand.
If you grant a user Edit permissions at the account level you can not grant them View permissions at the Property level. Again, you can’t reduce their access as you go down the hierarchy.
However, you can INCREASE their access as you move down the hierarchy. This is important because you can now let people modify settings for a property or profile without changing other settings in the account.
Examples & Best Practices
Let’s look at an example.
Let’s say you’re a big company with 100 web properties and a different marketing team that uses each of those properties to measure their marketing efforts. Each marketing team needs administrative control over their individual web property. But they also need to view data from other web properties to better understand how other teams are doing.
Start by giving them View access at the Account level. This will let them view data in every Property and every Profile.
Next, give them Edit access at their individual web property level. They will be able to view all the data and make configuration changes but ONLY to the Profiles within their property.
If there are some marketing teams that should only be able to see their own data, and not data from other teams, you need to rethink your strategy. You can’t give a user View permissions at the account level or else they will be able to see data in every Property and Profile. And you can’t reduce their permissions as you progress down the hierarchy.
In this case you need to set the user permissions at the Property and Profile, NOT the account level. Apply the correct permissions based on what the user should be able to do.
Here’s another example. Let’s say you’re a web analytics consultant that helps clients setup their account and analyze their data. You should ask your client to give you Edit permissions to the appropriate Web Properties and Profile. You probably don’t need Manage User permissions unless this is part of your role.
Other user permission best practices:
- It’s a good idea to limit the number of users that have Edit permissions at the Account level.
- The Manager Users setting is great for marketers. Many times a marker will need to give other team members access to data. Or, in an ideal case, an executive that wants deeper insights into the business! Don’t be afraid to give marketers Manager User access so they can add more users.
- Audit the people that have access to your data once a year (or once a quarter depending on your data governance). Prune people that don’t need access or adjust their permissions as necessary. I find that a lot of organizations forget to do this.
Matching the new permission types with different levels of the hierarchy should give every type of organization the flexibility they need in controlling access to data and configuration settings.
Adding a New User
Adding a new user to Google Analytics has not changed much.
the only difference is that you can now add a user at the Account, Property or Profile level. And when you add the user the permissions you assign will cascade down the hierarchy from Account, to Properties to Profiles.
Remember, the new user still needs to have a valid Google Account.
The little “Notify this user by email” check box will send an email to the user when they are added to the account.
Migrating to the new User Permissions
As Google migrates to the new user permissions you won’t notice many changes. The new permissions map fairly well to the old permissions:
Edit + Manage Users = Administrator
View = User
But there will be one change and it pertains to Annotations. From the Google Analytics help center:
If you previously had User access to a profile, you could create annotations that were shared with everyone in the profile. Former Users now have the View permission for a profile, and can create only private annotations that are not shared with anyone else in the profile. This change was made to enforce consistency and security across Analytics.
If you’re a Google Analytics manager User Permissions is a critical tool. It help you push more data into the hands of more people in a safe way.
Alan Morte says
Justin, great post! We will definitely be managing our companies user permissions early on this week.
Paul Bruce says
Thanks for the detailed post Justin, although it does raise some concerns for this analytics manager.
I have no plans to devolve profile edit rights to any teams outside of the core analytics team, however I do want us to be able to see annotations made by other users and for users to see other users profile wide. This is a process we have rolled out across the company to allow teams to share annotations so seems quite a big shift that this will go. Essentially this means moving the company to all using the same logon as the only way of accommodating this.
Also one thing missing that I had been hoping to see was locked down dashboards, one problem at present is the ability of teams to edit dashboards created by administrators (after spending a fair bit of time in creating them). I had hoped we would see much more granular options in the user permissions update, is there any sign of this on the horizon?
Justin Cutroni says
@Paul: Thanks for the detailed comment!
I agree, that the loss of shared annotations is a bummer. I used that feature quite a bit. But I’ve seen that complex permission schemes can lead to even more confusion.
I would recommend against using a shared login. I think there are a lot of potential issues with a shared login. For example, customizations are based on login. If everyone is creating different customizations then this could reduce the total number customizations you can make. You will also loose visibility into who makes configuration changes (only true if the user has Edit permissions).
Regarding the dashboard. Let me ramble for a second. I’ve heard of two primary use-cases when it comes to sharing dashboards, and other assets. First, people need the ability to create an asset and distribute it as a template. They want to share something that others can customize. The second is to create a shared asset that no one else can modify. This is the case you mentioned. I think both need to be supported. But it’s complex when you think about global permissions (view vs. edit). Can someone with view access to a profile edit a shared asset that has edit permissions? It can become complex quickly.
Thank you again for your comment, I appreciate your time.
Matt Stannard says
A great post – thanks!
This is a great step in the right direction but I’d love it if analytics could have groups and assign the permissions above based on a group.
In your example above, if somebody leaves you have to go through and edit all of the web properties they’re in. If you had groups for various marketing teams you could just update on group and remove the person who has left!!
Is there a way with the new model to simulate / facilitate groups?
Justin Cutroni says
@Matt: Great suggestion, groups would help to reduce some of the manual changes. You could remove a user from a group and have the changes ripple through automatically.
I think the new user management system is a good step. It solves many of the most common problems that organizations face when managing analytics users.
Thanks for the suggestion, I’ll make sure I pass it along.
I wish there is a Supper Administrator User Permission for better account control.
Justin Cutroni says
@Jeff: Tell me a little more about the permissions you would want the Super User to have. Thanks for the feedback!
For Example, some profiles and custom report created by the Super Admin can not be edited or removed by other users but him. That can prevent the main profiles from removing by some malicious people. Or the Super Admin may mark some profiles or custom settings as editing restricted. Yeah, I want the current Manage User role can do that for me.
Justin Cutroni says
@Jeff: Thanks for the explanation. Paul mentioned the same thing below: the ability to control assets like a custom report or dashboard. It gets a bit more complicated when you combine asset permissions and user permissions. But it’s something that I will suggest.
It could be a little bit complicated, but it will better protect the important data. Thanks.
Good post. However i don’t see these new user permissions settings in my account, not even in GA premium. How long do you think it will take for the Google to roll out these changes? I think super user can be someone who has power to recover lost accounts, properties and profiles. Only he should have the power to delete any account, property or profile. Few of my clients accidentally deleted their accounts in the past thinking that they are just removing them from their email list.
Justin Cutroni says
@Himanshu: It can take a couple of weeks, or longer, for changes to reach every account. Stay tuned, it will be there soon! And thanks for the feedback on a SU type of role.
Julien Coquet says
Of course, for many of us, our hope is that the Management API will become read/write instead or read-only as it is now, allowing for permissions to be set programatically. This would really streamline access right management.
Just a thought :)
This is great news, do you know if is it going to rolled out over all Google Analytics accounts or just GA premium?
Justin Cutroni says
@Joie: This is a change for all accounts. It’s slowly rolling out over the next couple of weeks.
Shawn Bouchard says
Thanks for the excellent post. Your breakdown of the various levels, and examples of how that might apply in the real world are really good. I’m going to reference your post in my web analytics class so my students have access to the latest info.
I do trust all the ideas you’ve offered on your post. They’re really convincing and can certainly
work. Still, the posts are very brief for beginners.
May you please extend them a little from next time?
Thanks for the post.
I’d like to know if there is any hope of using Google Analytics without Adobe products, or is it tied in with Adobe?
Justin Cutroni says
@RS: I assume you’re talking about the reporting interface. I believe there are only one or two reports that use Flash for the interface. Everything else is HTML.