Thank you for the answer @samplitude .
I have another question. Must we implement the session_id on each event track or we just need to add it in the identify event or we have to add it to all of them (track, page and identify)?
Hi @julian Ur !
Just noticed this reply - so sorry for the delayed response! We have two Destinations/ integrations with Segment, so depending on which one is currently set up, the answer varies slightly:
💡If you’re using our legacy Destination with Segment, it’s important to note that Segment doesn’t have a concept for a session.
Device-mode calls to Amplitude include session information because Segment bundles Amplitude’s SDK.
To set up the same sessionId
for cloud-mode calls to Amplitude, you must explicitly set the session_id
as an integration-specific option, as in the example below.
{
"userId": "1234",
"traits": {
"email": "someone@somewhere.com",
"name": "Some Person",
"industry": "Technology"
},
"context": {
"ip": "00.0.00.00"
},
"timestamp": "2016-10-17T00:30:08.276Z",
"integrations": {
"Amplitude": {
"session_id": "<Timestamp>"
}
}
}
You must pass the start time of a session as <Timestamp>
.
When you pass a timestamp value from the session_id
it must be in Unix format or else it generates an error when it is delivered to Amplitude. For example, a date of January 1, 2020 and 9:30am UTC would be written as 2020-12-07T19:33:44+00:00
in ISO 8601, but 1577871000
in Unix epoch time. There are many tools and libraries available to help you convert your timestamps.
💡However - if you’re using our latest and greatest Destination - Amplitude Actions (in Beta until October this year), sessions are automatically captured in Cloud Mode.
Benefits of Amplitude (Actions) vs Amplitude Classic
Amplitude (Actions) provides the following benefits over the classic Amplitude destination:
- Fewer settings. Data mapping for actions-based destinations happens in during configuration, which eliminates the need for most settings.
- Clearer mapping of data. Actions-based destinations enable you to define the mapping between the data Segment receives from your source, and the data Segment sends to the destination.
- Support for Amplitude’s HTTP API v2. Amplitude (Actions) is built on the latest version of Amplitude’s HTTP API.
- Revenue is a top-level property. Amplitude (Actions) elevates
revenue
to a top-level property in requests sent to Amplitude. This enables inclusion of this data in Amplitude features like customer LTV reports. - Session tracking in cloud-mode. Amplitude (Actions) supports sending session details from cloud-mode sources.
Thank you for the answer @samplitude .
I have another question. Must we implement the session_id on each event track or we just need to add it in the identify event or we have to add it to all of them (track, page and identify)?
@samplitude I also have the same question as above, which I didn’t see answered.
Which events types does the session_id need to be added?
When we try adding it to the screen event, Amplitude rejects the event from Segment: invalid_event_field. Invalid fields [session_id]
Thanks for these question @adrianbourke.
Somehow the team missed them! Were you able to find answers? I’m looping in platform specialist @ning.chang, who can take a closer look if needed.
Hi @julian Ur !
Just noticed this reply - so sorry for the delayed response! We have two Destinations/ integrations with Segment, so depending on which one is currently set up, the answer varies slightly:
If you’re using our legacy Destination with Segment, it’s important to note that Segment doesn’t have a concept for a session.
Device-mode calls to Amplitude include session information because Segment bundles Amplitude’s SDK.
To set up the same sessionId
for cloud-mode calls to Amplitude, you must explicitly set the session_id
as an integration-specific option, as in the example below.
{
"userId": "1234",
"traits": {
"email": "someone@somewhere.com",
"name": "Some Person",
"industry": "Technology"
},
"context": {
"ip": "00.0.00.00"
},
"timestamp": "2016-10-17T00:30:08.276Z",
"integrations": {
"Amplitude": {
"session_id": "<Timestamp>"
}
}
}
You must pass the start time of a session as <Timestamp>
.
When you pass a timestamp value from the session_id
it must be in Unix format or else it generates an error when it is delivered to Amplitude. For example, a date of January 1, 2020 and 9:30am UTC would be written as 2020-12-07T19:33:44+00:00
in ISO 8601, but 1577871000
in Unix epoch time. There are many tools and libraries available to help you convert your timestamps.
However - if you’re using our latest and greatest Destination - Amplitude Actions (in Beta until October this year), sessions are automatically captured in Cloud Mode.
Benefits of Amplitude (Actions) vs Amplitude Classic
Amplitude (Actions) provides the following benefits over the classic Amplitude destination:
- Fewer settings. Data mapping for actions-based destinations happens in during configuration, which eliminates the need for most settings.
- Clearer mapping of data. Actions-based destinations enable you to define the mapping between the data Segment receives from your source, and the data Segment sends to the destination.
- Support for Amplitude’s HTTP API v2. Amplitude (Actions) is built on the latest version of Amplitude’s HTTP API.
- Revenue is a top-level property. Amplitude (Actions) elevates
revenue
to a top-level property in requests sent to Amplitude. This enables inclusion of this data in Amplitude features like customer LTV reports. - Session tracking in cloud-mode. Amplitude (Actions) supports sending session details from cloud-mode sources.
Thanks for the detailed answer @samplitude . However, I’m just curious if there’s a way to pass custom session_id in Amplitude Actions over automatically captured sessions. I noticed that in Edit Mappings under Session ID field, the mapping for it is showed like this
integrations.Actions Amplitude.session_id
At first, I assumed that similar to Legacy Destination, when we’ll pass session_id like this in our page/track call using Actions Amplitude as integration name, since this is how it’s mentioned in the above mapping and the fact that I couldn’t find it in the docs, we’ll be able to achieve the custom session on Amplitude. I tried this way but it didn’t work where as the Legacy Destination was working fine with this way. Can you clarify if there’s any possibility where we can pass custom session id to Amplitude in Amplitude Actions destination?
@samplitude I have the same question as above
However, I’m just curious if there’s a way to pass custom session_id in Amplitude Actions over automatically captured sessions. I noticed that in Edit Mappings under Session ID field, the mapping for it is showed like this
integrations.Actions Amplitude.session_id
At first, I assumed that similar to Legacy Destination, when we’ll pass session_id like this in our page/track call using Actions Amplitude as integration name, since this is how it’s mentioned in the above mapping and the fact that I couldn’t find it in the docs, we’ll be able to achieve the custom session on Amplitude. I tried this way but it didn’t work where as the Legacy Destination was working fine with this way. Can you clarify if there’s any possibility where we can pass custom session id to Amplitude in Amplitude Actions destination?
Is this possible to do in amplitude actions ? What are some of the advantages of using custom session id vs the timestamp method?
Hi @smehrin, Thanks for following up here. 😀 I’m looping in platform specialist @ning.chang who can take a closer look and get back to you.
@Jeremie Gluckman @ning.chang wondering if you could help with the below question
We are a bit at loss at how this actually works. Is this session_id in epoch time passed by amplitude?
I couldn’t see this session id in the event payload in segment until I changed the session-id settings in amplitude. Segment doesn’t have a clear answer too and this is not passed by our devs either. How does this actually work?
analytics.track({ userId: 'samplitude1234' event: 'subscription renewed', integrations: { 'Amplitude': { 'session_id': 1531845205000 // Start time of session in milliseconds since epoch } } })
Hi @smehrin @aliahmed_makeen, from what I can see, the question now is: is it possible to pass a custom session ID from Segment to Amplitude, is that correct?
You are able to set the session ID manually in cloud-mode. Here is more information on Segment & session IDs. With the custom session property you'd be able to group the events sent to Amplitude by a property, a timeout, or start/end events to track sessions. Within the Session Definitions modal, you can set your specifications for any of three conditions that will define a session in your project. You can define one condition or multiple conditions, but be aware that all conditions you specify must be met in order for Amplitude to count a session. I'd recommend using this portion of your definition:

@smehrin “Is this session_id in epoch time passed by amplitude?” are you using the client-side bundled integration? If so, our SDK will indeed automatically capture session information in the form of epoch time: https://help.amplitude.com/hc/en-us/articles/217934128#client-side-bundled-integration
We had problems with sessions not being passed to segment. We resolved this by replacing our old Analytics script snippet with the one in documentation.
https://segment.com/docs/connections/sources/catalog/libraries/website/javascript/quickstart/#step-2-add-the-segment-snippet
I assume our snippet was out of date an missing some key methods.