Session ID not resetting

We are having issues with the Session ID resetting. One theory is that these users didnt close the browser window and session never got reset.
sessionId is regenerated whenever an event fires and it has been 30 minutes since the last event
. this is on SP documentation. This means (from what I understand) that if page_ping keeps getting fired beyond 30 min we sessionId will not reset. I have seen a session last for 45 in where in page_ping was being received at our end. So for these sessions lasting days. Is it possible that the browser got “paused” somehow if the computer went to sleep with MMcom page open when it woke up it generated a new event but with the same sessionID.

Hi @waspesi,

There’s a number of things that could be happening here.

You are right that page pings firing will stop a session from timing out.

If you’re using updatePageActivity to manually trigger page pings then they may fire even with no engagement from the user, but otherwise page pings will not fire if the user doesn’t interact in some way (ie. move the mouse, click a key, scroll, etc.). Furthermore, the tab must be open for a page ping to fire - so a computer in sleep mode isn’t likely to trigger a page ping.

Is it possible that the activity you’re seeing is due to a bot/spider/crawler? That feels like a likely explanation to me.

The first question I would ask myself is: How many sessions like this are there, as a proportion of all sessions? If this is a very small number you can just exclude these sessions without impacting upon your analysis.

You could also explore other activity from these users, and look at the useragent (many, but not all bots will have ‘bot’ or ‘spider’ in the useragent).

I hope this helps, do let us know what you find.

1 Like

Hi Colm,
If this is a bot issue how do you filter these out within snowplow?

Wayne Aspesi
Marketing Analytics Consultant | Data Analytics
T: (413) 744-1512
1295 State Street | MIP F205 | Springfield, MA 01111 | RetireSmart | Facebook | Twitter | LinkedIn
Please use below link to submit requests:
Data Analytics Requests

Massachusetts Mutual Life Insurance Company (MassMutual), Springfield, MA 01111-0001,
and its affiliated US insurance companies.

Hi Wayne,

Here’s a post on this topic. Some bots will be easily identifyable via the useragent, others won’t. Both Christophe’s post and Yali’s comment should give you a good idea of how to use Snowplow fields to determine what’s legitimate.

There’s also an open issue on using the IAB/ABC bots and spiders directory in an enrichment to exclude them.

Hope that’s helpful.