How to Track Ecommerce Conversions Across Domains, Devices & Browsers When Running an A/B Test?

What Is Cross-Environment Tracking?

One conversion, multiple touchpoints!

This is what cross-environment tracking is all about.

Customers today use a variety of touchpoints to complete ecommerce purchases. They may access the Internet from multiple devices and view marketing campaigns in one environment before converting on another, perhaps starting on a laptop device and domain “A” as they browse around until deciding which product is most appropriate for them, then going over onto smartphones, often switching browsers in between, and finally purchasing on a domain “B”.

As a result of this trend, an increasing number of conversion funnels stretch across multiple domains, devices, and web browsers.

Website visitor interactions can typically be of two types:

• Single-environment: When the journey to conversion starts and ends on the same device or browser or domain.
• Cross-environment: When website visitors click through from one device or browser or domain but convert in a different environment.

Here’s a simplified formula for understanding these terms:

With cross-environment interactions being far more common, tracking and attributing conversions can be a challenge. So, how can we track these ecommerce conversions when the environment changes to offer a customized experience? First, we need to understand what properties from the environment can change, and then, identify the different ways to track those conversions.

Let’s break down the different types of tracking that can happen in an omnichannel ecommerce funnel to make sure no customer slips through the cracks:

Cross-Domain Tracking

Cross-domain tracking is a way to analyze visitors across multiple domains.

Why Is Cross-Domain Tracking an Important Concept in A/B Testing?

Cross-domain tracking is a wonderful feature that allows you to attribute conversions and behavior to your campaigns even if the user journey spans multiple domains. Without it, attribution would be nearly impossible for those of us who have more than one domain (such as sites with a separate shopping or checkout domain).

Here are some of the conversion metrics that can be captured cross-domain:

• Conversions
• Conversion Events
• Click-through Conversions
• View-through Conversions
• Total Conversions
• Click-through Conversion Events
• View-through Conversion Events
• Total Conversion Events
• Total Revenue

Cross-Domain Tracking With Third Party Cookies

The most common form of cross-domain tracking relies on third-party cookies.

Websites use first-party cookies to store information about the visitor and their session and usually have the following attributes:

• Cookie Name: the name of the cookie.
• Cookie Domain: the domain on which the cookie is set up.
• Cookie Path: the path on which the cookie is set up. This is set as the root directory of the domain ‘/’.
• Cookie Expires: the time in seconds after which the cookie will expire.

Now, because these are first-party cookies, they cannot share information with other domains. This is where cross-domain tracking comes into play. In this case, we need to instruct it to share the values of the domain A cookie with the cookie of domain B, turning the first-party cookie into a third-party cookie.

What cross-domain tracking will do is append the domain A cookie values to the URLs where the domain changes using a query string by default. This can also be changed to a URL fragment if you are not a fan of query strings. Domain B will recognize these added parameters in these URLs to ensure that the cookie adopts these values.

Let’s see an example of what this would look like.

Say you want to rent a car online. To check out different options, you’ll likely go to a car rental website (we’ll use car.com in this example). As the site has numerous subdomains (car.com, payment.car.com, pickup.car.com, etc.) and a third-party domain for receiving payments (secure.booking.com), your user journey will be cross-domain.

Using cross-domain tracking, Car.com’s team can spot a user switching from one subdomain to another and personalize their entire experience with the most relevant products or services across different subdomains.

Cross-Domain Tracking with Local Storage

However, there is one big disadvantage when cookies are used in cross-domain tracking: their limited storage.

Cookies can hold a lot less data than local storage: cookie storage is limited to 4096 bytes whereas local storage has 5MB per domain. So if you use cookies, the more data you want to store in your visitors’ browsers, the more cookies you’ll need to create.

Another problem with cookies is that they slow down your website, making the user experience suboptimal. With each HTTP request, cookies are sent to the server. If you have a cross-domain journey, this becomes even worse. Visitors will browse back and forth between the different domains, increasing the HTTP requests and the number of cookies in their browser.

For the reasons above, some sites use a localStorage instead of cookie storage. What this means is you essentially host the file on domain A and use an iframe on domain B that loads the file from domain A. This way you share visitor data between the two domains as if it were one single domain:

File 1.html:

<html>
<head/>
<iframe src='http://127.0.0.1/test.html' />
</html>

File 2.html:

<html>
<head/>
<script>
console.log(localStorage);
localStorage.setItem('test', '123');
</script>
</html>

Misconceptions about Cross-Domain Tracking

