The JS tracker queue is processing immediately upon load and when there are multiple events hitting a collector, there's not any gating logic to wait until the first event returns; thereby ensuring a stable NUID has been assigned in the browser cookie pool.
Repro:
Enqueue 2 or more tracking events on page load
Watch assigned NUIDs returned in response via SET-COOKIE header; note that NUID values rotate when the second request initiates before the first response returns. (race condition since the second request initiated before the cookie was set by the response of the first request)
Looking through the tracker core lib and JS - I can't find a way to set a serial path for my initial page load events (e.g. 'trackPageView' followed by 'trackStructEvent') and ensure that the NUID is stable across both events. The DUID will stabilize in code, but the NUID entries in the logs are 1:N for the same session. Placing an initial queue length of 1 until the first XHR response completes (only applicable for POST given how the GET code runs) should ensure the NUID is set in the browser cookie-pool before continuing with the remaining events in queue.
Tested on 2.8.2 but a review of the 2.9.0 branch shows no change in core library functions.
The JS tracker queue is processing immediately upon load and when there are multiple events hitting a collector, there's not any gating logic to wait until the first event returns; thereby ensuring a stable NUID has been assigned in the browser cookie pool.
Repro:
Looking through the tracker core lib and JS - I can't find a way to set a serial path for my initial page load events (e.g. 'trackPageView' followed by 'trackStructEvent') and ensure that the NUID is stable across both events. The DUID will stabilize in code, but the NUID entries in the logs are 1:N for the same session. Placing an initial queue length of 1 until the first XHR response completes (only applicable for POST given how the GET code runs) should ensure the NUID is set in the browser cookie-pool before continuing with the remaining events in queue.
Tested on 2.8.2 but a review of the 2.9.0 branch shows no change in core library functions.