Summary

• Tracking inside an iframe when that iframe is on a third-party site is creating a new visitorId for every page visit/action taken by a visitor inside that iframe
• When the site you want to track with Matomo is embedded in an iframe on a third-party site, the getCookie() function cannot find the visitorId cookie inside of the documentAlias.cookie string.
• In our (limited) testing, changing the SameSite param in setCookie() function from SameSite=Lax to SameSite=None resolves the issue on most browsers (iOS Safari excluded) (i.e. the documentAlias.cookie string now contains our visitorId cookie and things work as expected)

Replicating the issue

• We first noticed this issue because we saw a large spike in traffic/actions in our Matomo dashboards for a particular site
• We determined this site was being iframed into a third-party site and any visits occuring inside this iframe were being tracked as new visitors for every page visit and action taken (blowing out the tracking statistics)
• To replicate the bug and test/prove our theory we created a test page and set the tracking JS to console log the visitorId every 5 seconds:

setInterval(function(){
    _paq.push([function () {
        var piwikVisitor = this.getVisitorId();
        console.log('the visitor ID is: ' + piwikVisitor)
    }]);
},5000)

• We then opened up the test page without using an iframe and we saw the same visitorId being spat out every 5 seconds (as expected):
  
• We then embedded this test page as an iframe on the same domain and we saw the same visitorId being spat out every 5 seconds (as expected)
• We then embedded this test page as an iframe on a third-party domain and we saw a new visitorId being spat out every 5 seconds (as expected, but not wanted, and thus proving our theory)
  

Our "almost" fix

• After trying a bunch of things (see other things we tried below) and pouring over the unminified piwik.js file we found that the "almost" fix for us was setting SameSite=None instead of SameSite=Lax on the setCookie() function
• This change allowed getCookie() to find the visitorId cookie inside of the documentAlias.cookie string which meant the same visitorId could be used
• Except this did not work for iOS Safari, which is still producing the same problem of a new visitor ID for every page visit/action, e.g:
  

Other things we tried

Presumably SameSite=Lax is set for a reason. And as noted SameSite=None does not resolve the issue on iOS Safari. So we have tried other things, such as:

• We did try setting _paq.push(['setSecureCookie', location.protocol === 'https:']);
• We did try enabling crossDomainLinking:

_paq.push(["setDomains", ["*.domain1.com", "*.domain2.com"]]);
_paq.push(["enableCrossDomainLinking"]);

• We have made sure we've upgraded to the latest version of Matomo, both in our core installation and our JS
• We tried on both secure and non-secure connections, on servers and local development environments

Potentially related...

• I note this issue from last year is still Open: Meta: Update Cookie Implementations #14904
• It lists some cookie shortcomings based on SameSite
• I couldn't see anything here that explicitly related, but there may be some crossover

Is it just us?

• I couldn't find any explicit mention of this issue on any other forum or git issue
• Can others replicate this issue using my steps to reproduce above?
• If it is limited to us then maybe there's something else we're doing incorrectly?