Be careful what you measure, because that is what are you going to get.
If you ask for 200 purchases, you will not get experience (and testing scope) what you would get by 200 different users making a purchase. You will get one user repeated 200 times. Which is better than nothing but does not tell you how your system will respond to 199 other ways to perform the purchase transaction. So it is almost useless.
There is a term "sapient testing". When sapient human is using website and looking for edge cases and bugs. It is very different from unleashing 200 monkeys bang the keyboards and report results which they find reportable.
Years ago our customer used '200 monkeys' approach to test the app we were developing for them (complicated application to handle non-performing mortgages - when people start paying, get behind on payments, get forbearance and/or refinance, add fees to principal, and possibly get foreclosure). They did not want to invest time in training students to understand what is going on. We got daily dozens of reports of "strange (for testers) behavior", of which 99.5% was correct behavior, which testers were not aware of.
All that was huge waste of time for developers to try understand what testers were doing (because they were also not trained to write good bugs, to save money on training as I said), so we get actionable bug report only after multiple emails exchanges. Then, we reported back that this is required functionality. After few weeks, futility of the approach became apparent, and 200 monkeys were transferred from testing to something more productive. Most of the results of their "testing" was discarded and not fully researched, because it became obvious it provides NO information.