mozanalysis.sizing

class mozanalysis.sizing.HistoricalTarget(experiment_name, start_date, analysis_length, num_dates_enrollment=7, continuous_enrollment=False, app_id=None, metrics_sql=None, targets_sql=None)[source]

Query historical data.

The methods here query data in a way compatible with the following principles, which are important for experiment analysis:

Example usage (in a colab notebook):

from google.colab import auth
auth.authenticate_user()
print('Authenticated')

from mozanalysis.config import ConfigLoader

active_hours = ConfigLoader.get_metric("active_hours", "firefox_desktop")
uri_count = ConfigLoader.get_metric("uri_count", "firefox_desktop")

new_or_resurrected_v3 = ConfigLoader.get_segment("new_or_resurrected_v3",
                                                    "firefox_desktop")
allweek_regular_v1 = ConfigLoader.get_segment("allweek_regular_v1",
                                                    "firefox_desktop")

bq_context = BigQueryContext(
    dataset_id='mbowerman',  # e.g. mine's mbowerman
    project_id='moz-fx-data-bq-data-science'  # this is the default anyway
)

ht = HistoricalTarget(
    experiment_name='my_test_name',
    start_date='2021-01-01',
    num_dates_enrollment=2,
    analysis_length=4
)

# Run the query and get the results as a DataFrame
res = ht.get_single_window_data(
    bq_context,
    metric_list = [
        active_hours,
        uri_count
    ],
    target_list = [
        allweek_regular_v1,
        new_or_resurrected_v3
    ]
)

targets_sql = ht.get_targets_sql()

metrics_sql = ht.get_metrics_sql()
Parameters:

  • experiment_name (str) – A simple name of this analysis, which is used to create table names when saving results in BigQuery.

  • start_date (str) – e.g. ‘2019-01-01’. First date for historical data to be retrieved.

  • analysis_length (int) – Number of days to include for analysis

  • num_dates_enrollment (int, default 7) – Number of days to consider to enroll clients in the analysis.

  • continuous_enrollment (bool) – Indicates if the analysis dates and enrollment should be overlap; clients that satisfy the target conditions at any point in the analysis will be included for the entire window when calculating metrics.

  • app_id (str, optional) – For a Glean app, the name of the BigQuery dataset derived from its app ID, like org_mozilla_firefox.

experiment_name

Name of the study, used in naming tables related to this analysis.

Type:

str

start_date

e.g. ‘2019-01-01’. First date on which enrollment events were received.

Type:

str

num_dates_enrollment

Number of days to consider to enroll clients in the analysis.

Type:

int

analysis_length

Number of days to include for analysis

Type:

int, optional

get_single_window_data(bq_context: BigQueryContext, metric_list: list[Metric], target_list: list[Segment] | None = None, custom_targets_query: str | None = None, replace_tables: bool = False) → DataFrame[source]

Return a DataFrame containing per-client metric values.

Also store them in a permanent table in BigQuery. The name of this table will be printed. Subsequent calls to this function will simply read the results from this table.

Parameters:

  • bq_context (BigQueryContext) – BigQuery configuration and client.

  • metric_list (list of mozanalysis.metric.Metric) – The metrics to analyze.

  • target_list (list of mozanalysis.segments.Segment) – The targets that define clients to be included in the analysis, based on inclusion in a defined user segment. For each Segment included in the list, client IDs are identified in the SegmentDataSource that based on the select_for statement in the Segment. Client IDs that satisfy the select_for statement in every Segment in the target_list will be returned by the query.

  • custom_targets_query (str) –

    A full SQL query to be used in the main query; must include a client_id column to join to metrics tables and an enrollment_date:

    N.B. this query’s results must be uniquely keyed by (client_id, enrollment_date), or else your results will be subtly wrong.

  • replace_tables (bool) – If True, delete tables that exist in BigQuery with the same name; used to rerun analyses under the same experiment name with different settings

Returns:

A pandas DataFrame of experiment data. One row per client_id. Some metadata columns, then one column per metric in metric_list, and one column per sanity-check metric. Columns (not necessarily in order):

  • client_id (str): Not necessary for “happy path” analyses.

  • Analysis window (int): Start and end of analysis window, in days of entire analysis included in the window

  • [metric 1]: The client’s value for the first metric in metric_list.

  • …

  • [metric n]: The client’s value for the nth (final) metric in metric_list.

get_time_series_data(bq_context: BigQueryContext, metric_list: list[Metric], time_series_period: str = 'weekly', custom_targets_query: str | None = None, target_list: list[HistoricalTarget] | None = None, replace_tables: bool = False) → TimeSeriesResult[source]

