Go Source

Our Go library lets you record analytics data from your Go code. The requests hit our servers, and then we route your data to any analytics service you enable on your destinations page.

This library is open-source, so you can check it out on Github.

All of our server-side libraries are built for high-performance, so you can use them in your web server controller code. This library uses a tunable buffer to batch messages, optimized for throughput and reduced network activity.

Getting Started

Install the Package

Install analytics-go via go get:

go get gopkg.in/segmentio/analytics-go.v3

Then import it and initialize an instance with your source’s Write Key. Of course, you’ll want to replace YOUR_WRITE_KEY with your actual Write Key which you can find in Segment under your source settings.

package main

import "gopkg.in/segmentio/analytics-go.v3"

func main() {
  client := analytics.New("YOUR_WRITE_KEY")

That will create a client that you can use to send data to Segment for your source.

The default initialization settings are production-ready and queue 20 messages before sending a batch request, and a 5 second interval.


identify lets you tie a user to their actions and record traits about them. It includes a unique User ID and any optional traits you know about them.

We recommend calling identify a single time when the user’s account is first created, and only identifying again later when their traits change.

Example identify call:

  UserId: "019mr8mf4r",
  Traits: analytics.NewTraits().
    SetName("Michael Bolton").
    Set("plan", "Enterprise").
    Set("friends", 42),

This call is identifying Michael by his unique User ID (the one you know him by in your database) and label him with name, email, plan and friends traits.

The identify call has the following fields:

userId StringThe ID for this user in your database.
traits Traits, optionalA dictionary of traits you know about the user. Things like: email, name or friends.

Find details on the identify method payload in our Spec.


track lets you record the actions your users perform.Every action triggers what we call an “event”, which can also have associated properties.

You’ll want to track events that are indicators of success for your site, like Signed Up, Item Purchased or Article Bookmarked.

To get started, we recommend tracking just a few important events. You can always add more later!

Example track call:

  UserId: "f4ca124298",
  Event:  "Signed Up",
  Properties: analytics.NewProperties().
    Set("plan", "Enterprise"),

This example track call tells us that your user just triggered the Signed Up event choosing the “Enterprise” plan.

track event properties can be anything you want to record. In this case, plan type.

The track call has the following fields:

event StringThe name of the event you’re tracking. We recommend human-readable names like Song Played or Status Updated.
properties Properties, optionalA dictionary of properties for the event. If the event was Product Added, it might have properties like price or product.

Find details on best practices in event naming as well as the track method payload in our Spec.


The page method lets you record page views on your website, along with optional extra information about the page being viewed.

If you’re using our client-side setup in combination with the Go library, page calls are already tracked for you by default. However, if you want to record your own page views manually and aren’t using our client-side library, read on!

Example page call:

  UserId: "f4ca124298",
  Name:   "Go Library",
  Properties: analytics.NewProperties().

The page call has the following fields:

name StringThe webpage name you’re tracking. We recommend human-readable names like Login or Register.
properties Properties, optionalA dictionary of properties for the page visit. If the page was Login, it might have properties like path or title.

Find details on the page payload in our Spec.


group lets you associate an identified user with a group. A group could be a company, organization, account, project or team! It also lets you record custom traits about the group, like industry or number of employees.

This is useful for tools like Intercom, Preact and Totango, as it ties the user to a group of other users.

Example group call:

  UserId:  "019mr8mf4r",
  GroupId: "56",
  Traits: map[string]interface{}{
    "name":        "Initech",
    "description": "Accounting Software",

The group call has the following fields:

groupId StringThe ID for this group in your database.
traits Traits, optionalA dictionary of traits you know about the group. Things like: name or website.

Find more details about group including the group payload in our Spec.


alias is how you associate one identity with another. This is an advanced method, but it is required to manage user identities successfully in some of our destinations.

In Mixpanel it’s used to associate an anonymous user with an identified user once they sign up. For KISSmetrics, if your user switches IDs, you can use ‘alias’ to rename the ‘userId’.

Example alias call:

  PreviousId: "anonymousUser",
  UserId:     "019mr8mf4r",

The alias call has the following fields:

UserId stringThe ID for this user in your database.
PreviousId stringThe previous ID to alias from.

Here’s a full example of how we might use the alias call:

// the anonymous user does actions ...
  Event:  "Anonymous Event",
  UserId: anonymousUser,

// the anonymous user signs up and is aliased
  PreviousId: anonymousUser,
  UserId:     "019mr8mf4r",

// the identified user is identified
  UserId: "019mr8mf4r",
  Traits: map[string]interface{}{
    "name":    "Michael Bolton",
    "email":   "mbolton@initech.com",
    "plan":    "Enterprise",
    "friends": 42,

// the identified user does actions ...
  Event:      "Item Viewed",
  UserId:     "019mr8mf4r",
  Properties: map[string]interface{}{
    "item": "lamp",

For more details about alias, including the alias call payload, check out our Spec.

Development Settings

You can use the BatchSize field of your configuration to 1 during development to make the library flush every time a message is submitted, so that you can be sure your calls are working properly.

func main() {
  client, _ := analytics.NewWithConfig("YOUR_WRITE_KEY", analytics.Config{
        BatchSize: 1,


The Verbose field of your configuration controls the level of logging, while the Logger field provides a hook to capture the log output:

func main() {
  client, _ := analytics.NewWithConfig("YOUR_WRITE_KEY", analytics.Config{
        Verbose: true,
        Logger:  analytics.StdLogger(log.New(os.Stderr, "segment ", log.LstdFlags)),

Selecting Destinations

The alias, group, identify, page and track calls can all be passed an object of context.integrations that lets you turn certain integrations on or off. By default all destinations are enabled.

Here’s an example track call with the context.integrations object shown.

  Event:  "Membership Upgraded",
  UserId: "019mr8mf4r",
  Integrations: map[string]interface{}{
    "All":      false,
    "Mixpanel": true,

In this case, we’re specifying that we want this Track to only go to Vero. All: false says that no destination should be enabled unless otherwise specified. Vero: true turns on Vero, etc.

Destination flags are case sensitive and match the destination’s name in the docs (i.e. “AdLearn Open Platform”, “awe.sm”, “MailChimp”, etc.).


  • Available at the business level, filtering track calls can be done right from the Segment UI on your source schema page. We recommend using the UI if possible since it’s a much simpler way of managing your filters and can be updated with no code changes on your side.

  • If you are on a grandfathered plan, events sent server-side that are filtered through the Segment dashboard will still count towards your API usage.

Historical Import

You can import historical data by adding the timestamp argument to any of your method calls. This can be helpful if you’ve just switched to Segment.

Historical imports can only be done into destinations that can accept historical timestamp’ed data. Most analytics tools like Mixpanel, Amplitude, Kissmetrics, etc. can handle that type of data just fine. One common destination that does not accept historical data is Google Analytics since their API cannot accept historical data.

Note: If you’re tracking things that are happening right now, leave out the timestamp and our servers will timestamp the requests for you.


Our libraries are built to support high performance environments. That means it is safe to use analytics-go on a web server that’s serving hundreds of requests per second.

Every method you call does not result in an HTTP request, but is queued in memory instead. Messages are flushed in batch in the background, which allows for much faster operation.

By default, our library will flush:

  • every 20 messages (control with FlushAt)
  • if 5 seconds has passed since the last flush (control with FlushAfter)

There is a maximum of 500kb per batch request and 15kb per call.

Sometimes you might not want batching (eg. when debugging, or in short-lived programs). You can turn off batching by setting the FlushAt argument to 1, and your requests will always be sent right away.


If you hate defaults you can configure analytics-go has a lot of configuration options. You can read more in the Godocs.

Version 2 (Deprecated)

If you’re looking for documentation for the v2 version of the library, click here.

Migrating from v2

v3 is a rewrite of our v2 version of the Go Library. We recommend using v3 as it supports many new features, has significant design improvements and is better tested.

v3 is currently in the v3.0 branch to minimize breaking changes for customers not using a package manager. You can refer to the documentation for your package manager to see how to use the v3.0 branch.

e.g. with govendor, you would run the command:

govendor fetch github.com/segmentio/analytics-go@v3.0

Alternatively, you can also use gopkg.in. First run go get gopkg.in/segmentio/analytics-go.v3 and replace your imports with import "gopkg.in/segmentio/analytics-go.v3".

To help with migrating your code, we recommend checking out a simple example that we’ve written in v2 and v3 so you can easily see the differences.

The first difference you’ll notice is that Client is now an interface. It has a single method - Enqueue that can accept messages of all types.

track := analytics.Track{
  Event:  "Download",
  UserId: "123456",
  Properties: map[string]interface{}{
    "application": "Segment Desktop",
    "version":     "1.1.0",
    "platform":    "osx",

// in v2, you would call the `Track` method with a `Track` struct.

// in v3, you would call the `Enqueue` method with a `Track` struct.
// Note that a pointer is not used here.

Secondly, you’ll notice that there are new types such as analytics.Properties and analytics.Traits. These can be used to replace map[string]interface{}. They provide type safety and reduce the chance of accidentally sending fields that are named incorrectly.

For instance, the following two examples are functionally equivalent in v3.

  UserId: "f4ca124298",
  Event:  "Signed Up",
  Properties: analytics.NewProperties().
    Set("application", "Segment Desktop"),
  UserId: "f4ca124298",
  Event:  "Signed Up",
  Properties: map[string]interface{}{
    "category": "Segment Desktop",
    "application": "Segment Desktop",

Lastly, you’ll notice that configuration is provided during initialization and cannot be changed after initialization. The various configuration options are documented in the GoDocs.

These are examples of applying same configuration options in v2 and v3.

// Example in v2:
client := analytics.New("h97jamjwbh")
client.Interval = 30 * time.Second
client.Verbose = true
client.Size = 100

// Example in v3:
client, _ := analytics.NewWithConfig("h97jamjwbh", analytics.Config{
  Interval:  30 * time.Second,
  BatchSize: 100,
  Verbose:   true,

What’s new in v3

v3 is a rewrite of our v2 version of the Go Library with many new features!

  • New type safe API to set properties, traits and context fields. This is less error prone than using the map[string]interface{} type (though you can still do so).
  UserId: "f4ca124298",
  Event:  "Signed Up",
  Properties: analytics.NewProperties().
  • Dynamically split batches into appropriately sized chunks to meet our API size limits. Previously you would have to calculate the batch size depending on this size of your data to figure out the appropriate size.

  • Improved logging abstraction. Previously we relied solely on the standard library log.Logger type which cannot distinguish between error and non-error logs. v3 has it’s own Logger interface that can be used to capture errors for your own reporting purposes. An adapter for the standard library logger is also included.

  • Ability to configure the retry policy based on the number of attempts.

client, _ := analytics.NewWithConfig("h97jamjwbh", analytics.Config{
  RetryAfter: func(attempt int) time.Duration {
    return time.Duration(attempt * 10)
  • Configurable default context on all messages.
client, _ := analytics.NewWithConfig("h97jamjwbh", analytics.Config{
  DefaultContext: &analytics.Context{
    App: analytics.AppInfo{
      Name:    "myapp",
      Version: "myappversion",


If you’re having trouble we have a few tips that help common problems.

No events in my debugger

  1. Double check that you’ve followed all the steps in the Quickstart.

  2. Make sure that you’re calling one of our API methods once the library is successfully installed—identify, track, etc.

No events in my end tools

  1. Double check your credentials for that destination.

  2. Make sure that the destination you are troubleshooting can accept server-side API calls. Compatibility is shown on the destination docs pages and on the sheets on your Segment source Destinations page.

  3. Check out the destination’s documentation to see if there are other requirements for using the method and destination you’re trying to get working.

If you have any questions or see anywhere we can improve our documentation, please let us know or kick off a conversation in the Segment Community!