Hey there,
Thank you for writing in. Happy to help!
There is a great article on our Help Center that shows the definition of each timestamp field. I will copy the explanation here.
https://help.amplitude.com/hc/en-us/articles/229313067#Raw-Data-Fields
server_received_time: Amplitude timestamp (UTC) when Amplitude's servers receive the event.
event_time: Amplitude timestamp (UTC) which is the client_event_time
adjusted by the difference between server_received_time
and client_upload_time
, specifically:
event_time = client_event_time + (server_received_time - client_upload_time)
server_upload_time: Amplitude timestamp (UTC) when the event is ingested into Amplitude's ingestion system. This timestamp is not used to calculate event_time
, but it is available to reference in the raw data.
client_event_time: Local timestamp (UTC) when the device logged the event.
client_upload_time: Local timestamp (UTC) when the device uploaded the event.
If you have a big difference in times - can mean that either your users are using your product offline (not sure if that is possible or not) and the events get sent to Amplitude once the user connects to the Internet, or it is possible that you or someone in your team made some changes to the way you send data to Amplitude if you started seeing this only recently.
The reason why I am mentioning this is because the difference in time might be because you are using an incorrect time stamp and this difference in event times might be caused by a time zone difference/conflict etc.
So in this situation I would recommend double checking how the events are sent from the server - for example with what time zone timestamp, as this could be what is causing the difference in event times.
P.S
event_time
is the parameter that should be used for practical analysis purposes. Data ingested into Amplitude is based on server_upload_time. So, for data-export purposes, server_upload_time should be used.
Generally speaking the server-side timestamps are more reliable provided that the events were sent in real-time and there wasn't any ingestion delays on our end that would have delayed the server-side times.
Hope this helps!
Best regards,
Zhenia