Cross-domain tracking is often a misunderstood practice. Here are the top three misconceptions about it that may surprise you!

Myth #1. You Need Cross-Domain Tracking to Track Users Across Subdomains

Many CRO experts believe that they need to enable cross-domain tracking to track visitors across subdomains. This is not true. Cookies can be shared between subdomains and the main domain.

So, for example, if a cookie is set on www.convert.com, it can also be accessed by blog.convert.com without enabling cross-domain tracking.

Myth #2. Cross-Domain Tracking Is Needed for Payment Gateways

The next confusing part about cross-domain tracking is that you need to set it up for payment gateways (e.g., PayPal.com).

However, cross-domain tracking only is possible when you have control over both domains.

Most times, payment gateways do not allow you to put your tracking code on their web pages because of security reasons (more on this below).

Myth #3. Cross-Domain Tracking Is Needed when There Are Multiple Domains

The other misconception is that you need cross-domain tracking whenever you are using various domains. This is only true if you want to see the same user navigating across websites and to attribute conversions to the sources of traffic. In that case, you will need cross-domain tracking.

Nonetheless, if you want to see domain A as a traffic source to domain B and do not care from which traffic sources people arrived at domain A, then you won’t need cross-domain tracking.

Cross-Device Tracking

Nowadays, people own multiple devices. This means visitors may interact with your brand (for example, click on your Google ads) on one device, then switch to another and continue checking your products. Thanks to cross-device conversion reporting, marketers can check the effectiveness of their campaigns across all devices (tablet, mobile, and desktop), regardless of the device a user actually converts on.

Cross-device reporting links together cookies (for web), device IDs (for mobile apps), and aggregated sign-in data, to identify a user across different devices. This allows website owners to identify the path taken by a user, from first interacting with a brand or seeing an ad to the point of conversion.

It helps marketers spot specific unique website visitors, even if they enter the funnel using different routes:

There are two primary methods of cross-device tracking.

In one method, website visitors are tracked through fixed visitor IDs. The other method is based on the behavior of a user with a device ID.

Cross-Device Tracking With Visitor IDs (Deterministic)

This method is often used when users sign up through a newsletter or login. Social networks like Facebook, Instagram, TikTok, or Twitter do cross-device tracking by assigning visitor IDs.

This method is suitable for websites that have registered visitors. Once a visitor is marked with a unique ID, the tracking platform is notified every time the visitor logs in. If the same visitor uses another device later, let’s say a tablet, and opens the website in question as an app and logs in, they can be accurately tracked.

This method, known also as deterministic, is highly accurate (nearly 100%) and can be used to run precise campaigns targeting specific users.

Cross-Device Tracking Based on Device ID (Probabilistic)

The second method of cross-device tracking also works by tagging users, only this time they do not need to be registered. This method is based on various attributes that are collected from IP addresses, devices, browsers, or apps the visitor browses and combined into a user profile. The disadvantage of this method is that it is not as accurate as when using a visitor ID.

It is also referred to as probabilistic targeting. As the name suggests, it speaks about the probability that A is likely the user with a desktop (X device) and a smartphone (Y device). So, to do the tracking, algorithms with a huge amount of attributes are designed, which then segment users based on similar behavior across devices, geographical locations, IP addresses, and any other similar context. Of course, the accuracy of this tracking cannot reach 100%, but 60-70% is a good target.

Cross-Browser Tracking

Finally, cross-browser tracking allows a website to track a user between different browsers, including Chrome, Firefox, Microsoft Edge, Safari, Tor.

The method behind cross-browser tracking is called browser fingerprinting.

It works by identifying a set of characteristics unique to a computer’s hardware and software and using that information, a “fingerprint” for the system in question.

You may not realize it, but everything from your installed apps to your browser settings is combined to form your unique profile. The degree of identifiability of this fingerprint depends on each browser’s algorithm.

Let’s say you’re browsing on Firefox, see an ad, and decide to move to Chrome to buy a product to avoid being targeted by retargeting campaigns. Unless you’ve disabled cross-browser tracking from your browser settings, browsers will still be able to target you with the campaigns.

When Do Sites Opt For Transactions on a Different Domain/Device/Browser?

Cross-domain tracking is especially useful when site owners want to track sessions that happen across two or more domains or subdomains and to treat those sessions as a single one.

Sessions usually span across multiple domains when:

1. The checkout process is set on a different domain (which is quite common when you are using a third-party shopping cart like Shopify),
2. The goal conversion or e-commerce transaction takes place on a different domain (which is also quite common in the case of affiliate websites).

