This is an optional library you can install if you're working with Python. It 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
pip install posthog
In your app, import the posthog
library and set your api key and host before making any calls.
from posthog import Posthog# The personal API key is necessary only if you want to use local evaluation of feature flags.posthog = Posthog('<ph_project_api_key>', host='<ph_instance_address>', personal_api_key='<ph_personal_api_key>')
You can read more about the differences between the project and personal API keys in the dedicated API authentication section of the Docs.
Note: As a general rule of thumb, we do not recommend having API keys in plaintext. Setting it as an environment variable would be best.
You can find your keys in the 'Project Settings' page in PostHog.
To debug, you can toggle debug mode on:
posthog.debug = True
And to make sure no calls happen during your tests, you can disable them, like so:
if settings.TEST:posthog.disabled = True
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 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).
Optionally you can submit:
properties
, which is a dictionary with any information you'd like to addtimestamp
, a datetime object for when the event happened. If this isn't submitted, it'll be set to the current timeuuid
, a uniqueuuid
for the event, leave blank to autogeneratesend_feature_flags
, a boolean that determines whether to send current known feature flags with this event. This is useful when running experiments which depends on this event. However, when this is set totrue
, we will make an additional request to fetch the current feature flags and thus slow things down. A workaround is to manually compute feature flag information so that we can avoid making the request.
For example:
posthog.capture('distinct id', 'movie played', {'movie_id': '123', 'category': 'romcom'})
or
posthog.capture('distinct id', event='movie played', properties={'movie_id': '123', 'category': 'romcom'}, timestamp=datetime.utcnow().replace(tzinfo=tzutc()))
Setting user properties
To set user properties, include the properties you'd like to set when capturing an event:
posthog.capture('distinct_id',event='event_name',properties={'$set': {'name': 'Max Hedgehog'},'$set_once': {'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.
Feature flags
PostHog's Feature Flags allow you to safely deploy and roll back new features.
When using them with one of libraries, you should check if a feature flag is enabled and use the result to toggle functionality on and off in you application.
How to check if a flag is enabled
Note: Whenever we face an error computing the flag, the library returns
None
, instead oftrue
,false
, or a string variant value.
posthog.feature_enabled('beta-feature', 'distinct id')# returns True or False or None
Example use case
Here's how you might send different users a different version of your homepage, for example:
def homepage(request):template = "new.html" if posthog.feature_enabled('new_ui', 'distinct id') else "old.html"return render_template(template, request=request)
Note: Feature flags are persistent for users across sessions. Read more about feature flag persistence on our dedicated page.
Get a flag value
If you're using multivariate feature flags, you can also get not just whether the flag is enabled, but what value its enabled to.
Note: Whenever we face an error computing the flag, the library returns
None
, instead oftrue
,false
, or a string variant value.
posthog.get_feature_flag('beta-feature', 'distinct id')# returns string or True or False or None
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:
posthog.get_feature_flag('beta-feature', 'distinct id', person_properties={'is_authorized': True})# returns string or None
The same holds for groups. If you have a group name organisation
, you can add properties like so:
posthog.get_feature_flag('beta-feature', 'distinct id', groups={'organisation': 'google'}, group_properties={'organisation': {'is_authorized': True})# returns string or None
Default overridden properties
Before posthog-python v3.0, we added GeoIP properties to all incoming events by default. We also used these properties for feature flag evaluation, based on the IP address of the request. This isn't ideal since they are created based on your server IP address, rather than the user's, leading to incorrect location resolution.
As of posthog-python v3.0, the default now is to disregard the server IP, not add the GeoIP properties, and not use the values for feature flag evaluations.
You can go back to previous behaviour by doing setting the disable_geoip
argument in your initialization to False
:
posthog = Posthog('api_key', disable_geoip=False)
The list of properties that this overrides:
- $geoip_city_name
- $geoip_country_name
- $geoip_country_code
- $geoip_continent_name
- $geoip_continent_code
- $geoip_postal_code
- $geoip_time_zone
You can also explicitly chose to override / not override properties for a single capture or feature flag request like so:
posthog.get_feature_flag("beta-feature", "distinct_id", disable_geoip=True|False)
posthog.capture('test id', 'test event', disable_geoip=True|False)
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.
posthog.get_all_flags('distinct id', groups={}, person_properties={'is_authorized': True}, group_properties={})# returns dict of flag key and value pairs.
Feature Flag Payloads
Payloads allow you to retrieve a value that is associated with the matched flag. The value can be a string, boolean, number, dictionary, or array. This allows for custom configurations based on values defined in the posthog app.
posthog.get_feature_flag_payload('feature-flag-key', 'distinct id')
Local Evaluation
Note: To enable local evaluation of feature flags you must also set a
personal_api_key
when configuring the integration, as described in the Installation section.
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. This is much faster, and requires two things to work:
- The library must be initialised with a personal API key
- You must know all person or group properties the flag depends on.
Then, the flag can be evaluated locally. The method signature looks exactly like above
posthog.get_feature_flag('beta-feature', 'distinct id', person_properties={'is_authorized': True})# returns string or None
Note: New feature flag definitions are polled every 30 seconds by default, which means there will be up to a 30 second delay between you changing the flag definition, and it reflecting on your servers. You can change this default on the client by setting
posthog.poll_interval = <value in seconds>
.
This works for get_all_flags
as well. It evaluates all flags locally if possible. If even one flag isn't locally evaluable, it falls back to decide.
posthog.get_all_flags('distinct id', groups={}, person_properties={'is_authorized': True}, group_properties={})# returns dict of flag key and value pairs.
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 only_evaluate_locally
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.
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.
- Capture an event and associate it with a group
posthog.capture('[distinct id]', 'some event', groups={'company': '42dlsfj23f'})
- Update properties on a group
posthog.group_identify('company', '42dlsfj23f', {'name': 'Awesome Inc.','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.
Sending page views
If you're aiming for a full back-end implementation of PostHog, you can send pageviews
from your backend
posthog.capture('distinct id', '$pageview', {'$current_url': 'https://example.com'})
Serverless environments (Render/Lambda/...)
By default, the library buffers events before sending them to the capture endpoint, for better performance. This can lead to lost events in serverless environments, if the python process is terminated by the platform before the buffer is fully flushed. To avoid this, you can either:
- ensure that
posthog.flush()
is called after processing every request, by adding a middleware to your server: this allowsposthog.capture()
to remain asynchronous for better performance. - enable the
sync_mode
option when initializing the client, so that all calls toposthog.capture()
become synchronous.
Django
For Django, you can do the initialisation of the key in the AppConfig, so that it's available everywhere.
in yourapp/apps.py
from django.apps import AppConfigimport posthogclass YourAppConfig(AppConfig):def ready(self):posthog.api_key = '<ph_project_api_key>'posthog.host = '<ph_instance_address>' # You can remove this line if you're using app.posthog.com
Then, anywhere else in your app you can do:
import posthogdef purchase(request):# example captureposthog.capture(request.user.pk, 'purchase', ...)
Integrations
Sentry
When using Sentry in Python, you can connect to PostHog in order to link Sentry errors to PostHog user profiles.
Example implementation
See the sentry_django_example
project for a complete example.
import sentry_sdkfrom sentry_sdk.integrations.django import DjangoIntegrationfrom posthog.sentry.posthog_integration import PostHogIntegrationPostHogIntegration.organization = "orgname"sentry_sdk.init(dsn="https://examplePublicKey@o0.ingest.sentry.io/0",integrations=[DjangoIntegration(), PostHogIntegration()],)# Also set `posthog_distinct_id` tagfrom sentry_sdk import configure_scopewith configure_scope() as scope:scope.set_tag('posthog_distinct_id', 'some distinct id')
Example implementation with Django
This can be made automatic in Django, by adding the following middleware and settings to settings.py
:
MIDDLEWARE = ["posthog.sentry.django.PosthogDistinctIdMiddleware"]POSTHOG_DJANGO = {"distinct_id": lambda request: request.user and request.user.distinct_id}
Alternative name
As our open source project PostHog shares the same module name, we created a special posthoganalytics
package, mostly for internal use to avoid module collision. It is the exact same.
Thank you
This library is largely based on the analytics-python
package.