Most past soft forks have been deployed with miner activated soft forks, and we know this because the deployment mechanisms used only allowed for miner activated soft forks. For a user activated soft fork to happen, the deployment mechanism would have to have some form of activation that is not reliant on miners. Thus far, the activation methods used have all deployed based on miner behavior and not a flag day.
There are two exceptions to this where it could be argued that those soft forks were user activated and not miner activated. The first is BIP 16 which ostensibly activated via a flag day (i.e. all blocks after a certain time must support BIP 16). However the flag day was determined only after a certain threshold of miners signaled support for BIP 16 in their blocks. So while the code was a flag day, the process was still a miner activated soft fork, just done manually rather than through code.
The second exception is segwit. However segwit used BIP 9 as its activation mechanism and that is entirely dependent on miner signaling. So technically, it is strictly a miner activated soft fork. But you could argue that it was user activated because users were running software that would have activated on a flag day, but miners began signaling readiness before that day. So the exact mechanism was through miner signaling, but perhaps it was user activated because users threatened miners by running software that had a user activated mechanism.
For future soft forks, it is likely that a combination of BIP 9 (MASF) and BIP 8 (both MASF and UASF) will be used. You can then determine whether it was miner activated or user activated. For both, miners can signal in their blocks to activate the fork. For BIP 8 only, after a certain time, the fork will activate via a flag day, so if that occurs, then it is a user activated soft fork.
The only soft fork that should be classified as a UASF is BIP 30. This was activated by a flag day and miner signaling was not officially part of the activation.