user_id you send. The id is yours: a database id, a session id, an anonymous visitor id. Curious stores what you tell it about the user and nothing it infers.
One id across decide and events
Rewards attribute to decisions by user: an event reported foruser_123 credits the decision made for user_123. Use the same id on decide and events, and when a person’s id changes, say so with identify.
The three buckets
Three explicit objects may travel with a decision. You pick the bucket; nothing is routed by key name.attributes and the call’s context. On a key present in both, the context value wins for this decision: the fresh fact beats the stored one. Event properties are facts about the event and are never written to the user.
Anonymous and known users
A visitor who has not logged in gets an anonymous id from you (the browser SDK mintsanon_<uuid> in a first-party cookie). Decisions and events accrue under it. When the person logs in or signs up, your server calls identify with anonymous_id and user_id, and from then on decisions and events on either id attribute to the same person: a purchase under user_123 credits a decision made under anon_456. Many anonymous ids may link into one known user; a retry of the same link is a no-op; a link that contradicts an existing one is a 409. Identify needs a secret key, because the browser never holds the authority to merge identities. See Identify users.
Environments keep users apart
A test key’suser_123 and a live key’s user_123 are different users. Test traffic can never read or change live user state, and test decisions never affect live ones. See Keys and environments.