Property filter operators

Property filters let you narrow down events, persons, groups, and feature flag targeting using operators on property values. These operators are shared across PostHog features including Feature Flags, Surveys, Cohorts, and Insights.

String operators

String operators work on text-based properties. These are the most common operators used in property filters.

OperatorDescription
exact / is notMatches when the property value equals (or does not equal) any value in the list
contains / does not containMatches when the property value contains (or does not contain) the substring
matches regex / does not match regexMatches when the property value matches (or does not match) a regular expression

String properties also support semver operators for comparing version strings like 1.2.3. These appear alongside the regular string operators in the filter dropdown.

Numeric operators

Numeric operators work on number-based properties like counts, ages, or amounts.

OperatorDescription
equals / does not equalMatches when the numeric value equals (or does not equal) the specified number
greater than / greater than or equal toMatches when the value is above (or at/above) the threshold
less than / less than or equal toMatches when the value is below (or at/below) the threshold
between / not betweenMatches when the value is (or is not) within the specified range
minimum / maximumMatches based on the minimum or maximum value

Presence operators

Presence operators check whether a property exists on a person or event, regardless of its value.

OperatorDescription
is setMatches when the property exists and has any value
is not setMatches when the property does not exist or has no value

Semver operators

Semver (semantic versioning) operators are additional operators available on string properties that compare values as version strings (e.g., 1.2.3) instead of plain text. There is no separate semver data type – these operators appear alongside the regular string operators in the filter dropdown, labeled with a (semver) suffix.

These are most useful with version-formatted properties like $app_version or $lib_version. Mobile SDKs automatically include $app_version in feature flag evaluation requests – see property overrides for details.

OperatorLabel in UIDescriptionExample
=equals (semver)Matches versions exactly equal to the value= 1.2.0 matches 1.2.0 only
not equals (semver)Matches versions not equal to the value≠ 1.2.0 matches any version except 1.2.0
>greater than (semver)Matches versions strictly greater than the value> 1.2.0 matches 1.3.0, 2.0.0
>=greater than or equal (semver)Matches versions greater than or equal to the value>= 1.2.0 matches 1.2.0, 1.3.0
<less than (semver)Matches versions strictly less than the value< 2.0.0 matches 1.9.9, 1.0.0
<=less than or equal (semver)Matches versions less than or equal to the value<= 2.0.0 matches 2.0.0, 1.5.0
~tilde range (semver)Matches versions compatible at the patch level~ 1.2.3 matches >=1.2.3 and <1.3.0
^caret range (semver)Matches versions compatible at the minor level^ 1.2.3 matches >=1.2.3 and <2.0.0
*wildcard (semver)Matches any version in the wildcard range1.2.* matches >=1.2.0 and <1.3.0

Note: The property value should follow semver conventions (e.g., 1.2.3) for accurate comparisons. Values that don't follow semver format may produce unexpected results.

Tilde, caret, and wildcard ranges

The tilde ~, caret ^, and wildcard * operators match a range of versions rather than a single comparison:

  • Tilde ~ allows patch-level changes. ~1.2.3 matches any version >=1.2.3 and <1.3.0. Use this when you want to allow bug fix updates but not new features.

  • Caret ^ allows minor-level changes. ^1.2.3 matches any version >=1.2.3 and <2.0.0. Use this when you want to allow new features but not breaking changes.

  • Wildcard * matches any version in the specified position. 1.2.* matches any version >=1.2.0 and <1.3.0. Use this for simple range matching without specifying exact bounds.

Cohort operators

Cohort operators are used exclusively with cohort properties to target users based on cohort membership. They cannot be used with person or group properties.

OperatorDescription
inMatches when you are a member of the specified cohort
not inMatches when you are not a member of the specified cohort

Where are property filters used?

Property filters appear throughout PostHog. Some of the most common places include:

  • Feature Flags: Define release conditions that target users based on person, group, or cohort properties.
  • Surveys: Control which users see a survey based on their properties.
  • Cohorts: Define dynamic cohort membership using person property criteria.
  • Insights: Filter event data in trends, funnels, and other analytics views.
  • Workflows: Filter which persons or events trigger a workflow based on their properties.

This is not an exhaustive list – property filters are used in many other parts of PostHog wherever you can filter or target based on properties.

Community questions

Was this page useful?

Questions about this page? or post a community question.