Web Model: Make behaviour of 'stray pings' deterministic

[colmsnowplow]

We have had a report of a difference between the old web model vs new on BQ, where a lot more 'stray pings' are excluded. Needs investigation, but I suspect it's because the incremental logic is less forgiving of these events than the old way.

I'm using the term 'stray ping' to describe a page ping which has a different session ID to its original page view event. It makes sense for these events to happen, when we consider that a user might leave a tab dormant for a long time, then return to either close it or continue as active on the site. Here the session ID would change due to inactivity, but the page view ID doesn't (since there's no new page view).

In the longer term I've requested a feature in the tracker to see if we can explicitly handle these cases - it's tricky because they may genuinely continue to browse, or they may just have triggered a ping when closing the tab.

In the shorter term, I believe this warrants looking into in the model because I'm not sure the behaviour is deterministic. This needs testing, but I think what happens is that:

If the stray ping happens to be in the same batch of data processed as the original page view, it will be included in the engaged time for that page view. If it doesn't happen to be in the same batch, it is disregarded by the page views module.

We should investigate and test this, and look to make the behaviour deterministic one way or the other if it currently isn't.

[colmsnowplow]

ZD ticket reference 26783 for an example (closed source) of when this comes into focus