Expand my Community achievements bar.

Applications for the 2024 Adobe Target Community Mentorship Program are open! Click to the right to learn more about participating as either an Aspirant, to professionally level up with a new Certification, or as a Mentor, to share your Adobe Target expertise and inspire through your leadership! Submit your application today.

Auto Create Global Mbox vs. Custom Global Mbox

Avatar

Level 4

Hello,

Our team is working to reduce flicker as much as possible in our test activities, and are weighing the options for using a Custom Global Mbox (current implementation) versus auto-creating a Global Mbox.

What are the potential adverse affects of switching from one to the other, particularly as it relates to live test activities? I understand that once saved, all activities will sync with the auto created mbox. This doesn't sound like an  ideal scenario.

Can the implementation be changed to use Auto Create and continue to use the custom name? Is there a way to sandbox this before committing to making the switch?

Thanks,

Brion

5 Replies

Avatar

Employee Advisor

Hey Brion,

In general at.js is better suited at reducing flicker on the page as per: How at.js Manages Flicker

Having said that, if you are creating VEC activities, you must have Global MBOX Autocreate enabled in at.js to ensure content is delivered correctly to the page. In general we do not suggest to have any customization done to the at.js library, so it is best to test with an at.js with Auto create Global mbox.

Avatar

Level 4

Thank you, Ram!

We are currently using at.js, but still experience some flicker in tests.

Considering the VEC and auto creating Global Mboxes, does the same apply with regard to the Form-based Composer? We use both VEC and FBC.

It sounds like the best (only) way to avoid flicker is to use Auto Create?

Avatar

Employee Advisor

Hey bkmills1,

The best way to go about this is to use the Global Auto Create with at.js.

As for the form based composer auto create is not essential in this case.

However, if you are still experiencing flicker with at.js and auto create global mbox, then try disabling the mbox on the page by using mboxDisable=1


Troubleshooting Content Delivery

if you are not continuing to have the flicker issue after disabling the mbox, then it may be best to create a support ticket with Customer Care as this would need more investigation

Avatar

Level 4

Thanks again RamH!

I believe our flicker is a result of using a custom global mbox. We prevent flicker by setting the targeted content to '0' opacity, then change the opacity to '1' once Target fires--similar to what the Auto Created Global Mbox does, just not on the body.

So, a few final questions:

  1. Does using Global Auto Create, force us to build test activities with the VEC?
  2. Are they mutually exclusive?
  3. Will using the Form-based Composer have any affect on flicker?

Avatar

Employee

HI bkmills1​ ,

  1. Does using Global Auto Create, force us to build test activities with the VEC?

         No. You can still use form based composer to create activities  .

   2.Are they mutually exclusive?

          Yes . You can setup tests using either the VEC or form based composer when you have the auto created global mbox.

   3.Will using the Form-based Composer have any affect on flicker?

      Please check How at.js Manages Flicker . The same flicker handling concepts apply to both form-based and VEC based activities                 delivering on the global mbox.