AdminBuleandra Cristian
(CEO / Founder, tips4design)
My feedback
13 results found
-
3 votes
An error occurred while saving the comment -
4 votesAdminBuleandra Cristian
(CEO / Founder, tips4design)
supported this idea
·
-
1 vote
An error occurred while saving the comment Hi Javier,
Unforunately domain-specific settings are not yet supported.
The current work-around is to save a copy of the tracking JS file (which contains the settings) for the domains where you need different settings.
I am planning to add domain-specific settings soon. The biggest problem is the UI/UX, and how to best decide which settings are "global" and which ones can be overwritten and what happens if you change a global setting for example.
See this section in the docs: https://docs.usertrack.net/installation/installation/adding-the-tracking-code#different-tracking-settings-for-each-domain
-
9 votes
An error occurred while saving the comment This is a really good suggestion, but from the recent news it looks like AMP will go away soon: https://www.seroundtable.com/40-of-seos-will-remove-amp-31481.html
https://www.seroundtable.com/google-core-web-vitals-top-stories-inclusion-31185.html
-
1 vote
An error occurred while saving the comment You can already block an IP or a range of IPs from the settings:
Settings -> Tracking settings -> Ignore tracking those IP addresses.
Are you referring to a different way?
-
1 vote
An error occurred while saving the comment You can already track events/clicks using tags: https://docs.usertrack.net/api/client-side-api#2-tag-visitors-dynamically
Are you referring to adding an automated way to track all clicks on all buttons, or is the tags feature what you were referring to?
-
20 votesAdminBuleandra Cristian
(CEO / Founder, tips4design)
supported this idea
·
-
11 votes
An error occurred while saving the comment Hello Boris,
This feature won't probably be implemented too soon but I will keep the ticket open.
The reason why this isn't implemented is because from the user experience point of view acessing your site as domain.com OR www.domain.com should lead to exactly the same content. This is the recommended way to server your website content and you should redirect the non-www version of your site to the www version.
So, by not implementing this "www" support userTrack "forces" the webmasters to follow the best-practices in order for it to work properly.
-
0 votes
An error occurred while saving the comment If by "normal work of product" you refer to your site then yes, userTrack does not alter your website in any way.
If you refer to userTrack, events can not be tracked from iFrames or Java applets as those elements do not propagate the mouse events to the containing website. So you will see the recordings correctly but no action done on those Java elements will be recorded.
-
4 votes
An error occurred while saving the comment I think you can force www. to be added by simply accessing your interface as www.site.com/userTrack instead of site.com/userTrack.
-
2 votes
An error occurred while saving the comment Send the number of visitors where, via e-mail?
I was thinking about implementing a monthly or weekly summary to be sent via e-mail, including some visitor and page statistics. Would you find that useful?
-
1 vote
An error occurred while saving the comment Hello Nebosja,
Do you mean on the main homepage statistics?
Initially userTrack was only a basic heatmap/session playback script. The statistics were added later, that's why they are a bit too simple. Improving the statistics is something planned, but currently the focus is on improving the heatmaps and session playbacks.
-
16 votes
An error occurred while saving the comment This is something really hard to implement. What I can do is provide an option to give a link to a specific recording.
You could actually export is as an MP4 file by recording your screen while playing back the visit (using a software like https://www.screenr.com/)
AdminBuleandra Cristian
(CEO / Founder, tips4design)
supported this idea
·
Hi David,
Thanks for the suggestion!
Let me just write my thoughts.
The main reason for having the two separated is performance.
If you included the same JS snippet for both recording modes, it would mean that either:
A. The JS for both modes will need to be served, which means a much larger JS file size when the default recording is used (as it would still include all the full recording systems)
B. No recording system is loaded initially, first the settings are loaded (to know which recording system is used), and then the recording system JavaScript is loaded. The problem with this is that it adds a lot of latency before anything can be recorded, which means more data will be lost from each pageview.
So, the implementation is not hard (to load the recording system after loading the tracking settings), but there are some big drawbacks that come from it.
That being said, there is also an option C: dynamically generate the ust.min.js to include the correct recording system. This is the best option, the only problem with this is caching. If the user already had the old ust.min.js stored, if you change something in the settings, they will not receive the new version if the browser still has the old one in cache.
Thinking about it now, this might not be that big of a problem, as now the tracking settings are indeed stored dynamically in ust.min.js and still encounter the same issue.
One "hacky" way of changing the tracking system without changing anything on the tracked website is to use .htaccess rewrite rules to load the different file.
You could write in the .htaccess file to always load ust-rr.min.js when ust.min.js is requested, thus switching to the full tracking mode.
> We can even have an icon on the session to indicate the type of recording.
There already is one in the playback (the HD indicator is for full recording). Where would you want this icon to be displayed?