Activity created from AEM Targeted Component not returned in Web SDK __view__ propositions

Hi ​@test1234567 

Based on the detail - it seems like you’re having the legacy implementation even though the Target request successful ..  

The OOTB AEM Targeted Component was originally built around the legacy Target integration model using mbox requests. The presence of mboxDefine() and CQ_Analytics.TestTarget() in the generated markup is a strong indication that the component is expecting the traditional Target delivery mechanism rather than new (Alloy )Web SDK proposition rendering.  

So, When using AEP Web SDK, Target activities are returned only for the requested decision scopes. An activity created from the AEM Targeted Component is not automatically converted into a Web SDK __view__ proposition, so it may never appear in the Alloy response even though the activity is Live in Target.

Can you confirm which implementation you’re referring to -  

 https://experienceleague.adobe.com/en/docs/experience-manager-65/content/implementing/developing/personlization/target 

https://experienceleague.adobe.com/en/docs/experience-manager-65/content/sites/administering/integration/target 

https://experienceleague.adobe.com/en/docs/experience-manager-65-lts/content/sites/administering/integration/target-configuring#manually-integrating-with-adobe-target   - here I can see some old references in the documentation like DTM, mbox.js etc .. which no longer exist today. 

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/sites/authoring/personalization/targeted-content  

So I’m not sure if OOTB supports the web sdk implementation at all … and I am not seeing anywhere in documentation so better to go with new approach using Adobe Launch ( Adobe Tags) 

Hope this helps. 

Thank you. 

Hi ​@test1234567 ,
 

The root cause is an architectural mismatch.

The legacy AEM Targeted Component is built around the Form-Based Experience Composer workflow, which generates localized, region-specific mboxes (via mboxDefine / mboxCreate scripts embedded in the component HTML).

By contrast, the AEP Web SDK __view__ decision scope only requests and returns activities authored in the Visual Experience Composer (VEC). As a result, the localized, form-based activity produced by your component is not included in the global __view__ request and is therefore ignored.

Underlying issue

1) VEC (__view__) vs. Form-Based mbox scopes

In the Web SDK model, __view__ is effectively the modern equivalent of target-global-mbox: it is designed to retrieve VEC-authored activities tied to the page “view.”
Form-based activities synced from AEM, however, are delivered through explicit, uniquely named custom mbox scopes (e.g., regional mboxes). These scopes are not automatically covered by __view__ unless you make corresponding explicit decisioning requests.

2) Legacy scripting output without at.js

The component continues to output legacy JavaScript such as mboxDefine(...) and CQ_Analytics.TestTarget(...). Without at.js on the page, those functions either fail outright or never trigger the explicit Web SDK decisioning calls required to request form-based (custom-mbox) offers. Consequently, no regional mbox decisioning occurs—and the only decisioning you get is whatever the global __view__ scope returns.

Another part of your question is related to overlay, are you trying to say overlay of XF? You can use the  overlay of XF in case you are seeing duplicate clientlibs in target renderd page.

-Tarun

Hi ​@test1234567 ,

The behavior you are seeing is expected for this implementation. The AEM 6.5 Targeted Component uses the classic AEM Target integration, which generates legacy mbox markup such as mboxDefault, mboxDefine(), and CQ_Analytics.TestTarget(). This integration expects the AEM Target client libraries and ContextHub, using either mbox.js or at.js; it does not automatically switch to Adobe Experience Platform Web SDK just because Alloy is present on the page.

The __view__ decision scope is part of the Web SDK implementation. It requests page-load Target activities and VEC view-based activities, but it does not automatically translate the legacy AEM component markup into Web SDK propositions. If you use a form-based activity, request the exact custom decision scope and implement the corresponding DOM rendering yourself.

You have two options:

• Keep the existing AEM Targeted Component and configure the supported AEM Target integration, including ContextHub and the appropriate at.js client library.
• Use an Alloy-only implementation and replace or customize the legacy Targeted Component. In that case, request the required decisions through Web SDK and render the returned propositions using automatic rendering or applyPropositions().

For example, a Web SDK page-load request would look like:

alloy("sendEvent", {
  renderDecisions: true,
  decisionScopes: ["__view__"]
});

For a custom form-based scope:

alloy("sendEvent", {
  decisionScopes: ["aem-hero"]
}).then(function (result) {
  // Process and render the returned proposition
});

Therefore, adding decisionScopes: ["__view__"] alone will not make the OOTB AEM Targeted Component compatible with an Alloy-only page. Either enable the classic at.js-based AEM integration or migrate the component to a Web SDK-based rendering pattern. Also avoid loading both at.js and Alloy for the same component unless the integration has been explicitly designed to prevent duplicate requests, flicker, and conflicting rendering.