Here’s a typical scenario where cross-domain tracking makes sense: e-commerce platforms with third-party shopping carts.

In this situation, a user may land on the main site to view a product from a PPC campaign. When the user heads over to the checkout, they are taken to a third-party shopping cart on a different domain, e.g. via Shopify, to complete the transaction.

Without cross-domain tracking, the shopping behavior and checkout won’t be linked and the conversions won’t be tracked across the different domains. So, these online store owners need to somehow connect their domains. Otherwise, the conversion will be credited to the third-party shopping cart, not the original traffic source.

So, cross-domain tracking allows you to reliably track a visitor even after they leave your site.

Another benefit of implementing cross-domain tracking is that you can collect data from different domains in a single report.

Centralizing transaction data facilitates better optimization because it

• supports continued improvements in decision-making processes,
• strengthens better tracking and optimization of business processes, and
• minimizes an organization’s risk while preventing the negative impact of inaccuracies and redundancies.

And finally, site owners do not have to limit themselves to doing all the pre-sales landing pages on their main money site anymore, because of tracking limitations. They can branch out to multiple websites for a wider, trackable marketing website funnel.

In today’s omnichannel world, the way consumers use devices and browsers spans different platforms: they might read the morning news on their tablets on Firefox, check email during the morning commute on their phones on Chrome, and use their desktop PCs when at work. At night, they might browse on their smartwatches to catch up on the news of the day.

Here is a typical scenario:

• A user is browsing the news feed on their phone and clicks on a post about your product. The user’s interested but doesn’t sign up right away.
• Later that week, the user decides to check out your product again, but this time visits your domain directly from their computer from another browser. The user then decides to sign up.
• In a couple of days, the user logs in to your app from their phone.
• All of their browsing history on the above devices and browsers should be properly tied to their account and that original click from their news feed should be properly attributed to their conversion.

This technology can help site owners better understand consumer behavior and their multi-channel path to purchase. It enables them to offer a better customer experience and create highly targeted omnichannel marketing strategies across various touchpoints. It helps answer questions like:

• Are my PPC campaigns reaching my ideal consumers at the right time?
• How can I effectively measure which devices bring in the most conversions to optimize my campaigns and reward that source?
• How can my website’s experiences run seamlessly across devices and browsers and provide my consumers a consistent brand experience?
• How can I reach consumers regardless of the device they are on, to not only motivate them to engage with my brand, but also to have them come back as repeat customers?

How Do Privacy Changes Affect Cross-Environment Tracking?

As the internet becomes more and more integral to everyday life, it’s important that people feel safe when browsing. To help keep personal information private on websites, more and more browsers are putting tracking prevention measures in place. Here’s a breakdown of the latest tracking prevention changes and how they may impact cross-environment tracking.

We’ll briefly go through each of the updates below, but for a more detailed description of each of the updates and how Convert tackled them, read How Tracking & Cookies Changed in 2019 and How Tracking & Cookies Changed in 2020.

Google Incognito Blocked Third Party Cookies

In the Incognito mode, Google Chrome doesn’t save a user’s browsing history, form information, or browser cookies. Starting with Chrome 83, the browser blocks third-party cookies in the Incognito mode by default.

Users can still allow third-party cookies for specific sites, but any cross-tracking methods relying on third-party cookies are now facing big challenges because they need to be enabled by website visitors from their browser settings.

Strict Tracking Prevention in Microsoft Edge’s InPrivate Mode

In Microsoft Edge 80, the default behavior allows users to decide whether they want strict mode protections or not while browsing InPrivate.

This means that if users turn this feature on, cross-tracking becomes impossible.

Mozilla Enhanced Tracking Protection (ETP) 2.0

Since 2019, new Firefox users will have Enhanced Tracking Protection (ETP) turned on by default, and last year, Mozilla added a further security layer with Enhanced Tracking Protection 2.0 where they block redirect tracking. ETP 2.0 clears cookies and site data from sites every 24 hours, save for those sites users interact regularly with!

So forget about the cross-tracking methods that rely on cookies that are blocked by ETP.

Intelligent Tracking Prevention in iOS 14, iPad 14, and Safari 14

With the release of iOS 14, iPad 14, and Safari 14, Apple included new privacy features like the Privacy Report where users can see information about blocked trackers, as well as ITP for all web browsers on iOS devices (v14 and above), which prevent cross-tracking attribution.

