1

Passing user's timezone information to downstream services

Hi all,

For some of our users we happen to know which timezone our users are in. We store this information in our database, in the traditional tzdata format. For example: 

America/Los_Angeles

We have certain downstream services (e.g. email automation using Vero).  We would like to be able to pass our user's preferred timezone so that these downstream services can use it. We are triggering identify and track calls from our server-side implementation.  I know Segment's JS library is tracking timezone, which seems to similarly be passing around tzdata.  I noticed it on this:
https://segment.com/docs/spec/common/

Questions:

1. From server-side, how are we supposed to pass timezone?  

     A. Can we pass timezone key with an identify call?  Similarly, does it live within the context key? For example:

{
    "userId": 123,
    "traits": {...},
    "context": {
        "timezone": "America/Los_Angeles"
    }
}

    B. If not, do we need to pass the user's timezone for every single track call?  Similarly, does it live within the context key? For example:

{
  "userId": 123,
  "event": "Event Name",
  "properties": {...},
  "context": {
      "timezone": "America/Los_Angeles"
  }
}

2. We really only want to be passing the user's timezone as additional context about the user, but is there any concerns we should be aware of (at least from Segment's point of view) if we set the timezone from server side?  

 

Thanks in advance,

Jesse

7replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Hi Jesse Forrest - thanks for reaching out! The timezone will be automatically picked up for certain libraries (as detailed here); in all other cases the timezone will default to UTC. As you are sending data server-side you can manually set the timezone in any call so long as you comply with the common spec structure; however we generally recommend that you instead change the timezone inside the destination tool you are using as they typically have a way to let you set that with their UI. Hope this info helps!
    Cheers,
    James

    Reply Upvote
  • James McGuinness : Thanks for the response. Is it possible to dig a little deeper into each question, just so we are on the same page.

    Regarding Question 1A:

    From your response, it sounds like we can pass timezone with identify calls. Can you just verify that the example I posted, with timezone inside context is correct too (for both identify and track calls)?

    Regarding Question 1B:

    Your response says that we can be setting timezone data "in any call".  I'm assuming you are referring to both an identify and track calls.  I'm a little confused though in how downstream services are supposed to be using this information.  I would have assumed that timezone would only be set for identify calls to showcase the preferred timezone of that user.  I guess I could see a situation where we would set the timezone for track calls to showcase the preferred timezone at the time the event was fired.  However, this could be misleading, since I could also see another possibility where we attempt to store the timezone that the event was triggered in (e.g. someone is on travel and triggered the event in a different time zone than their normal time zone).  Am I completely misunderstanding the purpose of this timezone parameter? To simplify the confusion, can Segment clarify what timezone means in the context of both an identify call and a track call. 

    Regarding Question 2:
    It's very possible that I'm misinterpreting the usage of the timezone parameter.  I am assuming it's a way to tell downstream services what the user's preferred timezone is (assuming we set it in an identify call).  If I'm understanding it correctly why would Segment "generally recommend that you instead change the timezone inside the destination tool you are using as they typically have a way to let you set that with their UI". That seems to be against Segment's primary benefit, where we send the data once to Segment and have Segment notify all downstream services.  If we take a very specific use case, which is ours, where we need to tell Vero what timezone our users are in so that we can properly send out automation at the right times, are you recommending we either A) manually set it for each of our users using their UI or B) see if they have an API that we can leverage to set a user's timezone.  Neither one of those seems like a viable solution.

    I hope my feedback didn't seem harsh, just trying to make sense of things.

    Thanks in advance,

    Jesse

    Reply Upvote
  • Segment / James McGuinness : Bump ^

    Reply Upvote
  • James McGuinness : I just submitted a tech support ticket due to lack of response.

    Reply Upvote
  • Thank you Spencer, from Segment, for responding to a direct Segment ticket.  Here is his response for those interested.  I will try to get him to reply here so that others can get value from it.  I will also respond beneath it so that him & Vero can see my reply.

    ----

    Hi Jesse,

    I'm so sorry that no further progress was made on your question in the Community Forum. Reaching out directly in this way is actually the best way to get in touch with us. I'd be happy to continue working with you here if that's ok with you.

    As a general note in regards to your questions, Segment's platform is meant to route data to hundreds of different integrations. We've built out the infrastructure to connect to our partner platforms so that you don't have to. Each integration uses the data which is sent to it in a different way based on its functionality. As that is the case, there are some nuances in terms of sending certain properties to specific destinations.

    Correct me if I'm wrong, but you're interested in sending the timezone property to Vero server-side. Is that right?

    I've tested this out on my end and it appears that Vero accepts that attribute in the `traits` object of an Identify call.

    Here is the test call I sent:

    analytics.identify({
      userId: '123456789',
      traits: {
        name: 'Test User 1',
        email: 'test1@user.com',
        timezone: 'America/Los_Angeles'
    
      }
    });
    


    Here is the JSON payload from the Segment debugger for your reference:

    {
      "context": {
        "library": {
          "name": "analytics-node",
          "version": "3.3.0"
        }
      },
      "messageId": "node-b702f0c608e226c44812b89373236058-c75422ed-25f9-428f-9003-5223a2f1d62d",
      "timestamp": "2019-02-11T20:21:09.283Z",
      "traits": {
        "email": "test1@user.com",
        "name": "Test User 1",
        "timezone": "America/Los_Angeles"
      },
      "type": "identify",
      "userId": "123456789",
      "writeKey": "iFMJiiv5CFwUopVPL6cNojgpFyv9CORp",
      "receivedAt": "2019-02-11T20:21:09.283Z",
      "sentAt": "2019-02-11T20:21:08.542Z",
      "integrations": {},
      "originalTimestamp": "2019-02-11T20:21:08.542Z"
    }


    Sending that call created a user in Vero with the `timezone` property:

    I was not able to populate that `timezone` field using a Track call.

    Is that what you were interested in knowing? Please let me know if I'm off base!

    I believe what James was referring to was in regards to our general Spec. The `timezone` field would typically be sent within the `context` object, but as I said, some properties are nuanced based on the API requirements of our partner integrations.

    Please let me know if you have any additional questions or if I can help with anything else.

    Best,
    Spencer
    Success Engineer | Segment

    Reply Upvote
  • Spencer, thank you for responding.  

    You have tried to answer question 1A by doing an identify call and seeing what shows up in a downstream service, but couldn't your results have been misleading? What did you expect to see in Vero? I could do an identify call with a trait named "foo" and I would also see that show up in Vero.  Question 1A, to be crystal clear is:
    How does segment recommend passing timezone data to downstream services?

    If you say that it should be a "timezone" trait in an identify call, then perfect, question answered. If so, I would recommend that Segment updates it's documentation for all to understand.

    I still feel like the responses from Segment have been pretty vague around how & what the timezone field is for.  I tried my best to document my confusion in the questions.  If there is any way you can try to help provide some more clarity, especially around 1B, I would really appreciate it.

    Thanks,

    Jesse

    Reply Upvote
  • Hi Jesse, 

     

    I apologize that we haven't yet reached the answers you're looking for. I'm more than happy to continue working with you until we get to the bottom of what you're interested in.

     

    There are several context fields which are collected automatically via some of our client-side capable libraries. You can get a full picture of these and what each field is expected to contain here. The `timezone` field is gathered in this way through our analytics-ios and analytics-android libraries. When this happens, those fields are set to tzdata strings as can be found here. When data is sent server-side, much less is collected automatically as the server generally doesn't have ready access to contextual data. I don't believe there are many fields in any of our libraries which are strict about what values are supplied to them outside of timestamp fields. For server-side events especially, there would be no way for our processes to determine the accuracy of what is sent as there generally is no server-side access to much in terms of additional context. You're more or less welcome to send whatever data value would be most useful to you downstream. As our destinations have widely varying expectations in terms of what will be supplied to them, this works out rather well in practice. For example, perhaps Google Analytics expects a tzdata string as a `timezone` and Amplitude expects a country code. We need to make sure we can accommodate both cases. I did a little digging and it appears that Vero is actually looking for an integer value there as per their documentation

     

    To summarize, you're able to send whatever makes the most sense for the destination you're routing data to. Does that align with what you're interested in knowing? I'd be happy to go down a different track if you have other questions or if I'm off base in terms of what you're asking.

     

    I think this concept is a bit tricky because it has to be fairly open-ended in order for us to be able to route data to such a wide variety of tools. 

     

    In terms of what the `timezone` field means for destinations, that also truly depends on the integration you're using. I am not an expert in Vero so I'm not sure how they use it specifically, but if you'd like to loop someone in from their team I'm sure they can speak to its use in their tool. 

     

    As for whether you should you should use a Track or an Identify call to send `timezone` data, that is again subject to destination and how certain end tools interpret and present that data. Integration code is written for each destination so that our methods and the fields sent with them will map to what the destinations' APIs expect. Some need certain fields to be sent with Track calls while others pull the same data fields only from Identify calls. It truly depends. 

     

    I'd like to amend what I said previously about Vero not being able to accept `timezone` on a Track call, I actually was able to do that. I'm not sure how I missed it. My apologies! 
     

    I hope there was some useful information in this response, but again please don't hesitate to let me know if I'm misunderstanding! I don't mean to be vague, there just happens to be a lot of room for folks to send what they need to make the most of their data in their downstream tools.

     

    Best,
    Spencer
    Success Engineer | Segment

    Reply Upvote