Different network_userid is being created by the tracker for each event by the same user on the same page.
Example: If a page_view event is triggered, the network_userid is 80934d52-6956-49d6-9ba9-fa603754e6b4 and for a page_ping event from the same page, the network_userid is 338a0b3d-ccab-4f92-93ca-467b736a720d.
There are many events including the events mentioned above where the domain_sesisionid is same. There are many cases where two or more users share the same domain_sessionid.
Assuming you are using a collector that supports network_userid (i.e. not Cloudfront), take a look at the domain on which the “sp” cookie is being set. It must be the domain of the collector, not of the page you are tracking.
There are generally two scenarios in which this occurs:
As @wleftwich has mentioned above you will need to check that the domain of the cookie is set correctly. This is configured in the cookie.domain setting of the collector configuration.
Third party cookies are being blocked by a browser. In earlier versions of the collector this could result in multiple network_userids for the same user - in more recent versions this is handled by the cookieBounce configuration portion of the stream collector that allow you to set a single network_userid if third party cookies cannot be set.
This problem has not affected all the events. If it was a problem with the cookie domain, I think all the events would have been affected. Please correct me if I’m wrong.
I am using the scala stream collector and the cookie domain is set to popxo.com. Event are being tracked from multiple domains like www.popxo.com, www.plixxo.com, and www.epopxo.com
cookie {
enabled = true
expiration = "365 days" # e.g. "365 days"
# Network cookie name
name = "sp"
# The domain is optional and will make the cookie accessible to other
# applications on the domain. Comment out this line to tie cookies to
# the collector's full domain
domain = "popxo.com"
}
Some browsers (and individual user preferences within a browser) won’t allow you to use third party cookies.
What version of the stream collector are you on? Your current collector looks like it predates the release where the cookie bounce logic was added in (R93) that would help in detecting this.
I was using v0.9. I have just updated the stream collector to v0.13. I can see in Elasticsearch that there are few users with the network_userid “00000000-0000-4000-A000-000000000000” (fallbackNetworkUserId). All these users are sharing the same domain_sessionid and domain_userid. Is this behaviour correct or have I made a configuration mistake?
There’s a reasonably low probability of domain_userids colliding though it does happen. If you’re seeing several entries with the same domain_userid and the cookie bounce network user id for a single user that’s expected behaviour.
If you are seeing different users (e.g., different user agents) but the same domain_userid this would be unexpected behaviour as we expect (with a small number of collisions) that most users will have a unique domain_userid.
Sorry to reply this old thread, but i met a problem when enabling cookieBounce with POST tracking.
Does the fallackNetworkUserId only support GET? Thanks
In my environment, i tried to track event using POST. but get random network_userid in Chrome incognito mode. is there any concern if i customize the Network cookie_name as “_xxxx_cookie”
