In the Documentation for Google Analytics Collection Limits and Quotas
It gives the rate limits
that are implemented by the various Google-provided librarie
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.
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!