Session not tracked correctly

Hi folks!

We are using the open source version of SP for our website. We are currently having js 2.10.0 version of the js tracker. We upgraded in February 2019 to the 2.10.0.

We are having problems since then with our session tracking. It seems that the session_id (domain-sessionid to be totally exact) never resets (even after 30 mins of inactivity) which leads to session_count = user_count.

We haven’t changed anything between 9.2 and 10.0 and everything was totally fine before the upgrade (ratio of 1 to 2 between user and session count when counting daily).

Have you heard from some other SP users of a similar bug ?

What I did so far:

  • I checked data with Poplin that confirmed the problem
  • I looked at our dwh and snowplow events models (we are using dbt snowplow models) to be sure of persistence of domain_sessionid infinitely.
  • I checked our tracker. We don’t have at the moment a session cookie set up.


Hello Mathieu,

We had a similar problem when using “localStorage” for the storage strategy. By setting it to “cookie” we managed to get the session count working.


Do you know why ?
Will the upgrade to 10.2 solve the problem ?

We are already on 2.10.2 so I suppose it would not solve the issue. We have not taken steps to properly identify the issue as we are ok using the cookie method for now. I’ll keep you posted if we decide to dig on this and find something.

Do you have the initialisation snippets you were using before and after for the Snowplow tracker?

In essence it looked like this:

<script type="text/javascript">

 snowplow_tracker("newTracker", "cf", "", {
        appId: "snowplow-gtm",
        platform: "web",
        stateStorageStrategy: "localStorage",
        cookieName: "acme-sp",
        contexts: {
          webPage: true,
          gaCookies: true

Hi @CoconutTherapy,

Apologies for the radio silence from the Snowplow team on this one so far - we’ve been wrapped up in a release cycle.

I haven’t yet had much time to dig into this, but I’ve had a look through the code and changes in the code between 2.9.X and 2.10.X - there’s nothing jumping out that obviously explains this or gives me a good avenue to investigate.

We’ve assigned someone to attempt to replicate the issue and try to pin down a cause/a version that introduces this behaviour.

In the meantime, from looking at your config (thanks for sharing), I have a hunch that looking at the interaction between stateStorageStrategy and cookieName might be a good place to start.

Is there any chance that your previous iteration of the tracker didn’t set a cookie name?
Could you remove the cookieName parameter from the snippet in QA, and tell us if the issue persists?


Hi All,

Can confirm the issue - I have created test site with almost nothing. I can see local storage objects being created, but session object seems to stay. From technical point of view this makes sense, as local storage objects do not have expire value…

1 Like

Hi @Colm ,

We’ll test the localStorage strategy again in a test env and report back. I can confirm that initially we had both cookieName and stateStorageStrategy = localStorage together.


Hi All,

There is GitHub issue for that:

I believe there is no point for replicating by somebody more.


1 Like