What is the rate limit for direct use of the Google Analytics Measurement Protocol API?

Question

In the Documentation for Google Analytics Collection Limits and Quotas

It gives the rate limits that are implemented by the various Google-provided libraries. I can't seem to find a published rate limit for users that are POSTing directly to measurement protocol (https://www.google-analytics.com/collect).

Is there one and if so what is it?

---

Edit on 10 July 2015 -

A few commenters asked for an example of the kind of data I am sending in.

Using a series of calls to wget with a sleep of one second between each call.

Here is an example with the app name and tracking code removed:

wget -nv --post-data 'ul=en&qt=7150000&av=0.0.1&ea=PLET&v=1&tid=<my_tracking_code>&ec=Move+to+Object&cid=1434738538-738-654031&an=<my_app_name>&t=event' -O /dev/null 'https://www.google-analytics.com/collect'

I've tried sending these queries to the /debug endpoint and all of them are valid. My first upload worked as expected and reports looked good. Subsequent uploads of the same data set to different GA properties have had mixed results. Sometimes no data appears in reports. Sometimes partial data appears in reports. During upload, realtime reports always show activity, though.

---

Irrevocable

I seem to be getting unpredictable results uploading hits via the Measurement Protocol API. Sometimes hits appear in historic reports, sometimes not. The /debug/collect endpoint tells me my hits are fine. Suspect that my hits are sometimes getting filtered out as 'spam', maybe because I'm uploading too quickly or at too high a volume from the same IP address. – Irrevocable

In the (unluckily) undying words of some outsourced colleagues, pleez send me teh codes! Or at least a reasonably simplified version of it so we have a chance to reproduce the problem. – Crushing

@EikePierstorff I added an example of the kind of calls to wget I am using. – Irrevocable

Answer 1

Directly from the documentation Google Analytics Collection Limits and Quotas

These limits apply to the Web Property / Property / Tracking ID.

10 million hits per month per property

Measurement protocol

Universal Analytics Enabled

This applies to analytics.js, Android iOS SDK, and the Measurement Protocol.

200,000 hits per user per day 500 hits per session not including ecommerce (item and transaction hit types). If you go over either of these limits, additional hits will not be processed for that session / day, respectively. These limits apply to Premium as well.

Now I agree it doesn't specifically state the per second it rate for measurement protocol but the above one dumped Measurement in with analytics.js so I think we can assume its

analytics.js:

Each analytics.js tracker object starts with 20 hits that are replenished at a rate of 2 hit per second. Applies to all hits except for ecommerce (item or transaction).

But just to make sure I am sending an email off to the development team they should make it more clear where the per second rate of the measurement protocol lies. I will repost here when I hear from them

Response from Google

The Measurement Protocol does not do any kind of rate limiting or quota-ing by IP address or tracking ID or anything like that. However, most of the client libraries do rate limit in some form or another.

As Linda points out in her answer, there are various limits and quotas imposed by the back end, but those are done at processing time, not collection time.

Conclusion

There is no limit to sending data through the measurement protocol. But when the data is processed limit may be applied. I think they may be referring to the max 2 million hits a month. It seems it's the libraries that apply limits on how fast you can send data not the measurement protocol directly.

Pedagogy

Looking forward to gleefully handing over the bounty in return for a definitive statement from Google on this matter. – Irrevocable

they are west cost USA time so its going to be a few hours before I hear anything back from them. – Pedagogy

Actually the documentation says "When the count is 0, the maximum limit has been reached, and no new requests are sent", which suggests that the send quota the docs are referring to is enforced at the client side. I, too, hope this get's a definitive answer :-) – Crushing

Judicious Googling implies that GA has been struggling with a spam problem. I wouldn't be surprised if they are evolving their heuristics to block 'suspicious' activity like seeing many pageviews and hits coming from the same IP address relatively quickly (what I'm doing). Would love it if there was a way for me to work around, possibly by sending some kind of secret along with my payload (so as to distinguish my hits from those sent directly from user browsers or app installs). – Irrevocable

Google has not officially acknowledged the spam problem or what they intend to do about it yet. – Pedagogy

Status: buck is being passed. My email was forwarded to someone else on the team. Could it be they don't know the answer either? – Pedagogy

Maybe we should join forces and build some kind of test suite to determine the limits of the measurement protocol. How are we supposed to work if we don't know what our tools can do and what they cannot ? – Crushing

test suite aka stress tester? I have an app script that dumps random data into an account via the measurement protocol. Use it as a demo testing account. :) – Pedagogy

Yup, me too. I'm sure one could make this a bit more sciency :-) – Crushing

I awarded the bounty as the answer is correct for the question I asked. That said, my underlying problem of hits never appearing in GA reports is still not solved. I strongly suspect that GA is filtering traffic that it identifies as 'spam' (many hits from the same IP address, consistent timing between hits). – Irrevocable

@astletron, I bet it's not IP filtering, as with the measurement protocol it is expected behaviour that all hits come from the same IP (if you do a serverside implementation all hits will originate with the servers IP). – Crushing

what exactly are you posting and how? – Pedagogy

@DaImTo - I added an example of the kind of calls to wget I am using to upload my data. – Irrevocable

Is their a way to track the limit/quota used? – Agueda

@ManojHL no there isn't. you need to check it on the Google Developer console personally (which isn't very arcuate) or save the number yourself – Pedagogy

Answer 2

Last Update: Please watch this video which explains all GA quotas policies: https://youtu.be/1UfER93ALxo

In particular, your issue might be result of 10 requests / 1 second limitation: https://youtu.be/1UfER93ALxo?t=5m27s

I can confirm the same thing. In my case I had own buildHitTask which constructs URL for a measurement protocol request (MPR) and stores it in the hitPayload field. But instead of original GA reporting - I was saving those URLs into cookies for delayed reporting.

In my experiment, only 10-20% of 2,000 measurement protocol requests were actually "stored".

Rest of hits are not available in GA Reporting UI, neither API or BigQuery. Each request was sent with 2 seconds delay via new Image() method, and slowdown in case of errors. Received results are not consistent. Both success and failed hits are randomly distributed across whole time period.

Please let me know in case if you find more details on this constraint!

Covert