CRITICAL WARNING: DO NOT USE THIS TOOL FOR NORMAL WORKFLOWS

Activities created via this API are PERMANENTLY LOCKED - they CANNOT be edited in Adobe Target UI.

DEFAULT WORKFLOW (USE THIS 99% OF THE TIME):

1. Create offers using createOffer tool (HTML) or createJsonOffer tool (JSON)

2. Provide user with offer IDs

3. User manually builds A/B activity in Target UI with full editing flexibility

DO NOT USE THIS TOOL UNLESS:

1. User is creating 10+ activities in bulk (programmatic bulk creation)

2. This is part of an automated CI/CD workflow

3. User has been EXPLICITLY WARNED that activities cannot be edited in Target UI

4. User has confirmed they understand the limitation and still want to proceed

MANDATORY STEPS BEFORE USING THIS TOOL: You MUST complete ALL of these steps before calling this tool:

1. Ask user: "Are you creating 10+ activities in bulk?"

   • If NO: Stop. Tell user to use createOffer workflow instead

   • If YES: Continue to step 2

2. Warn user: "Activities created via API will be permanently locked and cannot be edited in Adobe Target UI. You will not be able to modify them later through the Target interface. Do you understand and want to proceed?"

   • If NO: Stop. Use createOffer workflow instead

   • If YES: Continue to step 3

3. Confirm: "To confirm: You understand the activity will be locked in Target UI and you still want to create it programmatically?"

   • If NO: Stop. Use createOffer workflow

   • If YES: Proceed with this tool

If user does NOT confirm all three steps, DO NOT use this tool. Use createOffer instead.

RECOMMENDED ALTERNATIVE (99% of use cases): Use createOffer to create offers, then tell user: "I've created the offers. Here are the offer IDs: [list IDs] To create your A/B activity:

1. Go to Adobe Target → Activities → Create Activity → A/B Test

2. Choose Form-Based Experience Composer

3. Add experiences and select these offer IDs

4. Configure traffic split and metrics This gives you full editing flexibility in the Target UI."

AUTO-FILLED DEFAULTS:

• priority: 5

• workspace: TARGET_WORKSPACE_ID

• locations.mboxes: target-global-mbox

• metrics: Page views goal (engagement: "page_count")

• analytics (A4T): Auto-configured if set in .env

ACTIVITY MUST INCLUDE:

• name (string)

• state: "saved" (always use saved, activate later with updateActivityState)

• options: Array with offerIds from createOffer

• experiences: Traffic split configuration

• locations: Where activity runs (auto-filled if not provided)

• metrics: Success goal (auto-filled page views if not provided)

REFERENCE - Complete Payload Structure: { "id": 0, // int64: Activity ID (optional for create, auto-generated) "thirdPartyId": "string", // string: Optional external ID reference "name": "string", // string: REQUIRED - Activity name "state": "saved", // string: REQUIRED - "approved" | "saved" | "deactivated" | "deleted" // ALWAYS use "saved" for new activities "priority": 5, // int32: REQUIRED - Default: 5, Range: 0-999 "startsAt": "2024-01-01T00:00:00Z", // string (ISO-8601): Required if state is "approved" "endsAt": "2024-12-31T23:59:59Z", // string (ISO-8601): Required if state is "approved" "modifiedAt": "2024-01-01T00:00:00Z", // string (ISO-8601): Auto-generated timestamp

// LOCATIONS - Define where activity runs "locations": { "mboxes": [ // array: For server-side/mbox-based activities { "locationLocalId": 0, // int32: Unique ID for this location "name": "target-global-mbox", // string: Mbox name "audienceIds": [] // array: Optional audience targeting for location } ], "selectors": [ // array: For SPA/VEC activities with CSS selectors { "locationLocalId": 0, // int32: Unique ID for this location "name": "Hero Selector", // string: Display name "selector": "#hero-section", // string: CSS selector "audienceIds": [], // array: Optional audience targeting "selectorVersion": 1, // int32: Selector version "viewLocalId": 0 // int32: Reference to view (for SPA) } ] },

// OPTIONS - Define what content variations to show "options": [ { "optionLocalId": 0, // int32: Unique ID for this option "name": "Option A", // string: Option display name "offerId": 123456, // int64: ID from createOffer or existing offer "offerTemplates": [ // array: Optional - For dynamic offer templates { "offerTemplateId": 0, // int64: Template ID "templateParameters": [ // array: Template parameters { "name": "paramName", // string: Parameter name "value": "paramValue" // string: Parameter value } ] } ] } ],

// EXPERIENCES - Map options to locations with traffic allocation "experiences": [ { "experienceLocalId": 0, // int32: Unique ID for this experience "name": "Experience A (Control)", // string: Experience display name "audienceIds": [], // array: Optional audience targeting "visitorPercentage": 50, // int32: Traffic allocation (must total 100%) "optionLocations": [ // array: Map options to locations { "locationLocalId": 0, // int32: Reference to location "optionLocalId": 0 // int32: Reference to option } ] }, { "experienceLocalId": 1, "name": "Experience B", "audienceIds": [], "visitorPercentage": 50, "optionLocations": [ { "locationLocalId": 0, "optionLocalId": 1 } ] } ],

// METRICS - Define success metrics (conversions, engagement) "metrics": [ { "metricLocalId": 0, // int32: Unique ID for this metric "name": "Primary Goal", // string: Metric display name "conversion": true, // boolean: true for conversion metric "engagement": "page_count", // string: "page_count" | "score" | "time_on_site" | "none"

  // Action configuration (how to count metric)
  "action": {
    "type": "count_once",          // string: How to count this metric
    // Valid types:
    // "count_once" - Count only once per visitor
    // "count_landings" - Count each landing
    // "always_convert" - Always count as conversion
    // "restart_same_experience" - Restart in same experience
    // "restart_random_experience" - Restart in random experience
    // "restart_new_experience" - Restart in new experience
    // "exclude_to_same_experience" - Exclude but keep in same experience
    // "ban_from_campaign" - Permanently exclude from activity

    "conditions": {                // object: When to count
      "maxVisitCount": 0,          // int32: Max visits before counting (0 = unlimited)
      "maxImpressionCount": 0,     // int32: Max impressions before counting
      "experiences": [             // Per-experience conditions
        {
          "experienceLocalId": 0,  // int32: Reference to experience
          "maxVisitCount": 0,      // int32: Max visits for this experience
          "maxImpressionCount": 0  // int32: Max impressions for this experience
        }
      ]
    },
    "onConditionsMetAction": "count_once"  // string: Same values as "type"
  },

  // Mbox-based success tracking
  "mboxes": [
    {
      "name": "orderConfirmPage",   // string: Mbox name
      "successEvent": "mbox_shown", // string: "mbox_shown" | "mbox_clicked"
      "audienceIds": []              // array<int64>: Optional audience segmentation
    }
  ],

  // Click tracking (alternative to mbox tracking)
  "clickTrackSelectors": [
    {
      "selector": "#buy-button",   // string: CSS selector to track
      "audienceIds": [],           // array<int64>: Optional audience segmentation
      "selectorVersion": 1,        // int32: Selector version
      "viewLocalId": 0             // int32: Reference to view (for SPA)
    }
  ],

  // View-based tracking (for SPA)
  "views": [
    {
      "viewLocalId": 0,            // int32: Reference to view
      "audienceIds": []            // array<int64>: Optional audience segmentation
    }
  ],

  // Per-metric A4T configuration (overrides activity-level)
  "analytics": {
    "dataCollectionHost": "company.sc.omtrdc.net",
    "reportSuites": [
      {
        "companyName": "Company",
        "reportSuites": ["prod-rsid"]
      }
    ]
  }
}

],

// OPTIONAL: Entry constraints (limit who can enter) "entryConstraint": { "mboxes": [ // Require specific mboxes to fire { "name": "target-global-mbox", "audienceIds": [] // Optional audience constraints } ], "visitorPercentage": 100 // Limit % of visitors (default: 100) },

// OPTIONAL: Reporting audiences (segment reports) "reportingAudiences": [ { "reportingAudienceLocalId": 0, // int32: Unique ID for this reporting audience "audienceId": 789, // int64: Reference to audience "metricLocalId": 0 // int32: Reference to metric } ],

// OPTIONAL: Analytics for Target (A4T) integration "analytics": { "dataCollectionHost": "company.sc.omtrdc.net", // string: Analytics tracking server "reportSuites": [ // array: Report suite configuration { "companyName": "Company", // string: Analytics company name "reportSuites": ["prod-rsid"] // array: Report suite IDs } ] },

