Lint VWO campaigns with explint.com before you launch
Read a campaign from VWO with Wingify's MCP server, check the test plan with explint.com in the same chat, and fix the gaps before the campaign starts taking visitors.
What you need before you start
- A VWO account with an A/B test or Split URL campaign drafted, including its hypothesis, variations, and goals.
- Access to Wingify's MCP server for VWO web campaigns, or the VWO feature experimentation MCP if your test is a feature test, since VWO offers both and they cover different work.
- An assistant that can hold two MCP connections at once, and an A/BLint project for your team.
- A few minutes before launch to read the report, because a finding about a missing goal is quick to fix in draft and awkward to fix mid-test.
Connect VWO and A/BLint
- Add Wingify's MCP server in your assistant at https://mcp.wingify.ai/mcp for web campaigns, following VWO's help article for your assistant, and sign in with the VWO account that holds the campaign.
- Add A/BLint in the same assistant at https://explint.com/mcp and finish the browser sign-in, or use an API key from the MCP page in your A/BLint workspace if your assistant asks for a key instead.
- Ask the assistant to list your draft campaigns, because that confirms it is reading the right VWO account and shows which server you actually connected.
- Name the campaign and your A/BLint project, and say whether it is a web campaign or a feature test so the assistant uses the right details.
How the check runs
- The assistant reads the campaign from VWO, including its hypothesis, variations and what each one changes, traffic split, and goals.
- It turns those fields into one plain text with headings, and it flags any field that came back empty before the check runs.
- It sends the text to A/BLint with ablint__lint and brings back errors, warnings, and passes.
- It maps each finding to the VWO screen where you would fix it, such as the goals step or the traffic step of the campaign setup.
- You edit the campaign in VWO, ask for a fresh read and a fresh lint, and launch only when the errors have cleared.
Copy and paste this prompt
Change the words in square brackets to name your own project, board, or test.
Use the Wingify MCP tools to read the VWO campaign called [campaign name]. Build one text from its hypothesis, variations and what each one changes, traffic split, primary goal and other goals, and planned run time. Lint that text with explint.com against the project [your A/BLint project name]. Show me each error and warning with the VWO setup step it came from. Do not start the campaign and do not edit it yet. Suggest fixes in this chat, and re-check after I update VWO.
What A/BLint looks for
A/BLint scores the text against the rules switched on in your project. The default project uses the rules below, and your team can turn rules off, change how strict they are, or add its own rules in plain English. An error means the test cannot answer its question as written, and a warning means the result will be hard to judge when it comes in.
| Rule | Level | In plain words |
|---|---|---|
| hypothesis/names-metric-and-direction | error | The guess names the number it expects to move and which way it should move, such as a rise in checkout completion. |
| metrics/has-one-primary-metric | error | One main number decides the test, so the team agrees before the test starts which result matters most. |
| guardrails/are-listed | error | The write-up names the numbers that must not get worse, such as speed, errors, refunds, or people leaving. |
| variants/control-is-described | error | The current experience is described well enough that a reader who has never seen it can picture what people see today. |
| variants/each-differs-from-control-stated | error | Each version says exactly what changes, so the team can tell afterwards which change caused the result. |
| randomization/states-the-split | error | The plan gives the share of traffic each version gets, so the team can judge whether the test can finish in time. |
| power/states-the-minimum-detectable-effect | error | The plan names the smallest change that would matter to the business, which is the number the sample size rests on. |
| duration/covers-full-business-cycles | error | The test runs long enough to cover full weeks, so a busy Monday and a quiet Sunday both count in the result. |
An example you can compare against
Before
Pricing page test
- Hypothesis
- New pricing page will increase conversions.
- Variations
- Control, Variation 1
- Goals
- Clicks, revenue
- Traffic
- 50 percent of visitors
After, checked again
Clearer annual saving on the pricing page
- Hypothesis
- If the annual plan shows the saving as money saved per year beside the monthly price, then the share of pricing visits that start checkout will rise, because chat transcripts show visitors doing that maths themselves and leaving before they finish.
- Main goal
- Share of pricing visits that start checkout.
- Guardrails
- Checkout errors must not rise, and the share who pick monthly must not fall by more than 4 points without a rise in annual starts.
- Versions
- Control keeps the current prices. Variation changes only the annual saving line, with the same layout, prices, and buttons.
- Traffic and time
- 50/50 for three full weeks, about 25,000 pricing visits, enough to spot a 1.5 point rise.
- Decision rule
- Ship if the main goal rises and the guardrails hold.
Still flagged on the rewrite
- errorguardrails/have-launch-thresholdsThe main guardrail has no number, while the second one does.
- warningdecision/has-criteria-before-launchOnly the happy result has an outcome attached to it.
The stronger campaign names one main goal among its goals, because VWO will happily track many goals and a test with five equal goals invites the team to pick the happiest number afterwards. Naming the main one in the plan keeps the later read honest.
Fix what it finds and check again
Start with the errors, and have the assistant suggest each rewrite in the chat before anything is written back to VWO, so wording your team already agreed stays yours to approve. Rewrite the campaign plan so a teammate reading it cold could say what will change, what number will judge it, and what would stop a launch, then lint the same campaign plan again and ask which rules now pass that failed before.
Limits and things to check yourself
- VWO offers more than one MCP path, with a remote server for web campaigns and a local server for feature experimentation, so a campaign the assistant cannot see usually means the other server is the one to connect.
- Changes built in VWO's visual editor may read as a variation name with no words behind it, so describe what each variation changes in the campaign notes before you lint.
- Revenue and goal tracking depend on your VWO setup and your site tagging, which the written plan cannot prove, so keep your usual pre-launch checks beside this one.
- A passing score says the write-up covers what the rules ask for. It cannot say the idea is worth testing, that the traffic exists to reach a clear result, or that the change is safe to build, and those calls stay with your team.