Hi,
I’m slightly confused, as I would expect it rather the other way around, but my network_userid is updating for some users. domain_userid and session_id are staying the same over multiple days even.
I’ve set up the collector to use a first party server side cookie. Any idea, what is happening here?
What browsers are you seeing this behaviour on?
If you’re using SameSite=None; Secure then there are some incompatible clients: https://www.chromium.org/updates/same-site/incompatible-clients
If you’re running on a single domain, then setting SameSite=Lax is probably a better option.
Also, if you don’t set a fallback domain in your collector configuration, your cookie will have no domain set and Edge 15-18 will ignore it 
@volderette, the network_userid is set by the collector as you seem to be aware.
I’ve set up the collector to use a first party server side cookie.
What domain is the sp cookie set on? What domain your web application is on? I just wanted to make sure that the concept is not misunderstood somehow. The use case you describe does exhibit the scenario when network_userid is the 3rd party and is being blocked by the browser as such resulting in generating new UUID. Could you share the web application address to observe this issue?
Hi @ihor, @PaulBoocock,
thanks for your suggestions and help!
The device should be a Google Nexus phone in this specific case:
Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Mobile Safari/537.36
As you can see below one change could be to update to samesite = LAX instead. We will soon implement on various of our products with different domains though. I guess this would have implications for that as well?
What domain is the sp cookie set on?
This would be my configuration:
cookie {
enabled = true
enabled = ${?COLLECTOR_COOKIE_ENABLED}
expiration = "365 days" # e.g. "365 days"
expiration = ${?COLLECTOR_COOKIE_EXPIRATION}
name = "sp"
name = ${?COLLECTOR_COOKIE_NAME}
domains = [
"mittelbayerische.de"
]
domains += ${?COLLECTOR_COOKIE_DOMAIN_1}
fallbackDomain = "mittelbayerische.de"
fallbackDomain = ${?FALLBACK_DOMAIN}
secure = true
secure = ${?COLLECTOR_COOKIE_SECURE}
httpOnly = true
httpOnly = ${?COLLECTOR_COOKIE_HTTP_ONLY}
sameSite = "None"
sameSite = ${?COLLECTOR_COOKIE_SAME_SITE}
"mittelbayerische.de" # e.g. "domain.com" -> any origin domain ending with this will be matched and domain.com will be returned
# "{{cookieDomain2}}" # e.g. "secure.anotherdomain.com" -> any origin domain ending with this will be matched and secure.anotherdomain.com will be returned
# ... more domains
]
What domain your web application is on?
The site is https://www.mittelbayerische.de
Could you share the web application address to observe this issue?
This is implemented on https://www.mittelbayerische.de/
(Collector Domain: http://t.mittelbayerische.de/)
These are the cookies that get set:
The sp cookie has httpOnly true, secure true and sameSite None
This is an overview of one day:
It affects about 2000 sessions a day, which is roughly 2 percent of the traffic.
@volderette, the browsers on Google Nexus 5 phone are known to cause problems with generating UUID. They use a light-weight version of Javascript. This basically means the webpages are optimized for low-speed internet connection resulting in stripping off some “unnecessary elements from the page”. It looks like Javascript is affected by this optimization which prevents utilizing the required library to generate a unique event ID. Essentially, it is similar to the result produced by bots.
Apart from that, all looks good to me with your configuration (thanks for sharing). The “roughly 2 percent of the traffic” affected confirms that too. You might take into consideration @PaulBoocock’s earlier comment if mittelbayerische.de is the only domain in use (collector and web app).
