Show Menu
TOPICS×

mbox.js Frequently Asked Questions

Answers to frequently asked questions about mbox.js.

What is the impact of mbox.js on page-load times?

For more information, see Benefits of at.js .

Why do I get "Parser-blocking" warning messages in Google Chrome when using mbox.js and document.write?

This console message displays when using Chrome in many scenarios in which the document.write function is used within the mbox.js file. This is a warning message and should not affect your activity setup process.
The best way to prevent this situation is to migrate your Target implementation to the at.js JavaScript library , which doesn't use the document.write function. Using at.js provides many advantages versus using mbox.js. For more information, see at.js Frequently Asked Questions .

Why are my mboxes not firing on my web pages?

Target customers sometimes use cloud-based instances with Target for testing or simple proof-of-concept purposes. These domains, and many others, are part of the Public Suffix List .
Modern browsers won't save cookies if you are using these domains unless you customize the cookieDomain setting using targetGlobalSettings(). For more information, see Using Cloud-Based Instances with Target .

What is the domain tt.omtrdc.net that Target server calls go to?

tt.omtrdc.net is the domain name for Adobe's EDGE network, used to receive all server calls for Target.

Why don't at.js and mbox.js use HttpOnly and Secure cookie flags?

HttpOnly can be set only via server-side code. Target cookies, such as mbox, are created and saved via JavaScript code, so Target can't use the HttpOnly cookie flag.
Secure can be set via JavaScript only when the page has been loaded via HTTPS. If the page initially loads via HTTP, JavaScript can't set this flag. In addition, if the Secure flag is used, the cookie will be available only on HTTPS pages.
To ensure that Target can properly track users, and because the cookies are generated client-side, Target doesn't use either of these flags.