# Qualifying Events

## Using qualifying events

Statsig uses qualifying events to simulate exposures for power analysis, and to filter exposures to users who triggered a specific event. Setting up a Qualifying Event is identical to setting up an Assignment Source, except they don't require experimental information.

{% callout type="info" %}
The qualifying event must occur after the exposure, as their respective timestamps indicate.
{% /callout %}

You can use context columns to filter the qualifying event for power analysis. For example, you might have a Qualifying Event for page load and filter to different page identifiers for power analyses of experiments on different surfaces.

## Filter by qualifying events

Statsig provides controls for using qualifying events to filter exposures in an experiment in cases of over-exposure.

{% figure %}
![qualifying event filter](https://docs.statsig.com/images/whn/qe_filter.png)
{% /figure %}

In the image above:

* Forwarded SDK events from Statsig filter the exposures. This could also be a single-event source or any data source.
* The configuration replaces the actual exposure timestamp with the first observed qualifying event, which makes metric timelines and cohort timelines more accurate.
* The configuration counts only qualifying events from within an hour of an exposure event, which helps avoid issues with late-landing attribution.
* A filter limits events to the `www.statsig.com` domain.

Some customers prefer this flexibility, and many set up qualifying events as individual events to use in their analyses.

You can often identify over-exposed experiments by observing uniformly low participation rate on all metrics.

## Power analysis

Use qualifying events in power analysis to estimate your experimentation population based on how many users historically triggered your proposed trigger event.

{% figure %}
![power analysis with qualifying event](https://docs.statsig.com/images/whn/pac_qe.png)
{% /figure %}

You can filter these by event attributes, or by entity properties (e.g. users who triggered this event and are also in a segment or country).

## Example data

| Column Type            | Description                                                                               | Format/Rules                   |
| ---------------------- | ----------------------------------------------------------------------------------------- | ------------------------------ |
| timestamp              | **Required** an identifier of when the qualifying event occurred                          | Castable to Timestamp/Date     |
| unit identifier        | **Required** At least one entity to which this metric belongs                             | Generally a user ID or similar |
| additional identifiers | *Optional* Entity identifiers for reuse across identifier types                           |                                |
| context columns        | *Optional* Fields you can use to group by and filter results in exploratory queries |                                |

For example, you could pull from page load event logging directly and save it as a qualifying event called `Page Load`:

| timestamp           | user\_id       | company\_id | page\_route |
| ------------------- | ------------- | ---------- | ---------- |
| 2023-10-10 00:01:01 | my\_user\_17503 | c\_22235455 | /          |
| 2023-10-10 00:02:15 | my\_user\_18821 | c\_22235455 | /search    |
| 2023-10-10 00:03:12 | my\_user\_22251 | c\_9928     | /profile   |