Skip to main content
rockstar234
Level 2
August 17, 2026
Question

Adobe Target A/B Testing with AEM as a Cloud Service Adaptive Forms

  • August 17, 2026
  • 3 replies
  • 38 views

Question: Adobe Target A/B Testing with AEM as a Cloud Service Adaptive Forms

Hi ,

I’m currently using AEM as a Cloud Service with Adaptive Forms based on Core Components.

I would like to understand whether Adobe Target is supported with this setup, specifically for running A/B tests on Adaptive Forms.

If it is supported, could someone please share the recommended implementation approach and steps for:

  1. Integrating Adobe Target with AEM as a Cloud Service.

  2. Setting up A/B testing for an Adaptive Form using Core Components.

  3. Creating two different form experiences/variations in Adobe Target.

  4. Configuring the audience and traffic split (for example, 50/50).

  5. Tracking form submissions/conversions as the success metric.

  6. Using A4T/Analytics for reporting, if applicable.

  7. Any required Web SDK, Tags/Data Collection, Target client-side libraries, or Cloud Service configurations.

  8. Any limitations or prerequisites specific to Adaptive Forms Core Components.

If someone has implemented this successfully, a step-by-step guide or example architecture would be greatly appreciated.

Thanks!

 

3 replies

Adobe Employee
Pranay_MAdobe Employee
Adobe Employee
August 18, 2026

Hi ​@rockstar234,

Thanks for the detailed question. Here's where things stand:

Short answer: Yes, Adobe Target is supported with AEM as a Cloud Service for A/B testing Adaptive Forms — but the integration path is different from what you may find in older AEM documentation.

**Important distinction**
The legacy AEM Forms ↔ Target connector (the one with a dedicated "client code/email/password" config screen and built-in Forms Analytics reports) has reached end-of-life and is no longer supported. That integration was built for Foundation Component-based forms and doesn't apply to Core Components on AEM as a Cloud Service.

For your setup, the supported approach is to use the same Experience Platform Web SDK / Tags integration that AEM Sites uses to connect to Target and Analytics, leveraging the Adobe Client Data Layer that's already built into the Adaptive Forms Core Components.

**Recommended approach, step by step:**

1. **Target integration**: Set up a Tags (Data Collection) property linked to your AEM environment via Adobe IMS, and deploy the Experience Platform Web SDK through it. Most of the IMS setup is auto-provisioned on AEM as a Cloud Service.

2. **A/B test setup**: There's no built-in "A/B test" button for Core Components forms in AEM's authoring UI (that belonged to the deprecated flow). Instead, configure the test in Target itself, targeting the form's rendered DOM.

3. **Creating variations**: For structural changes (added/removed fields, layout changes), author two separate Adaptive Forms or experience fragments and let Target route traffic between them. For smaller visual/content tweaks, use Target's Visual Experience Composer directly on the form markup.

4. **Audience/traffic split**: Standard Target A/B Test activity setup — no form-specific steps. Set your 50/50 split in the activity's traffic allocation.

5. **Conversion tracking**: Hook into the Core Components submit-complete lifecycle event and fire it into the data layer / via Tags. Use that as your Target success metric.

6. **A4T/Analytics reporting**: Fully supported — send the same submit event to Adobe Analytics via Web SDK/Tags and enable A4T on the activity for Analytics-based lift reporting.

7. **Required components**: Experience Platform Web SDK (alloy.js), a Tags property linked via IMS, and the Adobe Client Data Layer (already built into Core Components). You do not need the old Forms-specific Target Cloud Service configuration.

**One limitation to flag:** If the form is embedded on a page outside of native AEM Sites/Forms rendering (e.g., an external website), Target experience targeting and A/B tests configured on the original form will not carry over, and submission data won't appear in Forms-specific reports. Keep the tested form on a natively rendered AEM page for this to work correctly.

Happy to go deeper on the actual data layer event names for submit tracking, or walk through a sample Target activity configuration for a form-swap A/B test if that would help your team get started.
 

Thanks
Pranay

rockstar234Author
Level 2
August 19, 2026

Hi ​@Pranay_M  I have integrated AEM with adobe target with IMS and have form variation in experience fragments and pushed to target.  Do we have adobe documents for Core component based adaptive End to End A/B Testing?

Adobe Employee
Pranay_MAdobe Employee
Adobe Employee
August 19, 2026

Hi ​@rockstar234,

Subject: RE: Documentation for Core Components Adaptive Forms A/B Testing

Hi [Name],

Thanks for the update — great to hear the IMS integration is in place and your form variations are set up as Experience Fragments pushed to Target.

To directly answer your question: **there isn't a dedicated Adobe document for "Core Components Adaptive Forms end-to-end A/B testing."** The Forms-specific A/B testing documentation you may come across is for the legacy OSGi-based integration, which has reached end-of-life and doesn't apply to a Web SDK + Experience Fragments setup like yours.

That said, since your architecture (IMS, Web SDK, Experience Fragments as Target offers) is functionally the same pattern AEM Sites uses, the closest and most relevant official walkthrough is Adobe's Sites experimentation tutorial. It covers the exact mechanics you've already implemented — just demonstrated on a Sites page rather than a form:

1. **Experimentation (A/B Testing) — AEM as a Cloud Service**
   https://experienceleague.adobe.com/en/docs/experience-manager-learn/cloud-service/personalization/use-cases/experimentation 
   End-to-end flow: exporting Experience Fragment variations to Target as offers, creating a Datastream to connect Web SDK to Target, building the A/B Test activity, setting the traffic split, defining success metrics, and activating.

2. **Use Adobe Target and Web SDK for personalization**
   https://experienceleague.adobe.com/en/docs/target-dev/developer/client-side/aep/target-overview 
   Explains the Web SDK + Target edge decisioning architecture (Datastream, Edge Network, A4T handoff) underlying any AEM as a Cloud Service A/B test, including form-based ones.

3. **How Do I Use AEM Experience Fragments? — Adobe Target**
   https://experienceleague.adobe.com/en/docs/target/using/integrate/aem/fragments/experience-fragments-aem 
   Covers exporting Experience Fragments as Target offers and consuming them via the Visual Experience Composer or Form-Based Experience Composer — the same offer-export step you've already completed.

**A few things worth validating on your specific setup, since none of the above documents address Forms directly:**

- **Duplicate/default content**: Confirm your Adaptive Form's container isn't rendering a hardcoded default fragment alongside the one Target injects dynamically — the Sites tutorial calls out removing the static default before activating, and the same applies here to avoid a flash of the wrong experience.
- **Datastream vs. legacy config**: Make sure your Datastream (not the older mbox/at.js-based Target Cloud Service config) is what's routing requests to Target, since that fully replaces the legacy integration.
- **Form model initialization timing**: Core Components Adaptive Forms initialize a client-side FormJSON model on load. Worth checking that this doesn't fire before the Web SDK personalization block resolves and swaps in Experience B — Target's page-hiding snippet should handle this, but it's worth confirming in the DOM.
- **Submit event coverage**: Since each experience is a separate Experience Fragment/form instance, verify your submit-success data layer event is registered on both variants, not just the default-rendered one.

Happy to put together a validation checklist or a short script to confirm the Web SDK personalization block is properly gating the form's model initialization, if that would help move testing along.

Thanks
Pranay

Terms & ConditionsAccessibility statement

Loading footer...