Our QA teams would find it very helpful for an activity QA preview link to persist for the current user's session.
Currently when testing an in-page experience:
1. QA grabs the preview URL
2. QA starts testing on the first page
3. If they click through on the experience or the experience spans multiple pages, they must reapply the QA params and refresh each page
Expected/Ideal:
1. QA params persist for the current browser session so that we can validate a consistent experience
We like to keep the publishing rights very tight (which makes profile scripts less desirable as an option), and we also prefer to validate our final A/B test builds in Target against production and on actual mobile devices.
Solved! Go to Solution.
Thanks for the note, @emcgall. Few questions:
What version of at.js are you using?
Has this experience been consistent across browsers?
Per our docs:
The ability to QA the entire user journey. You can access your site once with the QA link and then browse the entire site while in Activity QA. You remain in Activity QA until you end the session or until you use the QA Target bookmarklet to force yourself out of Activity QA. This feature is particularly useful if you have an activity spanning multiple web pages.
This is true for at.js implementations with version 2.x or later. For at.js 1.x and mbox.js implementations, this is true only if the visitor’s browser doesn’t block third-party cookies.
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Thanks for the note, @emcgall. Few questions:
What version of at.js are you using?
Has this experience been consistent across browsers?
Per our docs:
The ability to QA the entire user journey. You can access your site once with the QA link and then browse the entire site while in Activity QA. You remain in Activity QA until you end the session or until you use the QA Target bookmarklet to force yourself out of Activity QA. This feature is particularly useful if you have an activity spanning multiple web pages.
This is true for at.js implementations with version 2.x or later. For at.js 1.x and mbox.js implementations, this is true only if the visitor’s browser doesn’t block third-party cookies.