You can count the number of bugs open, bugs open/closed per sprint, number of open active critical bugs, average length of time open sliced by severity, priority and sprint, add a multiplier for how old each bug is, or any one of a hundred other ways.
The fact is, your customers don't care about these numbers.
Your customers want to know if the software will do what it's supposed to do. If it's a game, is the play fun? If it's a business tool, doe the program allow the client to finish their work faster with it than without it? Are your customers happy?
Customer happiness is the prime measure of quality software. There are a number of ways to measure that. One way is to ask the customers themselves. Your marketing team might even be running customer surveys right now. The feedback from these surveys should be driving development and testing.
Another useful metric (although it's not really a count of things, but a list), is a list of bugs reported by customers. Doesn't matter if they were found internally first or not. The bugs customers report are the bugs that are the most important to them. The Dev, Test, and Marketing teams need to study these lists and align their efforts with what customers report. This is the most important metric of all, because unhappy customers will flee to your competitors if their concerns are not addressed.