Can A/B Testing Tools Track Ecommerce Conversions AND Maintain User Privacy?

The tracking & privacy updates described above are limiting what information can get tracked across multiple environments, but maintaining user privacy and offering a customized experience aren’t mutually exclusive.

Cross-environment data collection doesn’t have to happen in an intrusive manner that compromises your customers’ trust or blocks them from getting the most out of their website – there’s a way you could do it while respecting both worlds!

A/B testing tools can offer solutions to help your company learn what users want and give them a great online experience, while at the same time respecting privacy.

Let’s go through some of the most popular A/B testing tools on the market, see what ecommerce conversion tracking solutions they offer, and how respectful of privacy they are.

Optimizely

Optimizely built two different methods to allow cross-environment conversion tracking.

Option 1: Enable and use BYOID

This can be done by enabling the “Bring Your Own Visitor ID” feature on Optimizely. This feature allows you to define your own visitor ID, either as a cookie, localStorage key, URL query parameter, or javascript variable. It has several advantages beyond ITP 2.x mitigation, including giving you control over your ID persistence strategy, allowing for a uniform visitor ID across multiple platforms, and reducing cookie bloat.

This option is a manual, tedious process that you need to define for each client or domain where you are running experiences. You also need to be careful that the unique IDs you build will be picked up successfully by the Optimizely API.

Option 2: Set optimizelyEndUserId on CDN

This method isn’t typically recommended because BYOID is a more complete approach. But another way of configuring cookie creation is through a CDN. This is a viable option for the UI-based and UI-managed implementation of server-side cookie creation in many cases. Optimizely currently provides documentation for server-side cookie creation through Akamai’s configuration.

If you are following this process, in addition to the above CDN settings changes, you should also disable the automatic lifetime extension of the visitor ID cookie by running this in the project JS:

window["optimizely"].push({
 "type": "extendCookieLifetime",
 "isEnabled": false
});

This strategy also has limited functionality when cross-domain tracking is enabled, especially when the different domains follow different strategies for visitor ID persistence.

VWO

VWO supports cross-domain tracking with the aid of third-party cookies.

If you enable the third-party cookies option in your test, in addition to storing visitor data (variation shown and conversion goals triggered) in cookies belonging to your domain, VWO will send that data to servers too. Once the data has been sent, VWO servers set cookies for the domain dev.visualwebsiteoptimizer.com. If your test involves another domain, the next time your page requests test data, VWO servers send back visitor data too. In a way, servers act as a proxy between your multiple different domains, and hence conversions can be tracked.

However, the Firefox and Safari browsers block third-party cookies by default. As a result, VWO cannot access the third-party cookies, thereby prohibiting cross-domain tracking from working in Safari and Firefox browsers.

Google Optimize

To implement Google Optimize cross-domain tracking successfully, you must know HTML & Javascript or get a dedicated web developer for that.

To set it up, create a single property in your Google Analytics account.

Then, you will have to use the same Google Analytics tracking ID on both sites you want to link.

1. The source domain decorates URLs that point to the destination domain so that they contain the first-party measurement cookie values of the source domain.
2. The destination domain checks for the presence of linked measurement cookies.

The linker parameter is identified in URL query parameters with the key _gl, like in the example below:

https://www.example.com/?_gl=1~abcde5~

Kameleoon

Their solution creates a server-side snippet that automatically synchronizes with localStorage. So they recommend installing a server-side snippet that automatically synchronizes their kameleoonVisitorCode cookie between the front and the back end. This contains the very important visitorCode identifier.

ITP does not impose any restrictions on server-side cookies, so this cookie will have an expiration date set sufficiently far in the future.

The snippet will create the KameleoonVisitorCode cookie server-side when no Kameleoon cookie has been found (i.e. it has not yet been created front-side) OR retrieve the existing value and recreate the cookie server-side to avoid ITP issues. The synchronization means that not only will identifiers not be removed after seven days, but there is no impact on performance or the user experience as we will only store a single cookie.

However, since Kameleoon stores other data in the Local Storage, data that is needed to trigger real-time experiments with no extra server calls, they have also implemented a Local Storage synchronization mechanism.

On Safari, once Kameleoon obtains its visitorCode by reading the kameleoonVisitorCode cookie, it will check if its current Local Storage is empty. If that is the case, which probably means that the last visit was more than seven days ago, they will perform a Server Synchronization Call (SSC) to fetch all the data that was present in the Local Storage from their backend servers. Once this call is over, data will be restored in the exact state it would have been if ITP did not wipe it. Normal operations can then resume.