Return a TimeSeriesResult with per-client metric values.

Roughly equivalent to looping over get_single_window_data() with different analysis windows, and reorganising the results.

Parameters:

  • bq_context (BigQueryContext) – BigQuery configuration and client.

  • metric_list (list of mozanalysis.metric.Metric) – The metrics to analyze.

  • time_series_period (str) – Period of the time series for which to retrieve data. Options are daily, weekly, and 28_day.

  • target_list (list of mozanalysis.segments.Segment) – The targets that define clients to be included in the analysis, based on inclusion in a defined user segment. For each Segment included in the list, client IDs are identified in the SegmentDataSource that based on the select_for statement in the Segment. Client IDs that satisfy the select_for statement in every Segment in the target_list will be returned by the query.

  • custom_targets_query (str) –

    A full SQL query to be used in the main query; must include a client_id column to join to metrics tables and an enrollment_date:

    N.B. this query’s results must be uniquely keyed by (client_id, enrollment_date), or else your results will be subtly wrong.

  • replace_tables (bool) – If True, delete tables that exist in BigQuery with the same name; used to rerun analyses under the same experiment name with different settings

Returns:

A mozanalysis.experiment.TimeSeriesResult object, which may be used to obtain a pandas DataFrame of per-client metric data, for each analysis window. Each DataFrame is a pandas DataFrame in “the standard format”: one row per client, some metadata columns, plus one column per metric and sanity-check metric. Its columns (not necessarily in order):

  • enrollment date and client_id

  • [metric 1]: The client’s value for the first metric in metric_list.

  • …

  • [metric n]: The client’s value for the nth (final) metric in metric_list.

build_metrics_query(metric_list: list[Metric], time_limits: TimeLimits, targets_table: str) → str[source]

Return a SQL query for querying metric data.

For interactive use, prefer get_single_window_data() or TODO get_time_series_data(), according to your use case, which will run the query for you and return a materialized dataframe.

Parameters:

  • metric_list (list of mozanalysis.metric.Metric) – The metrics to analyze.

  • time_limits (TimeLimits) – An object describing the interval(s) to query

  • targets_table (str) – The name of the targets BigQuery table

Returns:

A string containing a BigQuery SQL expression.

Building this query is the main goal of this module.

class mozanalysis.sizing.ContinuousEnrollmentTimeLimits(first_enrollment_date: str, last_enrollment_date: str, first_date_data_required: str, last_date_data_required: str, analysis_windows: tuple[AnalysisWindow])[source]

Expresses time limits for different kinds of analysis windows.

Instantiated and used by the Experiment class; end users should not need to interact with it.

Do not directly instantiate: use the constructors provided.

There are several time constraints needed to specify a valid query for experiment data:

  • When did enrollments start?

  • When did enrollments stop?

  • How long after enrollment does the analysis window start?

  • How long is the analysis window?

Even if these four quantities are specified directly, it is important to check that they are consistent with the available data - i.e. that we have data for the entire analysis window for every enrollment.

Furthermore, there are some extra quantities that are useful for writing efficient queries:

  • What is the first date for which we need data from our data source?

  • What is the last date for which we need data from our data source?

Instances of this class store all these quantities and do validation to make sure that they’re consistent. The “store lots of overlapping state and validate” strategy was chosen over “store minimal state and compute on the fly” because different state is supplied in different contexts.

classmethod for_single_analysis_window(first_date_full_data: str, analysis_length_dates: str) → ContinuousEnrollmentTimeLimits[source]

Return a ContinuousEnrollmentTimeLimits instance with the following parameters:

Parameters:

  • first_enrollment_date (str) – First date on which enrollment events were received; the start date of the experiment.

  • last_date_full_data (str) – The most recent date for which we have complete data, e.g. ‘2019-03-22’. If you want to ignore all data collected after a certain date (e.g. when the experiment recipe was deactivated), then do that here.

  • analysis_start_days (int) – the start of the analysis window, measured in ‘days since the client enrolled’. We ignore data collected outside this analysis window.

  • analysis_length_days (int) – the length of the analysis window, measured in days.

  • num_dates_enrollment (int, optional) – Only include this many days of enrollments. If None then use the maximum number of days as determined by the metric’s analysis window and last_date_full_data. Typically 7n+1, e.g. 8. The factor 7 removes weekly seasonality, and the +1 accounts for the fact that enrollment typically starts a few hours before UTC midnight.