This isn’t to be expected but I have seen it happen in the past. One driver for this can be ‘stray page pings’.
Such pings are generated a long time after the initial page view. The theory is that a user opens a page (day 0), then leaves the tab dormant for an extended period of time. When the tab is viewed again another page ping is fired (day 1). This page ping has the same
page_view_id as the original page view but a different
session_id, due to the large period of inactivity.
However because the model aggregates pings on
page_view_id and then joins this back to the original page view, the original page view and therefore session appears to have been going on much longer than it actually was. If a user were to have accessed your site via a second tab on day 1, you could now potentially have the day 0 session appearing to overlap with this new session.
As I said I have seen this in the past when modelling Snowplow data. I am not that familiar with dbt-labs snowplow package but from initial inspection this scenario seems possible given the implementation. I guess one way to check if this is the root cause would be to check if the original overlapping session has a particularly long page view in terms of the delta between
min_tstsamp, but a small
time_engaged_in_s (due to the large period of inactivity) using the data in this model.
Hope that makes sense and let me know how you get on. Could well be down to something else but I think this a good first check.