Showing posts with label Experience Cloud Visitor ID. Show all posts

Saturday, October 24, 2020

Marketo Integration with Adobe Experience Cloud Solutions

The Experience Cloud ID service consists of many solution integrations which I've written about in the past. The true value of the Experience Cloud ID service come to the fore with the various integrations that exist helping client really realize the true value of their investment in Adobe technology. A relatively newer addition to the Experience Cloud ecosystem is Marketo which was acquired by Adobe a few years ago for its rich cross-channel activation and marketing automation capabilities primarily in the B2B space but Marketo can be leveraged for B2C use cases as well.

I know that doesn't do justice to how powerful Marketo really is so here's a high-level overview of some of its capabilities especially around marketing automation:

To start off, let's start by understanding what marketing automation is. It is a technology that automates the measurement and orchestration of omnichannel marketing initiatives. It simplifies lead management & nurturing, event marketing, personalization, regular & triggered emails or SMS. I have worked extensively in the automotive vertical in the past and know how crucial it is for automotive companies or any other company to manage their leads throughout the customer journey starting from awareness to purchase. Marketo is the perfect system to do that and if you combine it with the power of the Adobe Experience Cloud, you are truly able to orchestrate and measure the customer journey from start to finish.

In this post, I will walk through the integration of Marketo with other Adobe Experience Cloud solutions focussing more on Audience Manager but the general process is the same for Adobe Analytics and Target. Please note I'm specifically referring to Marketo Engage but will call it Marketo in this post.

Use Cases

Let's start with some common use cases that can be executed with this integration:

Cross-device media activation of leads (B2B or B2C data from Marketo activated in Audience Manager leveraging the device graph)
Event-driven (signups, abandonments etc.) user messaging (in Marketo based on user behavioral data from Analytics)
Cross-channel and cross-device personalization (via Target and Marketo based on onboarded data, user behavioral data from Analytics leveraging the device graph in Audience Manager)

Prerequisites

Let's take a closer look at some of the prerequisites with this integration.

An Adobe org admin can enable this integration by mapping the IMS org in Marketo (Admin section).
It is recommended to setup the cookie sync as early as possible between the Adobe Experience Cloud ID Service and Marketo's munchkin.js to ensure a higher match rate. The "cookie sync" happens automatically as long as long as both these scripts are present on the page.
The other important piece to keep in mind is that the munchkin cookie needs to match to a known lead with an email address via a hashed id on the website when users authenticate or submit a form or click on an email given that hashed emails IDs are sent to AAM.

Architecture