// OPTIONAL: For premium customers "workspace": "1234567", // string: Workspace ID (max 250 chars) "propertyIds": [123], // array: Unique property IDs

// OPTIONAL: For SPA/single-page applications "views": [ { "viewLocalId": 0, // int32: Local ID for this view "viewId": 1001, // int64: Global view ID "audienceIds": [] // array: Optional audience targeting } ],

// OPTIONAL: Application context (mobile, channel) "applicationContext": { "channel": "web", // string: "web" | "mobile" "applicationVersions": ["1.0"], // array: App version numbers "mobilePlatformVersions": ["iOS 16"], // array: OS versions "deviceType": "phone", // string: "phone" | "tablet" | "desktop" "screenOrientation": "portrait" // string: "portrait" | "landscape" } }

See full API documentation for complete field reference.

REMINDER: For normal use cases, create offers with createOffer tool instead of using this advanced API.

Get details of a specific A/B Test activity

List all Target activities with optional filtering and sorting

Update an existing A/B Test activity definition. This can change the state, behavior, and configuration of an existing activity.

DEFAULT VALUES: This tool automatically applies default values from your configuration for any missing fields:

• priority: Defaults to 5

• workspace: Uses TARGET_WORKSPACE_ID if configured

• analytics (A4T): Auto-fills dataCollectionHost and reportSuites if configured

• metrics defaults: action type, success mboxes, etc.

You can override any default by explicitly providing the value.

USE CASES:

• Modify activity name, priority, or configuration

• Update experiences, locations, or metrics

• Change activity state (saved, approved, deactivated)

• Update dates (startsAt, endsAt)

• Modify audience targeting or reporting audiences

NOTE: For ONLY changing activity state (saved/approved/deactivated), use updateActivityState tool instead. This tool is for full activity definition updates.

ACTIVITY STATES:

• saved: Inactive state (for draft activities)

• approved: Activity is live (requires startsAt and endsAt dates)

• deactivated: Archived

• deleted: Removed from UI

STATE BEHAVIOR WITH DATES (when state is "approved"):

• startsAt in past + endsAt in future = Live

• startsAt in past + endsAt in past = Ended

• startsAt in future + endsAt in future = Scheduled

IMPORTANT NOTES:

• 15-minute latency between API and UI

• Activity stays in API-set state even if UI status changes (e.g., if you set to "approved" and end date passes, UI shows "Ended" but state remains "approved")

• Workspace ID required for premium customers (must have "approver" privilege)

• Provide complete activity object - this is a PUT request that replaces the existing definition

TYPICAL UPDATE STRUCTURE: { "id": 123456, "name": "Updated Activity Name", "state": "saved" | "approved", "priority": 5, "startsAt": "2024-01-01T00:00:00Z", // required if state is "approved" "endsAt": "2024-12-31T23:59:59Z", // required if state is "approved" "locations": { "mboxes": [ { "name": "target-global-mbox", "experiences": [...] } ] }, "experiences": [...], "metrics": [...], "workspace": "workspaceId" // for premium customers }

OPTIONAL FIELDS:

• entryConstraint (visitor percentage, mbox constraints)

• reportingAudiences

• analytics (A4T integration)

• propertyIds

• views (for SPA)

• applicationContext (channel, device type, etc.)

Update the state of an activity (approved, deactivated, saved)

Retrieve AT.js settings including client code, decisioning method, timeout, global mbox configuration, and other AT.js library settings

Retrieve list of available AT.js versions

Create a new audience

List all audiences available in Adobe Target.

USAGE: Use this tool to retrieve available audiences when creating activities with audience targeting. Each audience object contains an 'id' (number) and 'name' (string) that you can display to the user.

WORKFLOW:

1. Call this tool to get list of audiences

2. Present audiences to user in a clear format (e.g., "1) Mobile Users (ID: 12345), 2) Desktop Users (ID: 67890)")

3. User selects audience by name or number

4. Extract the audience ID from the selected audience

5. Pass the ID(s) to createActivityFromModifications via the audienceIds parameter

CRITICAL WARNING: DO NOT USE THIS TOOL FOR NORMAL WORKFLOWS

Activities created via this API are PERMANENTLY LOCKED - they CANNOT be edited in Adobe Target UI.

DEFAULT WORKFLOW (USE THIS 99% OF THE TIME):

1. Create offers using createOffer tool (HTML) or createJsonOffer tool (JSON)

2. Provide user with offer IDs

3. User manually builds XT activity in Target UI with full editing flexibility

DO NOT USE THIS TOOL UNLESS:

1. User is creating 10+ activities in bulk (programmatic bulk creation)

2. This is part of an automated CI/CD workflow

3. User has been EXPLICITLY WARNED that activities cannot be edited in Target UI

4. User has confirmed they understand the limitation and still want to proceed

MANDATORY STEPS BEFORE USING THIS TOOL: You MUST complete ALL of these steps before calling this tool:

1. Ask user: "Are you creating 10+ activities in bulk?"

   • If NO: Stop. Tell user to use createOffer workflow instead

   • If YES: Continue to step 2

2. Warn user: "Activities created via API will be permanently locked and cannot be edited in Adobe Target UI. You will not be able to modify them later through the Target interface. Do you understand and want to proceed?"

   • If NO: Stop. Use createOffer workflow instead

   • If YES: Continue to step 3

3. Confirm: "To confirm: You understand the activity will be locked in Target UI and you still want to create it programmatically?"

   • If NO: Stop. Use createOffer workflow

   • If YES: Proceed with this tool

If user does NOT confirm all three steps, DO NOT use this tool. Use createOffer instead.

RECOMMENDED ALTERNATIVE (99% of use cases): Use createOffer to create offers, then tell user: "I've created the offers. Here are the offer IDs: [list IDs] To create your XT activity:

1. Go to Adobe Target → Activities → Create Activity → Experience Targeting

2. Choose Form-Based Experience Composer

3. Add experiences and select these offer IDs

4. Configure audience targeting This gives you full editing flexibility in the Target UI."

CRITICAL WORKFLOW REQUIREMENTS FOR LLM (IF YOU MUST USE THIS TOOL):

1. BEFORE generating code, ask user: "Do you have any links or image assets that need to be used in this experience?"

   • If user provides links/images: Use the exact URLs provided

   • If user says "no" or doesn't provide assets: Use placeholder links (e.g., "https://example.com/image.jpg" or "#" for links)

   • Document any placeholders clearly so user knows what to replace

2. Generate the modification code following ALL Adobe Target coding rules CRITICAL: NEVER include emojis in generated code, HTML, text, or comments

3. PREVIEW THE CODE FIRST - Use Chrome DevTools MCP to inject and test:

   • Use Chrome DevTools MCP to navigate to the target URL

   • Inject the generated JavaScript code into the live page (with optional preview indicator for visual confirmation)

   • User will see changes live in their Chrome browser

   • Ask: "Does this look correct? Should I create the activity?"

   • If user wants changes, modify code and preview again

   • ONLY proceed to create activity after user approves the preview

   IMPORTANT: The preview indicator is ONLY for preview - do NOT include it in the modifications parameter when creating the activity

   RESPONSIVE TESTING - Test the experience across viewports:

   • ALWAYS test experiences on both mobile and desktop viewports before creating activity

   • Use Chrome DevTools MCP resize_page tool to test different viewport sizes

   • Standard viewport sizes to test:

     • Mobile: 375x667 (iPhone SE) or 390x844 (iPhone 14)

     • Desktop: 1920x1080 or 1440x900

   • After injecting code, resize to mobile viewport and ask user to check

   • Then resize to desktop viewport and ask user to check

   • Ensure the experience works correctly on both viewports before proceeding

   • If experience has responsive issues, modify the code to fix them

   Example responsive testing flow:

   1. Navigate to URL

   2. Inject modification code

   3. Resize to 375x667 (mobile)

   4. Ask: "Check mobile view in Chrome. Does it look correct?"

   5. Resize to 1920x1080 (desktop)

   6. Ask: "Check desktop view in Chrome. Does it look correct?"

   7. Only proceed if both viewports are approved

4. After user approves preview, create the activity:

   • Show the user a summary of what will be created

   • List any placeholder assets that need to be replaced

   • Call this tool to create the activity

   • NOTE: Audience targeting will be handled by the user manually in Target UI

5. NEVER create an activity without previewing it first

6. NEVER create an activity based on assumptions - always confirm via preview

Example workflow: LLM: "Do you have any links or images for this experience?" User: "No" LLM: [Generates clean, responsive modification code with media queries] LLM: "Let me preview this for you..." LLM: [Uses Chrome DevTools MCP to navigate and inject code - adds preview indicator] LLM: [Resizes viewport to 375x667 mobile] LLM: "Check your Chrome browser (mobile view). The button is now green with text 'Get Started Now'. Does this look correct?" User: "Yes" LLM: [Resizes viewport to 1920x1080 desktop] LLM: "Now check desktop view. Does it look correct?" User: "Yes, looks good" LLM: [Calls this tool with the clean modification code - NO preview indicator]

ADOBE TARGET CODE GENERATION RULES: You MUST follow these rules when generating JavaScript code for the modifications parameter:

DOM & Element Handling:

• Do NOT use DOM ready functions (no $(document).ready, DOMContentLoaded, etc.) unless explicitly asked

• Use specific selectors - NEVER use broad selectors like 'div', 'span', 'button' alone. Always use classes, IDs, or attribute selectors

• Modify existing elements - Change text/styles/attributes rather than replacing entire DOM structures

• Use hide/show patterns - Toggle visibility rather than remove/add elements

• Insert content through Target - Do not directly modify HTML structure with new divs

Code Quality & Compatibility:

• ES5 ONLY - Adobe Target cannot accept ES6 features:

  • NO backticks or template literals (use string concatenation with +)

  • NO arrow functions (use function() {} syntax)

  • NO const/let (use var only)

  • NO destructuring, spread operators, or other ES6+ features

• No external dependencies - Don't load jQuery, libraries, or external scripts

• Vanilla JavaScript only - Keep it simple and cross-browser compatible

• Defensive coding - Always check if element exists: if (element) { ... }

• Avoid global variable pollution - Wrap code in IIFE: (function() { ... })()

• Idempotent code - Script might run multiple times; ensure it handles that gracefully

Styling:

• Inline styles for specificity - Use element.style.property = value to override existing styles

• Inject CSS in tags - If adding CSS rules, inject a block in

• !important sparingly - Only use when absolutely necessary for specificity

• Prefix new classes with "at-" - ALL new classes you create must start with "at-" (e.g., "at-hero-banner", "at-cta-button"). This identifies Target-inserted elements.

• Never style existing page classes - Do NOT write CSS rules targeting existing page classes (too broad, causes conflicts)

• Target existing elements by ID - Use IDs or specific attribute selectors to target existing elements, NOT broad class names

• Example: Use '#main-cta' or '[data-testid="hero-button"]', NOT '.button' or '.cta'

Responsive Design:

• ALWAYS write responsive code that works on both mobile and desktop

• Use media queries when adding CSS via tags: @media (max-width: 768px) { ... }

• Test viewport-specific styles: Mobile (375px-768px), Desktop (1024px+)

• Avoid fixed pixel widths - Use percentages or max-width instead

• Consider mobile-first: Default styles for mobile, enhance for desktop

• Hide/show elements per viewport if needed: display: none on mobile, display: block on desktop

• Font sizes should scale appropriately: Smaller on mobile, larger on desktop

• Button/CTA sizes should be touch-friendly on mobile (min 44x44px tap target)

Performance & Safety:

• Minimize DOM queries - Cache element references: var button = document.querySelector('.cta')

• NO polling/setInterval/setTimeout - NEVER use timers for waiting. Bad for browser performance.

• Target fires after DOM ready - Elements should already exist when code runs

• Defensive coding - Always check if element exists: if (element) { modify it }

• If element doesn't exist, fail gracefully (don't throw errors)

