Summary
When "Turn off Visits Log & Visitor Profile" is enabled for a site, Matomo
removes some visitor-identifying segments from the available segment metadata,
but visitId remains registered and usable.
In particular, visitorId is conditionally registered based on the visitor
profile setting, while visitId is registered unconditionally.
This creates an inconsistency where the Visits Log / Visitor Profile UI is
disabled, but aggregate reporting APIs can still be segmented by an individual
visit ID.
This is intended as a regular behavior/privacy-consistency issue rather than a
permission-bypass report.
Current behavior
With Visits Log enabled, a view user can access aggregate reports and use
segments normally.
After enabling:
Turn off Visits Log & Visitor Profile
the direct Visits Log API is disabled as expected.
For example:
Live.getLastVisitsDetails
returns the expected message that the Visits Log is deactivated.
visitorId is also no longer available as a segment.
However, visitId remains available and can still be supplied to normal report
APIs, for example:
API.getSegmentsMetadata
VisitsSummary.get
Actions.getPageUrls
using:
segment=visitId==<idvisit>
This can reduce an otherwise aggregate report to the data belonging to one
specific visit.
Relevant implementation
plugins/CoreHome/Columns/VisitorId.php conditionally registers the
visitorId segment depending on whether visitor profiles are enabled.
plugins/CoreHome/Columns/VisitId.php registers the visitId segment
unconditionally.
Other identifying segments are also treated specially by the separate
privacy-compliance / LimitSegments functionality.
Expected behavior / possible resolution
It may be worth making the relationship between the Visits Log / Visitor
Profile setting and visitor-identifying segments more consistent.
Possible approaches could include either:
conditionally registering visitId when the relevant visitor-level feature
is enabled, similarly to visitorId; or
documenting that disabling Visits Log / Visitor Profile intentionally does
not restrict use of visitId in aggregate reporting, and that
privacy-compliance / LimitSegments is the setting intended to remove those
dimensions.
I am happy with whichever behavior best matches Matomo's intended privacy
model; the main issue is the current asymmetry between visitorId and
visitId.
Environment
Observed in current Matomo 6.x development code.
The relevant VisitId / VisitorId registration behavior is also present in
Matomo 5.13.0.
Summary
When "Turn off Visits Log & Visitor Profile" is enabled for a site, Matomo
removes some visitor-identifying segments from the available segment metadata,
but
visitIdremains registered and usable.In particular,
visitorIdis conditionally registered based on the visitorprofile setting, while
visitIdis registered unconditionally.This creates an inconsistency where the Visits Log / Visitor Profile UI is
disabled, but aggregate reporting APIs can still be segmented by an individual
visit ID.
This is intended as a regular behavior/privacy-consistency issue rather than a
permission-bypass report.
Current behavior
With Visits Log enabled, a view user can access aggregate reports and use
segments normally.
After enabling:
Turn off Visits Log & Visitor Profile
the direct Visits Log API is disabled as expected.
For example:
returns the expected message that the Visits Log is deactivated.
visitorId is also no longer available as a segment.
However, visitId remains available and can still be supplied to normal report
APIs, for example:
using:
This can reduce an otherwise aggregate report to the data belonging to one
specific visit.
Relevant implementation
plugins/CoreHome/Columns/VisitorId.php conditionally registers the
visitorId segment depending on whether visitor profiles are enabled.
plugins/CoreHome/Columns/VisitId.php registers the visitId segment
unconditionally.
Other identifying segments are also treated specially by the separate
privacy-compliance / LimitSegments functionality.
Expected behavior / possible resolution
It may be worth making the relationship between the Visits Log / Visitor
Profile setting and visitor-identifying segments more consistent.
Possible approaches could include either:
conditionally registering visitId when the relevant visitor-level feature
is enabled, similarly to visitorId; or
documenting that disabling Visits Log / Visitor Profile intentionally does
not restrict use of visitId in aggregate reporting, and that
privacy-compliance / LimitSegments is the setting intended to remove those
dimensions.
I am happy with whichever behavior best matches Matomo's intended privacy
model; the main issue is the current asymmetry between visitorId and
visitId.
Environment
Observed in current Matomo 6.x development code.
The relevant VisitId / VisitorId registration behavior is also present in
Matomo 5.13.0.