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.
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.
Best answer by lantzView original