This is a slightly detailed architecture diagram which shows the bi-directional integration between Marketo and Audience Manager and the general process is the same for Adobe Analytics and Target (currently it's only Marketo -> Target audience sharing).

One thing to note in this architecture is that the Marketo to AAM integration is currently manual but the AAM->Marketo integration is automated where AAM audiences are refreshed in real-time with a backfill done every 24 hours. Step #4 is explained in more detailed in Marketo's official documentation.

Another thing to note is that in Marketo, there will be an option to either "Send to Experience Cloud" (hashed email ids) or "Sync from Experience Cloud Audience" (ECIDs) to send and receive segments respectively. For Target, it's currently a one-way sync from Marketo.

Other Facts

Finally, let's take a quick look at some other interesting facts about the integration with Marketo:

Any email lead data from Marketo to Audience Manager must be hashed (handled automatically from Marketo if these are captured).
There is already an integration between AEM and Marketo where Marketo can receive assets from AEM to embed in emails. More information can be found here.
An integration between Ad Cloud, Real-Time CDP and Marketo is also possible. I have not worked with it directly but will share once I learn more.
This integration is not PHI compliant but can be used for any other customer not mandating PHI compliance.

Hope this gave you a general understanding of how this integration works. Feel free to share your use cases for this integration or let me know if you have any questions.

Monday, March 9, 2020

Overview of Adobe Device Graph

We are surrounded by all kinds of (regular and smart) devices. It's either a Laptop, Tablet, Smart Phone, Smart Watch, Smart TV, Smart Vacuum, Smart Plug, Nest Thermostat, Wifi Camera or Chromecast to name a few. However, not all of these devices are truly connected due to many factors with one being that not all devices may belong to one single company in a household but the most obvious one is the lack of a true user "Identity". The other issue we face is that it's really difficult to track users and attribute an action across all these devices consistently. Google does this well with Google Home where it's able to sync my Nest thermostat with Chromecast using my Gmail ID. The other company is obviously Adobe ;)

By 2030, Americans will own as many as 15 connected devices. While we're not fully there yet, the introduction of new devices every year might expedite that trend. In 2016, Adobe's coined the phrase "Devices don't buy products, people do" which is still very relevant in 2020 and will be in the future. So how does Adobe establish the link between multiple devices to one person? In this post, I'll provide an overview of the various ways by which Adobe is able to link multiple devices to a person or household.

Concept of a Device Graph

According to this article, "A device graph, also known as “identity management,” is a map that links an individual to all the devices they use, which could be a person’s computer at work, laptop at home, tablet and smartphone". I'd like to add other smart devices to this list but the most common use cases for cross device analytics we see today are still around mobile, desktop and tablet but there's continuous innovation happening to bring different types of devices into the mix.

Probabilistic and Deterministic Linking

The Adobe device graph comprises of multiple devices linked together via two methods namely deterministic and probabilistic. This Adobe article explains this concept really well but at a high level, probabilistic device link allows us to predict a person's identity (John Doe in our case) based on IP address, operating system etc. and deterministic device link allows us to identify a person based on their encrypted user ID captured on the website sent over to the Experience Cloud ID Service across devices. Please note that this matching and attribution happens

The visual below is my attempt to explain the device graph at a high level where John Doe visits a website or mobile app using his iPhone, iPad and Mac. There are prettier visuals available in the Adobe documentation but I just wanted to create something simple to convey the concept.

Types of Device Graphs

There are primarily two types of device graphs which Adobe supports and these are ways by which you can create a true identity of your customers across multiple devices and sites. There's also an external graph option as well which allows companies to leverage 3rd party device graph data which is explained in detail here but it's not in scope for this post.

Device Co-Op

The Device Co-Op (available in US and Canada) allows companies to participate in a device graph which allows them to identify their "linked" customer devices (at a person and household level) across a magnitude of channels and websites in near real-time. The last time I heard about the scale of the Co-op, there were 100+ companies, about 300 Million users and 2 billion devices part of the Co-op device graph but this number is obviously higher now.

Source: https://theblog.adobe.com/cross-device-marketing-three-tips-success/

The concept of the Co-op can be better understood based on the visual (above) taken from the Adobe blog:

A customer John Doe visits the travel website and authenticates on both his mobile device and laptop.
He then goes to a retail website but doesn't authenticate so the retailer doesn't know who this customer is.
Device co-op enables the retail website to "link" the customer's devices assuming both websites (companies) participate in the Device Co-op and identifies the anonymous user as John Doe.
This in turn allows both companies to personalize the experience for this customer on both devices and websites. As you can see, the Device Co-op makes use of both the probabilistic and deterministic linking methods.

In contrast, if these companies didn't participate in the Co-op, then the retail company wouldn't be able to know what all devices did its customers use before purchasing something and treat it as 2 unique visitors instead of 1.

Below are some common use cases of the Device Co-op:

If you want to access to a large pool of users for prospecting related use cases.
If you want to perform frequency capping across devices.
Some other use cases are covered here.

Here's a link to a document which covers the membership and eligibility criteria for companies to participate in the Device Co-op. One other requirement of the Device Co-op is for the company to make changes to its privacy policy so it takes into account all the necessary privacy requirements and it does not collect any kind of PII or behavioral data. You can view your all your devices linked to the Co-op here and can unlink your devices from it anytime.

Private Device Graph

The Private Graph is another way for a company to link their customer devices in a device graph but visible and accessible only for their own organization and not any other company.

Using the previous example, if we just look at the travel website alone we can treat it as a participant of the private graph as the data will simply be available within the context of that company. Private Device graph primarily makes use of the deterministic link as it works best if encrypted user ids are captured. Probabilistic matching will also be available to Private Graph sometime this year.

Below are some use cases of the Private Device Graph:

If you want to reconcile user identities across multiple devices into one.
If you want to perform frequency capping across devices thereby optimizing ad spend.
If you want to establish a common identity across online and offline channels.

In order to participate for the Private Graph, the customer must be on Analytics Ultimate or have Audience Manager or have Target Premium and also be an Adobe Experience Platform customer. If you qualify for this as a client, subscribing to this should be a no-brainer for you given that no privacy policy updates need to take place. However, Device Co-op does give you access to a much larger amount of users which you wouldn't get with a Private Graph so you'll have to weigh your options on which one to choose.

Device Graph and Adobe Experience Cloud Solutions

In this section, I'll cover how to leverage some of the Adobe solutions I've used in conjunction with Device Co-op. Please note that I've only used Adobe Analytics and Audience Manager for customers participating in Co-op but there are use cases pertinent to Adobe Experience Platform, Adobe Target and Ad Cloud as well.

Adobe Analytics

Device Co-op is a natural fit for Adobe Analytics given the availability of the "People" metric which deduplicates the user count tied to multiple device and provides a true representation of a user as opposed to a device. This was introduced back in 2017 so it's been around for a while now and you can find more information about it here. Below is an example of what this looks like in a sample taken from the Adobe documentation.

Source: https://docs.adobe.com/content/help/en/device-co-op/using/data/people.html

The other service you can leverage (I've not used it yet) is Cross Device Analytics (CDA) which allows you to analyze cross device behavior in Analysis Workspace using Adobe Analytics data (needs a cross device report suite). This is not a default service and all the details and eligibility requirements are included in this Adobe Spark page.

Audience Manager

If you are a member of the Co-op and use Audience Manager, you get a lot of benefits primarily around prospecting and cross device frequency capping in offsite marketing. The first thing to do is to setup your Profile Merge Rule similar to how it's shown in the screenshot below taken from Adobe's documentation.

The other thing which is very consistent with the screenshot is that your Co-op devices per Person count should be lower than the Person count of other data sources. Finally, you should expect to see a much larger count of users (potential reach) in the Co-op Person number compared to any other data source.

Source: https://docs.adobe.com/content/help/en/audience-manager/user-guide/features/profile-merge-rules/profile-link-metrics.html

Adobe Experience Platform, Adobe Target, Ad Cloud

Device Co-op also provides additional capabilities to Adobe Experience Platform for id stitching, Adobe Target for personalizing experiences across devices and to Ad Cloud for media uses cases around retargeting across devices. I haven't personally leveraged Co-op for AEP, Target and Ad Cloud so I'm unable to provide any additional context as I don't have much exposure to these three in the context of Device Co-op.

So, that was a high level overview of the Device Graph but I'll be writing more about it as I learn more about how it's used with other solutions of the Adobe Experience Cloud stack. Please feel free to share your feedback!

Saturday, February 8, 2020

Review Adobe Experience Cloud ID Cookies on Google Chrome 80

Web Browser Cookies have long been the lifeblood of the digital marketing ecosystem. A cookie is a tiny text file used by a web browser that typically captures non-intrusive information about a browser (indirectly a user) such as logged in state, user preferences and anonymized or encrypted ids etc. A cookie allows companies to measure browsing patterns (pages visited, products bought), remembering products added to a shopping cart or simply personalizing user experiences that match previous patterns and behaviors.

As of December 2019, Google Chrome was the most popular web browser with a market share of 69%. Google recently released their newest Chrome browser version 80 which introduced clear guidelines around how cookies need to be set moving forward keeping in mind privacy regulations such as GDPR and CCPA. As an example, Safari now completely blocks 3rd party cookies from being set. Given that Google has advertising platforms which primarily leverage 3rd party cookies, there are still a few years left before Google completely phases out 3rd party cookies by 2022 which means we don't have a lot of time left. So, what does it mean for companies like Adobe which also rely on cookies for measuring user behavior using 1st party cookies and activating anonymous profiles on publishers using 3rd party cookies in the interim?

In this post, I will review changes made by the Adobe Identity Service team to address cookie setting requirements in Google Chrome 80. I will refer to this article written by the Adobe Identity service team and validate changes made by Adobe primarily around the Experience Cloud ID Service cookies. So let's dive in!

What is all the Fuss About?

Here, I'll cover exactly was has been changed by Chrome 80 and I've made a simple decision tree to depict what the change is in regards to the new cookie guidelines. At a high level, 3rd party cookies need to be secure with a SameSite attribute equal to "None". On the other hand, cookies without a SameSite attribute will default to "lax".

In the next two sections, I'll do a quick pre/post comparison between Chrome 79 and Chrome 80 and review the Experience Cloud demdex cookie set in both versions.

The World Before Google Chrome 80

I'm first looking at Chrome version 79 and I've visited an Adobe customer website using the Experience Cloud Visitor ID Service.

I'll primarily focus on the demdex which is our 3rd party cookie that is most susceptible to deletion after this change. I previously wrote about migrating to the Visitor ID service where I've covered some of the cookies set by the ID service in more detail. The first thing we see is an error in the developer console specifically calling out the demdex cookie and stating that it's set without the SameSite flag.

The World After Google Chrome 80

In this section, I will show how the Google Chrome error for demdex went away after I updated my browser version and look at the site customer website in incognito mode.

Looking at what the developer console shows for the same customer website, we can see that the change was made by the Adobe ID Service (demdex) server side and the error went away. Please note that it DID NOT require a Visitor ID service version upgrade as the change was made server side. Having said that, it's always advisable to upgrade your ID service library to the latest version.

Now looking at how the demdex cookie is now set as shown by Chrome 80, we can see that the cookie has both the SameSite=None and Secure values set with a TTL expiration of 6 months.

What is the Recommendation for 1st Party Cookies on Safari?

In this section I want to talk about the importance of leveraging a CNAME tracking server to measure your website activity in Adobe Analytics which is more of an issue post ITP2.1 in Safari (slightly going off topic). This Adobe article covers how we can use a CNAME to set a new s_ecid cookie that extends the AMCV cookie expiration to 2 years instead of 7 days which Safari enforces today (see below).

Please note that this requires ID service version 4.3.0 + to take advantage of this change to extend your visitor expiration to 2 years instead of 7 days on Safari.

So, that's it! Hope found this helpful in understanding what changes were made by Chrome 80 and how Adobe is prepared to address any potential tracking issues as a result of this.

Saturday, June 22, 2019

Send Real-Time Adobe Analytics Events to Adobe Campaign via Triggers

Triggers are part of the Experience Cloud Activation Core Service and have been in existence for a few years now. There's a lot of documentation already out there but with this post, I'll fill in some gaps that exist in the public facing documentation. I will also provide a quick overview of Triggers from my sandbox account, cover common use cases, share a logical architecture diagram and discuss the provisioning process along with some common access issues. Let's get into it!

Overview of Triggers

Triggers allow marketers to activate Adobe Analytics events in Adobe Campaign to re-market and engage customers via emails and other channels. Adobe Campaign is the main solution that leverages Triggers to send emails or SMS based on an action performed on the site in near real-time. I will be covering the integration between Triggers and Adobe Campaign Standard (ACS) at a high level.

We can access Triggers by going to the Activation site and clicking "Manage Triggers" (provisioning covered in the next section). There are 4 types of Triggers we can create which are:

Abandonment (Send an email or SMS after a gap of between 10 minutes to 2 hours)
Actions (Send an email or SMS if a particular action is performed on the site)
Session Start (Send an email or SMS if an action occurred at the start of a session)
Session End (Send an email or SMS if an action occurred at the end of a session)

Below is the UI we see when we create a new Trigger based on an abandonment.

Once created, Triggers will start collecting data immediately based on the conditional logic. In my actual example, I've created a simple Trigger based on an action tied to a particular Page Name.

Few Considerations While Using Triggers

We can create up to 100 Triggers.
We cannot bring in any calculated metrics or segments created in Adobe Analytics.
There's no way to select a Visitor container like we can in the Analytics Segment UI.
Values from Adobe Analytics reporting don't automatically populate in the dropdown menu when we use the "Equal" operator.
For Products or other dimensional data, there's no way to know which particular product has been added to the cart etc. so all the data is sent as it comes in. Prior manipulation of data will have to done to specify exactly which product was sent.
The conditional logic to create Triggers can get really cumbersome and there's a lot of flexibility provided around boolean logic and Containers provided in the Triggers UI.

Common Use Cases For Triggers

There are numerous use cases that can be met using Triggers and below are some examples. Please note that for these to work properly, the user would have to be signed in.

Abandonment (Time Bound)

A user abandons the cart or form and needs to be contacted within 10 minutes
A user signs up for an offer and you need to send a confirmation email
Notify of a shipment or password reset
A user purchases a product

Actions (Event Driven)

A user views a promotional video
A user completes a survey
Personalize email to show last product viewed
Confirm when a prospect opts-in for a newsletter

Session Start and End-I haven't used these yet

A user visits a campaign landing page after clicking on an ad
A user did not sign up for a form and exited the site

Aside from these, we can leverage the propensity score attribute to NOT trigger an email if a user is likely to visit the website in the next 30 days.

Triggers Provisioning

Email the Digital Request Alias

Anyone can can email the Digital-Request@adobe.com alias to get Triggers enabled for their Experience Cloud Org. This team will enable Triggers in the Admin Console as well as enable Triggers in Adobe Campaign Standard (They create an additional ticket). Below is what needs to be communicated in the email:

Marketing Cloud Company Name
IMS ORG ID
Analytics Login Company (could be same as marketing cloud company name)

Map Report Suites to the Experience Cloud Org

All Adobe Analytics Report Suites need to be mapped to the correct Experience Cloud Org as explained here.

Enable Triggers in the Admin Console

In the Adobe Admin console, we need to turn on the toggle to enable Triggers as shown below.

Create Data Sources

Create a data source in Customer Attributes to capture authenticated users which includes an integration code. This is needed to tie users logging in to the website with profile data in Adobe Campaign Standard. Please note that the user ID is hashed and needs to be reconciled in Adobe Campaign Standard (covered below).

Sync the Hashed User IDs with the Experience Cloud

This is a very important piece of this integration and is a required step to sync Customer or Declared IDs captured on the site with AAM or Customer Attributes and eventually with Campaign. This can be done easily in a Tag Manager like Launch.

Reconcile Triggers with the ID Service in Campaign Standard

The final step is to reconcile the an encrypted ID with a Declared ID data source in Adobe Campaign Standard. Below is an example of a Declared ID data source in ACS which is a new data source that needs to be created tied to the authenticated Customer ID by going to Administration -> Application settings -> Shared Data Sources. The link below the image covers this step in more detail.

Here's some more information on how to configure Triggers to send emails in Adobe Campaign Standard:

Triggers are also Accessible via Adobe I/O

I recently wrote about Adobe APIs last time and covered how to create an integration in Adobe I/O but this link covers how to connect with the Triggers API.

Common Access Issues

I recently ran into some issues while trying to access Triggers and had to log tickets internally at Adobe so if you run into these issues, you'll have to ask your Campaign consultant to log these on your behalf.

The first issues I ran into was around not being able to create a trigger. The fix for this was to map the report suites to the Experience Cloud (covered above).

This is an issue which I'm currently facing for a client where I'm unable to create an authenticated Customer ID Data Source. I had to log an internal ticket to get this resolved.

Simplified Integration Architecture

Below is a simplified architecture diagram I put together to outline the integration between Analytics and Adobe Campaign Standard using Triggers. I've leveraged some internal documentation to provide more details primarily around steps 4-6. Below is a screenshot of that and a summary of the various steps.

1 - AEM Services the page
2a - ECID Service is called and relevant IDs are returned back to the page
2b - If the visitor is logged in, an Authenticated "Declared ID" will be paired with the ECID
3 - Analytics image request fires and page/event level data gets sent to Adobe Analytics
4 - Real-Time Events sent via Analytics are detected using the Triggers State Machine
5 - Events are "enriched" with the Customer ID sent from the ID Service
6 - The enriched trigger events are sent through Pipeline Services and made available to Campaign. ACS "listens" for Trigger data that comes in as IDs starting with analyticsHitSummary
7 - Campaign queries data sources to build personalized multi-channel messages
8 - Campaign ingests/shares data from/to other data sources
9 - ACS delivers marketing messages across channels (Email, SMS) based on Triggers
10 - Customer clicks on the email and is routed back to the client website

So that was it! I hope you found this post helpful and hope that it will pique your interest in Triggers if you aren't already using it. Here's a link to another post where I've written about how to use webhooks to listen for Triggers.

Sunday, May 6, 2018

Migrate legacy Adobe Visitor ID to Experience Cloud Visitor ID

The Adobe Experience Cloud ID Service (formerly known as the Marketing Cloud ID Service) has been around for more than three years now but there are some Adobe Analytics customers who are still on the legacy visitor tracking system. This post covers the various steps involved in migrating from a legacy Analytics tracking solution to the new Experience Cloud Visitor ID Service.

The Experience Cloud Visitor ID Service leverages a common and universal cookie identifier across all Adobe solutions that enables us to seamlessly integrate Adobe solutions with each other.

The Visitor ID service provides the following benefits:

As explained above, the ID service provides us with the benefit of seamlessly integrating all Adobe solutions which isn't easy to do with the legacy visitor tracking solution.
Visitor ID service enables the Adobe Experience Cloud Device Co-op which is a feature that allows subscribed customers to identify customers across devices and mobile apps. Device co-op also provides customers with the “People” metric that shows a deduplicated count of your users across multiple devices.
It enables Customer Attributes that allows customers to upload offline CRM data and tie it to online behavioral data.
Customers can leverage the latest video Heartbeat tracking that provides a lot of functionality to track media events across multiple video player formats.
It sets a first party cookie (AMCV) that is less susceptible to deletion. The legacy visitor tracking method (by default) sets a third party cookie that is more likely to be deleted by browsers, firewalls and ad blockers. This benefit may not apply to customers who leverage a CNAME as the tracking server where they set the cookie on their own domain.
It removes the need to get tracking servers migrated to a CNAME (E.g. metrics.companyname.com) which would otherwise require additional support from the network operations team. This benefit only applies to customers who are already on RDC (covered below).

Before we proceed, let's first take a look at the various cookies involved in this process. The following table shows which cookies & IDs come into play during the Visitor ID migration. Please click it to enlarge if you're unable to see it clearly.

Now that we've looked at the various cookies involved, let's go through the steps we need to follow to migrate to the new Visitor ID service.

Migrate Tracking Server to RDC

Visitor ID Service requires the tracking server to be migrated to RDC (Regional Data Collection) which is a network of data collection servers that are faster, safer and more reliable compared to the older data collection servers. RDC connects to the closest data center thereby reducing response times of image requests and incorporates load balancing to switch servers in case of a failure.

The RDC domain is on "omtrdc.net" as opposed to the legacy "2o7.net" domain so it's always a good idea to check if you're already on RDC (omtrdc.net) or 2o7.net. The steps outlined in this Adobe article shows you how to check if your tracking server is on RDC or not.

If you're on the legacy 2o7.net domain then you will have to switch your tracking server entirely or if there are other domain change scenarios involved in your case, then follow the steps outline in this Adobe article to proceed.

If you're already on CNAME pointing to 207.net legacy servers and don't plan to change your tracking server, then you will follow the following steps:

Contact Adobe client care to request a migration to RDC by providing them with your existing CNAME based 2o7.net secure and non-secure tracking server names.
Customer services provides you with the new RDC tracking server hostnames which will end with omtrdc.net.
Contact your network operations team to redirect your CNAME tracking servers to now point to the new RDC (omtrdc.net) domain.
Finally, test your tracking servers by pinging them and validating if they're redirecting to the omtrdc.net domain as described in this article.

Setup Grace Period

A grace period typically setup for 30/60/90 days is put in place when customers want to continue leveraging the legacy analytics s_vi cookie in place of the new AMCV cookie set by the Visitor ID service. This is most commonly put in place if certain areas of the website have an older code version that cannot upgrade to the Visitor ID service and the implementation is leveraging a global report suite. The reason why it's necessary to put a grace period in place so that we don't see visitor "cliffing" or inflation in visitor & visit counts. That's because the Visitor ID service leverages a new cookie to track visitors and will probably count a repeat visitor as a new visitor. A grace period can also be setup for a company that wants to avoid visitor "cliffing" as they prepare to factor in the eventual visitor & visit inflation.

To request a grace period, contact the Adobe client care team and provide them with the following information:

Experience Cloud or IMS Org ID
Company Name
Data Center
Date to start Grace Period
Grace Period Length (Up to 180 days but can be extended)

Setup Visitor ID Service

Once a grace period has been put in place by client care, work with your IT team to setup the Visitor ID service. Here's an example from the Launch by Adobe Tag Management tool to show the Visitor ID service extension. Notice that the we have to put in the Experience Cloud Org ID and populate the secure and regular tracking server fields (highlighted in Red) to setup the Visitor ID service which is required to get grace period to work and for the 'aid' parameter to appear.

Once the ID service is setup, you will start to see the new first party AMCV cookie and third party demdex cookie appear in your browser instead of the legacy s_vi cookie. However during a grace period, the s_vi continues to be set and is populated in the AMCV cookie to avoid visitor & visit inflation. Below is a visual that explains how cookies are set during a grace period.

Source: Adobe Blog

Validate

The next step is to validate the grace period. This is done by checking if the "AID" and "MID" parameters appear in the Analytics image request. The "AID" will contain the Visitor ID value from the s_vi cookie and will continue to be set till the grace period is active. This screenshot shows what the image request during a grace period looks like.

Prepare for the Inevitable

Finally, the most important step is for you to internally prepare your organization for this change as it's a revamped methodology to track visitors and at some point, you will have to confront the reality of visitor inflation when the grace period is turned off. Please note that this visitor "cliffing" will ONLY impact repeat visitors as new visitors will automatically get the new AMCV cookie.

It might be a good idea to estimate how much impact this change will have on your visitors & visits based on your repeat visitors. If you're on the grace period for 180 days and turn it off after that, what % of your repeat visitors come back to your site or app after 6 months. This number will vary based on the kind of business you're in so all in all, you need to weigh the pros and cons and determine when you want to take the plunge.

So, that was it! If you're already on the Visitor ID service and don't have to deal with any of these outlined steps, then Congratulations. If not, then I'd highly encourage you to give a serious thought to proceeding with it as it will be worth it if you're an Adobe Experience Cloud customer.