@ibril15 opened this Issue on August 7th 2019


Is it possible to configure Matomo for a new visit to be automatically created when a new browser session is created? We have a site where you need to log in to create a browser session, and we would like the entire duration of that logged in session to be counted as one visit (which we can mostly do by extending the visit timeout), and any new browser session to be another visit. For example: a user logs in to and uses the site, that's visit 1; the user closes the browser, opens it right away and logs in to the site again, that's visit 2 (for the same visitor).

It appears that it's not enough for the _pk_ses cookie to be session based for a new visit to get created. I know that new_visit=1 can be used to manually trigger a new visit, but due to the complexity of our site it may be challenging to find a way to only fire off that code only once.

Have others tried to address similar requirements?

Thanks a lot.


@tsteur commented on August 7th 2019 Member

Looking at the code this could work by calling

_paq.push(['appendToTrackingUrl', 'new_visit=1']);
_paq.push(['trackPageView']); // just an example .. or track an event that user logs in
_paq.push(['appendToTrackingUrl', '']); // then unset it

I haven't tested it though.
We could also in the future provide a method _paq.push(['setNewVisit']); which would need to be called before the trackPageView to make it a bit easier.

I reckon it is indeed not enough for the _pk_ses cookie to create a new visit.

There isn't really any other way for us to do this... You would also need to handle manually what should happen before the user logs in (eg for the one pageview where user is viewing the log in page etc).

We can't really detect any newly created browser sessions unfortunately. Unless you have some way to do this on our code then you could create a PR and we would see if that works for us.

@ibril15 commented on August 7th 2019

Thanks for the quick feedback. The trouble I have with new_visit=1 is that parts of our site are not SPA, so that code would get loaded on multiple pages. I'd have to somehow determine whether the new_visit flag was already passed in once or not for this visit.

Would creating a new cookie with a browser-session lifetime be something that would be considered? Then if the cookie doesn't exist, automatically create a new visit and a new session cookie. Or maybe leveraging the _pk_ses cookie in this way by making it have a session lifetime and then checking for it on the back-end (I'm not quite sure exactly what the _pk_ses cookie is currently for)?

Taking a step back, is this generally considered to be not best practice? I would think that if a user closed the browser and then came back to the site some time later, it would make sense for that to be a new visit. Or do I misunderstand the definition of "visit"?

Thanks again.

@tsteur commented on August 7th 2019 Member

Whether it makes sense is really up to you I guess. In general you might just want to set the userId on ALL requests as soon as the user logged in: https://matomo.org/docs/user-id/ and https://developer.matomo.org/guides/tracking-javascript-guide#user-id

This might actually give you the wanted behaviour. So you'd do this:

_paq.push(['setUserId', 'USER_ID_HERE']);

We won't be able to leverage _pk_ses cookie here I think. When you say browser session I'm not sure what you mean cause the session cookie only exists during browser session AFAIK unless you mean "Browser session = time the user is logged into your system".

I would actually recommend you try the userId feature and it should give you what you want maybe. Otherwise you'll have to track an event on successful login. You should be able to detect this maybe in your application and send out that tracking code once.

@ibril15 commented on August 12th 2019

Thanks for the recommendation.

Our website is a web app which (in most cases) requires a user to log in before using the site. In essence we're trying to get the concept of a "visit" to line up with our web app's "session" which begins when you login (by the regular tracking code) and ends when you close the browser or log out (I believe we can manually end the visit with _paq.push(["deleteCookies"]); on log out).

When I'm talking about the "browser session", I mean from the start of the browser to when the browser is closed. The _pk_ses cookie now has an expiration of 30 minutes by default (we bumped it up to 120 to match our visit_standard_length setting), so it exists beyond the lifetime of the browser for a little bit. Though even if I manually delete the _pk_ses cookie out of the browser, it doesn't seem to change the visit tracking behavior, so that's probably a moot point.

The UserID is a good feature that we're considering (we have some some GDPR concerns), but I'm not sure how it helps limit a visit to the lifetime of the browser session. Can you please elaborate?

Thanks again for your help.

@tsteur commented on August 12th 2019 Member

Re GDPR: There is a feature to pseudo anonymize the user ID in Matomo Admin.

It helps limit visit since you would basically unset the userId as soon as the user logs out (or it be no longer set) and therefore potentially create a new visit but I'm not quite sure.

When I'm talking about the "browser session", I mean from the start of the browser to when the browser is closed.

This should be pretty much implemented by default but I might be wrong?

@ibril15 commented on August 12th 2019

Not to go too much off topic, but I was concerned by the comment in the UserId documentation that says "in GDPR terms: the User ID pseudonym still counts as personal data."

Matomo doesn't appear to start a new visit when you open a new browser session if you still have your cookies from the last session and it's been less than visit_standard_length. Though we are a few versions back on 3.7; maybe that's been changed?

Powered by GitHub Issue Mirror