Preparing Assignment Source Tables for Warehouse Native Experimentation
Learn how to prepare your assignment source tables in your data warehouse for Warehouse Native Experimentation.
To prepare an Assignment Source for Warehouse Native Experimentation, transform your raw exposure or impression logs into a clean, standardized table that serves as the foundation for experimentation analyses.
This page describes the required fields, recommended fields, and best practices for preparing your assignment source tables.
Required columns
Every Assignment Source table must include the following columns:
Unique Key
STRING
Unique identifier for the unit of randomization (for example, user_id, account_id, or a custom key). Must be stable across the experiment duration.
Exposure Timestamp
DATETIME / TIMESTAMP
The time the assignment occurred (for example, when an impression was logged, a flag evaluated, or getTreatment was called). Must be provided in epoch milliseconds or UTC format (e.g. 1714953600000 or 2026-05-05T00:00:00Z).
Timestamps must be in UTC (epoch milliseconds or UTC datetime) and align with the format used in Metric Sources for accurate joins and analysis.
Treatment (Variant Group)
STRING
The assigned experiment variant (for example, control, treatment_a, variant_1).
Recommended columns
While not required, the following fields make debugging, filtering, and governance more efficient.
Experiment ID / Name
STRING
Helps differentiate exposures when multiple experiments are logged in the same raw table.
Targeting Rule
STRING
Indicates which targeting rule or condition led to the assignment. Useful for audit and debugging. If you are using FME feature flag impressions, filter by a single targeting rule to ensure the experiment analyzes the intended population.
Environment ID
STRING
Allows filtering by environment (for example, production, staging). When configuring an assignment source in FME, you can map column values to a matching Harness environment or hard-code a single environment. When creating an experiment, it must be scoped to one environment.
Traffic Type
STRING
Distinguishes the unit type (for example, user, account, anonymous visitor). When configuring an assignment source, you can map column values or hard-code the environment. Each experiment must be scoped to one traffic type.
Common raw table schemas
Most organizations log impressions or exposures from feature flag evaluations, SDKs, or event pipelines. Below are common raw schemas and how to normalize them.
Feature Flag Evaluation Logs
Example Raw Schema
Transformations
user_id
flag_name
treatment
impression_time
environment
rule_id
• Map flag_name values → experiment_id (if multiple flags correspond to the same experiment).
• Cast evaluation_time to TIMESTAMP.
• Deduplicate on (user_id, experiment_id) by keeping the earliest exposure.
A/B Test Impression Logs
Example Raw Schema
Transformations
experiment_id
user_id
bucket or arm
impression_time
• Standardize bucket → treatment.
• Standardize impression_time → exposure_timestamp.
• Deduplicate to keep only the first exposure per user per experiment.
Event Logging Pipelines (Custom Analytics Events)
Example Raw Schema
Transformations
event_name
event_time
properties.experiment_id
properties.variant
properties.user_id
• Flatten nested fields (JSON → explicit columns).
• Filter to only event_name = 'experiment_exposure'.
• Standardize column names to match required schema.
Prepare your assignment table
Follow these best practices for preparing your assignment table in your data warehouse.
De-duplication: Keep only the earliest exposure per user per experiment. For example:
Consistent Variant Labels: Standardize variant naming (
control,treatment,variant_1) across experiments. Avoid null or empty strings; default tocontrolif needed.Timestamp Format: All exposure timestamps must be in epoch milliseconds or UTC (ISO 8601).
Use UTC Consistently: Store all exposure and event timestamps in UTC to ensure consistent comparisons across regions.
Stable Identifiers: Use the same user or account key across Assignment Source and Metric Source tables. If your system logs multiple IDs (for example,
cookie_idanduser_id), choose the most stable one.Environment Separation: If raw tables mix environments (for example,
stagingandproduction), add anenvironment_idcolumn and filter accordingly. This prevents accidental inclusion of test data in production environments.Partitioning and Indexing: Partition large tables by
DATE(exposure_timestamp)to optimize query performance. Cluster or index byexperiment_idanduser_idfor faster lookups.
Example prepared table schema
user_id
STRING
abc123
experiment_id
STRING
checkout_flow_v2
treatment
STRING
control
exposure_timestamp
TIMESTAMP
2025-03-14T12:45:00Z
environment_id
STRING
prod
traffic_type
STRING
user
Once your Assignment Source tables are prepared and validated, see Setting Up an Assignment Source to connect them in Harness FME.
Last updated
Was this helpful?