Docs navigation

Docs / Connectors

Binding evidence

A binding links one experiment to a connector's data source. On every refresh, Converise aggregates the rows in your warehouse, imports the per-variant summary, and re-runs the full review — so the recommendation never lags behind the data.

Create a binding

  1. 1

    Open Add evidence

    On the experiment's Data sources tab click Add evidence and choose Warehouse connector. (The tile is disabled until your workspace has at least one connector with a data source.)

  2. 2

    Pick the connector and the experiment key

    Table, columns, join and dedup come from the connector's data source — nothing is mapped here. When the source holds many experiments, pick the experiment key from the list Converise reads from the warehouse (each entry shows subjects and the variant split, with an SRM hint).

  3. 3

    Tick KPIs and segments

    Tick the connector KPIs that matter for this experiment and give each a role — primary, guardrail or secondary. Ticking a KPI the experiment does not have yet creates its KPI definition (type from the connector KPI). Tick the segment columns you want as segment dimensions.

  4. 4

    Preview, then Save & refresh

    Preview runs the compiled query and shows what a refresh would import (and the SQL). Save & refresh stores the binding and runs the first import. The aggregation is two-level — collapse to the subject first, then to the variant — so each user is counted once and per-subject variance is computed in-warehouse.

Refresh, auto-refresh, and alerts

  • Refresh re-imports the evidence and re-runs the review — KPI effects, quality checks, and the recommendation update in the same request.
  • Auto-refresh runs the same thing once a day at the hour you set on the binding (default 04:00 UTC — pick a time after your warehouse ETL completes) and fires your configured alerts (primary-KPI regression, significance reached, SRM, failed refresh). It is off by default — every scheduled run re-executes the warehouse queries — so turn it on deliberately. Refreshes, manual and scheduled, run only while the experiment is running: an opt-in on a test that has not started is paused until launch, and completing the experiment switches the schedule off — so pull the final numbers before you mark it completed. Refresh frequency is deliberately daily-only: refreshing more often would just institutionalize peeking.
  • Each binding shows its status — never refreshed, succeeded (with time and row count), or failed with the error message so you can fix the mapping or credentials.

Diagnostics

If subjects appear in more than one variant, the binding shows a contamination warning — variant assignment may be leaking. Fix the assignment logic or the variant column before trusting the result; the quality checks will also flag it in the review.

The outcomes source must contain every assigned subject for conversion denominators to be valid. If it only holds outcome events, switch on the connector's separate assignmentssource (exposures / variant assignments) — outcomes are then joined on subject and counted only after the first assignment — or point the connector at a warehouse view. Joins beyond subject, attribution, and business filtering belong in the warehouse (or the connector's SQL source), not the app.

PreviousSnowflakeNextCSV & JSON upload