Activity QA Preview Links Persisting

[emcgall]

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.

[rewajklcvashuia]

I set up a multi-page A/B test but was only seeing the changes applied on the first page of the variant using the QA link. Are you saying that I'd have to add everything after the page url and refresh to QA the subsequent pages?

[emcgall]

Yes, 100%. That is exactly the issue. We would like preview links to persists for user's session to help with multi-page activity QA

[rewajklcvashuia]

Interesting. I tried to append the QA params to the other pages but it didn't seem to work for me. Just getting the control experience. Was hopeful that there would be some (albeit frustrating) workaround for QAing multi-page tests.

[surebee · Accepted 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.