Hi @luigi7up,
This is Yuanyuan from the Amplitude Support team - thank you for posting the questions!
For Q1 registering user prop:
You can send the user properties via either Identify API or HTTP API. You can certainly send/update user properties in the event payload. Please kindly check the HTTP API dev doc for reference.
For Q2 Updating the user prop:
By “client side”, do you mean using our SDKs? If so, please check our Dev Center doc on how to update user properties in iOS, Android and JS SDK.
For Q3 Collision:
By “collision”, do you mean the collision between event property and user property? If so, there is no collision in such cases. Event properties and user properties are independent from each other, even if they have the same name and value. So updating the user property email will not affect the event property email.
Yes - you can update user props as long as the name is correct by simply adding them to any event. Once a user property is set, it will be applied to all events going forward until it gets updated. For example, you first have user property email = abc@gmail.com, all events will have this user property value. Then you send in another value today email = def@gmail.com, all events from that point onwards will have the user property value def@gmail.com.
HI Yuanyuan, thank you for your reply. I really appreciate it
Yes, it’s all JS SDK related
I still have a few questions. I hope you can help me
Q2 Updating the user prop
By “client side”, do you mean using our SDKs? If so, please check our Dev Center doc on how to update user properties in iOS, Android and JS SDK.
Yes, I mean JS SDK. IN the docs you shared I only only see a way of updating the user props using the Identify method so I conclude that sending user props in events won’t affect the user prop with the same name.
In the Q3 you confirm that there is no collision between the user props and event props with the same name such as
EVENTX {email: asd@asd.com} VS analytics.identify( {email: asd@asd.com} )
Nevertheless, in the next paragraph you say:
Yes - you can update user props as long as the name is correct by simply adding them to any event.
Which looks like you can update user properties by sending them as events payload. I’m confused 
Q1 How do we send user prop values in events if there is no “collision” (user props and event props with the same name have no effect)
I guess, I can explain myself a bit better with the following example:
- user is identified with analytics.identify(user_id: “123”, email: “asd@asd.com”)
- an event Menu Item Clicked is logged
- a button click is logged track(“Button Clicked”, {email: xxx@xxx.com})
Questions:
Q2 The value of email in 2. would be asd@asd.com because the user prop values are implicitly associated with the events at the time of logging them, right?
After the 3 happens what would be the value of email for the Button Clicked” event in the events stream and what would be the value of the user property email from then onward?
Thank you again,
Best regards
Thank you very much
Hi @luigi7up
Yes, I mean JS SDK. IN the docs you shared I only only see a way of updating the user props using the Identify method so I conclude that sending user props in events won’t affect the user prop with the same name.
You can update the same user prop "email" by including "email" in the payload with the new value and specify that it will be overwritten for the user properties at the top and the new value will propagate to further events. Historical events will not get updated.
When I mentioned there is no collision between the user props and event props with the same name, I meant if you send “email” specifically as a user property AND an event property. Then when you send an identify call to update the user property “email”, the event property “email” will not be affected, only the user property “email” will be updated.
When I mentioned you can send/update user properties in the event payload, the example below is what I was referring to. I am sending an event with user properties in the payload:
{
"api_key":"{{API_KEY}}",
"events": A
{
"user_id": "datamonster@gmail.com",
"device_id": "C8F9E604-F01A-4BD9-95C6-xxxxxxxxxx",
"event_type": "yuanyuan's test event",
"user_properties": {
"age": 99
},
"app_version": "2.1.3",
"platform": "iOS",
"os_name": "Android",
"os_version": "4.2.2",
"device_brand": "Verizon",
"device_manufacturer": "Apple",
"device_model": "iPhone 9,1",
"carrier": "Verizon",
"country": "United States",
"region": "California",
"city": "San Francisco",
"dma": "San Francisco-Oakland-San Jose, CA",
"language": "English",
"location_lat": 37.77,
"location_lng": -122.39,
"ip": "127.0.0.1",
"android_id": "BCCE52E7-03EE-321A-B3D4-E57123966239",
"event_id": 24,
}
]
}
To answer your questions:
Yes - The value of email in 2. would be asd@asd.com. It’s because the user prop values was set before the event was logged, so all events going forward with this value until it’s updated again.
After the 3 happened, email: xxx@xxx.com was sent in a track call, can I understand it was sent as an event property? If yes, then the value for the user property email will still be asd@asd.com.
I hope this clarifies!
Best,
Yuanyuan, thank you very much for all the info!
I found the API calls that allow tracking an event and sending the object representing the user properties in it, but I couldn’t find anywhere the JS example for doing the same. Is there somewhere documentation on sending the user props in the track() method using the JS lib?
Again, thank you so much for all the clarifications!
Luka
@Yuanyuan Zhang Hi! Me again… We are having this issue again :/
We’d like to send an event and in that same call update a user property, but we are not sure how to do that in the JS SDK. You shared some info on how we can do that using the HTTP API calls, but not the JS library
Imagine we had a user property {dark_mode_on: boolean} that we set to true after a user logs into the app by calling:
identify(“USER_ID”, {dark_mode_on: true})
In the application a user can toggle the dark mode and we would track that toggle by sending the
track(“dark_mode toggled”)
The question is could we send user property payload in the track(“dark_mode toggled”) method to update the dark_mode_on user property or we would have to explicitly call identify(“USER_ID”, {dark_mode_on: true}) right after the track(“dark_mode toggled”
Actually, we have a lot of use cases like this one where we track some users actions that should also be reflected in user properties change.
Thank you very much
L
Hi @luigi7up,
Thanks for reaching out again.
Our JS SDK uses the HTTP V2 API to send events and properties. So the payload I shared in the earlier reply indeed looks like a HTTP API call, but it is also a call you can make in JS SDK.
So you mentioned two approaches:
1) send the updated user property in the track call
2) send an identify call to update the user property right after the track call
Withe approach 2), the updated user property will not be applied to the event that is sent before the identify call. So for your use case, I would suggest using approach 1 and sending the updated user property in the track call. This way, the updated event property will be applied to that event and all events going forward.
Please kindly check this help center doc for how Amplitude updates user properties and how Amplitude applies user properties to events.
Hope this clarifies.
@Yuanyuan Zhang Thank you so much! Yes, the exmple you posted confused me and I thought you were showing the HTTP API payload example. Sorry for that!
So, we simply do this:
analytics.track(“EVENT NAME”, {
event_prop1: xxx
event_prop2: yyy
user_properties: {
dark_mode_on: true
}
})
If I understand well, this would first update the user property and then log event right after it. That way the new event would get logged with the updated value of the user property
Thank you so much, I’ll test this right away :)
Hi @luigi7up
Sorry for the confusion! I am gald to hear everrthing is clear now. With the payload you shared, the event and the user property would get updated at the same time, so this new event will have the updated user property once it’s logged.
I hope this will work for you!
