This surely could have been both documented better and have had a better runtime-warning. I've logged that task in our backlog.
The documentation doesn't explain the usage in full:
The UserID will only be used if there is no way for the monitor itself to generate and store a unique identification of this user. This is the case if either 1) you have asked to disable cookies by setting settings.useCookies to false or 2) cookies are disabled by the end-user in the browser. Only then
will the monitor resort to use your provided value. In order for your UserID to take effect you could therefore choose to set useCookies to false in the settings.
The method documentation also leaves out another important point: the UserID must be a GUID-formatted string. Agree, it would be better if any string was allowed and uniquely one-way converted into a GUID by the monitor itself, but for now the passed UserID must be a GUID.
Why these obstacles, you may think? Basically, it's because this ID is almost solely used for the sake of counting uniqueness, and for that purpose the monitor provides the best uniform mechanism it can completely automatically without the implementor having to do anything. The UserID-setter is really just a last resort in case cookies are not supported.
If, on the other hand, you wish to associate the identification of a certain user (as your SID code suggests) with the registered statistics for this particular session, then it is much more useful to use another Analytics setting: the InstallationId
I think it does just what you want the userId to do and it can be any string. You can read more about it here:
If the InstallationId doesn't match your intentions then please write me again.
EQATEC Application Analytics is now Telerik Analytics
. For more information on the new name, plus what's new in Telerik Analytics, please, check out the Analytics Service Announcement