How can I tell Piwik programmatically to set the Session Cookie only?

I am tracking Piwik Pro without Tag Manager and with an external consent manager. Depending on the consent level, I want to only use the Piwik Session Cookie for the user.

I may have misunderstood the docs (Guides — Piwik PRO Analytics Suite 17.4 documentation), but to me it sounded like setting _paq.push(["setUserIsAnonymous"]) before initializing the PiwikPro tracker should do the job.

But it doesn’t. I always get both session and user cookies.

Hi. You can use this method to limit or extend the timeout: API — Piwik PRO Analytics Suite 18.6 documentation

_paq.push([“setVisitorCookieTimeout”, 1800]);

1 Like

@kuba Thanks once again. :slight_smile:
What do you mean by “this method”?

And in the method you suggested, there is still that Visitor Cookie, it simply times out after 30 minutes, right? There is no way to only have the Session Cookie?

I changed the
call to
_paq.push(["setUserIsAnonymous", true])
like in your documentation.

But nothing changes:
There is still a Visitor Cookie with a lifetime of 1 year and the session cookie:

I have tried various implementation methods, to no avail. The “anonymous mode” does not work or I misunderstand it. Here an example of how I tried it:

  1. What am I doing wrong?

  2. Is there some documentation of what the cookies should look like after using the method. The documentation on anonymous tracking says:

" From now on all following requests sent by trackPageView or any other function that sends requests to Collecting & Processing Pipeline, will be marked as a request that should be anonymized. Learn more how Piwik PRO anonymizes visitors data."
a) How can this be verified? Is there a particular parameters in the PiwikPro tracking request that tell me this mode is switched on? Is there a JS method I can call to the tracker object to get the info that this anonymization mode is switched on?

Update: I compared 2 Pageview requests, one with the anonymous setting, one without:
The only setting is the uia = 1 (probably “user is anonymous”) parameter. Everything else looks the same. And again, Visitor Cookie exists and lives for a year.

So how can I use the option 2 that is described here: Anonymous tracking: useful analytics without personal data :
"1. Anonymous tracking with cookies and session data

In this scenario, Piwik PRO deploys a session identifier as a cookie that collects session data but no personal data. After 30 minutes, which is the duration of a session, Piwik PRO removes the identifier from the web browser.

The major advantage of this approach is that it gives you more trustworthy data than any other anonymous data tracking method."

=> I thought this is what the setUserIsAnonymous method does, but it does not apparently…

  1. Which documentation is “correct”? My documentation link (Guides — Piwik PRO Analytics Suite 17.4 documentation) says without true, yours (API — Piwik PRO Analytics Suite 17.4 documentation) says with true.

Again, our goal is:

  • Have only the session cookie, no visitor cookie
  • Context: No Piwik Tag Manager or Consent Manager in place

The visitor cookies is our source of truth when it comes to the analytics session recognition. The _pk_ses.* cookie is just an addition used to calculate some of the engagement reports (I explained it in the other thread).

The call: _paq.push(["setUserIsAnonymous", true]); translates directly to the tracker HTTP api param uia=1. It drops the IP address and limits the geolocation to country level. In the future, we plan to add more control, to be able to disable Session ID via tracker param. For now it can be disabled only globally via Site&app settings. While double checking that I noticed that docs are inconsistent in some cases. We plan to fix that asap.

We always rely on the visitor cookie. Our anonymous tracking mode that relies on cookies, limits its lifetime to 30 mins. The whole process of setting it up is much easier when our Tag Manager is used. Nevertheless, having all that context, you should be able to set it up.

Side note: we never set the cookie expiration to “session”.

1 Like

Thanks a lot, that link to the HTTP API in both the other documentations or the blog post would have saved me hours… :wink:

  1. Lifetime 30 min

=> I may misremember, but I could not verify that. Visitor Cookie expiration is unaffected by Anonymous mode.

  1. Also the HTTP API docs say:
    " > “All IP bytes will be masked (, no GeoIP data will be stored and visits won’t be matched by the fingerprinting process.”"
    => Session fingerprint seems to be unaffected by anonymous mode. I got recognized as the same user in Anonymous mode after deleting my cookies = Session fingerprint is active.

  2. Also to conclude, it seems impossible to just have one cookie. The _pk._ses Cookie is always there. My expectation was that I could have “just” a session (30-minute) cookie and nothing else.

By anonymous tracking mode I meant the settings from the UI which use both the uia=1 and disabling/limiting cookies.

  • the first point is exactly the part of docs that needs to be fixed (I mentioned that in my previous post)
  • yes, _pk_ses. cannot be disabled separately.
1 Like

Thanks, that helps. We want to have as few cookies as possible in the lowest consent stage. What happens if we have our Consent Manager delete the pk_ses Cookie?

That would affect the engagement reports mentioned before (anything that relies on the session count taken from the visitor cookie). Other than that, all the crucial reporting and session recognition should work just fine.

So “engagement” refers to only Session Count-based Reports (new vs returning, session number, but not things like “time since last session”?) So not all of the reports under “Engagement”, only those referring to Session Count (because the user will always be in his first session (?)):

Session count, session count before conversion. New vs. returning should work even without the pk_ses cookie. From what I remember it’s based on sole existence of pk_id cookie. If for some reason new vs. returning stops working after removing this cookie, please let me know.