Expand my Community achievements bar.

SOLVED

Why us there more than 1 Unique Visitor for some ECIDs

Avatar

Level 4

My understanding is that when a visitor goes to our site (with Adobe Data Collection/Analytics), the Adobe software looks for an Adobe cookie. If there is one found it means that cookie was created previously and an ECID already exists for that visitor (or technically the browser/device). If there isn't one found, a new cookie is created. Each ECID is a unique identifier for a unique browser/device.

How is it possible that in Workspace I see ECIDs that have more than one Unique Visitor count? In essence, isn't the Unique Visitor a count of unique ECIDs? Or am I misunderstanding this? Not all ECIDs in Workspace have more than one Unique Visitor. The majority have a 1:1 ECID vs Unique Visitors but there are some that have more than 1 Unique Visitor count for 1 ECID.

 

eVar11 is the ECID in the screenshot.

michaela7702973_1-1647979275925.png

 

 

 

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

What is the code of the data element called using line: _satellite.getVar('Marketing Cloud ID') ?

 

I agree with the advice to use doPlugins to collect Visitor ID data as it will be executed each time a s.t() or s.tl() is called.

 

Persistence of an eVar is linked to allocation and expiration but in our case I do not think it will necessary have an effect. You have the same eVar value for 2 unique visitors, this means that for 2 distinct visitor profile the same value was set and persisted. As the persistence of a value is scoped to a visitor profile, I believe it cannot span 2 visitor profiles, therefore if a new visitor id is generated for the user the value will not persist to the new profile with the new visitor id.

 

What I would expect here is the code you are using to set the Visitor ID in the doPlugins somehow returns same value for multiple users. Usually to debug this support would do 2 things:

  • First request an URL from your side where we can check the implementation, as you are using Adobe Launch we can easily scan the library without using .min from your launch URL to have a better understanding of what is happening
  • Second you should request from Adobe Support if they can export raw logs (basically data feed export for one day) from 1 specific day and check on what pages the eVar11 duplicated values are set and which visiorID values are used. Could it be that it is linked to some sort of 2 types of visitor ID type set on some pages like legacy analytics visitor ID and new MID. In this case MID will be generated with same value but in one part of your website there is a legacy s_vi cookie and in another part there is not, so same eVar11 value which contains MID value will be reported but in terms of unique visitor metric in one side of your website it will allocate to legacy s_vi and in another just to MID as there is no s_vi. By exporting raw logs you can check the type of visitor ID used on the hit. I would ask to add columns "mcvisid", and "visid_type".

visid_type will be the one to give you an indication of which final value has been used, so if the value is NOT 5 and mcvisid is present then it would mean that somehow you have some users still using legacy analytics cookie or some other sort of identification, even if you have implemented visitor id services.

 

visid_typeNot for external use; internally used by Adobe for processing optimizations. Numeric ID representing the method used to identify the visitor.
0: Custom visitorID or Unknown/not applicable
1: IP and user agent fallback
2: HTTP Mobile Subscriber Header
3: Legacy cookie value (s_vi)
4: Fallback cookie value (s_fid)
5: Identity Service
tinyint unsigned

View solution in original post

4 Replies

Avatar

Community Advisor

What are the allocation and expiration settings of eVar11?

Avatar

Community Advisor

The issue might come from how you capture/sotre/persist the value in your code.

 

You are correct in saying that a customer should only have one ECID/MID per Unique Visitors, it should have a 1:1 relationship. Based on the screenshot provided, it does look like you might have your own custom code to populate eVar11.

 

If you have data feeds in your business, try to query it for the day and validate that the visitor ID for the hits where one of the duplicate unique visitor for a value of eVar11 exists is the same or differs.

 

If you provide us more details on how it is implemented or provide us the URL we might b able to have a look to validate your implementation. Also what is the configuration of eVar11, like allocation and expiration.

Avatar

Level 4

eVar11 Allocation is - Most Recent (Last). Expire after is - Never.

 

There is custom code that pulls eVar11. There was an issue last year that was causing eVar11 to show Unspecified for 30% of PVs. Adobe support was contacted and they recommended to add this code into the Adobe Analytics extension in Data Collection (aka Launch). This is the code as is from the AA extension (CONFIGURE TRACKER USING CUSTOM CODE): 

 

/* March 2021: Bug exists where MCID is set to Unspecified for 30% of page view hits. Adobe Support advised to use doPlugins and provided code below. */

s.usePlugins= true;
s.doPlugins = function() {
s.eVar11 = _satellite.getVar('Marketing Cloud ID')
}
/* end of doPlugins for MCID */

 

 

Just a reminder again that not all ECIDs show 2 Unique Visitors in Workspace. Majority has 1 UV per 1 ECID but there's the odd one that has >1 UV per ECID; so this appears to be an intermittent issue.

Avatar

Correct answer by
Community Advisor

What is the code of the data element called using line: _satellite.getVar('Marketing Cloud ID') ?

 

I agree with the advice to use doPlugins to collect Visitor ID data as it will be executed each time a s.t() or s.tl() is called.

 

Persistence of an eVar is linked to allocation and expiration but in our case I do not think it will necessary have an effect. You have the same eVar value for 2 unique visitors, this means that for 2 distinct visitor profile the same value was set and persisted. As the persistence of a value is scoped to a visitor profile, I believe it cannot span 2 visitor profiles, therefore if a new visitor id is generated for the user the value will not persist to the new profile with the new visitor id.

 

What I would expect here is the code you are using to set the Visitor ID in the doPlugins somehow returns same value for multiple users. Usually to debug this support would do 2 things:

  • First request an URL from your side where we can check the implementation, as you are using Adobe Launch we can easily scan the library without using .min from your launch URL to have a better understanding of what is happening
  • Second you should request from Adobe Support if they can export raw logs (basically data feed export for one day) from 1 specific day and check on what pages the eVar11 duplicated values are set and which visiorID values are used. Could it be that it is linked to some sort of 2 types of visitor ID type set on some pages like legacy analytics visitor ID and new MID. In this case MID will be generated with same value but in one part of your website there is a legacy s_vi cookie and in another part there is not, so same eVar11 value which contains MID value will be reported but in terms of unique visitor metric in one side of your website it will allocate to legacy s_vi and in another just to MID as there is no s_vi. By exporting raw logs you can check the type of visitor ID used on the hit. I would ask to add columns "mcvisid", and "visid_type".

visid_type will be the one to give you an indication of which final value has been used, so if the value is NOT 5 and mcvisid is present then it would mean that somehow you have some users still using legacy analytics cookie or some other sort of identification, even if you have implemented visitor id services.

 

visid_typeNot for external use; internally used by Adobe for processing optimizations. Numeric ID representing the method used to identify the visitor.
0: Custom visitorID or Unknown/not applicable
1: IP and user agent fallback
2: HTTP Mobile Subscriber Header
3: Legacy cookie value (s_vi)
4: Fallback cookie value (s_fid)
5: Identity Service
tinyint unsigned