Migrating from mbox.js to at.js in Adobe Target is a straightforward process.
Use the following steps to migrate from mbox.js to at.js and to check your migration:
Determine your organization’s browser support requirements.
Check your website’s current mbox.js implementation for capabilities that are not supported by at.js.
When auditing your implementation, look for the following:
What types of mboxes do you currently use?
|Auto-created global mbox||The auto-created global mbox is created when the only line of Target code on your site is the mbox.js file. That file automatically generates an mbox call.|
|Global, empty mboxCreate||It is recommended that you switch to the auto-created global mbox.|
|Wrapping mboxCreate||Migration should be simple, as long as your
|mboxUpdate||Migration should be simple when
|Custom clicktracking mboxes, including mboxTrack||We recommend that you update your code to use
For more information about the various functions mentioned in the preceding table, see at.js functions.
Do you have any customizations to your mbox.js file?
Most of the mbox.js objects and methods (such as
mboxFactories, and others) are not supported. Alternate approaches might be possible to accomplish what you are trying to do.
Do you have mbox.js on any of your web pages?
The mbox cookie is the main way Adobe stitches the visitor from page to page. As part of your QA process, you should confirm that the cookie is being preserved and read correctly as the visitor moves back and forth between pages with at.js and those with mbox.js. Make sure the same
mboxSession values are passed in the mbox calls, regardless of which section of the site ( at.js or mbox.js) the visitor first lands on and which section originally sets the cookie. If you use 3rd-party cookies in your implementation, ensure that those values stay the same as you browse the site.
Do you integrate Target with any other Adobe solutions?
Some of the legacy integrations are not supported by at.js. For more information, see the Integrations page.
Do you integrate Target with any 3rd-party tools?
These integreations might need to be adjusted to work with at.js. For more information, see the Integrations page.
Do you use a tag manager?
For more information, see at.js Integrations.
If you are not currently using a tag manager to deploy Target, now might be a good time to consider it. Adobe’s Dynamic Tag Management is free to Target customers and is the recommended method to deploy Target. For more information, see Best Practices for Implementing Adobe Target using Dynamic Tag Management.
Verify that all current activities and integrations are working as expected.
Here are some things you can do while testing to confirm that at.js is working as expected:
Possible Issues When Migrating to at.js Some customers have reported the following issues after performing the migration to at.js:
Some VEC activities that were built on a page with mbox.js might need to be updated to work with at.js.
This issue occurs most frequently on websites that don’t use many id or class attributes in HTML elements. You can confirm if you are experiencing this issue by loading the page and determining whether the experience is being delivered as expected by loading the page with
?mboxDebug=true and reviewing the console statements.
In these instances, element selectors might start with something like
HTML > BODY > DIV:nth-of-type(2)
and were built with the expectation that mbox.js added an extra
<div> element to the top of the page. Because at.js doesn’t add a
<div> element to the top of the page, this selector would no longer work with at.js.
This issue can be addressed by recreating the activity in the VEC on the URL using at.js or by manually updating the selector using the </> Code > Modifications option in the VEC.
To remedy this problem, you should subtract 1 from the nth-of-type number in the first DIV element after BODY. In the above example the edited code would be:
HTML > BODY > DIV:nth-of-type(1)
For more information about how to use the code editor to do this, see Code Editor.
Because all mboxes are now asynchronous, they won’t block page rendering or return in the order in which they fired. For more information, see “Asynchronous Considerations” in at.js Limitations.