Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions contents/docs/feature-flags/best-practices.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -26,12 +26,14 @@ function useBetaFeature() {
}
```

## 3. Identify users
## 3. Identify users (or target by device for anonymous users)

Because PostHog evaluates flags based on the user's distinct ID, having different IDs can cause the same user to receive different flag values across different sessions, devices, and platforms. By [identifying](/docs/getting-started/identify-users) them, you can ensure they consistent flag values.
Because PostHog evaluates flags based on the user's distinct ID, having different IDs can cause the same user to receive different flag values across different sessions, devices, and platforms. By [identifying](/docs/getting-started/identify-users) them, you can ensure consistent flag values.

The same applies to identifying [groups](/docs/product-analytics/group-analytics) for group-level flags.

For flags targeting anonymous users — such as signup flows or landing page experiments — consider using [device targeting](/docs/feature-flags/targeting-groups#targeting-by-device) instead. This evaluates the flag based on the device ID, ensuring a consistent experience on the device even after the user logs in.

## 4. Use server-side local evaluation for faster flags

Evaluating feature flags requires making a request to PostHog for each flag. However, you can improve performance by evaluating flags locally. Instead of making a request for each flag, PostHog will periodically request and store feature flag definitions locally, enabling you to evaluate flags without making additional requests.
Expand Down
2 changes: 1 addition & 1 deletion contents/docs/feature-flags/canary-release.md
Original file line number Diff line number Diff line change
Expand Up @@ -70,7 +70,7 @@ Canary releases ensure higher quality features get shipped and fewer issues impa

## Further reading

- [Targeting feature flags on groups, pages, machines, and more](/docs/feature-flags/targeting-groups)
- [Targeting feature flags on devices, groups, pages, machines, and more](/docs/feature-flags/targeting-groups)
- [How to bootstrap feature flags in React and Express](/tutorials/bootstrap-feature-flags-react)
- [How to evaluate and update feature flags with the PostHog API](/tutorials/api-feature-flags)

Expand Down
8 changes: 8 additions & 0 deletions contents/docs/feature-flags/creating-feature-flags.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -80,6 +80,12 @@ This specifies the conditions a user must meet to access the feature flag and re

Condition sets are evaluated from **top to bottom**, and the **first** condition set that matches will be used. A condition matches when all property filters pass and the target falls within the rollout percentage.

By default, release conditions **match by user**, meaning the flag is evaluated based on the user's distinct ID. You can change this using the **Match by** dropdown:

- **User** (default) – Evaluates based on the user's distinct ID. Best for in-app features targeting logged-in users.
- **Device** – Evaluates based on the device ID. Best for flags targeting anonymous users, as it ensures a consistent experience on the device even after the user logs in. See [targeting by device](/docs/feature-flags/targeting-groups#targeting-by-device) for more details.
- **Group** (requires [group analytics](/docs/product-analytics/group-analytics)) – Evaluates based on a group key (e.g., company, team, or organization). See [targeting groups](/docs/feature-flags/targeting-groups#targeting-groups-teams-or-organizations) for more details.

Percentage rollouts are available for all flags. More options depend on your PostHog setup:

- If GeoIP is enabled, you can target based on geographic location.
Expand Down Expand Up @@ -151,6 +157,8 @@ Feature flag values are calculated based on a user's properties. Since it's poss

By enabling the option to persist feature flags across authentication, you ensure that the flag value remains the same.

> **Tip:** If your flag targets anonymous users and you just need the flag value to stay consistent through the login flow on the same device, consider using [device targeting](/docs/feature-flags/targeting-groups#targeting-by-device) instead. It achieves this without the performance tradeoffs below.

> **Note:** This feature requires `person_profiles: 'always'` and calling `posthog.identify` from the JavaScript Web SDK to function as expected. [Learn more about anonymous vs identified events here](/docs/data/anonymous-vs-identified-events).

In our experience, the tradeoffs to enabling this are **not** worthwhile for the majority of our users. They include:
Expand Down
29 changes: 27 additions & 2 deletions contents/docs/feature-flags/targeting-groups.md
Original file line number Diff line number Diff line change
@@ -1,13 +1,38 @@
---
title: 'Targeting feature flags on groups, pages, machines, and more'
title: Targeting feature flags on devices, groups, pages, machines, and more
showTitle: true
sidebar: Docs
---

To decide what value to return, PostHog’s feature flag service uses a flag key and an entity. Which entity to use it up to you, and these don't necessarily need to be _users_ – you can also target organizations, pages, machines, and more.
To decide what value to return, PostHog’s feature flag service uses a flag key and an entity. Which entity to use is up to you, and these dont necessarily need to be _users_ – you can also target devices, organizations, pages, machines, and more.

This tutorial shows you how to target these non-user entities in your use of feature flags.

## Targeting by device

By default, feature flags match by **user**, meaning the flag is evaluated based on the user’s distinct ID. This works well for in-app features where users are logged in.

For flags that target anonymous users — such as landing page experiments, onboarding flows, or signup forms — matching by **device** is often a better choice. When you match by device, PostHog uses the device ID (rather than the user’s distinct ID) to determine the flag value. This ensures a consistent experience on the device, even after the user logs in.

To target by device, change the **Match by** value under **Release conditions** to **Device** when creating or editing your feature flag.

### When to use device targeting

- **Anonymous user experiences:** If a user sees a new signup flow before logging in, matching by device ensures they continue seeing the same variant after they create an account and log in.
- **Pre-authentication features:** Landing pages, pricing pages, or other features shown before a user is identified.
- **Experiments on anonymous traffic:** When running A/B tests on pages visited by both anonymous and logged-in users, device targeting prevents users from switching variants mid-experiment.

### How it differs from user targeting

| | Match by user | Match by device |
|---|---|---|
| **Evaluation basis** | User’s distinct ID | Device ID |
| **Best for** | Logged-in, identified users | Anonymous or pre-login experiences |
| **Consistent across login** | May change if distinct ID changes | Stays consistent on the same device |
| **Cross-device consistency** | Yes, if user is identified | No, each device is evaluated independently |

> **Note:** Device targeting is a simpler alternative to [persisting flags across authentication steps](/docs/feature-flags/creating-feature-flags#persisting-feature-flags-across-authentication-steps-optional). If your flag only needs to be consistent on the same device through the login flow, device targeting achieves this without the performance tradeoffs of flag persistence.

## Targeting groups, teams, or organizations

If you enabled [group analytics](/docs/product-analytics/group-analytics) and set up group idenitifcation, targeting by groups, teams, or organizations is easy. When creating your feature flag, change the "Match by" value under "Release conditions" your group type name, add any conditions you want, and roll out the flag.
Expand Down
2 changes: 1 addition & 1 deletion contents/docs/feature-flags/tutorials.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ showTitle: true
---
Got a question which isn't answered below? Head to [the community forum](/questions) to let us know!

- [How to target flags with groups, pages, machines, and more](/docs/feature-flags/targeting-groups)
- [How to target flags with devices, groups, pages, machines, and more](/docs/feature-flags/targeting-groups)
- [How to set up one-time feature flags](/tutorials/one-time-feature-flags)
- [How to create sticky feature flags](/tutorials/sticky-feature-flags)
- [How to do a canary release with feature flags](/docs/feature-flags/canary-release)
Expand Down
2 changes: 1 addition & 1 deletion src/navs/index.js
Original file line number Diff line number Diff line change
Expand Up @@ -3813,7 +3813,7 @@ export const docsMenu = {
featured: true,
},
{
name: 'Target flags with groups',
name: 'Target flags with devices & groups',
url: '/docs/feature-flags/targeting-groups',
icon: 'IconPeople',
color: 'purple',
Expand Down