Reviewing & approving proposals

Open a proposal to see the full case for it.

What a proposal contains

• The page it applies to.
• The element it targets, identified by selector, with a match status.
• The proposed variation — the exact new copy, styling or layout.
• The evidence — the data that prompted it, with links back to the source heatmap, funnel or replay.
• The reasoning — why this change should move the metric.
• A confidence score — see Confidence explained, because this number is easy to misread.

Check the element match first

A proposal records whether its target element was actually found on the page. If the match status is not found, the page has changed since the proposal was generated and approving it would produce a test that never applies. Decline it and let a fresh one be generated.

What approving does

Approving creates an A/B test with your current page as the control and the proposal as the variation, using the goal implied by the evidence. From that point it is an ordinary test: you can edit variations in the visual editor, change the traffic split, adjust targeting, or stop it.

Edit before approving

You do not have to take the proposed copy verbatim. The generated wording is a starting point; your brand voice is not something the model has. Editing before approving is the normal path, not an exception.

When to decline

• The target element no longer exists.
• The change conflicts with brand, legal or accessibility requirements.
• You have already tested essentially this change and it lost.
• The page is about to be redesigned anyway.

Declining is useful signal, not a rejection of the feature — it narrows what gets proposed next.

Don't launch everything at once

Several simultaneous tests on the same page interfere with each other and each one gets a slice of the traffic. Approve the strongest one or two, let them finish, then come back.