Skip to main content

I’ve got a kind of unique situation that I’d love some insight on - I suspect we have long been skating by with a kind-of-busted data model for this particular feature, but some insight would help.

The setup:

Segment → Amplitude (Actions)

We send page, identify and track calls to Amplitude.

The issue is that we have a feature in our application that allows an admin user to effectively impersonate a user. Through our admin portal, you can log in as and do tasks/etc. as a user.

To document this, we write a property to the User object in our database called impersonate where we store the impersonating users id.

Originally, that was all we did, but because that was a dynamic field (mongodb), it wasn’t always sending, and thus there was no way to… “reset” it, if you get what I’m saying -- as far as Amplitude was concered, if user 1 ever impersonated user 2, user 1 was *always* impersonated in Amplitude from there on, as there was no default value in our datamodel to pass on to clean that field.

Okay, so we resolved that: created a default value and set the property to required - it now passes user as the impersonate value to identify authentic interactions vs. impersonated ones.

So, the question I have is:

Can I remove all sessions that have an identify property that ≠ ‘user’?

  • If so, is this the best method?
  • Should I, instead, be manually overriding the ‘session’ value in the Segment payload and just setting that to “impersonated’ or something?
  • Or should I just leave the data as it comes in and use filters and tooling to manage this in my dashboards?
    • IE: Event = event name (and) impersonate = user.

It’s my understanding that Amplitude applies the set of user properties that it has to ever event that fires.

So, if I am sure that I am identifying before every event call, in theory that should tighten up the data, yeah?

Am I crazy? I feel crazy. Haha.

Thanks in advance.

Hey @lantz!

 

I’m making a couple assumptions here but throwing out an idea - would it make sense to set the User ID as “Impersonate” or “Admin” when a login is made via the Admin Portal? This will create a separate profile where all admin activity will be logged. You could easily create a cohort where User ID does not equal “Impersonate” or “Admin” and use this to filter out the data. 

 

In your current set up, it doesn’t sound like you would be able to filter at the cohort level and filtering each event on every chart would end up being very manual and would hinder scalability. I suspect it could also lead to even more craziness :wink:

Hey @SheenaGreen 

 

Thanks for the response. Unfortunately, the userID is the key piece of information that we use for everything, including “impersonated” sessions. I suppose I could use Segment to augment the UserID and append -admin or something of the like to it when I see an impersonate property that isn’t ‘user’ that way it’s _clean_ before it gets to Amplitude.

 

I toyed with the idea of just blocking *all* calls that are ‘impersonated’ from even getting to Amplitude, but because we send that value on an identify I can’t actually and accurately also deny whatever page and track calls are related to that user when that value isn’t passed there.

 

=/

Hi both! If I’m understanding correctly, you’d like to be able to remove sessions from your analysis that do not have events in it where a user property equals ‘user’. Is that right?

Off top of my head, there’s no way to isolate and filter our sessions/group events from analyses. However, if you apply a user property to all events within impersonation sessions and then filter specifically on that property to remove those events, that may work?

Let me know! Once I gain a better understanding, I can also ask my team for their input.

Yo @jmagg - seems like I actually got this sorted. I think I was dealing with some bunk data from before changed the methodology - created a new project and replayed my segment data into it and things are looking ~right.

For what it’s worth, and to better distill this, the crux of it is I need to be able to ensure that any _event_ that fires has an accurate representation of the `impersonate` value as it lives on our user object when that event was fired.

That means we either have to: a) send that value with each event or b) ensure that an identify call is sent prior to each event, which should appropriately update the user value and that event will properly flag as impersonated or not.

Does that check out from your side?

Nice!! Good job sorting it out @lantz. Glad things are looking good! 

I’m leaning towards option a at the moment. Amplitude is an event-based platform, which means that events are logged with the event properties and the user properties present at the time the event was fired, which is what is reflected in the chart/user’s event stream. The Identify API, on the other hand, updates user properties of a particular user without sending an event. However, these user property updates will not apply or appear in the platform until the user's next event. I think option a would be more precise. What do you think?

Reply


Terms & ConditionsCookie settings