Screen_summary context missing screen size properties

We’ve updated to the latest mobile tracking SDKs and are attempting to implement the screen engagement events in both iOS and Android. Based on the demo, the content_height, content_width, min/max_y_offset and min/max_x_offset properties should be included in the payload regardless if the user scrolls or not.

However, we’re noticing that if a user views a screen, does not scroll at all and visits another screen, the screen_summary context only picks up the foreground_sec and background_sec properties. If the user scrolls, and then leaves the page, we see all of the properties as expected.

We’re seeing this behaviour in both Android and iOS and wondering if there’s any issue in the SDK that may be causing this?

Thanks,

Hi @ks107,

I think this can happen due to two reasons:

  1. In case the user does not interact with the scroll view, you might not get any callback with the scroll changed. In this case, you won’t track any ScrollChanged events and thus the tracker won’t have information about the content width/height and offsets and won’t track it in the screen summary.
    • Can you check if the ScrollChanged event is tracked even if users don’t scroll on the screen?
    • If that is the case, you may track a ScrollChanged event after every screen view just passing the current information.
  2. The ScrollChanged event is tracked before the ScreenView event. In some cases, you might get a callback about the scroll position earlier than you get a callback for the screen view.
    • This depends on how you implement the tracking, but could you check on the order of the events?

I hope this makes sense, let us know if you have more questions or suggestions!

1 Like

@matus Thanks for the quick reply! Turns out it was the second scenario you mentioned. We were able to adjust the tracking and it’s now working as expected. Appreciate it!

2 Likes

@matus do you have any recommendations on how to ensure the order of events is correct in the second scenario you mentioned above, other than implementing a delay on the screen_view event?

Unfortunately, I don’t have a general solution for this other than delaying the ScrollChanged events a few milliseconds (you mentioned a delay on the screen view event but if I understand correctly the problem is that the scroll is tracked before screen view).

It depends on the UI framework and what are the options there though – is it possible to track the screen view at an earlier point in the screen transition (e.g., before the scroll view is rendered)?