• No document.write() - Breaks page after load

• Preserve existing functionality - Don't remove event listeners or break page behavior

Documentation:

• Add inline comments - Explain what each modification does (helps editing in Target UI later)

• Include selector explanations - Comment why specific selector was chosen

Conversion Tracking:

• ALWAYS add dataLayer tracking to conversion elements (buttons, CTAs, forms, etc.)

• Add datalayer tracking to any negative user actions too like closing a popup or offer

• Use the generateDataLayerEvent tool to generate tracking code

• Ask the User for the name of the test to populate at_activity

• Attach click/submit event listeners that fire: dataLayer.push({event: "target_conversion", at_activity: "...", at_experience: "..."})

• Event structure must be: event="target_conversion", at_activity="...", at_experience="..."

• NO template literals - use string concatenation only for ES5 compatibility

• Example: element.addEventListener('click', function() { dataLayer.push({event: 'target_conversion', at_activity: 'Hero Test', at_experience: 'Variant A'}); });

Generate ES5-compatible event tracking code for Adobe Target activity conversions. Supports multiple tag managers with configurable event structures and firing conditions.

SUPPORTED TAG MANAGERS:

• gtm: Google Tag Manager (dataLayer.push)

• adobeLaunch: Adobe Experience Platform Tags (_satellite.track)

• tealium: Tealium iQ (utag.link)

• segment: Segment Analytics (analytics.track)

• customDataLayer: Custom dataLayer implementation

USAGE: When creating or modifying Target experiences with conversion elements (buttons, links, forms), use this tool to generate click tracking code.

WORKFLOW:

1. User creates an experience with a button/link/conversion element

2. LLM identifies the conversion element selector

3. LLM asks: "What should I name this activity?" (if not already provided)

4. LLM asks: "What experience name should I use?" (e.g., "Experience A", "Control", "Variant B")

5. TAG MANAGER SELECTION:

   • If full-page extraction was done earlier, check context for tagManagers.summary.recommendedForTracking

   • If tag manager was auto-detected, use that (inform user: "I detected {name} on the page")

   • If NOT detected or no full-page extraction in context, ask: "Which tag manager are you using?" (default: adobeLaunch)

6. LLM MUST ASK: "When should this conversion event fire?" and present these options:

   1. Every time (no limit) - DEFAULT - Track every interaction 2. Once per session - Track only once per session (prevents duplicate conversions) 3. Once per page - Track only once per page load 4. Once ever - Track only once, stored permanently 5. Throttle - Limit frequency (e.g., max once per second) 6. Debounce - Wait for user to stop interacting

   Default is "always" (every time). User can override if needed.

7. LLM calls this tool with selector, activity_name, experience_name, tag_manager (auto-detected or selected), and firing_condition

8. Tool returns ES5-compatible click event listener code with firing condition logic

9. LLM includes this code in the activity modifications

FIRING CONDITIONS:

• always: No limit, fires every time - DEFAULT

• once_per_session: Fires once per session (uses sessionStorage) - For preventing duplicate conversions

• once_per_page: Fires once per page load (uses flag)

• once_ever: Fires once ever (uses localStorage)

• throttle: Limits frequency (requires interval parameter in ms)

• debounce: Waits for user to stop (requires delay parameter in ms)

IMPORTANT:

• ALWAYS ask about firing conditions - don't assume

• Default is "always" (fires every time) - user can override if needed

• Attach to ALL conversion elements (buttons, CTAs, forms, etc.)

• Attach to the most specific selector possible

• Attach to negative user actions aswell, like ignoring a popup or closing a modal

• activity_name should match the Target activity name

• experience_name should be descriptive (e.g., "Control", "Variant A", "Green Button Test")

• Generated code is ES5-compatible (no template literals, arrow functions, const/let)

• Code includes defensive check for element and tag manager object existence

• NO polling/setInterval - Target fires after DOM ready, so elements should already exist

Generate a preview script for Chrome DevTools MCP to inject modifications into a live page.

WORKFLOW REQUIREMENTS FOR LLM:

1. Before calling this tool, explain to the user what modifications you're about to preview

2. Show them the specific selectors and changes (e.g., "I'll change the button .cta-primary to have a blue background")

3. Call this tool to get the preview script

4. Use Chrome DevTools MCP 'navigate_to' to load the page (if not already open) IMPORTANT: use a timeout of 30000 ms to ensure the page fully loads

5. Use Chrome DevTools MCP 'evaluate_script' with the provided script to inject the modifications

6. Ask the user to review the changes visually in their browser

7. Wait for user approval before creating the activity

This approach uses Chrome DevTools MCP and execute_script for live preview

Extract detailed page structure to prepare for mockup comparison and experience generation.

