Google Analytics Error rate limiting

So what is the error rate limit. The error reate limit is the limit to the number of errors you can receive from the Google API before the system will block you for being annoying. The main point to this I have been told was to prevent people from abusing the system and encourage developers to fix there code.
[wp_ad_camp_3]

Management API change

Yesterday there was a change made to the Google Analytics Management API. You can read the change log here.

Google Analytics Management API Changelog search for Release 2016-02-25 (February 25, 2016)

Error rate limiting

It has always been our policy that developers should implement exponential backoff, when handling 500 or 503 responses. Today we are introducing a rate limit on 500 and 503 errors to enforce this policy.

• 50 failed write requests per hour.

Thu Feb 25 2016

What the 500 and 503 error?

When we make a request to any of the Google APIs (not just Google Analytics) there are some standard errors that your request can result in. There are quite a few of them but lets just look at 500 and 503.

500 – internalError

{  
   "code":500,
   "errors":[  
      {  
         "domain":"global",
         "message":"There was an internal error.",
         "reason":"internalError"
      }
   ],
   "message":"There was an internal error."
}

500 – Backend Error

{  
   "code":500,
   "errors":[  
      {  
         "domain":"global",
         "message":"Backend Error",
         "reason":"backendError"
      }
   ],
   "message":"Backend Error"
}

503 -Backend Error

{  
   "code":503,
   "errors":[  
      {  
         "domain":"global",
         "message":"Backend Error",
         "reason":"backendError"
      }
   ],
   "message":"Backend Error"
}

That is what the JSon looks like if you encounter one of those errors.

403: User Rate Limit Exceeded

There is one more that I am aware of.

{
 "error": {
  "errors": [
   {
    "domain": "usageLimits",
    "reason": "userRateLimitExceeded",
    "message": "User Rate Limit Exceeded"
   }
  ],
  "code": 403,
  "message": "User Rate Limit Exceeded"
 }
}

What to do when you encounter those errors.

If you ever encounter in 500 , 503 or 403. You should simply try the request again, however its not quite that simple. You need to slow down your code you are running to fast. When it comes to the Google Analytics API we are allowed 10 requests a second per User. Remember user is denoted by either userip or quotauser.
[wp_ad_camp_1]
I normally run my code 6 times and add a half a second sleep in between each iteration of the loop.

• sleep half a second try again
• sleep a second try again
• sleep a second and a half try again
• sleep two seconds try again
• sleep two and a half seconds try again
• sleep three seconds try again

If it hasn’t been able to return the results after that I fail the application. This rarely happens. Most of the time in my experience it works after the second or third sleep. However I like to add a few extra in there to be sure that it doesn’t cause a problem. Also Google recommends we do it six times so it is probably a good idea to follow their recommendations.

So what does this change mean for me?

Well that is a really good question and why I am posting this hear. It is unclear to me what they mean by

Error rate limiting 50 failed write requests per hour.

• Does this mean that they are going to block all of your requests for an hour if you hit this?
• Is it user specific. If i have an application with 60 users and they each hit it once will my application be blocked?

I am going to send an email off to the Google Analytics API developers and see if I cant get us a little clarification on this.   I will update this post when I hear back from them

Documentation bug

Also there is a slight issue with the documentation. I have always gone buy the documentation. If you check here it says.

• 500 internalServerError Unexpected internal server error occurred. Do not retry this query more than once.
• 503 backendError Server returned an error. Do not retry this query more than once.

Only try it once?

However if you scroll down to here it says to

A 500 or 503 error might result during heavy load or for larger more complex requests. For larger requests consider requesting data for a shorter time period. Also consider implementing exponential backoff. The frequency of these errors can be dependent on the view (profile) and the amount of reporting data associated with that view; A query that causes a500 or 503 error for one view (profile) will not necessarily cause an error for the same query with a different view (profile).

I am going to report that little bug as well. They need to make up there mind try it once or more then once.