Skip to main content

Hi all,

Our first tracked events in Amplitude are “User Signed Up” and “User Signed In”. These events are the starting point for the user’s journey.

The tracking of these two events needs to be done using HTTP API V2. Any subsequent events (such as “Feed Scrolled”, “Created Post”, etc...) will be done using the JS SDK.

A few questions:

  1. From what I understand, if we use HTTP API V2 then we have to manually update all the user’s properties such as location, IP, referrer, etc?
  2. Should/can we grab those user properties from the JS SDK and then add them to our POST call coming from the backend?
  3. We tried doing the above by sending an event with some of the user properties but got a random event ID that wasn’t in sequence with any preceding or subsequent events. We can set event_id to 1 but not sure if that’s recommended.
  4. What is the safest way to do this? Basically we want to send an event that the user signed up with his user_id. Ideally it would all be in the JS SDK but we can only safely know when a new account is created from the backend so that’s why we’re trying to use HTTP API V2.

Anyone?


Hi @davidgrey! Welcome to the Amplitude Community :wave: I’ll go ahead and address your questions accordingly:

  1. If you use HTTP API V2 and that is the very first event that is sent for the user, then yes you will need to manually update all the user’s properties such as location, IP, referrer, etc, if you want to have those user properties exist on the event. If you send events from HTTP API V2 and those events are not the very first events, the HTTP API events can carry on the user properties that are already set in the user’s profile. https://help.amplitude.com/hc/en-us/articles/115002380567 
  2. You can grab those user properties from the JS SDK and then add them to your POST call coming from the backend. Your team will need to figure out what would work best for you
  3. It’s likely that you won’t be getting an event ID that is in sequence with any preceding or subsequent events. If event_id is left as null in the event request, a value does get set for event_id - currently it just gets set to a random number in the interval i0, 999999999)
    1. I wouldn’t worry too much about the Event ID as Amplitude doesn’t rely on it too much now unless you want to deterministically sort two events with the exact same time. 
    2. I would rather you look into making sure the session_id is the same session_id as the rest of the JS SDK events so that the User Signed In event is in the same session as the other events. 
  4. You are more than welcome to send a mix of events from client-side (SDKs) and server-side (HTTP API), and we have customers who do so. The main thing to watch out for are making sure the right identifiers are being sent with the event so the event is attached to the correct profile. Usually I would recommend also sending the user properties with the server-side event just so you know for sure that the server-side event will have the properties. But if you know the user profile already has the user properties set, then you can leave the user properties blank (except I would still send IP address and also make sure the IP address is representative of the IP of the user). Finally one last thing to check is that the session_id is matched with the session_id of the JS SDK events so the Sign In event is associated to the right session (instead of being out-of-session if you don’t send session_id). 

Hope this helps! 


Thank you so much @belinda.chiu! Your answer definitely cleared things up.


You’re welcome @davidgrey ! Happy to have helped :) 


Reply