This topic contains answers to questions that are frequently asked about using redirect offers when using Adobe Analytics as the reporting source for Adobe Target (A4T).
Yes, if your implementation uses at.js. However, your implementation must meet the minimum requirements listed below in order to use redirect offers in activities that use Analytics as the reporting source.
A known issue exits that is causing a limited number of customers using redirects with A4T to see a higher percentage of unstitched hit rates. See Known issues and resolved issues.
Your implementation must meet the following minimum requirements:
The three libraries must be included on both the page with the redirect offer and the page to which the visitor is redirected.
Some data discrepancies are expected. For more information, see Expected data variances between Target and Analytics when using and not using A4T.
When using at.js version 1.6.3 or later, counting page views on both pages is not an issue. This race condition affects only customers using earlier versions. The Target team maintains two versions of at.js: the current version and the second-latest version. Upgrade at.js as necessary to ensure that you are running a supported version.
If you are using an earlier, non-supported version of at.js, there is a possibility that a race condition can occur that might cause the Analytics call to fire before the redirect executes on the first page. This situation can cause page views on the original page and on the redirect page to all be counted. This situation results in an extra page view on the first page, when the visitor never really “saw” this first page.
Using the form-based composer to build a redirect activity is recommended to increase the speed of the page redirect because of where the code gets executed on the page. Also, creating a redirect offer for every experience, even the default experience, where the redirect would return the original page is recommended. Creating a redirect offer for each experience ensures that if mis-counting occurs, it happens across all experiences. Reporting and analysis are still valid for the test.
One reason you might want to use redirect offers for all experiences in the activity, including the default (control) experience, is to put the same conditions on all experiences. For example, if the default experience does not have a redirect offer but the other experiences have redirect offers, the speed of the experience without the redirect offer has an inherent advantage. Redirect offers are recommended for temporary scenarios only, such as testing. Redirect offers are not recommended for permanent scenarios, such as personalization. After you determine the “winner,” you should remove the redirect to improve page-load performance.
For more information about this issue, see the “Redirect offers” information in Known Issues.
Yes, both composers are supported as long as you use the built-in redirect offers.
If you use your own custom code for the redirect, you must ensure that you populate the two new parameters associated with redirect URLs (
adobe_mc_ref, explained below).
The following query string parameters are associated with redirect offers:
These parameters are automatically added to the redirect URLs when using the built-in redirect offers in the VEC and Form-Based Experience Composer when the Visitor Id service is implemented on the page. If you are using your own custom redirect code in the VEC or Form-Based Composer, you must be sure to pass these parameters with your custom code.
Work with your IT team to have these parameters (
Use a custom-coded redirect if:
However, as best practice, you might want to keep the
adobe_mc_ref parameter in the URL in order to report the referrer information to Analytics correctly.
If you use A4T and redirect offers, Target appends the
adobe_mc_sdid parameters to the URL. These values are already URL encoded. Most of the time everything works as expected, however, some customers might have load balancers or WEB servers that try to encode the query string parameters one more time.
Because of this double encoding when the Visitor API tries to decode the
adobe_mc_sdid value, it can’t extract the SDID value and generates a new SDID. This process leads to incorrect SDID values being sent to Target and Analytics and you see uneven split for redirects in Analytics reports.
Adobe recommends that you talk to your IT team to ensure that
adobe_mc_sdid are allowlisted so that these values are not transformed in any way.
Suppose that a visitor clicks a link on
www.google.com to your homepage (
www.mysite.com/index.html) on which a redirect activity is live and is then redirected to a new page (
Previously, the Analytics request on the new page would report a referring URL of
www.mysite.com/index.html instead of
www.google.com. This caused inaccurate reporting in Analytics associated with the referring URLs (Marketing Channel reports, for example). The reports had lost the fact that you came to the site from [!DNL
With at.js version 0.9.6 (or later) and AppMeasurement.js 2.1 (or later), the Analytics request on the new page reports a referring URL of [!DNL
The following FAQs provide more information about using A4T and redirect offers with the Platform Web SDK.
Yes, A4T via the Platform Web SDK supports redirect offers.