Earlier quoted context omitted.
If you could use heuristics to discard automation such as search engine indexing and open graph lookups, then the limit is probably fine. I'm not sure I'm a fan of the pricing model in general though. If I were you, I'd look into smart caching, traditional (high and scaling) bandwidth limits, and instead applying tier limits on updates/edits/data pulls. More user friendly, more generous for smaller projects and sligh…
Yes that makes sense. Though, it would be hard to apply edits limits because the number of edits can vary greatly, independently from the purchasing power of a customer (for example a startup would change it's home page every other day while a large corporate would barely touch it once a quarter). The bandwidth or page views limits seem to be raising the same issue and the logic for us is simply to avoid server costs…
Of course you need some sort of traffic restriction for things not to spiral out of control. Putting this restriction on actual MB's transferred is an acceptable safeguard. Cache bandwidth is cheap using the right strategies, so your bounds could be pretty high while keeping it profitable.