@bettercms-ai/mcp 0.83.0 → 0.83.2

package/dist/skills/bettercms/references/content-experiments.md

@@ -1,62 +1,62 @@
----
-title: "Content experiments"
-description: "A/B tests on section variants: hypothesis, design, readout and pitfalls."
----
-
-# Content experiments on section variants
-
-**Outcome.** Editors manage approved variant content, the runtime serves a reproducible
-experiment, and measurement answers the question that was asked. A component variant is a
-presentation option. It is not an A/B test until something assigns, exposes and measures it.
-
-## Decide whether an experiment is viable
-
-Read the connected project (`get_project`) and the site's analytics and consent setup. Write
-down one hypothesis, the primary metric, guardrail metrics, the audience, the unit of assignment
-(user, session or account), the baseline, the planned duration and the stop rules.
-
-Check the MCP tool list for experiment assignment, exposure events or reporting. When none is
-there, assignment and measurement live in a dedicated code or analytics service; BetterCMS owns
-the variant definitions and the editorial values only. Say that to the user rather than implying
-the dashboard runs the test.
-
-Do not start a test when traffic is too low for a useful result, the metric cannot be observed,
-or a legal or consent dependency is unresolved. A plain launch or a qualitative study is the
-better answer there.
-
-## Model and serve variants
-
-- **Treatments are variants of one family.** Components that share a `sectionType` are one
-  family, and every variant declares the same prop keys with the same types. Why: a swap changes
-  only `componentId`, so a key the other variant lacks is silently not rendered. Read both with
-  `get_component` before the test starts; detail in [components.md](components.md) §3.
-- **Keep a stable control.** Freeze the control's copy and tokens for the run, so an unrelated
-  edit does not change the test mid-flight.
-- **Instance override versus default.** An edit on a placed instance writes that placement's
-  override; an edit on the component canvas writes the variant's default and reaches every
-  instance without an override. Decide which one the treatment is before anyone edits.
-- **A swap warns, it does not block.** `update_page` answers a swap that would hide overrides
-  with `COMPONENT_SWAP_DROPS_OVERRIDES` or `COMPONENT_SWAP_PROP_TYPE_CHANGED`. Read the warnings
-  before calling a treatment ready.
-- **Publish both.** A draft component renders nothing on the live site, and publishing copies
-  the draft to live; an unpublished treatment is an empty band, not a variant.
-
-Preview every variant at desktop and mobile widths in its real route. Assignment must be
-sticky for the chosen unit; avoid sending both variants to one person through cache keys,
-server/client hydration or locale routing. Emit an exposure only when the variant was shown.
-Follow the site's consent settings for analytics and personalization. Keep accessible names,
-forms, pricing facts and critical navigation equivalent unless the experiment tests them on
-purpose and the risk is reviewed. Crawlers should see a stable canonical route, never cloaked
-content.
-
-## Measure and finish
-
-Fix the analysis window and the decision rule before reading results. Check sample imbalance,
-missing exposure events, bot and internal traffic, cross-device leakage and guardrail
-regressions before interpreting any uplift. Report the observed estimate with its uncertainty,
-never a guaranteed improvement.
-
-A winner is promoted by an explicit change: make it the default, or set the instances, then
-publish and verify through the normal release path ([publishing.md](publishing.md)). Archive the
-hypothesis, the variants, the measurement definition, the result and the rollback point. Keep
-the losing variant while it is needed for audit or rollback.
+---
+title: "Content experiments"
+description: "A/B tests on section variants: hypothesis, design, readout and pitfalls."
+---
+
+# Content experiments on section variants
+
+**Outcome.** Editors manage approved variant content, the runtime serves a reproducible
+experiment, and measurement answers the question that was asked. A component variant is a
+presentation option. It is not an A/B test until something assigns, exposes and measures it.
+
+## Decide whether an experiment is viable
+
+Read the connected project (`get_project`) and the site's analytics and consent setup. Write
+down one hypothesis, the primary metric, guardrail metrics, the audience, the unit of assignment
+(user, session or account), the baseline, the planned duration and the stop rules.
+
+Check the MCP tool list for experiment assignment, exposure events or reporting. When none is
+there, assignment and measurement live in a dedicated code or analytics service; BetterCMS owns
+the variant definitions and the editorial values only. Say that to the user rather than implying
+the dashboard runs the test.
+
+Do not start a test when traffic is too low for a useful result, the metric cannot be observed,
+or a legal or consent dependency is unresolved. A plain launch or a qualitative study is the
+better answer there.
+
+## Model and serve variants
+
+- **Treatments are variants of one family.** Components that share a `sectionType` are one
+  family, and every variant declares the same prop keys with the same types. Why: a swap changes
+  only `componentId`, so a key the other variant lacks is silently not rendered. Read both with
+  `get_component` before the test starts; detail in [components.md](components.md) §3.
+- **Keep a stable control.** Freeze the control's copy and tokens for the run, so an unrelated
+  edit does not change the test mid-flight.
+- **Instance override versus default.** An edit on a placed instance writes that placement's
+  override; an edit on the component canvas writes the variant's default and reaches every
+  instance without an override. Decide which one the treatment is before anyone edits.
+- **A swap warns, it does not block.** `update_page` answers a swap that would hide overrides
+  with `COMPONENT_SWAP_DROPS_OVERRIDES` or `COMPONENT_SWAP_PROP_TYPE_CHANGED`. Read the warnings
+  before calling a treatment ready.
+- **Publish both.** A draft component renders nothing on the live site, and publishing copies
+  the draft to live; an unpublished treatment is an empty band, not a variant.
+
+Preview every variant at desktop and mobile widths in its real route. Assignment must be
+sticky for the chosen unit; avoid sending both variants to one person through cache keys,
+server/client hydration or locale routing. Emit an exposure only when the variant was shown.
+Follow the site's consent settings for analytics and personalization. Keep accessible names,
+forms, pricing facts and critical navigation equivalent unless the experiment tests them on
+purpose and the risk is reviewed. Crawlers should see a stable canonical route, never cloaked
+content.
+
+## Measure and finish
+
+Fix the analysis window and the decision rule before reading results. Check sample imbalance,
+missing exposure events, bot and internal traffic, cross-device leakage and guardrail
+regressions before interpreting any uplift. Report the observed estimate with its uncertainty,
+never a guaranteed improvement.
+
+A winner is promoted by an explicit change: make it the default, or set the instances, then
+publish and verify through the normal release path ([publishing.md](publishing.md)). Archive the
+hypothesis, the variants, the measurement definition, the result and the rollback point. Keep
+the losing variant while it is needed for audit or rollback.