Expand my Community achievements bar.

Significant Delay in Mboxes injected via DTM versus on-page mbox code

Avatar

Level 3

Has anyone else seen pretty significant delays and content flicker on mboxes that are injected on a page using DTM versus mboxes that are hard-coded on the page? I have a client with literal seconds differences between mbox loads and have definitely seen some flicker (gah!). Would love to know if anyone has any sneaky work-around out there.

9 Replies

Avatar

Level 2

We have seen the same delay for mboxes inserted via DTM, about 3-5 seconds. We ended up using Jquery/swizzle via the global mbox to speed things up, however it is great to know the option for using Sequential HTML to introduce an mbox(create) into the page. Thanks!

Avatar

Level 8

Hi Eric,

The documentation here provides an example for implementing an Mbox with built-in flicker handling.

Please let me know if this helps

Kind Regards

Rahul

Avatar

Level 3

Thanks Rahul. That is the way I'm deploying mboxes.

The client I'm deploying mboxes on has a significant difference between DOM Ready and Window Onload - up to 15 seconds depending on the page.

I've reached out to ClientCare and it seems that the issue I'm dealing with is more the significant delay caused by DTM using the mboxUpdate() method instead of the mboxCreate() method. The issue is that mboxUpdate() waits to load content on the page until window.onload. mboxCreate() would load the content significantly earlier.

Can anything be done to have DTM use the proper method to inject mboxes?

Avatar

Level 5

Eric,

Rather than using the built-in integration you can try to use a third-party tag with sequential HTML triggered on top of page that uses a more traditional mboxCreate syntax (this is obviously a bit different than the "create mbox around" so you may need to adjust accordingly). 

<div class="mboxDefault"></div>

    <script type="text/javascript">
        mboxCreate("xxxxxx");
    </script>

Avatar

Level 3

Thanks Mike - I agree that's another option. Unfortunately it's not a very elegant one (inject code via jQuery would be my first move). I'd much rather Adobe just get DTM to use the right function.

Avatar

Employee

Eric, it's not a question of the function being wrong, it's question of how DTM was designed. The mboxes added via the Page Load Rules use mboxUpdate on purpose. If you need mboxCreate because you're working on a client site with poor performance practices, or any other reason, you're free to use the Target functions wherever they perform best for your needs. There are many clients that fire mboxCreate calls throughout their Page Load Rules in DTM with great success.

As Target evolves, the DTM - Target integration will also evolve to include more precise control from the UI, but you can still implement that level of control in custom script windows or Data Elements where needed.

Avatar

Level 3

That's fair - good to know that the mboxCreate solution works. Out of curiosity, why does DTM use update instead of create? Is there a missing functionality or something with create?

Avatar

Employee

@Eric - Just how DTM (Satellite) was built - to allow marketers & analysts to add asynchronous mboxes around existing elements.

Avatar

Level 3

Agreed with Mark - it's great to see there are so many options! Also great to hear that an even tighter integration between these technologies is already in the works.