Redirect offers - A4T FAQ

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).

Does Analytics for Adobe Target (A4T) support redirect offers? section_46B8B03ED4D542C6AD875F5F61176298

Answer
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.

What are the minimum requirements to use redirect offers with A4T? section_FA9384C2AA9D41EDBCE263FFFD1D9B58

Answer

Your implementation must meet the following minimum requirements:

  • Experience Cloud Visitor ID Service: visitorAPI.js version 2.3.0 or later.
  • Adobe Analytics: appMeasurement.js version 2.1.
  • Adobe Target: at.js version 1.6.2 or later.

The three libraries must be included on both the page with the redirect offer and the page to which the visitor is redirected.

Why are there sometimes data discrepancies between A4T and Analytics?

Answer
Some data discrepancies are expected. For more information, see Expected data variances between Target and Analytics when using and not using A4T.

How can I minimize discrepancies in traffic distribution when using redirect offers in A4T activities? discrepancies

Answer

A limited number of customers have reported higher degrees of variance in traffic distribution when using redirect offers in activities configured with Analytics for Target (A4T).

Consider the following:

  • Incorrect order of Target and Analytics calls might be responsible for higher degrees of variance.

    The Target call must precede the Analytics call on the source page (where redirect occurs) and on the destination page (where redirect ends).

  • Ensure that you use redirect offers in A4T redirect activities.

  • If there are multiple Target location requests on the source page (where the redirect occurs), Adobe recommends that you run the redirect activity on the first Target location request.

    Running the redirect activity on the first Target location request reduces the chances of any activity qualifications happening on other Target location requests and getting counted in the report. Visitors who are redirected need not be counted in the reports of other activities as they will not see the experiences.

Why are page views on the original page and on the redirect page sometimes counted? section_B8F6CC2190B84CF08D945E797C5AF07B

Answer

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.

Are both the Visual Experience Composer (VEC) and Form-Based Experience Composer supported? section_FDA26FE7909B48539DA770559E687677

Answer

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_sdid and adobe_mc_ref, explained below).

What are the new query string parameters added to the redirect URLs? section_BA73E8B3CFCC4CBEB5BE3F76B2BC8682

Answer

The following query string parameters are associated with redirect offers:

table 0-row-2 1-row-2 2-row-2
Parameter Description
adobe_mc_sdid The adobe_mc_sdid parameter passes the Supplemental Data Id (SDID) and Experience Cloud Org Id from the default page to the new page. These IDs allow A4T to “stitch” together the Target request on the default page with the Analytic request on the new page.
The expected format to pass sdid in the url (for hybrid apps or from one app to the website or one website to another) is `ex. adobe_mc_sdid=SDID=123
adobe_mc_ref The adobe_mc_ref parameter passes the referring URL of the default page to the new page. When used with AppMeasurement.js version 2.1 (or later), Analytics uses this parameter value as the referring URL on the new page.

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.

My web servers are stripping these parameters from my URLs, what should I do? section_0C2DDB72939F4875B6D0428B8DCB38E5

Answer
Work with your IT team to have these parameters ( adobe_mc_sdid and adobe_mc_ref) allowlisted.

What if I am not using A4T with my redirect activity and don’t want to have these extra parameters added to my URLs? section_9E608D75FF9349FE96C65FEDD7539F45

Answer

Use a custom-coded redirect if:

  • You are not using A4T with your redirect activity
  • You have the Visitor Id service implemented
  • You don’t want these parameters to be automatically added to your URLs

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.

Why are the adobe_mc_ref and adobe_mc_sdid parameters double URL encoded in my implementation? section_5EFE5F012B944C40865731EA18E7E79E

Answer

If you use A4T and redirect offers, Target appends the adobe_mc_ref and 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_ref and adobe_mc_sdid are allowlisted so that these values are not transformed in any way.

Why must the referring URL be passed to the new page? section_91AB8B0891F6416CBF7E973DCAF54EB5

Answer

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 (www.mysite.com/index2.html).

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 www.google.com.

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 www.google.com.

Can I use custom/HTML redirect offers? section_E49F9A83A286488C8F1098A040203D7E

Answer
No, you must use a built-in redirect offer for activities that use Analytics as the reporting source (A4T). From the Target perspective, HTML offers are opaque: Target can’t know that a particular piece of HTML contains JavaScript that instantiates a redirect.

Adobe Experience Platform Web SDK badge Does the Adobe Experience Platform Web SDK support redirect offers for A4T? platform

The following FAQs provide more information about using A4T and redirect offers with the Platform Web SDK.

Does Analytics for Target (A4T) support redirect offers?

Answer
Yes, A4T via the Platform Web SDK supports redirect offers.

Are the Visual Experience Composer (VEC) and Form-Based Experience Composer supported?

Answer
Yes, the Visual Experience Composer (VEC) and the Form-Based Experience Composer are supported if you use built-in redirect offers.

Can I use custom/HTML redirect offers with the Platform Web SDK?

Answer
No, you must use a built-in redirect offer for activities that use A4T. From the Target perspective, HTML offers are opaque. Target can’t know that a particular piece of HTML contains JavaScript that instantiates a redirect.
recommendation-more-help
3d9ad939-5908-4b30-aac1-a4ad253cd654