Using Segment to capture diffs or other unstructured updates

Hi, we run a platform where users have the ability to edit content in a variety of ways. A basic example is maintaining their company's profile page. Some of this information is used in the user's identify call, but not all of it. Either way, we'd like to be able to capture when they make an update to that page and what content they updated, including what the old value was and what the new value is. 

Has anyone used Segment to capture event data like this? If so, any suggestions on how to structure the track call? 

5replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Hey there Marc, thanks for posting! Really interesting use-case and no, I cannot say that we've come across customers using Segment for this type of tracking.

    I would say that it's probably best to capture what is being changed via .track() calls. Perhaps something along the lines of:

    //store any changed attributes in varibales, such as oldCompanyName, newCompanyName, etc ???
    // on change handler calls analytics.track along the lines of:
    analytics.track('Updated Company Profile', {
      oldCompanyName: oldCompanyName,
      newCompanyName: newCompanyName,
    // repeat key-value pairs for any other attributes that were changed


    I'm not really sure what you analytics goals are and what downstream tools / Segment destinations you will use to study this data, but I would say you should carefully parse through our Analytics Academy article on .track() calls.


    Besides this, please bear in mind that different destinations will treat nested objects differently (as mentioned in that article). So, instead of breaking down separate company attributes that were changed into individual keys, like in the code from my example above - you could say:

    analytics.track('Updated Company Profile', {
      oldCompanyProperties: oldCompanyProperties,
      newCompanyProperties, newCompanyProperties,

    , with the oldCompanyProperties and newCompanyProperties being nested objects in themselves - but this may not work the way you want it to. 


    I would also recommend testing in a development and staging environment!


    I hope this is somewhat helpful! Let us know how it goes.

    Reply Upvote 1
  • Thanks Illya Yanchuk ! 

    I think we're going to proceed with it as you described in the first example, with the only change being that the new/old descriptor will append the property rather than prepend it to keep them better grouped (ie: companyNameNew/companyNameOld rather than newCompanyName/oldCompanyName)

    The example of a profile was a more generic one (and easier to describe in my initial post) than our actual primary intended use case. Our platform is a marketplace and we want to understand how often sellers are modifying their listings and what attributes are most frequently modified. We'd also like the ability for Client Services to keep up to date on any changes and see what those changes were, as we don't have any versioning of these listings, and updates are currently made directly to the database. 

    We may still pursue more complete versioning in the future, but this is a much faster implementation that delivers most of the functionality that we'd be looking for initially. 

    As for analytics, we do most of our analysis out of a PostgreSQL destination. 

    Reply Upvote
  • hey Marc - thanks for replying! Cool! Happy my advise was at least somewhat helpful. Don't forget, as always - we encourage testing! 


    Since you're just getting started, I would also like to strongly encourage you to invest the (small amount of) time to parse through our Analytics Academy and various guides (especially the one about identifying users), as well as read through our Spec docs (if you haven't done so already). 


    This will really set you up for success in tracking through Segment, and in my experience of helping customers - will go a long way to making your analytics and tracking life much easier down the line.


    It's better to get that in now and pay it forward, before you incur any "analytics tech debt," if that makes sense.


    Hope this helps! Happy tracking. Should you ever have more specific questions, feel free to submit a support ticket via our contact form here.

    Reply Upvote
  • In case it's helpful for anyone else, I wanted to give an update on how we've decided to implement this. Rather than including new/old values directly within the Segment event, we're going to just have a Segment event indicating the action took place, and we're going to do versioning in a PostgreSQL database with the object stored in JSON. The Segment events will serve as an indicator that the action took place, but the actual actions within the event will be stored elsewhere. 

    Reply Upvote 2
  • Marc, awesome! Thanks for sharing. Honestly - sounds like a much cleaner way to do this. The previous approach could have really created some less than ideal effects in your downstream destinations.

    Great work, and we really appreciate you following up on here. With so many vastly different use cases, it really helps us build a good knowledge base and community with customers like you!

    Happy tracking!

    Reply Upvote