@diosmosis opened this Pull Request on January 10th 2020 Member

Fixes #15191

Also includes an new UI test that tests the JS tracker.

@tsteur commented on February 3rd 2020 Member

FYI @diosmosis I've added some new URL API to the tracker which I need in Heatmaps and Forms... basically matching page rules used to be done server side on every request, but now I need to basically return these configurations as part of the configs and match them client side. To not needing to re-implement these things all the time I added it to Piwik. Thinking might eventually also add other things I'm using repeatedly between plugins. Eg type.isArray, type.isString etc. Might be good to expose more APIs

@tsteur commented on February 4th 2020 Member

FYI:
image

  • Haven't looked yet why Matomo would print a stack trace when there is a notice... wondering if an error handler needs to be registered to basically mute these errors? Otherwise the JSONP won't work...

  • I noticed the session storage key is eg mtm.extraTrackerConfig.1. I reckon this could be problematic since we cannot guarantee that each tracker always get the same ID? Even ourselves on some of our pages we might sometimes create a different tracker first and then the logic wouldn't work anymore. I suppose we would maybe need to include the idSite and matomo tracker url as a hash instead of the unique tracker ID?

  • Also I wonder if we could maybe send the config request along with a trackPageView tracking request for example (like &send_config=1)? It wouldn't be needed but I reckon it could save us some extra request on occasion. That would of course only work when it is not using bulk tracking and not using queued tracking I suppose. In many or most cases it would maybe improve things though. As often visits have only one page view, it could save us quite a bit. The problem with this config request is, that in worst case it double our tracking requests eg on Cloud (but also for a regular user). It won't double it, but maybe increase tracking requests by say 50% if there are many visitors with only one page view. So if we could avoid needing to request this info in a separate request, that could be a great improvement. Here's some of the thoughts:

Eg FormAnalytics...
Most pages have forms (eg search). When page is loaded, and Form Analytics detects a form, we would need to issue a configs request. Meaning when someone is using Form Analytics (which we do eg on Cloud), then per visit there will be at least one request to configs. However, if the config be returned as part of eg trackPageView, then this extra request could be avoided. Meanwhile, during a page view, it would basically only mean we need to trigger that event and don't need to bootstrap Matomo again etc

Note for myself: If we wanted to troubleshoot the ExtraConfig logic, and needed to basically clear the cache, we can execute eg sessionStorage.removeItem('mtm.extraTrackerConfig.1') or sessionStorage.clear() as part of the tracking code.

Otherwise it'll still take me a few more days to fully integrate Heatmaps and Form Analytics as it's not that trivial.

@diosmosis commented on February 4th 2020 Member

I suppose we would maybe need to include the idSite and matomo tracker url as a hash instead of the unique tracker ID?

It should be using the idSite, not the tracker ID. It used the tracker ID at first then I realized it would make more sense to set it based on idSite.

Also I wonder if we could maybe send the config request along with a trackPageView tracking request for example (like &send_config=1)?

I thought about this, but noticed it wasn't simple. I can't remember exactly why, but I believe it was due to the fact that in the tracker we use an Image to get the response. We'd have to conditionally do something different then?

@tsteur commented on February 4th 2020 Member

It should be using the idSite, not the tracker ID. It used the tracker ID at first then I realized it would make more sense to set it based on idSite.

Wouldn't it also need to include the trackerUrl since you might track to different Matomo's that use both same idSite? We do these things partially eg on matomo.org

@diosmosis commented on February 4th 2020 Member

Wouldn't it also need to include the trackerUrl since you might track to different Matomo's that use both same idSite? We do these things partially eg on matomo.org

Ah, I didn't think of that, will make that change as well.

@tsteur commented on February 4th 2020 Member

I thought about this, but noticed it wasn't simple. I can't remember exactly why, but I believe it was due to the fact that in the tracker we use an Image to get the response. We'd have to conditionally do something different then?

Yeah I would say the first request could do something like if (!extraConfigLoading && !extraConfigLoaded) { $requestUrl.= 'send_image=0&send_configs=1; $extraConfigLoading = true; }`

The problem is then though... that we might request this info even though no plugins actually requests it and in the end we transfer more data. I suppose in this case the output/response of configs be empty though so it wouldn't be a major overhead. Or we could find some way to potentially ask plugins to register very early while the tracking code is being parsed that they need extra config and only then we'd do this... (that be not too complicated eg they would only need to listen to the TrackerSetup event) but it may not be needed.

I just realise actually that we have now enabled sendBeacon by default and AFAIK we cannot get the response from this so the whole idea would actually not work anyway. :(

@diosmosis commented on February 4th 2020 Member

I just realise actually that we have now enabled sendBeacon by default and AFAIK we cannot get the response from this so the whole idea would actually not work anyway. :(

That's it! That was the reason why I couldn't figure out how to do it :)

@diosmosis commented on February 4th 2020 Member

Haven't looked yet why Matomo would print a stack trace when there is a notice... wondering if an error handler needs to be registered to basically mute these errors? Otherwise the JSONP won't work...

Added an error handler for this case.

@diosmosis commented on February 4th 2020 Member

I noticed the session storage key is eg mtm.extraTrackerConfig.1. I reckon this could be problematic since we cannot guarantee that each tracker always get the same ID? Even ourselves on some of our pages we might sometimes create a different tracker first and then the logic wouldn't work anymore. I suppose we would maybe need to include the idSite and matomo tracker url as a hash instead of the unique tracker ID?

Fixed. Issues should be fixed.

@diosmosis commented on February 5th 2020 Member

Note: added an extra url= parameter to the JS query so plugins can see what the current page URL is.

@diosmosis commented on February 5th 2020 Member

Actually adding the url= parameter is probably a mistake... I'll remove it.

  • [ ] remove url= param
This Pull Request was closed on February 7th 2020
Powered by GitHub Issue Mirror