Stats for a Single Page Application-like website

Or is it possible to trigger a registration of an event that should be tracked? Eg could our own js code fire an event that registers as a click on a goal class?

Hi @johannesdb,

Thanks for your suggestion!

I think this is a simple change, so I’ve updated the plugin to listen to URL changes as well, in this branch:
https://github.com/Burst-Statistics/burst/tree/listen-to-url-change-for-SPA

Let me know if this works for you.

It’s added to our test queue, and will get merged when found working correctly.

Hey @rogierlankhorst

We did some more testing – and though the function works as expected, we found that there are to many scenarios where a change in the url should not count as a page view. For example we edit the url when someone searches, so the url reflects the search string if shared. Each character that is typed then counts as a pageview – and that is not optimal at all.

So we will trigger the event burst_fire_hit, so we control what changes should be registered as a pageview.

So I would suggest that this option, listen for changes in the url, is not enabled as default. And that it should be an option in the plugin, if it was included.

Thanks for the help with the branch so we could test it ??

It is merged in the latest release, but we will link this to a setting in the next release.

check. An option to enable the feature would be perfect ??

Thanks!

@rogierlankhorst do you have a time frame for the next release? We have some temp code, that is not optimalt, but need to prevent to many page views when searching.

I have a branch ready with this feature, currently in the test queue:
https://github.com/Burst-Statistics/burst/tree/track-url-change-as-option

You can use it for now. As we will be releasing a patch release Tuesday, I don’t think this feature will make it in that release.

@rogierlankhorst Thanks for the info! I will use the branch ??

@rogierlankhorst Ah! that is on the free version of the plugin. I am using the pro version :-/ Any chance that version has a branch with this feature as well? I can send a mail to support with my license if you can then send me a link.

Ah, of course that’s possible. Please email support as we’re not allowed to provide premium support here.

@rogierlankhorst Perfect! Mail sendt ??

Thanks again!

@rogierlankhorst Got them mail with the branch and we have tested it. There is a small bug as a result of these new changes.

In our use case we want to make sure that we control when a url change should be registered as a page view. We therefore use the burst_fire_hit to register that a user has opened a modal. We can’t use history change as a search results in multiple url changes and therefore to many page views.

But the issue is that there is an event to update a previous init call. But there is no event, we can call, to send this init call. Therefore the update, we send, is not registered as there is no url in the database for the user that matches the update, we send.

Before your update with this new option to turn register url changes on and off, the init was sent, when we used burst_fire_hit. And if I enable the track_url_change, the init is sent again.

So the “bug” is that there is no way for us to send the init call when a user opens the modal and the url changes – and therefore when we send the update when the user closes the modal, it is not registered in the database as there is no url match.

Is it possible to make a js-event like burst_fire_hit that we can call to init the new url?

I think burst_update_hit() runs because burst_initial_track_hit === true;

So if you want to ensure that it registers as an initial hit, before firing the burst_fire_hit event, you can do:

burst_initial_track_hit = false;

Does that resolve your issue?

@rogierlankhorst Check. We can do that.

But there is another and more profound “bug”, that has been introduced back when the plugin started to track URL parameters.

The issue is that if the URL changes after the page has been loaded, the url does not match the url set in the init call to Burst, when opening the page. Therefore when leaving the page the update call to Burst sends an unknown URL and the time on page is not registered.

I have tested this scenario on our test site:

I open bog.udstillerdemo.dk/udstillere -> a init call is sent to Burst and I can see the entry in the database

I open do a search which changes the url to include the term I am searching for. This makes it easy for us to maintain a state on the page and for the user to share the url. But we can enable the new function to track url changes as that would result in a page view for each letter the user enters.
The url is now https://bog.udstillerdemo.dk/udstillere/?1.soeg=test – no event is fired and no data sent to Burst

The user navigates to a new page and an update is sent to Burst – BUT the url does not match the url from the init call and does not match an url in the database, so the update is not registered.

A solution could be that the URL is saved in a global variable when the init call is sent to Burst – and that URL is used when the update is sent instead of the actual url.

The same scenario – that the URL is changed after the page is loaded – could happen in many cases. And it could maybe account for some of the rather sharp decline in time on page that we have seen after Burst started to track URL parameters. We went from 4-5 min to 0,5-1 min on the same page during the same time of the year.

Does that make sense? And would that be a possible and useful solution for you?