@stefanspatialmedia opened this Issue on April 29th 2019


I am trying to get the current visitor ID of a piwik tracking session by using getVisitorInfo(), however it seems to be returning a previous ID. This is the code I am using.

var _paq = _paq || [];

        _paq.push(['setUserId', sessionStorage.getItem('engagement')]);

        //Set custom ID.
        var timestamp = Date.now();
        _paq.push(['setCustomVariable', variable_id, 'variable_string', sessionStorage.getItem('engagement')+timestamp, 'visit']);

        // Load tracker
        (function() {
        var u="https://xxxxxxxxxxxxxxxxxxxxxx/";
        _paq.push(['setTrackerUrl', u+'piwik.php']);
        _paq.push(['setSiteId', '80']);
        var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
        g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'piwik.js'; s.parentNode.insertBefore(g,s);

                //Get the visitor info.

From piwik's end of things this all works well, it shows up in the piwik dashboard with all the right data etc. However the visitor ID i see in the piwik backend is different from the ID returned by getVisitorId(). This used to work before I believe, perhaps broken by an update?

Any suggestions for how to proceed?

@tsteur commented on April 29th 2019 Member

The visitorId in the client doesn't always match the visitorId in the backend. Eg after deleting cookies and in some other cases.

@promediadd commented on April 30th 2019


I'm a colleague of the OP and want to offer some feedback, suggestions for improvement, and also details of a workaround because I've seen a few threads around various forums on this topic and nothing conclusive ever seems to be presented... so, here's everything we've learned so far on this since posting our original issue above:

  • it is a bit frustrating that the JS getVisitorInfo() doesn't return a reliably accurate visitor_id... I'm not sure if this is intentional for privacy reasons, but it seems odd that a tracking plugin can't reliably tell you the visitor_id
  • also frustrating that you can't access the visit_id from the getVisitorInfo()
  • and the getVisitorInfo() method returns a confusing array that isn't clearly documented in official docs, from what I've seen — could be better as an object?
  • there are convoluted workarounds as long as you have a third-party reference (database) to match against (see workaround below)

Feature request?

  • potentially the Matomo dev team could consider creating a getVisitInfo() method which returns something like this (we would offer to create this as a working solution in a PR but its beyond our skillset, sorry!):
    "visitor_id": "", // accurate visitor_id
    "user_id": "", // if available
    "visit_id": "", // the visit_id of this visit
    "visit_ip": "", // the ip address of this visit
    "visit_first_action_timestamp": "", // the timestamp of the first action of this visit
    "visit_last_action_timestamp": "" // the timestamp of the last (most recent) action of this visit

    A workaround for obtaining an accurate visitor_id

FYI, for those who may stumble on this issue (not being able to reliably get the accurate visitor_id), in our particular use-case we got around this by using user_id:

  • in our JS tracking we used setUserId to give a unique user ID for the visitor
  • on our custom reporting side we then used the UserId.getUsers method in the PHP API to find the unique user_id (assigned to label in the UserId.getUsers method) we knew we were looking for, which has an associated idvisitor value (AKA visitor_id) that is always accurate from our testing

Added tidbit for how to get visit_ids (note visitor_id vs visit_id)

  • visit_ids aren't available to the JS getVisitorInfo() method, and we needed that visit_id for some custom visit-specific reporting
  • So, once you get the accurate visitor_id (using the steps outlined above) you can then use the Live.getVisitorProfile method in the PHP API to look up the visitor profile for that visitor_id
    • and loop over the lastVisits array to find the visit for that visitor that you need
    • which will give you access to the idVisit value (AKA visit_id)
  • If you're wondering how to pluck out the correct visit (if the visitor has multiple visits) you could consider cross referencing against a known third-party value
    • e.g. a known timestamp for the time the visit started
    • or in our case we used a known UUID from our database and assigned that to a custom variable in the JS tracking using the JS setCustomVariable() method, which we could then specifically look for when we looped over the lastVisits


  • the above breakdown was helpful to us in our specific use-case, but might not work for you (e.g. if you don't have a DB of known user IDs to assign)
  • I think there are many varied and valid use cases for needing an accurate visitor_id && visit_id so I hope this helps you, and hopefully the Matomo team may offer new JS methods in the future
@tsteur commented on May 1st 2019 Member

Thanks for the input. I was gonna keep the issue open with the enhancement label but realise it's better to close the issue as we very likely won't be working on it and there are already ways to achieve this right now as you mention using userId or custom dimensions.

For example quite certain we won't ever return the visitId as you could eg misuse it and through that detect the number of visits you got in X hours (as it is incremental).

The visitorId can be frustrating if it doesn't match for sure. By default it should match, but as the visitorId is created client side, it can't be 100% correct if you clear your cookies and you have meanwhile a different visitorId client side.

A workaround (and the correct way of doing this) is for sure to use userId and manage the ids yourself. Or you use custom dimensions and segment the LiveAPI for example based on the custom dimension.

If you are familiar with PHP, there are ways though in general to achieve this through a custom plugin I suppose.

@promediadd commented on May 1st 2019

Thanks for the reply @tsteur — hopefully this conversation will help others in future. Appreciate the reply.

This Issue was closed on May 1st 2019
Powered by GitHub Issue Mirror