Go - Docs - PostHog

This library uses an internal queue to make calls fast and non-blocking. It also batches requests and flushes asynchronously, making it perfect to use in any part of your web app or other server-side application that needs performance.

Installation

go get github.com/posthog/posthog-go

Usage

package main

import (
    "os"
    "github.com/posthog/posthog-go"
)

func main() {
    client, _ := posthog.NewWithConfig(
        os.Getenv("POSTHOG_API_KEY"),
        posthog.Config{
            Endpoint:       "<ph_instance_address>",
            PersonalApiKey: "your personal API key", // needed for feature flags
        },
    )
    defer client.Close()

    // run commands
}

Making calls

Capture

Capture allows you to capture anything a user does within your system, which you can later use in PostHog to find patterns in usage, work out which features to improve, or find out where people are giving up.

A capture call requires:

distinct id which uniquely identifies your user
event name to specify the event
- We recommend naming events with "[noun][verb]", such as movie played or movie updated, in order to easily identify what your events mean later on (we know this from experience).

Optionally you can submit:

properties, which can be an array with any information you'd like to add

For example:

client.Enqueue(posthog.Capture{
  DistinctId: "test-user",
  Event:      "test-snippet",
  Properties: posthog.NewProperties().
    Set("plan", "Enterprise").
    Set("friends", 42),
})

Setting user properties

To set user properties, include the properties you'd like to set when capturing an event:

client.Enqueue(posthog.Capture{
    DistinctId: "distinct_id",
    Event:      "event_name",
    Properties: map[string]interface{}{
        "$set": map[string]interface{}{
            "name": "Max Hedgehog",
        },
        "$set_once": map[string]interface{}{
            "initial_url": "/blog",
        },
    },
})

For more details on the difference between $set and $set_once, see our user properties docs.

Alias

Sometimes, you may want to assign multiple distinct IDs to a single user. This is helpful in scenarios where your primary distinct ID may be inaccessible. For example, if a distinct ID which is typically used on the frontend is not available in certain parts of your backend code. In this case, you can use alias to assign another distinct ID to the same user.

We strongly recommend reading our docs on alias to best understand how to correctly use this method.

Sending page views

If you're aiming for a backend-only implementation of PostHog and won't be capturing events from your frontend, you can send pageviews from your backend like so:

client.Enqueue(posthog.Capture{
  DistinctId: "distinct_id",
  Event:      "$pageview",
  Properties: posthog.NewProperties().
    Set("$current_url", "https://example.com"),
})

Feature flags

Note that to use feature flags you must specify PersonalApiKey in the options passed to posthog.NewWithConfig.

How to check if a flag is enabled

Note: Whenever we face an error computing the flag, the library returns undefined, instead of true, false, or a string variant value.

// IsFeatureEnabled(FeatureFlagPayload) (interface{}, error)
isFlagEnabledForUser, err := client.IsFeatureEnabled(
        FeatureFlagPayload{
            Key:        "flag-key",
            DistinctId: "distinct-id",
        },
    )

if (isFlagEnabledForUser) {
  // Do something differently for this user
}

If your feature flag relies entirely on rollout percentage (i.e. it has no filters), isFeatureEnabled will provide a fast response, allowing it to be used in the logic for API endpoints, for example. Flags that depend on filters require a call to the PostHog API so will take longer.

Note: Whenever we face an error computing the flag, the library returns nil, instead of true or false or a string variant value.

Get a flag value

If you're using multivariate feature flags, you can also get the value of the flag, as well as whether or not it is enabled.

Note: Whenever we face an error computing the flag, the library returns None, instead of true or false or a string variant value.

// GetFeatureFlag(FeatureFlagPayload) (interface{}, error)
enabledVariant, err := client.GetFeatureFlag(
        FeatureFlagPayload{
            Key:        "multivariate-flag",
            DistinctId: "distinct-id",
        },
)

Overriding server properties

Sometimes, you might want to evaluate feature flags using properties that haven't been ingested yet, or were set incorrectly earlier. You can do so by setting properties the flag depends on with these calls.

