Lint Adobe Target activities with explint.com before you launch
Read an activity from Adobe Target through Adobe's Target MCP tools or its Admin API, check the plan with explint.com in the same chat, and fix the gaps before the activity goes live.
What you need before you start
- An Adobe Target workspace with an A/B Test or Experience Targeting activity drafted, including its audiences, experiences, and success metrics.
- Access to Adobe Target's MCP tools where your Adobe admin has made them available, or an Adobe Developer Console project with the Adobe Target API added for the Admin API path.
- An assistant that can hold the Adobe connection beside A/BLint, and an A/BLint project for your team.
- Someone who can approve activity changes, since Target workspaces often split building, approving, and activating between different people.
Connect Adobe Target and A/BLint
- Connect Adobe Target through the MCP setup your Adobe organisation uses, following Adobe's Target MCP guidance in Experience League, and confirm with your admin which workspaces and activity types you can read or change. Some activity types are read only through those tools, so check your own access before you plan around edits.
- 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.
- If your organisation has not enabled the MCP tools, use the API path instead. An Adobe Developer Console project with the Adobe Target Admin API and OAuth sign-in can list and read activities, and your assistant can work from that read or from a careful paste of the activity setup.
- Ask the assistant to list a few activities by name, then name the draft activity and your A/BLint project so the check starts from the right place.
How the check runs
- The assistant reads the activity, including its goal, audiences, experiences and what each experience changes, traffic split, and reporting metrics.
- It writes those details into one text with headings that match the Target screens, which helps the approver on your team follow the report without learning a new layout.
- It sends the text to A/BLint with ablint__lint and brings back errors, warnings, and passes.
- It ties each finding to the activity field it came from and suggests wording you can paste into Target.
- You or your approver update the activity, then the assistant reads the fresh version and lints it again before activation.
Copy and paste this prompt
Change the words in square brackets to name your own project, board, or test.
Prompt for your assistant
Use the Adobe Target MCP or API tools available to you to read the draft activity called [activity name]. Build one text from its goal, hypothesis if one is written, audiences, experiences and what each experience changes, traffic split, primary metric and guardrail metrics, and planned run time. If a field is missing, say so instead of filling it in. Lint that text with explint.com against the project [your A/BLint project name]. Show me each error and warning with the Target field it came from. Do not activate or edit the activity. Suggest fixes in this chat, and re-check after the activity is updated.
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. |
| guardrails/have-launch-thresholds | error | Each guardrail has a clear limit that would stop a launch, written as a number the team can check without debate. |
| variants/each-differs-from-control-stated | error | Each version says exactly what changes, so the team can tell afterwards which change caused the result. |
| audience/has-exclusion-criteria | warning | The plan says who is left out, such as staff, bots, or test accounts, and why they would muddy the result if they stayed in. |
| 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. |
| decision/has-criteria-before-launch | error | The team writes down before launch what result would ship, what result would stop, and what result would mean running the test again. |
An example you can compare against
Before
Hero personalisation
- Type
- Experience Targeting
- Experiences
- Default, Hero B
- Metric
- Click through rate
- Audience
- All visitors
After, checked again
Delivery promise for returning visitors
- Hypothesis
- If returning visitors see the free delivery threshold in the hero instead of a general welcome back line, then the share of visits that add something to the basket will rise, because basket research shows returning visitors check delivery cost before they browse.
- Main number
- Share of visits that add an item to the basket.
- Guardrails
- Hero load time must not get worse by more than 0.3 seconds, and visits ending within ten seconds must not rise by more than 2 points.
- Experiences
- Control keeps the current hero. Test changes only the hero line for returning visitors, with the same image and button.
- Audience and split
- Returning visitors only, 50/50, staff and preview traffic left out, for three full weeks.
- Decision rule
- Activate for all returning visitors if the main number rises and the guardrails hold.
Still flagged on the rewrite
- errorpower/has-a-sample-size-calculationThe audience is careful, and no visit count or size working appears anywhere in the plan.
- warningdecision/has-criteria-before-launchActivation is decided, and a flat result is left for a later meeting.
The stronger activity gives each experience a plain description of what changes, which matters in Target because an experience can bundle a picture, a layout, and a line of copy that no single name can explain later. Writing the bundle down keeps the result readable when a new team member asks what was actually tested.
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 Adobe Target, so wording your team already agreed stays yours to approve. Rewrite the activity 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 activity plan again and ask which rules now pass that failed before.
Limits and things to check yourself
- Adobe's Target MCP tools cover some activity types for reading and fewer for editing, and your admin controls the exact access, so treat any write the assistant offers as a step to confirm with your approver first.
- Targeting rules and offers that live in separate libraries may not travel into the activity read, so paste the audience and offer wording into the text when the report looks thin.
- Activation rights in Target often sit with a different person from the builder, so this check helps the handover and does not replace your approval flow.
- 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.