So we’re currently implementing Snowplow in a couple of apps, one is Unity and one is Swift. We have the screen_view working (though weirdly uses a different schema for each tracker) - but I was wondering what the best practise for tracking dwell. We use the page_pings on the web (Javascript) implementation, but I couldn’t readily see an equivalent for screen_ping? What’s the best practise here?
Thanks
Jo
As far as I know, there is no equivalent kind of event to page pings on platforms other than Web. However, you could calculate dwell by subtracting timestamps of subsequent screen views (perhaps also considering app background/foreground events to account for all transitions).
In the mobile screen view schema, there is a direct reference to previous screen view ID which could help in calculating this difference. There is no such reference in the non-mobile screen view schema, so you would have to look at subsequent screen views within a session.
This could perhaps be easier if you can make use of the recently released mobile data model that builds on the mobile screen view events. But I will let others expand on this as I don’t have practical experience here 
Yeah, I’m tracking screen views - but with a “single page” app, there’s no exit, so dwell time can’t be gotten there. Hoping to get some insight from devs that use Snowplow in apps?
I see the application background and foreground events in the Swift/ObjC tracker - but nothing in Unity.
“out of the box” I’d use session with foreground and background and checkinterval this. outlines how to implement. The check interval appears to operate somewhat like a ping and check if the session is still active “The timeout’s refer to the length of time the session remains active after the last event is sent. As long as events are sent within this limit the session will not timeout.” You will need to tweak the length over time but it is probably the most straightforward and best place to start and see if it is fit for your purpose.
@kfitzpatrick would this send something on session timeout?
No only end the session based on the set time and event timeout. So in the example code, backgrounding the app will end the session in 300 seconds providing no other event is created. So if after say 400 seconds the user brings the app to the foreground you will get a new session id. Take a look at the Snowplow Native Model, namely this file in particular to see how you could benefit.
Overall you do have a table or view with all events, and taking the MIN & MAX derived_tstamp of all events in a session will get you the last engagement. Controlling your session a bit more via foreground and background and check interval will improve on this.
I understand that engagement may be different than how you see dwell but unless an event is happening by the user then all you have to go on is the last event. Perhaps you have scrolling, then a custom schema would be ideal to create events for movement. So is there anything a user can do that you have not tracked?
Yeah its a camera view - so no scrolling. Lots to think about though, so thanks for the help.
We’ve needed to do similar things in the past (tracking activity in an app where screens aren’t being changed frequently) and ended up using timers in the app to do so. We’d keep a timer running and then either reset or resume it based foreground / background / user input / video activity to that it could keep a reasonably sound estimate that the user was active - particularly when they may be on a single screen for a period of time.
I imagine you could do something similar with a camera view and potentially bind to things like focus events depending on what the application is.