Change webpage content using Form Based Composer and target-global-mbox

[colstephan]

Hello, I'm currently facing some difficulties with the form-based composer and would greatly appreciate the community's guidance and expertise in resolving this matter.

Goal -- to update the hero section of my website's homepage using the form-based composer.

I'm specifically interested in hearing success stories from others who have achieved similar updates and would greatly appreciate any guidelines you can provide regarding the tagging and activity setup process.

To provide some context, I attempted to implement an activity targeting "Location 1" with the value 'hphero'. I ran a script in the console, and it successfully fetched and rendered the new hero experience as expected. However, when I added the same script to the tag manager (both sync and async versions) and tested it, the hero section flickered, which was not the desired outcome.

At this point, I'm struggling to fully comprehend the solution. Could you please explain how I can change the content inside a specific page div using the form-based composer in conjunction with the target-global-mbox? Additionally, I would like to know how I can accomplish the same content update using the form-based composer and a custom regional mbox around the hero section, without experiencing any flickering issues.

To provide some context, here is the script I utilized:

document.querySelector('#dcom_hero_global').classList.add("mbox-name-hphero");
adobe.target.getOffer({
"mbox": "hphero",
"params": {},
"success": function(offer) {
adobe.target.applyOffer({
"mbox": "hphero",
"selector": ".mbox-name-hphero",
"offer": offer
});
},
"error": function(status, error) {
console.log('AT Error', status, error);
}
});

 Thank you very much!

Col

[alexbishop · Accepted solution]

What type of changes are you making in your Form Composer offer code? I'm just wondering if there is a reason you can't use the Visual Editor for this test? The reason I ask is because this seems like a timing issue between the Target request being made and the hero element being rendered.

Creating the test via the Visual Editor (and therefore global mbox) would offer some benefits, both in terms of how early in the page load the Target request was made and in terms of "polling" for element availability. However, if Visual Editor simply isn't possible then you might want to consider the Target pre-hiding snippet, so that you hide some/all page content until applyOffer has had time to render the Target offer content from your activity

[colstephan]

Thanks for your reply, Alex!

The Visual Editor has worked perfectly fine for years for this hero element -- which is why I haven't really explored other options aside from the VEC/global mbox. But, my org would like to see the hero alternatively powered by an external source, depending on the quality/value of external offers. So, I'm doing what I can to explore getting offers on the page using a regional mbox+form composer+HTML Offer activity, a small step toward not entirely relying on the VEC.

I'll add the pre-hiding snippet and update on how it goes.

Thanks again!

[colstephan]

The pre-hiding snippet works. 

https://experienceleague.adobe.com/docs/target-dev/developer/client-side/at-js-implementation/at-js/...

From the KB article, copied and pasted the part I found most helpful. FWIW I pre-hide specific element IDs rather than the body, as described in the last bit pasted below.

Managing flicker when loading at.js asynchronously

Loading at.js asynchronously is a great way to avoid blocking the browser from rendering; however, this technique can lead to flicker on the web page.

You can avoid flicker by using a pre-hiding snippet that will be visible after the relevant HTML elements are personalized by Target.

at.js can be loaded asynchronously, either directly embedded on the page or via a tag manager (for example Adobe Experience Platform Launch).

If at.js is embedded on the page, the snippet must be added before loading at.js. If you load at.js via a tag manager, which is also loaded asynchronously, you must add the snippet before loading the tag manager. If the tag manager is loaded syncronously, the script might be included within the tag manager before at.js.

The pre-hiding code snippet is as follows:

;(function(win, doc, style, timeout) {
  var STYLE_ID = 'at-body-style';

  function getParent() {
    return doc.getElementsByTagName('head')[0];
  }

  function addStyle(parent, id, def) {
    if (!parent) {
      return;
    }

    var style = doc.createElement('style');
    style.id = id;
    style.innerHTML = def;
    parent.appendChild(style);
  }

  function removeStyle(parent, id) {
    if (!parent) {
      return;
    }

    var style = doc.getElementById(id);

    if (!style) {
      return;
    }

    parent.removeChild(style);
  }

  addStyle(getParent(), STYLE_ID, style);
  setTimeout(function() {
    removeStyle(getParent(), STYLE_ID);
  }, timeout);
}(window, document, "body {opacity: 0 !important}", 3000));

By default the snippet pre-hides the whole HTML BODY. In some cases, you may only want to pre-hide certain HTML elements and not the entire page. You can achieve that by customizing the style parameter. It can be replaced with something that pre-hides only particular regions of the page.

For example, you have two regions identified by IDs container-1 and container-2, then the style can be replaced with the following:

#container-1, #container-2 {opacity: 0 !important}

Instead of the default:

body {opacity: 0 !important}