Skip to main content

Hi All,

I have a question around user properties with the goal of getting an accurate understanding of our MAUs.

We have a platform which allows our admins to impersonate a client user, this allows them to see an identical version of the platform that the client user would see. The admin can then complete tasks on their behalf which fires events as the client user.

I want to be able to tell the difference between events fired by a real client user and an admin impersonating a client user.

There is a user property we use called impersonating_user_id which captures an id of the admin who is doing task on their behalf.

My question is: If an admin 1234 impersonates the client user 5678 on Monday and fires an event the user property impersonating_user_id would capture user 1234 on that event.

If the next day the client user 5678 logs onto the platform as does actions themselves and fires events. In this case would the impersonating_user_id property fire as null as no one is impersonating? or does the old user property be pulled across.

Would the below setup capture our non-impersonated active users who have fired an event, even if at a seperate time they had been impersonated by an admin?


Sorry for the rant, not an easy thing to explain, thanks for reading.

 

Sam

Hi Sam,

 

Thanks for writing in, we greatly appreciate it! I love a good rant and it’s better to include too much detail than too little, so thank you. 

 

As Amplitude is an events-based platform, you will be querying on events at the time they occur. So the impersonating_id would be 1234 for client 5678. If Admin then logs out and the client triggers another event, the previous user property will populate to the next call. To stop that, and if you want to set the impersonating_id to 0, you could use something like our identify API to change or remove the impersonating ID value before the actual client uses it. Otherwise, you could implement a check to see if the client is doing the event, to have a user property such as Access=Client or Access_Admin so you can easily group by on those properties and filter the events done by the client, and not the Admin.


I would also recommend setting up a dummy project and using the HTTP API, you can play around with this scenario and see if that fits. I hope this helps!

 

Kind Regards,
Denis

Hey @sam_toose 

Agree with Denis’ suggestion here.
In a similar scenario of admin-client usage,  properties like is_admin ( True/False ) and target_user_id on the event can help tackle such use cases.

 

Thanks for the info @Denis Holmes & @Saish Redkar. Really appreciate the knowledge and ideas.

We will give it a go.   

Reply


Terms & ConditionsCookie settings