@peterbo opened this Issue on March 27th 2020 Contributor

I see this in multiple instances - a row in the Pagetitle report that shows "Page Name not defined". This row has too many visits to be just a "rogue tracking request" somewhere on the website. Also, this row always reports 0 for exit and bounce rate and 00:00:00 for time on site.

This is also reproducible on the demo:

  • navigate to the page titlte report
  • there you can see the "Page Name not defined" row, mostly in the top 10 to top 15 visited page titles.

This seems to be a regression where another tracking method seems to write an empty action name to the database.

PageNameNotDefined

Probably is the same as #14512.

@tsteur commented on March 29th 2020 Member

@peterbo I suppose it wouldn't be some 404 error page or so? Any chance you could do some query on the DB to find out more about this (like idaction_name is null) or so?

@peterbo commented on March 29th 2020 Contributor

Hi @tsteur - presumably it's not a 404/Error page. I investigated a bit further on the issue and it seems, that this is related to Form Analytics.

Form Analytics sometimes seems to bundle/bulk some requests ("POST /piwik.php?{%22requests%22:[%22?fa_vid=[...]") - which seems to be buggy. Every time a bulk request was sent, there was an extra visit recorded in Matomo (compare the timing from the action in the "main" visit in the middle and the action without page title from the "rogue" visit below):

fa-bulk1

For this example, the request was 77.xxx.xxx.xxx - - [30/Mar/2020:00:03:25 +0200] "POST /piwik.php?{%22requests%22:[%22?fa_vid=HVy4f0&fa_fv=1&&idsite=xxx&rec=1&r=284966&h=0&m=3&s=23&url=xxx/kostenloses-girokonto%2F&urlref=xxxxxxxkarte%2F&_id=xxxx&_idts=1585519335&_idvc=1&_idn=0&_refts=1585519335&_viewts=1585519335&_ref=https%3A%2F%2Fwww.google.com%2F&send_image=0&cookie=1&res=1536x864&gt_ms=118%22,%22?fa_vid=6GLu76&fa_id=xxxxxx&fa_fv=1&&idsite=195&rec=1&r=904620&h=0&m=3&s=23&url=xxxx/kostenloses-girokonto%2F&urlref=xxxxreditkarte%2F&_id=dff94ac81dce7f88&_idts=1585519335&_idvc=1&_idn=0&_refts=1585519335&_viewts=1585519335&_ref=https%3A%2F%2Fwww.google.com%2F&send_image=0&cookie=1&res=1536x864&gt_ms=118%22]} HTTP/2.0" 204 0 "xxx/kostenloses-girokonto/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0"

This seems to also happen on the demo and it doesn't seem to be isolated to the Form Analytics plugin (but I don't know is this is just automatically generated data, so I'm not sure if I can use that as an example):
demo4
demo3
demo2
demo1

@tsteur commented on March 30th 2020 Member

Thanks @peterbo

77.xxx.xxx.xxx - - [30/Mar/2020:00:03:25 +0200] "POST /piwik.php?{%22requests%22:[%22?fa_vid=HVy4f0&fa_fv=1&&idsite=xxx&rec=1&r=284966&h=0&m=3&s=23&url=xxx/kostenloses-girokonto%2F&urlref=xxxxxxxkarte%2F&_id=xxxx&_idts=1585519335&_idvc=1&_idn=0&_refts=1585519335&_viewts=1585519335&_ref=https%3A%2F%2Fwww.google.com%2F&send_image=0&cookie=1&res=1536x864&gt_ms=118%22,%22?fa_vid=6GLu76&fa_id=xxxxxx&fa_fv=1&&idsite=195&rec=1&r=904620&h=0&m=3&s=23&url=xxxx/kostenloses-girokonto%2F&urlref=xxxxreditkarte%2F&_id=dff94ac81dce7f88&_idts=1585519335&_idvc=1&_idn=0&_refts=1585519335&_viewts=1585519335&_ref=https%3A%2F%2Fwww.google.com%2F&send_image=0&cookie=1&res=1536x864&gt_ms=118%22]} HTTP/2.0" 204 0 "xxx/kostenloses-girokonto/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0"

Do I see this right the first request within bulk request is missing the _id or at least different from the second request? Looking at the form analytics code in particular, I do see it does call tracker.queueRequest(...) instead of _paq.push('queueRequest', '...') so technically, it could be possible, that tracker.queueRequest is called even though the tracker is not configured yet.

Looking at the code this can't really happen though because it wouldn't find a tracker instance to use. Maybe though there the userId is configured somehow differently? Like it adds a tracker but configures it fully only later or so (like idSite or the URL or cookie domain or ...).

@peterbo commented on March 30th 2020 Contributor

Hi @tsteur - both requests contain the correct user-ID. Sorry for just "anonymizing" one of them, that was probably misleading.

@tsteur commented on March 31st 2020 Member

Thanks @peterbo Can't really think of a reason why they wouldn't be put into the same request. Any chance you can send me the log_link_visit_action and log_visit entries for the ones from the first screenshot? Eg in chat? Can't explain it just yet

@peterbo commented on April 3rd 2020 Contributor

Hi @tsteur - sorry for the confusion, I think the "extra visit problem" would be better addressed in another ticket, since I don't think these two things are connected. I'm still searching for possible reasons for the "Page Name not defined", but had no luck yet. Most of the provided screenshots are from the Matomo Demo, where I do not have access to the database. But I'll also try to reproduce this on other instances.

@tsteur commented on April 6th 2020 Member

@peterbo I quickly looked at a site from us and was able to reproduce this (finding such log entries). Then looked in server logs for the same tracking request and noticed it was also by form analytics.

Then tried the individual requests within that bulk request and things worked. Then tried the actual bulk request and from what I can see this happens:

image

So basically the bulk request is treated as one request instead of a bulk request. We send bulk requests through GET parameters should the total request be like less than 2K requests. This has the advantage that it can be replayed potentially, and that it helps with debugging issues (like these) as otherwise the request parameters would not appear in the log if it was posted.

Looking at bulk request plugin it doesn't support this through search query though.

Looking at the tracker code it should only happen when it does a request through send beacon in https://github.com/matomo-org/matomo/blob/3.13.4/js/piwik.js#L3579-L3582 . There we would probably need to check whether it is a bulk request and if so, not append it to the query but post it.

Not sure if it can happen also in another way.

@mattab I suppose the tracker tracking wrong data for bulk requests is something we want to fix in 3.x?

@mattab commented on April 7th 2020 Member

I suppose the tracker tracking wrong data for bulk requests is something we want to fix in 3.x?

if the PR can be easily backported, that would be valuable. To better understand what's affected, which plugins or use cases are potentially affected due to this issue? (Since it wasn't detected so far, maybe it's not critical to backport it if'd be too time consuming).

This Issue was closed on April 13th 2020
Powered by GitHub Issue Mirror