MOCKUP-TO-EXPERIENCE WORKFLOW: This tool is the FIRST STEP when a user provides a mockup/screenshot and wants to create an experience.

Workflow:

1. User provides: mockup screenshot + target URL

2. LLM calls THIS TOOL with the URL to get current page structure

3. LLM analyzes mockup image (using vision) vs current page data

4. LLM identifies differences (layout, colors, text, positioning, etc.)

5. LLM generates ES5 modification code following ALL Adobe Target coding rules

6. LLM shows user the proposed changes for approval

7. LLM calls createActivityFromModifications to deploy

IMPORTANT INSTRUCTIONS FOR LLM: When user provides a mockup/screenshot:

1. Ask user: "What's the URL of the page this mockup is for?"

2. Ask user: "Do you have any links or image assets that need to be used in this experience?"

   • If user provides links/images: Use the exact URLs provided

   • If user says "no" or doesn't provide assets: Use placeholder links (e.g., "https://example.com/image.jpg" or "#")

3. Call THIS TOOL with the URL

4. Analyze the mockup screenshot carefully:

   • Identify visual differences from current page

   • Note layout changes, color changes, text changes, new elements

   • Look for CSS properties: colors, fonts, spacing, positioning

   • Identify which elements need modification (use specific selectors)

5. Generate modification code that:

   • Follows ALL Adobe Target code generation rules (ES5 only, at- prefix, etc.)

   • Uses specific selectors (IDs, data attributes, NOT broad classes)

   • Waits for elements to exist before modifying

   • Is well-commented explaining each change

6. Show user the generated code and explain the changes

7. After approval, call createActivityFromModifications

KEY ANALYSIS POINTS:

• Compare mockup colors vs current page colors

• Compare mockup text vs current page text

• Compare mockup layout/positioning vs current page

• Identify new elements in mockup that need to be created

• Identify hidden elements that need to be shown/hidden

• Note font changes, size changes, spacing changes

Get details of a specific mbox by name, including location ID, name, and associated audience IDs

List all profile attributes associated with mboxes in Adobe Target

List all mboxes

SPECIALIZED TOOL - FOR SPAs, SERVER-SIDE, MOBILE, AND HEADLESS

Create JSON offers for applications that consume structured data (not HTML/DOM changes).

DO NOT USE THIS AS THE DEFAULT - Use createOffer (HTML) for most use cases!

CRITICAL: THIS TOOL CREATES OFFERS, NOT ACTIVITIES When users mention activity types like "A/B test", "XT", "Experience Targeting", etc., they are describing HOW the offer will be used, NOT what to create via API. ALWAYS create an OFFER using this tool, then the user builds the activity in Target UI.

=============================================================================== COMPLETE END-TO-END WORKFLOW FOR JSON OFFERS

TYPICAL REQUEST: "Create A/B test for product recommendations data in my React app"

STEP 1: SHOW JSON TO USER IN MCP CLIENT Before creating the offer, display the JSON structure to the user in the MCP client output. Ask: "Here's the JSON I'll create. Does this look correct?"

Example: User: "Create JSON offer with product recommendations" LLM: "I'll create this JSON offer:

{
  "products": [
    {"id": "123", "name": "Widget", "price": 29.99},
    {"id": "456", "name": "Gadget", "price": 49.99}
  ],
  "layout": "grid"
}

Does this structure look correct for your needs?"

User reviews the JSON in the MCP client → Confirms → LLM proceeds to Step 2

STEP 2: CREATE JSON OFFERS (After User Approval) Create one JSON offer per variation/experience:

A/B Test Pattern (Most Common):

• Control Offer: Original/baseline data configuration

• Variant Offer: New data configuration being tested

• Total: 2 JSON offers

Example A/B Test: User: "Test 2 different product recommendation algorithms" → Control Offer: {"algorithm": "collaborative", "maxItems": 4} → Variant Offer: {"algorithm": "content-based", "maxItems": 6} → User creates A/B activity in Target UI with these 2 JSON offers

Experience Targeting (XT) Pattern:

• One JSON offer per audience segment

• Each offer contains data tailored to specific audience

• Total: 1+ JSON offers

Example XT: User: "Show different features to free vs premium users" → Free User Offer: {"features": ["basic", "limited"], "upsell": true} → Premium User Offer: {"features": ["advanced", "unlimited", "priority"], "upsell": false} → User creates XT activity in Target UI with these 2 JSON offers + audience rules

Feature Flags Pattern:

• JSON offers control feature availability

• A/B test feature enablement

Example Feature Flags: User: "Test new checkout flow with 50% of users" → Control Offer: {"newCheckout": false, "checkoutVersion": "v1"} → Variant Offer: {"newCheckout": true, "checkoutVersion": "v2"}

IMPORTANT JSON OFFER RULES:

