25 active tokens / site limit

Hi there,
The 25 token limit is not one we impose, it’s one imposed on all Google accounts by Google. It’s not specific to any plugin or service, nor is it a limit that is constrained by app (for example using 24 sites on plugin 1 and another 24 on plugin 2 doesn’t work).

It is an Google account limit by Google, so it doesn’t matter if you auth 25 times from a single view of a single property or from 25 different GA account/property/view combos, since it’s an account based limit.

Let’s say for example you authenticate 25 sites. On the 26th site the first sites token will be revoked. Again this is not something specific to us, so changing WordPress plugins won’t make a difference, it’s a limit on the number of refresh tokens your Google account is permitted to have for all Google services. You’ll run into this limit regardless of whose plugin you use or how many you use.

It’d be best if your clients could authenticate because then you’d never run into this limit, but short of that you could get around it by either using a different Gsuites email as the auth email for each 25 sites. We’re also working with their team on finding ways to increase this limit because obviously in cases like yours it makes a headache for everyone involved.

• This reply was modified 4 years, 10 months ago by chriscct7.

Just to clarify further the limitations are two tiered.

The first is by Google service, the second is by account.

At any given time you may have up to 50 refresh tokens across any Google services for a single Google account. Up to 25 of those can be used for an integration with Google Analytics.

These limits are not based on the applications that you decide to integrate with in any manner. They are put into place by the team that simply runs Google’s OAuth2 service.

So let’s take two examples.

First is the easiest one, if you integrate with 26 sites, upon authentication of the 26th one the first one will be deauthenticated. Because you have exceeded that the number of refresh tokens that a single Google account may have that integrates with analytics (in any capacity), they will revoke the first one to keep you under the 25 analytics per Google account limit.

A second one is let’s say you decide to authenticate 25 sites into Google Analytics. Then you decide to authenticate 20 times into a service that uses Google drive API. Then you decide to authenticate six times into a service that uses YouTube’s API. In this case on the sixth authorization for YouTube, the refresh token for the first Google Analytics account will be revoked even though you are under the 25 limit, because the 6th YouTube authorization puts you over the 50 refresh token per Google account limit and therefore they will revoke the first one regardless of the service it belongs to to keep you under the limit for the entire account.

Again as you’ll notice none of these are affected by which app you use for Google Analytics or YouTube or Google drive. They are account limits that Google puts on the account, not based on the actual integrations you use.

It appears that tracking still works thankfully. Who knows why they don’t mention this somewhere on the authentication area..

We don’t have any way to know how many refresh tokens a user account has been issued or to what. For 99.99999% of users they will never hit this limit, and we’ve found previously by having a section there that explains it it increases our support load tremendously from users who are more confused if the limit applies to them (which for the fact majority it will not).

There are many things that Google could help to M
make the situation better which is what we are focused on such as:
– allowing integrations to retrieve the number of refresh tokens a user has
– increasing the per account and per service limits
And so forth

Note relocation of the oAuth token does not affect tracking. We built our plugin in a way that if for some reason the connection is lost or if the refresh token is revoked it will continue to track. You just will not be able to access reporting.

Then perhaps a good place would be within the “This plugin needs an authorization” notice on the dashboard? Perhaps a “Common reasons this happens” link?