Skip to main content

In the context of an app implementation, we are using screen calls and track calls to collect events from our front-end.

Is there a way, using destination functions or something else, to force track calls to inherit some of the properties from the preceding screen call? The idea is to add context to events in order to know on which screen they happened.

This is needed in my case because some downstream destinations do not support this screen>event hierarchy and do not display screen properties to events. I see that Mixpanel has this concept of “borrowed property” which is cool but limited (and only works in Mixpanel obviously).

Thanks!

I’d recommend against hydrating events based on prior events when you can instead fire events with the desired context or properties (there isn’t a standardized spot for screen name in the `context` object currently.)

For example, as part of our mobile application Tracking Plans, we’ve included `screen` as a property on Track events that can occur on multiple screens. Would that work for your use case and is it feasible for your Track events to be updated to include the `screen` property?

Ahoy! This actually comes up often and I’m curious if there are others in the ecosystem that have considered this and the solutions. We often would like to know what “surface” an Event (Track) is occurring on. In this general case it’s the screen, but we’ve seen customers need to know which particular modals, carousels, or site widgets the Event occurred. While there is no standard in context @Gray Sanborn you can always add whatever you want there if it makes more sense semantically as context vs. property. For the screen example that @Sylvain Pastor posed we have seen customers “cache” the values of say “Last Seen Screen Name” and then apply that to all Track Events. This would need to be managed on your side for now, but this type of request comes up more and more. In fact - we had one customer get excited about hearing our Linked Events feature as they thought it had more to do with this than what it actually does. Let me know if this is helpful!

Update on the workaround I found using Mixpanel borrowed properties (until our devs find a way to add those context properties to events):

  1. create “Screenview” event in the destination mapping to duplicate the screen event (which is by default mapped in Mixpanel to “viewed + event name”. Set a condition for it to fire only when the property is present
  2. Create another Screenview” event similar to above but set to fire when the properti isn’t present. This one has static values “none” mapped to my screen properties (I don’t want any undefined properties with my screen events, otherwise Mixpanel will go back to revious screens until it finds a value).
  3. In Mixpanel, setup a borrowed property for the property I want in “Screenview” events.
  4. In Mixpanel’s Lexicon, hide the Screenview events from the interface to avoid seeing double the screen events in reports. In Mixpanel it is preferable in most reports (flows etc...) to have the event name set to “viewed + event name” instead of a generic “Screenview”.

Of course it is not ideal as those hidden events still count towards my Mixpanel event quota, but it seems to be working so far.

Reply


Terms & Conditions