1. Create separate JSON offers for each variation (don't combine in one offer)

2. Each JSON offer should have consistent schema (same keys, different values)

3. Your application must handle consuming and applying the JSON data

4. Name offers clearly: "[Test Name] - [Variation Name]"

STEP 3: PROVIDE OFFER IDs TO USER (Required) After creating JSON offers, tell the user:

"I've created [N] JSON offers for your [activity type]:

OFFER IDs:

• [Offer Name]: ID [12345]

• [Offer Name]: ID [67890]

NEXT STEPS - Create Activity in Adobe Target UI:

1. Go to Adobe Target → Activities → Create Activity → [A/B Test | Experience Targeting | etc.]

2. Choose Form-Based Experience Composer

3. Set location to: target-global-mbox (or your preferred mbox)

4. For Experience A:

   • Click 'Change Content' → JSON Offer

   • Search for offer ID: [12345]

   • Select the offer

5. Click 'Add Experience' for Experience B

   • Select offer ID: [67890]

6. Configure traffic allocation

7. Set up success metrics

8. Name your activity and save

APPLICATION INTEGRATION: Your application needs to retrieve and use the JSON offer:

Client-side (SPA with at.js): adobe.target.getOffer({ mbox: "target-global-mbox", success: function(offer) { var jsonData = offer[0].content; // Your JSON data // Use jsonData to configure your app } });

Server-side (Node.js, Java, .NET, Python): Use Adobe Target Delivery API or SDK to retrieve JSON offer Parse the JSON and use it to configure server-side rendering

Mobile (iOS, Android): Use Adobe Target Mobile SDK to retrieve JSON offer Parse and apply to mobile app UI/behavior"

CONTROL VS VARIANT GUIDANCE FOR JSON OFFERS:

What is a Control?

• The baseline data configuration (current algorithm, current settings)

• Used to compare performance against new configurations

What is a Variant?

• The new data configuration being tested

• Different values/settings you're testing for better performance

How many JSON offers to create:

A/B Test (2 JSON offers): → Control: Current configuration → Variant A: New configuration

A/B/n Test (3+ JSON offers): → Control: Current configuration → Variant A: First alternative configuration → Variant B: Second alternative configuration

Experience Targeting (1+ JSON offers): → One JSON offer per audience segment → Each with data tailored to that segment

Example conversation: User: "A/B test product recommendations" LLM: "I'll create 2 JSON offers for your A/B test:

1. Control - current recommendation algorithm

2. Variant - new recommendation algorithm What data should each offer contain?"

WHEN TO USE THIS TOOL (JSON OFFERS):

• User explicitly asks for "JSON offer" or "JSON content"

• User mentions "SPA", "React", "Vue", "Angular", "single-page application"

• User mentions "server-side", "backend", "API", "SDK" (Node.js, Java, .NET, Python)

• User mentions "mobile app" (iOS, Android)

• User mentions "headless", "API-driven", "cross-channel"

• User mentions "IoT", "kiosk", "connected TV", "email personalization"

• User wants structured data that their application will consume

• User is testing different data configurations (feature flags, product data, pricing, etc.)

WHEN NOT TO USE (Use createOffer instead):

• User asks to create/modify page elements (carousel, button, banner, modal, etc.)

• Traditional A/B tests with visual changes

• DOM modifications

• Adding HTML content to the page

• Most standard Target use cases (95%+ of requests)

IF USER REQUEST IS AMBIGUOUS: Ask: "How will this content be used?"

• "Will your application consume this as JSON data (SPA, server-side, mobile app)?"

• "Or do you want to modify the page's HTML/DOM directly (change buttons, add banners, etc.)?"

Decision:

• If user says "consume as JSON" or "server-side" or "mobile app" → Use this tool (createJsonOffer)

• If user says "modify page" or "change HTML" or "add elements" → Use createOffer instead

• Default to createOffer (HTML) if still unclear after asking

WHY USE THIS TOOL (when appropriate):

• JSON offers created via API CAN be fully edited in Adobe Target UI

• User maintains full control and flexibility in Target UI

• User can build/modify activities in Target manually

• No limitations or restrictions

JSON offers deliver structured data to your application, typically for:

• Single Page Applications (SPAs) - React, Vue, Angular consuming JSON client-side

• Server-side integrations - Node.js, Java, .NET, Python SDKs consuming JSON

• Mobile apps - iOS, Android apps consuming JSON via Adobe Target Mobile SDKs

• Headless/API-driven experiences - Decoupled frontend consuming Target decisioning

• Cross-channel delivery - Email, IoT, kiosks, connected TVs

• Feature flags and configuration data - Dynamic app behavior

• Product/pricing data - E-commerce personalization

HOW JSON OFFERS WORK:

• JSON offers are NOT automatically applied to the page (unlike HTML offers)

• Your application must explicitly retrieve the JSON offer using:

  • Client-side: Target's at.js getOffer() method for SPAs

  • Server-side: Target Delivery API or SDKs (Node.js, Java, .NET, Python)

  • Mobile: Adobe Target Mobile SDKs

• Your application consumes the JSON and renders/uses it however needed

• Example: Target returns {"buttonColor": "green", "headline": "Sale!"}, your app reads and applies it

After creating the JSON offer, user builds the activity in Target UI (recommended workflow).

=============================================================================== TEMPLATE SEARCH WORKFLOW (Do This First):

Before creating JSON from scratch, search for existing templates that match the user's request:

1. SEARCH FOR MATCHING TEMPLATES:

   • Use MCP Resources to access templates (URIs like template://json/feature-flags)

   • Look for templates matching user's request by:

     • Template name (e.g., "feature-flags" for "feature flags")

     • Keywords and descriptions

   • Common template matches:

     • "products", "recommendations", "ecommerce" → template://json/product-recommendations

     • "features", "flags", "toggle", "beta" → template://json/feature-flags

     • "hero", "banner", "config" → template://json/hero-config

     • "pricing", "plans", "tiers", "subscription" → template://json/pricing-data

     • "personalization", "targeting", "offers" → template://json/personalization-content

2. IF TEMPLATE FOUND: a) Read the template using MCP Resource (e.g., template://json/feature-flags) b) Parse the template JSON to get name, description, content, and variables c) Show template to user: "I found a '{name}' template: {description}. Would you like to use it as a starting point, or would you prefer I create custom JSON?" d) If user chooses template:

   • Ask user for required variable values (marked as required: true in template)

   • Ask about optional variables (show defaults from template)

   • Replace all {{VARIABLE}} placeholders in content with user's values

   • Convert the content to proper JSON (replace string placeholders with actual values)

   • Show the populated JSON to user

   • Ask: "Does this look good? Should I create this offer in Target?"

   • If yes: Call createJsonOffer tool with the populated JSON content e) If user prefers custom JSON:

   • Continue to WORKFLOW section below

3. IF NO TEMPLATE FOUND:

   • Continue to WORKFLOW section below

IMPORTANT NOTES ABOUT JSON TEMPLATES:

• Templates provide structured, tested JSON schemas for common use cases

• Templates ensure consistent data structure across offers

• You can modify template JSON after populating variables if user requests changes

• Templates are located in src/templates/json/

• Each template has a variables array defining what needs to be replaced

• Variable replacement in JSON templates:

  • String values: {{VARIABLE}} → "user value"

  • Number values: {{VARIABLE}} → 123 (no quotes)

  • Boolean values: {{VARIABLE}} → true/false (no quotes)

  • Arrays: Keep JSON array structure, replace individual items

===============================================================================

USAGE: JSON offers allow you to return structured data instead of HTML. The content should be a valid JSON object that your application can consume.

WORKFLOW (if not using templates):

1. Define your JSON structure (e.g., product data, configuration, feature flags)

2. Create the offer with this tool

3. Use the returned offer ID in your Target activity

4. Your application receives the JSON when the activity fires

CONTENT RULES:

• NEVER include emojis in JSON content, property values, or any part of the offer

• Keep all text values professional and emoji-free

• Use plain text only for all content

IMPORTANT:

• Content must be a valid JSON object

• Offers created via API CAN be edited in Adobe Target UI

• Use with Form-Based Experience Composer or server-side decisioning

• Workspace parameter is optional (uses TARGET_WORKSPACE_ID from config if not provided)

EXAMPLES:

1. Product Recommendations: { "products": [ {"id": "123", "name": "Widget", "price": 29.99}, {"id": "456", "name": "Gadget", "price": 49.99} ], "layout": "grid" }

2. Feature Flags: { "features": { "newCheckout": true, "darkMode": false, "beta": true } }

3. Hero Banner Configuration: { "heading": "Summer Sale", "subheading": "Save up to 50%", "ctaText": "Shop Now", "ctaUrl": "/sale", "imageUrl": "https://example.com/banner.jpg", "backgroundColor": "#FF5733" }

4. A/B Test Variant Data: { "variant": "B", "buttonColor": "green", "buttonText": "Get Started Now", "headline": "Transform Your Business Today" }

PRIMARY DEFAULT WORKFLOW - USE THIS FOR 95%+ OF ALL USE CASES

Create HTML/CSS/JavaScript offers for DOM modifications and visual changes.

THIS IS THE MAIN TOOL FOR ADOBE TARGET CONTENT DEVELOPMENT

CRITICAL: THIS TOOL CREATES OFFERS, NOT ACTIVITIES When users mention activity types like "A/B test", "XT", "Experience Targeting", "Automated Personalization", etc., they are describing HOW the offer will be used, NOT what to create via API.

ALWAYS create an OFFER using this tool, regardless of activity type mentioned:

• "Create an A/B test banner" → Create OFFER with banner code

• "Create an XT experience" → Create OFFER with experience code

• "Create an Automated Personalization element" → Create OFFER with element code

The user will then use these offers in the Target UI to build their activity (A/B, XT, AP, etc.).

=============================================================================== COMPLETE END-TO-END WORKFLOW

TYPICAL REQUEST: "Create an A/B test for a new hero banner on example.com/products"

STEP 1: PAGE EXTRACTION (When Needed) Extract the page structure to understand what you're modifying:

When to extract:

• User wants to modify existing elements (change button color, update text, hide section)

• Need to understand page structure (find selectors, IDs, classes)

• Need to know where to insert new elements (parent hierarchy, insertion points)

• Unsure what elements exist on the page

When NOT to extract (skip to Step 2):

• Creating standalone element with no page context needed (simple banner, modal)

• User already provided selectors/IDs to target

• Very simple modifications that don't need page analysis

How to extract:

1. Call getPageStructureSnippets with extractionType: 'full-page'

2. Use Chrome DevTools MCP to navigate to the page

3. Execute the extraction script

4. Call extractPageStructure to save data and get summary

5. Use queryPageStructure to find specific elements as needed

Example:

• Get extraction script → Navigate to page → Execute script → Save structure

• Query for button: queryPageStructure(sessionId, 'find-by-id', 'cta-button')

• Get hierarchy: queryPageStructure(sessionId, 'get-element-hierarchy', 'hero-section')

STEP 2: GENERATE PREVIEW (REQUIRED - ALWAYS DO THIS BEFORE CREATING OFFERS) Generate a preview of the modifications and show it to the user in Chrome BEFORE creating any offers:

CRITICAL: This step is MANDATORY and must ALWAYS be executed before calling createOffer. The preview runs client-side in Chrome and does NOT require Adobe auth, so it will work even if your auth token is expired.

How to generate preview:

1. Generate the offer code following all Adobe Target rules (see ADOBE TARGET CODE GENERATION RULES section)

2. Call generatePreviewScript with:

   • modifications: The JavaScript code that makes the DOM changes

   • description: Clear description of what changes will be made

   • url: The URL where preview should be shown

3. Use Chrome DevTools MCP navigate_to to load the page (IMPORTANT: use timeout of 30000ms)

4. Use Chrome DevTools MCP evaluate_script to inject the preview script

5. The page will show a red "Target Preview Active" indicator

6. Ask the user: "Please review the changes in your browser. Does this look good?"

7. Wait for user approval before proceeding to Step 3

Example: User: "Create a green CTA button" LLM: Generates button code → Calls generatePreviewScript → Uses Chrome DevTools MCP to show preview → User sees green button in browser → User says "looks good" → LLM proceeds to Step 3

WHY THIS STEP IS REQUIRED:

• User can see and approve changes BEFORE any offers are created

• Preview works even if Adobe auth token is expired (client-side only)

• Prevents wasted API calls for offers that user might reject

• Better user experience - visual confirmation before commitment

• If auth fails in Step 3, user has still seen the preview

STEP 3: CREATE OFFERS (Only After Preview Approval) Create one offer per variation/experience:

A/B Test Pattern (Most Common):

• Control Offer: Original/baseline version (often minimal or no changes)

• Variant Offer: New version being tested

• Total: 2 offers

Example A/B Test: User: "Test a green button vs current blue button" → Control Offer: No changes (or minimal code to track existing button) → Variant Offer: Change button to green + tracking code → User creates A/B activity in Target UI with these 2 offers

Experience Targeting (XT) Pattern:

• One offer per audience segment

• Each offer tailored to specific audience

• Total: 1+ offers (depends on number of segments)

Example XT: User: "Show different hero to mobile vs desktop users" → Mobile Offer: Mobile-optimized hero banner → Desktop Offer: Desktop-optimized hero banner → User creates XT activity in Target UI with these 2 offers + audience rules

Multivariate Test (MVT) Pattern:

• One offer per element per variation

• Test multiple elements simultaneously

• Total: Many offers (elements × variations)

Example MVT: User: "Test headline (2 versions) and button (2 colors)" → Headline A Offer, Headline B Offer → Button Green Offer, Button Red Offer → Total: 4 offers → User creates MVT activity in Target UI testing all combinations

IMPORTANT OFFER CREATION RULES:

1. Create separate offers for each variation (don't combine in one offer)

2. Each offer should be self-contained and work independently

3. Control offer can be empty/minimal if testing against current page

4. Always include tracking code for conversion elements

5. Name offers clearly: "[Test Name] - [Variation Name]" (e.g., "Hero Test - Variant A")

STEP 4: PROVIDE OFFER IDs TO USER (Required) After creating offers, tell the user:

"I've created [N] offers for your [activity type]:

OFFER IDs:

• [Offer Name]: ID [12345]

• [Offer Name]: ID [67890]

NEXT STEPS - Create Activity in Adobe Target UI:

1. Go to Adobe Target → Activities → Create Activity → [A/B Test | Experience Targeting | etc.]

2. Choose Form-Based Experience Composer

3. Set location to: target-global-mbox (or your preferred mbox)

4. For Experience A:

   • Click 'Change Content' → HTML Offer

   • Search for offer ID: [12345]

   • Select the offer

5. Click 'Add Experience' for Experience B (repeat for each variation)

   • Select offer ID: [67890]

6. Configure traffic allocation (e.g., 50/50 split for A/B test)

7. Set up success metrics (conversions, engagement, revenue)

8. Review audience targeting (if needed for XT)

9. Name your activity and save

BENEFITS:

• Full control in Target UI

• Can edit offers anytime

• Can edit activity settings

• QA mode works normally

• Reporting and analytics fully functional"

CONTROL VS VARIANT GUIDANCE:

What is a Control?

• The baseline/original experience (what users see now)

• Used to compare against new variations

• Can be "no changes" or the existing page as-is

What is a Variant?

• The new experience being tested

• Contains your modifications/improvements

• What you're testing to see if it performs better than control

How many offers to create:

A/B Test (2 offers): → Control: Existing experience (minimal code or tracking only) → Variant A: New experience with changes

A/B/n Test (3+ offers): → Control: Existing experience → Variant A: First alternative → Variant B: Second alternative → Variant C: Third alternative (etc.)

Experience Targeting (1+ offers): → One offer per audience segment → No "control" concept - each audience gets tailored experience

Example conversation: User: "Create an A/B test for a new banner" LLM: "I'll create 2 offers for your A/B test:

1. Control - keeps existing page as-is (no banner)

2. Variant - adds your new banner Should I proceed?"

User: "Test 3 different button colors" LLM: "I'll create 4 offers for your A/B/n test:

1. Control - current button (blue)

2. Variant A - green button

3. Variant B - red button

4. Variant C - purple button Should I proceed?"

WHEN TO USE THIS TOOL (HTML OFFERS):

• User asks to create/modify page elements (carousel, button, banner, modal, form, etc.)

• User mentions ANY activity type (A/B, XT, AP) - just create the offer

• Traditional A/B tests with visual changes

• Experience Targeting (XT) experiences

• DOM modifications (change text, colors, layout, etc.)

• Adding new page elements

• Most standard Target use cases

• When user doesn't specify "JSON" or "SPA"

WHEN NOT TO USE (Use createJsonOffer instead):

• User explicitly asks for "JSON offer" or "JSON content"

• User mentions "SPA", "React", "Vue", "Angular", "headless", "API-driven"

• User wants structured data without DOM changes

• User is building a single-page application that consumes JSON

IF UNCLEAR WHICH TO USE: Ask the user: "Are you working with a single-page application (SPA) that consumes JSON data, or do you want to modify the page's HTML/DOM directly?"

• If "SPA/JSON": Use createJsonOffer

• If "HTML/DOM": Use this tool (createOffer)

• Default to this tool (HTML) if user is still unclear

WHY USE THIS TOOL AS DEFAULT:

• Offers created via API CAN be fully edited in Adobe Target UI

• User maintains full control and flexibility in Target UI

• User can build/modify activities in Target with Visual Experience Composer

• QA mode and previews work normally

• No limitations or restrictions

DO NOT create activities programmatically unless:

• User explicitly requests bulk creation (10+ activities)

• User explicitly asks for programmatic activity creation after being warned about UI limitations

For 99% of use cases: CREATE OFFERS ONLY, let user build activity in Target UI.

=============================================================================== COMPLETE A/B TEST WORKFLOW (USE THIS APPROACH FOR ALL TARGET CONTENT CREATION & DEVELOPMENT)

When a user asks to create an A/B test, experience, or personalization:

TEMPLATE SEARCH (Do This First): Before generating code from scratch, search for existing templates that match the user's request:

1. SEARCH FOR MATCHING TEMPLATES:

   • Use MCP Resources to access templates (URIs like template://html/carousel)

   • Look for templates matching user's request by:

     • Template name (e.g., "carousel" for "create a carousel")

     • Keywords and descriptions

   • Common template matches:

     • "carousel", "slider", "gallery" → template://html/carousel

     • "hero", "banner" → template://html/hero-banner

     • "button", "cta" → template://html/cta-button

     • "modal", "popup", "overlay" → template://html/modal

     • "sticky", "announcement", "notification" → template://html/sticky-header

     • "countdown", "timer", "urgency" → template://html/countdown-timer

2. IF TEMPLATE FOUND: a) Read the template using MCP Resource (e.g., template://html/carousel) b) Parse the template JSON to get name, description, content, and variables c) Show template to user: "I found a '{name}' template: {description}. Would you like to use it as a starting point, or would you prefer I generate custom code?" d) If user chooses template:

   • Ask user for required variable values (marked as required: true in template)

   • Ask about optional variables (show defaults from template)

   • Replace all {{VARIABLE}} placeholders in content with user's values

   • Show the populated code to user

   • Ask: "Does this look good? Should I preview this in Chrome?"

   • If yes: Continue to STEP 2 (GENERATE PREVIEW), then STEP 3A.6 (CREATE OFFER) with the populated template code

   • If user wants changes: Modify the code and ask again e) If user prefers custom code:

   • Continue to STEP 1 (PAGE EXTRACTION) below

3. IF NO TEMPLATE FOUND:

   • Continue to STEP 1 (PAGE EXTRACTION) below

IMPORTANT NOTES ABOUT TEMPLATES:

• Templates already follow all Adobe Target rules (ES5, IIFE, responsive, defensive coding, no emojis)

• Templates are tested and working - use them when available to save time

• You can modify template code after populating variables if user requests changes

• Templates are located in src/templates/html/

• Each template has a variables array defining what needs to be replaced

STEP 1: ASK CLARIFYING QUESTIONS Before generating any code, ask the user: a) "Do you have any links or image assets that need to be used?"

• If yes: Use their exact URLs

• If no: Add placeholders and document them. b) "How many variations do you want to test?" (if not specified) c) "What page element are you targeting?" (if not clear from the initial request) d) "Would you like me to create the offers in Target, or just show you the code?"

• If "create offers": Follow STEP 2 (GENERATE PREVIEW), then STEP 3A

• If "just show code": Follow STEP 2 (GENERATE PREVIEW), then STEP 3B

STEP 3A: GENERATE AND CREATE OFFERS (Use This Tool) For each variation:

3A.1 IDENTIFY CONVERSION ELEMENTS

• Determine if this variation creates or modifies conversion elements (buttons, CTAs, links, forms)

• If YES: Continue to Step 3A.2

• If NO (only visual changes): Skip to Step 3A.4

3A.2 ASK ABOUT TRACKING (REQUIRED FOR NEW ELEMENTS) Before generating code: a) TAG MANAGER SELECTION:

