First of all, there is no problem with using SHA256 or SHAKE128/256[1] those would have had $2^{128}$ collision resistance with a 50% probability by the birthday attack. If you really fear that switch to 512-bit versions. Take SHA512 or Shake256/512 both have $2^{256}$ collision resistance with a 50% probability by the birthday attack. Even if you ever hash $2^{80}$ uniform random 256-bit strings then the probability of the collision is $(2^{80})^2/2^{256}/2 = 2^{160 - 256-1} = 1/2^{97}$ and this is not going to happen, and the less the data you have, the more little probability you will get.
If you ever find a collision tell the world that you will be famous. Actually, I would go for the tiny, tiny chance to find a collision in SHA256 or SHAKE128. A simple query for checking the existence of the identifier would find out the collision. There is always such checking already since you might add the same user again.
For direct hashing with SHA-256, you do not need to worry about the collisions, you need to worry about the possible leak of information, and that totally depends on how the data are transmitted and/or stored.
It is possible to use a keyed hashes if you have some HSM to protect the key. The HMAC-X is proven to be PRF if the underlying hash function is PRF. The X stands for a hash function as HMAC-SHA256.
All of the above would solve your problem without any fear.
In short: A good cryptographing hashing is enough if there is no leakage problem. Even a collision resistance is not required at all. It may suffice to use a 128-bit PRF, if the secret key is safe to be used in your application.