Migration from mbox.js to at.js
Why you need to migrate?
Adobe is going to deprecate mbox.js on August 30,2020 and in turn, no longer support mbox.js. Hence, migration from mbox.js to at.js would inevitably be a scenario companies would need to address. Migration to at.js would bring in the benefits listed below and some more.
- Improved page load times
- Prevents document.write warnings in Chrome
- Works well with single-page-apps
Since this blog post is not about advantages at.js has over mbox.js, but rather on how to migrate from mbox.js to at.js successfully without any issues, we’ll leave advantages for another blog post.
The process may look straightforward but it is not.
For many users, this just seems to be a simple task of just replacing the mbox.js file with at.js file and the migration is complete. This thought is far from reality.
If you follow this approach, then you are bound to have issues with Adobe Target and if there are any live activities running on the website it may also cause issues with those activities. Some of the common issues are listed below,
| Issue | Reason |
|---|---|
| mboxes does not load | If you are upgrading to at.js via Adobe Launch but your mbox.js implementation is still on DTM, in DTM, once the tool is configured, it automatically injects a global mbox but that’s not the case with Adobe Launch. |
Users qualifies for an experience but does not see the content changes | If you are using custom code to do the changes for a particular experience and using HTML tags other than script or style tag the content changes may not appear on the page especially if you are using form based approach to set up an activity. This is because at.js injects the code inside head tag which will only accept style and script tags |
| Custom parameter are not getting passed with the mboxes | This is because with at.js we need to pass mbox parameters using adobe.target.getOffer() codes or via Add Params action from the global page load rule action if using Launch |
| Users stop qualifying for the activity | This is because with at.js we need to pass mbox parameters using adobe.target.getOffer() codes or via Add Params action from the global page load rule action if using Launch |
| Users stop qualifying for the activity | This may be because if the audiences were created using parameters which use to get populated via legacy code which are not supported by at.js |
Recommended approach for migration
Process:
Audit:
In this phase,
• Verify the legacy mbox.js code to see if there are any custom JavaScript code which uses any deprecated function that needs to be changed/removed
• Identify the parameter that needs to be passed via the global mbox
• Identify the profile scripts that uses parameters which are part of the custom mbox.
• Identify both VEC and Form based historical live campaigns which uses custom mbox to deliver experiences or which are part of metrics definition
Plan:
In this phase,
- Get/Download the latest at.js file
- Get all the updated codes which will replace the legacy/deprecated codes
- Confirm with the stakeholders whether the profile scripts are still relevant for the business
Migrate:
In this phase,
- Upgrade mbox.js to at.js
- Map all required mbox parameters as part of global mbox
- Update the profile scripts to use global mbox instead of custom mboxes
- Update historical live campaigns to use global mbox for both to deliver experiences and metrics configuration
QA:
In this phase,
- Verify if at.js loads instead of mbox.js on all pages
- Verify mbox parameters are getting set as expected with proper values
- Verify if all profile parameters are working as expected
- Verify if you are able to qualify for the campaigns and see relevant content
Launch:
In this phase, push all the changes to production and do one more round of testing to ensure nothing breaks once the changes are live.
Written by Naresh (Head of Marketing and Operations in Helium India)
For supports on your campaigning, please reach out to Helium anytime (email: personalisation@iamhelium.com.au)