• If full-page extraction was done earlier (getPageStructureSnippets with extractionType: 'full-page'), check context for tagManagers.summary.recommendedForTracking

• If tag manager was auto-detected, use that and inform user: "I detected {name} on the page, I'll use that for tracking"

• If NOT detected or no full-page extraction in context:

  • Read src/config/tag-managers.json to discover available tag managers

  • Ask the user: "Which tag manager are you using?" (default: adobeLaunch)

  • Present the available options from the config file b) Ask the user: "When should the conversion event fire?" (default: always) Present these options clearly:

• Every time (no limit) - DEFAULT - Track every interaction

• Once per session - Prevents duplicate tracking (use for conversions if needed)

• Once per page - Track once per page load

• Once ever - Track once, stored permanently

• Throttle - Limit frequency (ask for interval)

• Debounce - Wait for user to stop interacting (ask for delay)

3A.3 GENERATE TRACKING CODE

• Call generateDataLayerEvent tool with:

  • selector: The CSS selector for the conversion element (e.g., ".at-cta-button", "#at-signup-btn")

  • activity_name: The activity name (ask user if not provided)

  • experience_name: The variation name (e.g., "Control", "Variant A", "Green Button")

  • tag_manager: From user's answer in 3A.2a

  • firing_condition: From user's answer in 3A.2b