For example, if the beta-feature depends on the is_authorized property, and you know the value of the property, you can tell PostHog to use this property, like so:

enabledVariant, err := client.GetFeatureFlag(
        FeatureFlagPayload{
            Key:        "multivariate-flag",
            DistinctId: "distinct-id",
      PersonProperties: posthog.NewProperties().
        Set("is_authorized", true),
        },
)

The same holds for groups. if you have a group name organisation, you can add properties like so:

enabledVariant, err := client.GetFeatureFlag(
        FeatureFlagPayload{
            Key:        "multivariate-flag",
            DistinctId: "distinct-id",
      Groups:          Groups{"organisation": "some-company"},
            GroupProperties: map[string]Properties{"organisation": NewProperties().Set("is_authorized", true)},
        },
)

Getting all flag values

You can also get all known flag values as well. This is useful when you want to seed a frontend client with initial known flags. Like all methods above, this also takes optional person and group properties, if known.

featureVariants, _ := client.GetAllFlags(FeatureFlagPayloadNoKey{
        DistinctId: "distinct-id",
})

Local Evaluation

Note: This feature requires version 2.0 of the library, which in turn requires a minimum PostHog version of 1.38

All feature flag evaluation requires an API request to your PostHog servers to get a response. However, where latency matters, you can evaluate flags locally. You must know all person or group properties the flag depends on.

The method call looks just like above

enabledVariant, err := client.GetFeatureFlag(
        FeatureFlagPayload{
            Key:        "multivariate-flag",
            DistinctId: "distinct-id",
      PersonProperties: posthog.NewProperties().
        Set("is_authorized", true),
        },
)

This works for getAllFlags as well. It evaluates all flags locally if possible. If even one flag isn't locally evaluable, it falls back to decide.

featureVariants, _ := client.GetAllFlags(FeatureFlagPayloadNoKey{
        DistinctId: "distinct-id",
})

Restricting evaluation to local only

Sometimes, performance might matter to you so much that you never want an HTTP request roundtrip delay when computing flags. In this case, you can set the OnlyEvaluateLocally parameter to true, which tries to compute flags only with the properties it has. If it fails to compute a flag, it returns None, instead of going to PostHog's servers to get the value.

Cohort expansion

To support feature flags that depend on cohorts locally as well, we translate the cohort definition into person properties, so that the person properties you set can be used to evaluate cohorts as well.

However, there are a few constraints here and we don't support doing this for arbitrary cohorts. Cohorts won't be evaluated locally if:

They have non-person properties
There's more than one cohort in the feature flag definition.
The cohort in the feature flag is in the same group as another condition.
The cohort has nested AND-OR filters. Only simple cohorts that have a top level OR group, and inner level ANDs will be evaluated locally.

Note that this restriction is for local evaluation only. If you're hitting PostHog's servers, all of these cohorts will be evaluated as expected. Further, posthog-node v2.6.0 onwards, and posthog-python v2.4.0 onwards do not face this issue and can evaluate all cohorts locally.

Reloading feature flags

When initializing PostHog, you can configure the interval at which feature flags are polled (fetched from the server). However, if you need to force a reload, you can use ReloadFeatureFlags:

client.ReloadFeatureFlags()

// Do something with feature flags here

Group analytics

Group analytics allows you to associate an event with a group (e.g. teams, organizations, etc.). Read the Group Analytics guide for more information.

Note: This is a paid feature and is not available on the open-source or free cloud plan. Learn more here.

Send an event associated with a group

client.Enqueue(posthog.Capture{
    DistinctId: "[distinct id]",
    Event:      "some event",
    Groups: posthog.NewGroups().
        Set("company", "42dlsfj23f").
})

Update properties on a group

client.Enqueue(posthog.GroupIdentify{
    Type: "company",
    Key:  "42dlsfj23f",
    Properties: posthog.NewProperties().
        Set("name", "Awesome Inc.").
        Set("employees", 11),
})

The name is a special property which is used in the PostHog UI for the name of the Group. If you don't specify a name property, the group ID will be used instead.

Thank you

This library is largely based on the analytics-go package.

Go

Which features are available in this library?