How do you implement “user impersonation” support?

It really depends on your size, and how sensitive the data is. At small size with non-sensitive data, where you've got 2 guys with admin access to the db anyway, simple impersonation is fine as they've already got access. You don't want to be spending a ton of time engineering a really complex solution. You probably should have a policy in place, and any staff you do give access to the feature explain the responsibility.

Most (small) startups I've worked at have usually had a homegrown solution with admin only access where you can login as the user.

However, these days, with more and more PII laws coming in, you do need to consider whether you really need it.

As you grow you have to add more checks, logging, etc., the user has to approve an access request, etc., to the point where you get bigger you don't allow it at all.

It's actually rare in my experience to need to impersonate a user to replicate bugs if you read their support request/ask the right questions, and can be a sign of an inexperienced dev if someone constantly asks for this. You have to put yourself in the mind of the user, what were they doing, what were they clicking, what were they trying to achieve. You'll usually be able to replicate it.

But another way to fix bugs due to complicated data interactions, when you're not allowed to access the data, is to have a script to anonymize the PII in a backup DB.

Two parallel builds, running of physically separate machines where the impersonation build has all writes turned off. Live build uses OAuth for authentication, impersonation build uses AD for authentication + HTTP cookie for impersonated person ID. All logged out the wazoo. This is in the financial industry.