• Save the returned tracking code

3A.4 GENERATE COMPLETE OFFER CODE

• Generate optimized HTML/CSS/JS code following all Adobe Target rules below

• NEVER include emojis in the generated code or content (text, comments, HTML, etc.)

• If conversion element exists (from 3A.1):

  • Include the DOM modifications (create/modify button, styling, etc.)

  • Include the tracking code from 3A.3 AFTER the DOM modifications

  • Wrap everything in an IIFE: (function() { /* code */ })()

• Ensure all code is ES5-compatible (no backticks, arrow functions, const/let)

3A.5 SHOW CODE TO USER

• Display the complete offer code (including tracking if applicable)

• Explain what the code does

• If tracking was included, note: "This includes conversion tracking for [tag manager] that fires [firing condition]"

3A.6 CREATE OFFER

• Ask: "Should I create this offer in Adobe Target?"

• If yes: Create offer via createOffer tool and save the returned offer ID

• If no: Just provide the code for manual use

Example: Control Offer ID: 2299231 Variant Offer ID: 2299232

STEP 3B: GENERATE CODE ONLY (No Tool Call) For each variation:

3B.1 IDENTIFY CONVERSION ELEMENTS

• Determine if this variation creates or modifies conversion elements (buttons, CTAs, links, forms)

• If YES: Continue to Step 3B.2

• IF NO (only visual changes): Skip to Step 3B.4

3B.2 ASK ABOUT TRACKING (REQUIRED FOR NEW ELEMENTS) Before generating code: a) TAG MANAGER SELECTION (same as STEP 3A.2a):

• If full-page extraction was done earlier, check context for tagManagers.summary.recommendedForTracking

• If tag manager was auto-detected, use that and inform user: "I detected {name} on the page, I'll use that for tracking"

• If NOT detected or no full-page extraction in context:

  • Read src/config/tag-managers.json to discover available tag managers

  • Ask the user: "Which tag manager are you using?" (default: adobeLaunch)

  • Present the available options from the config file b) Ask the user: "When should the conversion event fire?" (default: always) Present the same options as STEP 3A.2b

3B.3 GENERATE TRACKING CODE

• Call generateDataLayerEvent tool with appropriate parameters

• Save the returned tracking code

3B.4 GENERATE COMPLETE CODE

• Generate optimized HTML/CSS/JS code following all Adobe Target rules below

• If conversion element exists: Include tracking code AFTER DOM modifications

• Wrap in IIFE

3B.5 SHOW CODE TO USER

• Show the code with explanation

• If tracking included, note: "This includes conversion tracking for [tag manager] that fires [firing condition]"

• Provide manual instructions: "You can copy this code and paste it into Target UI when creating your offer manually"

STEP 4: PROVIDE NEXT STEPS TO USER After creating offers, provide these EXACT instructions:

"I've created {N} offers for your A/B test. Here's how to set up the activity:

OFFER IDs CREATED:

• Control: {offer_name} (ID: {offer_id})

• Variant: {offer_name} (ID: {offer_id})

NEXT STEPS IN ADOBE TARGET UI:

1. Go to Adobe Target → Activities → Create Activity → A/B Test

2. Choose Form-Based Experience Composer

3. Set location to: {mbox_name} (default: target-global-mbox)

4. For Experience A (Control):

   • Click 'Change Content' → HTML Offer

   • Search for offer ID: {control_offer_id}

   • Select the offer

5. Click 'Add Experience' to create Experience B (Variant)

   • Click 'Change Content' → HTML Offer

   • Search for offer ID: {variant_offer_id}

   • Select the offer

6. Set traffic allocation (default: 50/50 split)

7. Configure goal/metric (default: Page Views - Engagement)

8. Review, name your activity, and save

BENEFITS OF THIS APPROACH:

• You can edit the activity in Target UI

• You can edit the offers in Target UI

• Full flexibility with Visual Experience Composer

• QA mode and previews work normally"

If only code was generated (no offers created), provide these instructions:

"I've generated {N} code variations for your A/B test:

VARIATION {N}: {variation_name} [Show the HTML/CSS/JS code here]

TO USE THIS CODE MANUALLY:

1. Go to Adobe Target → Activities → Create Activity → A/B Test

2. Choose Form-Based Experience Composer

3. For each experience:

   • Click 'Change Content' → Create HTML Offer

   • Paste the code above

   • Name the offer

4. Set traffic allocation (default: 50/50 split)

5. Configure goal/metric (default: Page Views)

6. Save and activate

TIP: If you want me to create these as offers in Target for you (so you can reuse them), just let me know and I'll call the createOffer tool."

===============================================================================

HTML OFFER STRUCTURE (CRITICAL - MUST FOLLOW): When creating HTML offers, the content parameter MUST be properly structured:

REQUIRED STRUCTURE:

• All JavaScript code MUST be wrapped in tags

• CSS CANNOT be added via tags directly - it must be injected via JavaScript

• HTML can be included directly (no wrapper needed)

CSS HANDLING (CRITICAL): Adobe Target HTML offers do NOT support standalone tags. You have TWO options for styling:

OPTION 1: Inject tag into via JavaScript (RECOMMENDED for multiple styles)

OPTION 2: Apply inline styles directly via JavaScript (RECOMMENDED for few styles)

WRONG - Do NOT use standalone tags:

CORRECT - Complete offer example with injected CSS:

CORRECT - Offer with HTML and JavaScript:

===============================================================================

ADOBE TARGET CODE GENERATION RULES (CRITICAL - MUST FOLLOW): When generating code for the content parameter, you MUST follow these rules:

CONTENT RULES:

• NEVER use emojis in generated code, HTML content, text, comments, or anywhere in the offer

• Keep all text, button labels, and content professional and emoji-free

• Use plain text only for all user-facing content

DOM & Element Handling:

• Do NOT use DOM ready functions (no $(document).ready, DOMContentLoaded, etc.) unless explicitly asked

• Use specific selectors - NEVER use broad selectors like 'div', 'span', 'button' alone. Always use classes, IDs, or attribute selectors

• Modify existing elements - Change text/styles/attributes rather than replacing entire DOM structures

• Use hide/show patterns - Toggle visibility rather than remove/add elements

• Insert content through Target - Do not directly modify HTML structure with new divs

Code Quality & Compatibility:

• ES5 ONLY - Adobe Target cannot accept ES6 features:

  • NO backticks or template literals (use string concatenation with +)

  • NO arrow functions (use function() {} syntax)

  • NO const/let (use var only)

  • NO destructuring, spread operators, or other ES6+ features

PREVENTING VARIABLE COLLISIONS (CRITICAL):

• ALWAYS wrap code in IIFE to avoid polluting global scope: (function() { ... })()

• Use local 'var' variables inside IIFE (they won't conflict with page variables)

• IF you absolutely need a global variable (rare - only for cross-offer state):

  • Use window.at_variableName = value; (explicit global with 'at_' prefix)

  • Check if it exists first: if (!window.at_myVar) { window.at_myVar = ...; }

  • NEVER use bare 'var' at top level (creates implicit globals that can overwrite page vars)

Examples: CORRECT - Local variables in IIFE (recommended):

CORRECT - Explicit global when needed (rare):

WRONG - Bare var at top level (can overwrite page variables):

• No external dependencies - Don't load jQuery, libraries, or external scripts

• Vanilla JavaScript only - Keep it simple and cross-browser compatible

• Defensive coding - Always check if element exists: if (element) { ... }

• Idempotent code - Script might run multiple times; ensure it handles that gracefully

Styling:

• Inline styles for specificity - Use element.style.property = value to override existing styles

• Inject CSS in tags - If adding CSS rules, inject a block in

• !important sparingly - Only use when absolutely necessary for specificity

• Prefix new classes with "at-" - ALL new classes you create must start with "at-" (e.g., "at-hero-banner", "at-cta-button"). This identifies Target-inserted elements.

• Never style existing page classes - Do NOT write CSS rules targeting existing page classes (too broad, causes conflicts)

• Target existing elements by ID - Use IDs or specific attribute selectors to target existing elements, NOT broad class names

• Example: Use '#main-cta' or '[data-testid="hero-button"]', NOT '.button' or '.cta'

Responsive Design:

• ALWAYS write responsive code that works on both mobile and desktop

• Use media queries when adding CSS via tags: @media (max-width: 768px) { ... }

• Test viewport-specific styles: Mobile (375px-768px), Desktop (1024px+)

• Avoid fixed pixel widths - Use percentages or max-width instead

• Consider mobile-first: Default styles for mobile, enhance for desktop

• Hide/show elements per viewport if needed: display: none on mobile, display: block on desktop

• Font sizes should scale appropriately: Smaller on mobile, larger on desktop

• Button/CTA sizes should be touch-friendly on mobile (min 44x44px tap target)

Performance & Safety:

• Minimize DOM queries - Cache element references: var button = document.querySelector('.cta')

• NO polling/setInterval/setTimeout - NEVER use timers for waiting. Bad for browser performance.

• Target fires after DOM ready - Elements should already exist when code runs

• Defensive coding - Always check if element exists: if (element) { modify it }

• If element doesn't exist, fail gracefully (don't throw errors)

• No document.write() - Breaks page after load

• Preserve existing functionality - Don't remove event listeners or break page behavior

Documentation:

• Add inline comments - Explain what each modification does (helps editing in Target UI later)

• Include selector explanations - Comment why specific selector was chosen

Conversion Tracking (CRITICAL - FOLLOW STEP 2A.2 AND 2A.3):

• ALWAYS add dataLayer tracking to conversion elements (buttons, CTAs, forms, etc.)

• BEFORE generating the offer code:

  1. Ask user about tag manager preference if not detected automatically (Step 3A.2a or 3B.2a)

  2. Ask user about firing condition (Step 3A.2b or 3B.2b)

  3. Call generateDataLayerEvent tool to get tracking code (Step 3A.3 or 3B.3)

  4. Include the tracking code in the offer AFTER DOM modifications (Step 3A.4 or 3B.4)

• Use the generateDataLayerEvent tool - it generates ES5-compatible code with proper firing conditions

• Place tracking code AFTER DOM modifications in the offer

• Attach click/submit event listeners that fire: dataLayer.push({event: "target_conversion", at_activity: "...", at_experience: "..."})

• Default event structure should be be: event="target_conversion", at_activity="...", at_experience="..." unless specified differently by the user

• NO template literals - use string concatenation only for ES5 compatibility

• Example workflow:

  1. Generate button modification code

  2. Call generateDataLayerEvent(selector: '.at-cta-button', activity_name: 'Hero Test', experience_name: 'Variant A', tag_manager: 'adobeLaunch', firing_condition: 'always')

  3. Include returned tracking code in offer after button code

  4. Show complete offer code to user

Get details of a specific offer

List all offers

Update an existing offer. This is a PUT request that updates the offer's name and/or content.

IMPORTANT: The 'name' parameter is REQUIRED by the Adobe Target API. Even if you're only updating the content, you must provide the current or new name.

WORKFLOW:

1. To update content only: Provide id, current name, and new content

2. To update name only: Provide id, new name, and current content

3. To update both: Provide id, new name, and new content

TIP: If you don't know the current name, use getOffer first to retrieve it.

List all properties

Get orders report data for an A/B Test activity, including conversion metrics and order information

Get performance report for an A/B Test activity with metrics, conversions, and visitor data

Get performance report for an Automated Personalization Test (APT) activity with metrics, conversions, and visitor data

Search for an activity by name and get a detailed performance comparison of all experiences with insights and recommendations. No activity ID needed - just provide the activity name.

Get orders report data for an Experience Targeting (XT) activity, including conversion metrics and order information

Get performance report for an Experience Targeting (XT) activity with metrics, conversions, and visitor data

Create a NEW CUSTOM response token to include data in Adobe Target activity responses.

IMPORTANT: This tool creates NEW custom tokens only. Many common tokens already exist in your account:

• System tokens (experience.id, activity.name, geo.city, etc.) already exist with deletable: false

• These existing tokens can only be ACTIVATED/DEACTIVATED in the Target UI (Administration > Response Tokens)

• Use this tool to create NEW custom tokens that don't already exist

To check existing tokens, use listResponseTokens first.

Response tokens make additional data available in Target's response payload (mbox.js, at.js).

TOKEN TYPES (for creating NEW tokens):

1. BUILT_IN - System-level tokens (e.g., experience.id, activity.name) Example: { token: "experience.id", type: "BUILT_IN" }

2. ACTIVITY - Activity-based attributes (e.g., activity.name, campaign.id) Example: { token: "activity.name", type: "ACTIVITY" }

3. GEO - Geographic data (e.g., geo.city, geo.country) Example: { token: "geo.city", type: "GEO" }

4. CRS - Customer Record Service attributes Example: { token: "crs.customAttribute", type: "CRS" }

5. MBOX - Custom mbox parameters passed in requests (MOST COMMON FOR NEW TOKENS) Example: { token: "profile.userType", type: "MBOX" } Example: { token: "profile.productId", type: "MBOX" } Note: Mbox parameters must be passed by your implementation (at.js/mobile SDK) This is the most common type for creating custom response tokens

6. SCRIPT - Profile script outputs (e.g., profile.scriptName) Example: { token: "profile.userSegment", type: "SCRIPT" }

   IMPORTANT LIMITATION: Profile scripts CANNOT be created via the Admin API. You must create profile scripts in the Target UI first:

   • Navigate to Audiences > Profile Scripts

   • Create your script (e.g., "userSegment")

   • Then create the response token: { token: "profile.userSegment", type: "SCRIPT" }

COMMON USE CASES FOR CUSTOM TOKENS:

Custom tracking: Create tokens for your specific mbox parameters (profile.userType, profile.campaignId, etc.) Business data: Return custom business attributes in responses Integration: Pass custom data to analytics or tag management systems

BEFORE CREATING:

1. Run listResponseTokens to check if the token already exists

2. If it exists with deletable: false, activate it in Target UI instead

3. If it doesn't exist, create it with this tool

WORKFLOW FOR SCRIPT TOKENS:

1. Create profile script in Target UI (Audiences > Profile Scripts)

2. Use this tool to create response token referencing that script

3. Response token becomes available in Target responses

Retrieve list of response tokens, including built-in and custom tokens with their active status

Get all revisions (audit history) of a specific entity by ID, in descending order by time.

NOTE:

• Only the latest 100 revisions are retained per entity (including CREATE and DELETE actions)

• For admin page entities, only concrete updates are recorded

• For authorizedHosts, use client ID as entity ID

Get all revisions (audit log) for a specific resource type, filtered by author's name and optionally by modified-after timestamp (defaults to last 1 day)