Spec: Track

The Track API call is how you record any actions your users perform, along with any properties that describe the action.

Each action is known as an event. Each event has a name, like User Registered, and properties. For example, a User Registered event might have properties like plan or accountType. Calling Track in one of our sources is one of the first steps to getting started with Segment.

Here’s the payload of a typical Track call with most common fields removed:

{
  "type": "track",
  "event": "User Registered",
  "properties": {
    "plan": "Pro Annual",
    "accountType" : "Facebook"
  }
}

And here’s the corresponding JavaScript event that would generate the above payload:

analytics.track("User Registered", {
  plan: "Pro Annual",
  accountType: "Facebook"
});

Beyond the common fields, the Track call has the following fields:

Example

Here’s a complete example of a Track call:

{
  "anonymousId": "23adfd82-aa0f-45a7-a756-24f2a7a4c895",
  "context": {
    "library": {
      "name": "analytics.js",
      "version": "2.11.1"
    },
    "page": {
      "path": "/academy/",
      "referrer": "",
      "search": "",
      "title": "Analytics Academy",
      "url": "https://segment.com/academy/"
    },
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36",
    "ip": "108.0.78.21"
  },
  "event": "Course Clicked",
  "integrations": {},
  "messageId": "ajs-f8ca1e4de5024d9430b3928bd8ac6b96",
  "properties": {
    "title": "Intro to Analytics"
  },
  "receivedAt": "2015-12-12T19:11:01.266Z",
  "sentAt": "2015-12-12T19:11:01.169Z",
  "timestamp": "2015-12-12T19:11:01.249Z",
  "type": "track",
  "userId": "AiUGstSDIg",
  "originalTimestamp": "2015-12-12T19:11:01.152Z"
}

Create your own Track call

Use the following interactive code pen to see what your Track calls look like with user-provided information:

Sample output goes here!

Identities

The User ID is a unique identifier for the user performing the actions. Check out the User ID docs for more detail.

The Anonymous ID can be any pseudo-unique identifier, for cases where you don’t know who the user is, but you still want to tie them to an event. Check out the Anonymous ID docs for more detail.

Note: In our browser and mobile libraries a User ID is automatically added from the state stored by a previous identify call, so you do not need to add it yourself. They will also automatically handle Anonymous IDs under the covers.

Event

Every Track call records a single user action. Segment calls these “events”, and recommend that you make your event names human-readable, so that everyone on your team (even you, after all that caffeine) can know what they mean instantly.

Don’t use nondescript names like Event 12 or TMDropd. Instead, use unique but recognizable names like Video Recorded and Order Completed.

Segment recommends event names built from a noun and past-tense verb. For more information about best practices in event naming, check out Segment’s Analytics Academy lesson on best practices for naming conventions for clean data.

Segment has standardized a series of reserved event names that have special semantic meaning. We map these events to tools that support them whenever possible. See the Semantic Events docs for more detail.

Properties

Properties are extra pieces of information you can tie to events you track. They can be anything that will be useful while analyzing the events later. Segment recommends sending properties whenever possible because they give you a more complete picture of what your users are doing.

Segment has reserved some properties that have semantic meanings, and handle them in special ways. For example, we always expect revenue to be a dollar amount that we send to tools that handle revenue tracking.

You should only use reserved properties for their intended meaning.

The following are all of the reserved properties Segment has standardized that apply to all events. Check out the Semantic Events docs for properties specific to individual reserved events.

Note: You might be used to some destinations recognizing special properties differently. For example, Mixpanel has a special track_charges method for accepting revenue. Luckily, you don’t have to worry about those inconsistencies. Just pass along revenue. Segment will handle all of the destination-specific conversions for you automatically. Same goes for the rest of the reserved properties.

Sending Traits in a Track Call - Destination Actions

All events have the ability to include additional event data in the context object. There may be instances when your team may want to include user traits or group traits in a Track event, such as having a single event trigger multiple events in an Actions destination. Since user Traits are not standard fields for a Track event, in order to do this, you’ll need to explicitely pass the user’s traits into the event payload’s context.traits object. For instructions on how to pass fields to the context object for a specific library, please see the related library’s Source documentation.

Segment’s Actions destinations allows your team to build individual actions that are triggered based on a set of configured conditions. By adding the user’s latest traits to the Track event’s context.traits object, its possible to build two separate Actions to be triggered by this single event. For example, if your team would like to send an Identify event anytime the specific Track event “Button Clicked” is triggered, simply add the available traits into the Track event’s payload, then build a destination Actions for the Track event : Event Name is Button Clicked, and a destination Action for the Identify event : All of the following conditions are true: Event Name is Button Clicked, Event Context traits exists, and then both Actions will have access to reference the context.traits fields within its mappings.

For more information on the context object, please see the Spec: Common Fields documentation.

If the Example Payload shared above is modified as the event Button Clicked with "username": "testing-123" in the context.traits object, then the event’s payload would be :

{
  "anonymousId": "23adfd82-aa0f-45a7-a756-24f2a7a4c895",
  "context": {
    "library": {
      "name": "analytics.js",
      "version": "2.11.1"
    },
    "page": {
      "path": "/academy/",
      "referrer": "",
      "search": "",
      "title": "Analytics Academy",
      "url": "https://segment.com/academy/"
    },
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36",
    "ip": "108.0.78.21",
    "traits": {
      "username": "testing-123"
    }
  },
  "event": "Button Clicked",
  "integrations": {},
  "messageId": "ajs-f8ca1e4de5024d9430b3928bd8ac6b96",
  "properties": {
    "title": "Intro to Analytics"
  },
  "receivedAt": "2015-12-12T19:11:01.266Z",
  "sentAt": "2015-12-12T19:11:01.169Z",
  "timestamp": "2015-12-12T19:11:01.249Z",
  "type": "track",
  "userId": "AiUGstSDIg",
  "originalTimestamp": "2015-12-12T19:11:01.152Z"
}

Here’s what that Identify Action would look like :

Context

Context is a dictionary of extra information that provides useful context about a datapoint, for example the user’s ip address or locale. You should only use Context fields for their intended meaning.