How Does Convert Experiences Manage Cross-Environment Tracking?

Convert Experiences respects all privacy rules and, by default, does not allow cross-domain, cross-device, and cross-browser tracking.

However, if users want to, they can enable cross-domain tracking in their Project Settings and can ask the Convert support team for custom solutions in cross-device tracking. Cross-browser tracking is not supported.

Now, let’s see more details about each type of tracking and how to set it up in the app.

Cross-Domain Tracking in Convert Experiences

This section describes how Convert Experiences handles cross-domain tracking; e.g. if your website spans multiple domain names. This is often the case if you are using a third-party shopping cart.

The cross-domain tracking is by default turned off for all projects in Convert Experiences, because of the GDPR. However, you can uncheck the setting “Do not allow cross domain linking” to make tracking possible:

In the Convert Experiences app, Experiments are organized within Projects. A Project is an entity that can contain any number of Experiences and which includes domains (Active Websites):

All the websites within one Convert Project share cookies, making cross-domain tracking possible UNLESS you enable the “Do not allow cross-domain linking” Project Setting above.

The way cookies are shared between domains is done by automatically passing cookies between domains that belong to the same project when a visitor clicks on links or submits forms. Those cookies get passed to your other domains through GET variables.

Two variables are added to the query string to pass cookies:

• _conv_v
• _conv_s

It’s also possible to manually pass cookies to selected links or forms. All you need to do is to pass the _conv_v and _conv_s variables in the URL of the link or action of the form.

<a href="http://www.myothersite.com/page.html" onclick="window.location=this.href+'?_conv_v='+escape(convert.getCookie("_conv_v"))+'&_conv_s='+escape(convert.getCookie("_conv_s")); return false;" >

Now, let’s walk you through a use case of cross-domain tracking in Convert Experiences.

Let’s say I start my journey on an event page where I need to place a subscription:

https://domainA.com/reports/WCI/cpc-bndl

Once I have to pay, domain A redirects me to the payment cart page that lies under domain B and adds the Convert cookies that are necessary for cross-domain tracking as URL query parameters, like so:

https://domainB.com/EWCIAH80/wci-cpc-bndl/?_conv_v=vi%3A1*sc%3A1*cs%3A1635157350*fs%3A1635157350*pv%3A2*exp%3A%7B100323139.%7Bv.1003114910-g.%7B10037703.1-10037704.1%7D%7D%7D&_conv_s=si%3A1*sh%3A1635157349857-0.9940523874349994*pv%3A2

Once I finish making the payment, I land on the thank you page of domain A:

https://domainA.com/thanks/wci-cpc-bndl-thanks?_conv_v=vi%3A1%2Asc%3A1%2Acs%3A1635157350%2Afs%3A1635157350%2Apv%3A2%2Aexp%3A%7B100323139.%7Bv.1003114910-g.%7B10037703.1-10037704.1%7D%7D%7D&_conv_s=si%3A1%2Ash%3A1635157349857-0.9940523874349994%2Apv%3A2

where I am considered an existing visitor, so the revenue conversion is captured across both of the domains.

Cross-Device Tracking in Convert Experiences

Convert Experiences does not support cross-device tracking by default. The method below was only designed for custom solutions and upon request for Leader plans. It is no longer active, but we present it here for educational purposes.

In order to track visitors on different devices and to offer a consistent user experience, regardless of the device they are using, the user has to be “identified” through some sort of unique identifier that shouldn’t contain any personally identifiable (PII) data.

Convert created an API function through which customers could present this unique identifier that identifies the visitor across devices. The unique identifier needs to be “given” on a page, before the main Convert tracking snippet.

It looks like this:

window._conv_q = window._conv_q || {};
_conv_q.push([“identify”,”unique_hashed_id_here”]);

When the unique identifier is provided, Convert will delay the experience presentation until it queries the server for data (experiences seen, goals fired, etc.) and gets the results back. When results are returned, they are saved on a long-term cookie replacing the eventual bucketing that the user had before being “identified”. We expect this to be done only if data isn’t already available on the long-term cookie, to avoid delays in experience presentation on each pageview.

Responses should be minimized and compressed to avoid extra networking latencies. The final solution consists of 2 requests made by the page:

