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 mainimport ("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 userevent name
to specify the event- We recommend naming events with "[noun][verb]", such as
movie played
ormovie updated
, in order to easily identify what your events mean later on (we know this from experience).
- We recommend naming events with "[noun][verb]", such as
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 via an event
To set properties on your users via an event, you can leverage the event properties $set
and $set_once
.
$set
Example
client.Enqueue(posthog.Capture{DistinctId: "test-user",Event: "test-snippet",Properties: map[string]interface{}{"eventProp": "value1","$set": map[string]interface{}{"userProp": "value2",},}})
Usage
When capturing an event, you can pass a property called $set
as an event property, and specify its value to be an object with properties to be set on the user that will be associated with the user who triggered the event.
$set_once
Example
client.Enqueue(posthog.Capture{DistinctId: "test-user",Event: "test-snippet",Properties: map[string]interface{}{"eventProp": "value1","$set_once": map[string]interface{}{"userProp": "value2",},}})
Usage
$set_once
works just like $set
, except that it will only set the property if the user doesn't already have that property set.
Identify
We highly recommend reading our section on Identifying users to better understand how to correctly use this method.
Identify lets you add metadata to your users so you can easily identify who they are in PostHog, as well as do things like segment users by these properties.
An identify call requires:
distinct id
which uniquely identifies your userproperties
with a dictionary of any key:value pairs you'd like to add
For example:
client.Enqueue(posthog.Identify{DistinctId: "user:123",Properties: posthog.NewProperties().Set("email", "john@doe.com").Set("proUser", false),})
The most obvious place to make this call is whenever a user signs up, or when they update their information.
Alias
To connect whatever a user does before they sign up or login with what they do after, you need to make an alias call. This will allow you to answer questions like "Which marketing channels lead to users churning after a month?" or "What do users do on our website before signing up?"
In a purely back-end implementation, this means whenever an anonymous user does something, you'll want to send a session ID with the capture call. Then, when that users signs up, you want to do an alias call with the session ID and the newly created user ID.
The same concept applies for when a user logs in.
If you're using PostHog in the front-end and back-end, doing the identify call in the frontend will be enough.
An alias call requires
DistinctId
– the current unique id (logged in user id)Alias
– the other distinct ID of the user, which will be aliased to the current one
For example:
client.Enqueue(posthog.Alias{DistinctId: "user:123",Alias: "session:12345",})
Sending page views
If you're aiming for a full back-end implementation of PostHog, you can send page views from your backend, like so:
client.Enqueue(posthog.Capture{DistinctId: "test-user",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 toposthog.NewWithConfig
.
How to check if a flag is enabled
Note: Whenever we face an error computing the flag, the library returns
undefined
, instead oftrue
,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 oftrue
orfalse
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 oftrue
orfalse
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.
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
PostHog 1.31.0 introduced support for group analytics, which allows you to associate users and events with larger groups (teams, organizations, etc.). This feature requires the latest version of posthog-go
Note: This is a paid feature and is not available on the open-source or free cloud plan. Learn more here.
- Capture an event and associate it with a group
client.Enqueue(posthog.Capture{DistinctId: "[distinct id]",Event: "some event",Groups: posthog.NewGroups().Set("company", "id:5").})
- Update properties on a group
client.Enqueue(posthog.GroupIdentify{Type: "company",Key: "id:5",Properties: posthog.NewProperties().Set("company_name", "Awesome Inc").Set("employees", 11),})
Thank you
This library is largely based on the analytics-go
package.