​

Cross-customer priors

Every experiment you decide is a data point about how a kind of change moves a kind of metric. On its own it benefits only your organization. Pooled across every organization on Erdo, those data points become something no single company could build alone: a library of “changes of this structural kind tend to move this metric by about this much.” Erdo distills that library nightly and uses it as a zero-information starting belief when planning a new experiment — a prior for which treatment kinds are worth trying, and roughly how large an effect to expect, before your own traffic has said anything. This page is the disclosure of exactly what that library contains, what it can never contain, and how to remove your organization from it.

​

What is shared: aggregate effect sizes over a fixed set of change kinds

The only thing the platform learns is the aggregate effect of a structural treatment class on a metric, pooled across organizations. A treatment class is a coarse, structural label for what kind of change a variant makes — never what the change says. There are exactly eight, and the set is fixed:

• headline_change — the headline/hook copy changed
• hero_media_change — the hero image or video changed
• cta_change — the call-to-action changed
• form_length_change — the lead form gained or shed fields
• social_proof_add — testimonials, logos, ratings, or counts were added
• layout_reorder — the same sections in a different order
• offer_change — the underlying offer, price, or incentive changed
• full_page_rebuild — several dimensions changed at once

When an agent creates an experiment variant, it declares which of these classes the variant belongs to. The distiller reads that declared label and the measured outcome — it never reads your page’s content, copy, or design. Eight classes is deliberate: coarse enough that no aggregate can be traced back to one organization, specific enough to carry a useful prior. For each (treatment class, metric) pair, a published prior contains only:

• how many experiments and how many distinct organizations contributed,
• a five-number summary (minimum, quartiles, maximum) of the relative effect of the winning variant versus its control, and
• the share of those experiments in which the effect was positive.

The test we hold this schema to is simple: every published cell is something we would be comfortable printing on our marketing site.

​

What is never shared

No page content, copy, headline, image, or design. No organization name, slug, or identifier. No per-experiment result, and no per-organization number of any kind. A published prior is an aggregate and nothing but an aggregate — there is no field in it that names or reconstructs any single organization’s data. Two thresholds enforce this by construction: a (treatment class, metric) cell is published only when at least five experiments from at least three distinct organizations have contributed to it. Below either threshold the cell publishes nothing at all. An aggregate over five experiments from three organizations cannot be attributed to any one of them.

​

How the prior is used

A cross-customer prior is the outermost belief in Erdo’s experiment decision policy: it is overridden by your own calibrated persona-panel prediction, and by any real traffic the moment it arrives. Its weight is capped so that a day or two of your own visitors washes it out entirely. In practice it does one useful thing — it stops an obviously-oversized experiment before it launches and nudges the opening traffic split — and then it gets out of the way of your real data.

​

Reading the library

The published library is visible to every organization, verbatim — there is nothing hidden about it. Read it through any Erdo surface:

• MCP: erdo_list_cross_customer_priors
• REST: GET /v1/cross-customer-priors
• CLI: erdo experiment priors

Each entry is one (treatment class, metric) cell with its counts and five-number effect summary.

​

Contributing, and how to opt out

Contribution is on by default, because only de-identified aggregates over many organizations are ever published. If you would rather your organization’s experiments not contribute, an organization admin can turn it off in Settings (the contribute_aggregate_learning toggle). Opting out takes effect at the next nightly run: your experiments are dropped from the aggregation entirely, and any published cell that no longer clears the five-experiment / three-organization thresholds without your data is removed — there is no residue. You keep every benefit of your own experiments and your own calibration; you simply stop contributing to the shared library.