viewId is extrapolated out of the viewSessionId by appending an incremented integer to it to isolate subsequent playback within the same tracker.
All is good until consumer of the library uses custom events prior to the initial play event of their video player. This causes custom events to be reported under viewId-0 while the rest of the playback events will be stored under viewId-1.
⛑️ Fix
By simply not incrementing the viewId during sendRequest, but rather do it on sendEnd, we end up having the expected behavior where all events are stored under the same viewId.
🖼️ Results
CONTENT_MANIFEST_REQUEST being a custom event sent prior to the first sendRequest(), we see in this screenshot that is now bound to the proper viewId:
Hi @Boubalou, thank your for your contribution. I just want to state that, given this change, a playback must always end with a sendEnd, otherwise the next player session will have the same viewId.
📄 Description
viewId
is extrapolated out of theviewSessionId
by appending an incremented integer to it to isolate subsequent playback within the same tracker.All is good until consumer of the library uses custom events prior to the initial play event of their video player. This causes custom events to be reported under
viewId-0
while the rest of the playback events will be stored underviewId-1
.⛑️ Fix
By simply not incrementing the
viewId
duringsendRequest
, but rather do it on sendEnd, we end up having the expected behavior where all events are stored under the sameviewId
.🖼️ Results
CONTENT_MANIFEST_REQUEST
being a custom event sent prior to the first sendRequest(), we see in this screenshot that is now bound to the proper viewId: