From what I can see by looking in the code there is actually no way to really force the creation of a new visit. This needs to be implemented and would be actually useful.

I don't think it's too hard to implement but we'll likely not be able to work on it soon. Would be a good feature for Piwik 3 at least

Thanks for the suggestion! Pull request would be very welcome 👍

Wouldn't it enough to use setSessionCookie with an actual "session identifier" instead of the character '*'. (see https://github.com/piwik/piwik/blob/3.x-dev/js/piwik.js#L3885), This way we force a new visit by setting another session identifier.

Example

JS Tracker

function setSessionCookie() {
                var sessionUUID = now() + generateUUID();
                setCookie(getCookieName('ses'), sessionUUID, configSessionCookieTimeout, configCookiePath, configCookieDomain);
            }

The actual HTTP request would then look like:

http://piwik-server/piwik.php?action_name=View settings&url=http://mobileapp.piwik.org/window/settings &idsite=8876&rand=351459&h=18&m=13&s=3 
&rec=1&apiv=1&cookie=1&urlref=http://iphone.mobileapp.piwik.org&_id=af344a398df83874 &_idvc=19
&res=320×480&_session=<somerandomidentifier>

On the piwik backend, we would aggregate visits based on the session identifier (sessionUUID).

Note: Of course this only works when the client accepts cookies.

what do you think ?

Wanted to share the recent investigation analysis on this, and would request @mattab / @tsteur to help with

1. Manually ending session (esp. when browser closed kind of a scenario)
2. Manually extending session (when there is no activity by the user watching a video in the application etc.)

For #1 - Manually ending session, we tried the following -

Delete the session cookie contents by setting setSessionCookie and expiration to -86400, so it immediately expires, and value to empty string.

_paq.push(['setSessionCookie', 'ses', '', '-86400']);

The main drawback or the challenge we faced was, while we are controlling the session cookie in the client side, the server side still continuing to work based on the predefined limit of visit length (30 mins or so) without honoring the session cookie state.

We also don't want to lose the main cookie id as it is the key thing for capturing the data for returning visits, else we would have chosen the path of delete cookies during the browser close etc OR whenever we wanted to end the session.

For #2 , manually extending session we tried two approaches:

Approach #1:

Tried with setting up Ping + SetSessionCookie, and as Igor mentioned in the other issue (#14897 ), there is no way we can extend the session with "Ping" as it is claimed in the documentation. Again as said above SetSessionCookie only controls the client side cookie expiration behavior but not the server side.

Though this option is implemented, we are not able to control the server side behavior of extending session, and hence resulting in creation of a new visit, when the session expires.

Approach #2:

So when there is a timer shown to the users and they manually select the extension of application session, we are forcing a specific action to be sent to the Matomo server (like pageview, download, click track, event track etc).

the resulting behavior is that the session is getting extended. However there is a downside of this approach. The base page whichever is viewed by the end user is supposed to get tracked on the amount of time spent on it, but the delta time from when the action is tracked, the time is marked for this latest action (be it event, or download, or link track etc).

Summary, it is serving the purpose of extending session, but data captured is incorrect.

Thanks a lot to you both and help prioritize this.

Regds,
Sivakumar

FYI it is possible to force the creation of a new visit, this is documented see
https://matomo.org/faq/how-to/faq_187/

To create a new visit on demand you can use the &new_visit=1 parameter in the Tracking API (see Reference docs).

(and also in other ways in https://matomo.org/faq/how-to/faq_19616/)

Thanks @mattab , for your feedback on this. We are currently not using "UserID" feature and hence we won't be able to use "resetUserID" method.

For the "new_visit=1", we are aware of this functionality, however we won't be able to use this as the application can also be accessed using the deep links, and this cannot be attributed to a specific page as a starting point. i.e. end users can access any page that is allowed for them.

Hello @mattab . We got some breakthrough on this one!

We have used sessionStorage to check whether the page has been tracked at least once or not, and accordingly handle the "new_visit" flag.

The limitation from the piwik.js file is that there is no way we can undo the addition of "new_visit=1" in the single page applications, i.e. undo the appending of "new_visit=1" from the second URL onwards.

To support that SPA flow, we are requesting you to allow the PR to add the below method to the tracker code.

New method:
this.removeFromTrackingUrl = function (queryString) { configRemoveFromTrackingUrl = queryString; };

Update getRequest method:

if (configAppendToTrackingUrl.length) { request += '&' + configAppendToTrackingUrl; } if (configRemoveFromTrackingUrl.length) { if(configAppendToTrackingUrl === configRemoveFromTrackingUrl) configAppendToTrackingUrl = ""; request = request.replace(new RegExp("&" + configRemoveFromTrackingUrl, "g"), ""); } if (isFunction(configCustomRequestContentProcessing)) { request = configCustomRequestContentProcessing(request); }

configRemoveFromTrackingUrl is a new member of the Tracker class.

Please let me know if you have any other questions.

Attaching the file for your reference.

piwik_modified.zip

Thanks a lot.

Hi @siva538 it's probably possible to add such a method 👍 But would it be possible to create a pull request so it can get reviewed? See: https://developer.matomo.org/guides/contributing-to-piwik-core for a guide to get started