• The first request is responsible for loading the main js file (load data) —  it’s cached on CDN level and it contains all available experiments, jquery library dependencies, goals, other util functions, and tracking, but doesn’t contain user bucketing. This file is served minimized and compressed (gzip).
• The second call is a couple of bytes in size. It tries to get previously assigned bucketing for this particular user. It loads the experiments IDs and goals IDs the user was assigned to previously by reaching out to a performant key-value NoSQL database (cached within the memory caching system). If further performance improvements are required, Convert will optimize by using a CDN in front of it (in which case, each request will be cached per user). This response is also served minimized and compressed (gzip).

When the unique identifier is provided for a new unique website visitor, the bucketing on experiences is done this way:

1. For a new user — there’s no long-term cookie stored; if the unique identifier is provided, experiments are delayed until the second call returns. That call will:
   1. either return what experiments/variations are connected to the unique identifier, in which case Convert will show the same pair of experiment/variation to the user (behaving the same way it behaves for a visitor that returns to an experiment page seen before)
   2. or won’t return data if that unique identifier does not have anything connected to it in which case Convert will do the randomization as normal; As a result, when a new bucket is assigned, there will be an extra asynchronous call to the backend to save the new bucketing that just occurred.

When the unique identifier is provided for an existing website visitor, the bucketing on experiences is done like this:

2. For an existing user (with identifier) — we have the long-term cookie found in their browser set by Convert. If a unique identifier is provided, we may have one of these two cases:
   1. There’s no browsing session started (a new session is identified through a session cookie which expires after 20 minutes of no activity) OR the visitor ID stored on the long-term cookie is different from the visitor ID provided through the unique ID; in this case, the same thing as in the previous example will happen: when bucketing is returned from the server, it will overwrite current bucketing stored on the long-term cookie; If the server returns no data, the long-term cookie will prevail. This overwriting can become problematic when, for the same user, part of the session has a unique identifier and part of it does not.
   2. A current browsing session started and the visitor ID stored on the long-term cookie is the same as the unique identifier provided. In this case, the process is the same as usual: it’s a user for which eventually the bucketing was restored at the first pageview of the user session, therefore, no additional requests are required (no second call to retrieve the data since it’s already in the long-term cookie, nor a third call to save any bucketing that would’ve had happened otherwise).

Cross-Browser Tracking in Convert Experiences

Convert Experiences does NOT support cross-browser tracking.

How to Test if Cross-Domain Tracking Works?

Here are some tell-tale signs you can look for in your Convert reports that can indicate that cross-domain tracking isn’t working right:

• There is less traffic than you would expect,
• Your conversions are not triggered/captured,
• Traffic on one domain has various campaigns being attributed, while another domain includes less traffic.

Basically, if your Convert report is accounting for less traffic or fewer conversions than you’d expect, this could mean Convert is losing track of the attribution when your users switch domains. That might be an indication that cross-domain tracking isn’t working properly.

Things to Consider When You Enable Cross-Domain Tracking

• You do not need to enable cross-domain tracking for subdomains in your account.
• Cross-domain tracking must be enabled when the original and variation URLs in a Split URL test are on different domains.
• For enhanced privacy, the Firefox and Safari browsers block cross-domain tracking by default. As a result, Convert cannot access the third-party cookies, thereby prohibiting cross-domain tracking from working in Safari and Firefox browsers. However, the default browser settings can be disabled:
  • In the Safari browser, go to Preferences > Privacy and disable the Prevent cross-site tracking setting.
  • In the Firefox browser, go to Preferences > Privacy & Security > Custom and disable the “Cookies and Tracking Content” setting.
• With the iOS 14 and macOS 11 upgrade, Apple introduced the Privacy Report feature in Safari. You can use this to examine a website’s report to see which websites are tracking you and display the trackers that Safari has blocked. The report shows both cross-site tracking trackers and those detected by Apple’s intelligent tracking prevention.
  Please note that this does not have any impact on your Convert experiences as our app only works with first-party cookies. Convert tracking would only be affected when you use the cross-domain tracking feature on Safari since the browser does not allow working with third-party cookies by default.

There are a lot of things to think about when it comes to tracking ecommerce conversions in A/B testing. It’s not as simple as just looking at your web analytics reports or cookies, because customers may be seeing your digital marketing campaigns in one environment before converting on another. Today’s consumers use an increasing number of touchpoints throughout their journey, which can get tracking info difficult for marketers.

Fortunately, A/B testing tools like Convert Experiences give users the ability to see how individuals interact with their online business, all while making sure that user privacy rights are upheld. Click the banner below to take a free trial and see for yourself how this works.