Some common scenarios
There are many reasons that may trigger the need to move a property from one account to another. Here are just several examples:
- Company A had their website created by Agency B. Agency B included Google Analytics (GA) tracking as part of their design package but implemented the tracking using a property within their agency GA account. Company A want to take full ownership and control of their GA data so wish to move the property to a new account.
- Company C has two domains with teams that have historically worked independently of each other. For this reason, the two domains have separate GA accounts. Company C has just signed up to GA 360 and want to be able to use a Roll-Up property in order to see the data from both sites in aggregate. In order to be able to do this, the properties must sit within the same GA account.
- Company D has just bought a specific part of Company E. They want full access to and control over the analytics data (including historic data). Similarly, Company E wants to restrict access to the rest of their analytics properties. Here the best solution would be for the specific property to be moved to an account controlled by Company D.
Right, that’s provided some insight into why a property may need to be moved, let’s now look at how to do it.
Before we start…
There are a few checks to perform before trying to migrate a property:
- The user must have ‘Manage Users, Edit, Collaborate, Read & Analyse’ access at account level for both the source and destination accounts.
- The destination account must have a free slot to accept the move. A property cannot be moved to an account which has already reached the property limit (50 by default).
For 360 users, there are several additional checks to complete:
- A property cannot be moved if it is currently processing an unsampled report. Simply wait until processing has completed before initiating the move.
- The property being moved cannot be a Roll-Up property. Additionally, the property to be moved cannot be a Source property for a Roll-Up property. However, Source properties may be moved if they are first unlinked from their Roll-Up property.
- The property to be moved must not be linked to a DoubleClick for Publishers (DFP) account. If it is, then a call to the reseller or support representative will be required in order to get the DFP account un-linked and then re-linked after the move.
How does the new feature work?
The property moving feature sits within the Admin > Property > Property Settings menu:
Note that the option will only be available to users who have ‘Manage Users, Edit, Collaborate, Read & Analyse’ access at account level. This is a sensible security restriction that Google have put in place to prevent fraudulent use of the feature.
Clicking on the ‘Move property’ buttons brings up the ‘Move Property’ configuration screen:
From here, there are three steps to complete:
Select the account that the property is to move to. Clicking on the dropdown will provide a list of all the accounts that the user has some level of access to.
Note that whilst the list will include all accounts the user has some level of access to, it will only be possible to send the property to a destination account that the user has ‘Manage Users, Edit, Collaborate, Read & Analyse’ access at account level for.
This list will be limited to accounts that appear within the current organization. For non-360 accounts, this will be the ‘Personal Accounts’ organisation which effectively holds all the non-360 linked accounts that you have access to. 360 clients will need to ensure that the correct organisation has been selected from the dropdown list:
Additionally, both the source account and destination account must already be linked to the organisation from within the Suite Home admin tools. Without this linking it will not be possible to select the required destination account.
Once the destination account has been selected, there is a prompt to select one of two options that dictate how access to the property is controlled post-migration. The selection will largely be determined by the reason for moving the property:
Option 1: Keep existing property and view permissions
This would be the option to select if the move is primarily being driven by internal factors and there is no need to prevent some of the current users from having access to the data post-migration. Note that account level access is not replicated in the new account (as there may be other properties there that some users should not have access to), consequently any user who is added to the new account as part of the move will be limited to property or view level access only.
Option 2: Use permissions of the destination account
If there are any doubts as to whether current users of the property should have access post-migration this is the option to select. Basically any user with account level permissions within the destination account will get the corresponding access to the property after it has moved. Any users from the old account who need to retain access (and do not already have access to the destination account) will need to be added manually.
The final step of the process is to check the ‘Confirm changes’ box and hit ‘Start move’. Before doing this, it is important to read and understand the corresponding notes provided by Google. The key point being that after migration the data will only be available within the new account.
Upon clicking ‘Start move’ there will be one final prompt to confirm 100% that the property is to be moved:
Clicking ‘Confirm’ will then initiate the process and there’s no turning back now (well, other than migrating back to the previous account)! A final success dialogue box is then shown with a click on ‘Go To Home’ taking returning the user to their GA Home screen.
So what exactly gets moved?
- The property, its settings and associated configurations. This includes product linking (excluding DFP), data import files, audiences etc.
- All views within the property, including their settings, goals, dashboards, segments etc.
- Any filters that are applied to views within the property. Where there is an exact match for a filter that already sits within the destination account then that filter is used (rather than a duplicate be created).
- The reporting data.
Great, let’s cover some additional questions
The property will be sitting within a new account which will have a different ID. Will the web property ID change too?
The property ID gets migrated too (i.e. there is no change). Therefore, no need to make any changes to the tracking code. It is important to note that the source account will not re-use the ID. This ensures that no tracking conflict will occur.
If the property was the only property within the source account, what happens to the source account?
It is still possible to migrate the property. Post-migration, there will be a message such as the following within the GA Home screen:
Similarly, within the account screen the only options available would be to adjust Account Settings, update User Management or create a new property:
Whilst the account may be empty, it still contributes towards the user’s account limit until it is deleted!
The Property Moving feature is a welcome addition to the account management tool set that will really help to organise GA setups that have grown unwieldy over time.
It will be particularly useful for 360 users who are looking to make use of the existing Roll-Up property feature which will enable them to save 0.5 hits per hit versus the alternative roll-up (multi) tracker approach.
If you have any questions on this feature, Roll-Up properties or GA 360 in general then please get in touch!
- Google have blogged about the release here.
- They also have a very good support article on the property moving feature here.