Network user ID / collector cookie constantly changing value

I started looking at the network_userid value for some use case but found the value is constantly changing and I’m not sure why.

In devtools, every time event data is sent to the collector, I see a set-cookie with a new value.

The cookie is a first party cookie, e.g.: set on the domain, the collector is, the site itself is Same site = None; Secure; HttpOnly

I went to Snowplow’s own site to see the behavior and it’s a little strange there as well.

For example, starting with a cleared browser data, going to, I saw the first 3 tp2 POST responses constantly setting the sp_biz1 cookie to a new value. Thereafter, the cookie value behaves like I would expect. But is the initial instability in sp_biz1 value expected?

@anteup, there are a few other things that you need to take into consideration, namely

  • cookie domain
  • SameSite cookie attribute

Having the collector on the same domain as your application is not enough. The collector also needs to be configured with the cookie domain. For your example, the cookie domain has to be If you do not set it up, the cookie domain will be your “fallback” domain. If that is not set up on the collector either, the cookie will be stored on the full collector domain forcing it to be reset as your application will not be able to read it.

Additionally, some browsers are not compatible with the SameSite=None attribute. Therefore, we recommend using SameSite=Lax.

initial instability in sp_biz1 value expected?

If you reset the cookie, the first request will instruct the application to store a new UUID. However, it will be set after first pageview firing if I’m not mistaken.

Cookie domain is indeed set to
The browser I’m testing with is the latest Chrome browser. Do you still think SameSite=Lax will have an effect?

(Also, I see the sp_biz1 cookie is also set with SameSite=None)

As for / sp_biz1 cookie - it looks like these 3 tp2 POST cookie resets occurred before the cookie actually gets set and persisted on the browser side, since I don’t see the cookie being sent in any of the 3 POST request headers. I guess it would just be a minor annoyance in the data, on first visits. But curious if there’s anything to be done to clean that up.

Editing to add:
for my case, I do see the collector cookie being returned in the request headers, but the response header still has a set-cookie header with a different value.

Digging more with our infra folks and found it has something to do with Cloudflare URL rewriting (although not sure why yet).

The first visit cookie initialization race-condition that I describe using as an example is a separate issue.