Using your js library, there’s the setUserId() method, which should be used before any tracking call on each page load, according to your docs.
We’ve been wondering why that’s necessary, and a brief chat with your support team confirmed that no cookie is set with your setUserId() method. We wondered about this, as other players in the market as for example CDPs etc. and their or similar analytics js libraries provide a setUserId() function. But in their case, that automatically sets a cookie (and even a local- & session storage value) with a huge lifetime + the user ID as the value. Then any other js trackWhatever() call of their library checks for that user ID value in the cookies, the local and the session storage, and if it’s set anywhere, it grabs it and sends the according user ID along with the concerned tracking request.
Of course it’s still better to call setUserId() on every page load even then, as you never know on which page the user first arrives. But especially when we for example have private browser sessions etc. and visitors make something allowing to identify them and then drop off, it represents a great chance to store some kind of persistent identifier on their device. So we wondered, why did you decide that the setUserId() method will not set a first-party cookie, while all of your other tracking is based on first-party cookies?
We’re particularly asking as we’re currently implementing our own js-workaround to do so (set a first-party cookie whenever setUserId() is called in our code), and we wondered if that may be a bad idea for some reason / forgot about something …?