Issue with the adobe visitor id between native app and Webviews

[nitesh__anwani]

Issue: In the Android and iOS apps, we present content to users from both native screens and web views. To ensure the user is counted uniquely and tied to the same session, we use the "appendVisitorIDsTo" app SDK method to append the "adobe_mc" parameter to the URL of web view page loads. However, there have been instances where we launched new web view navigations in the app and missed implementing appendVisitorIDsTo, while all existing web view navigations have this method properly implemented.
appendVisitorIDsTo doc -- https://experienceleague.adobe.com/en/docs/id-service/using/id-service-api/methods/appendvisitorid

Our observation is that when a user installs the app and accesses any web view that doesn't have the "adobe_mc" parameters appended, a new ECID is created for that visitor on the web view. This new ECID persists across all subsequent web view navigations regardless of different ECIDs being passed in the "adobe_mc" parameter, resulting in inflated visitor and visit counts in the reports.

Expected: When a page is loaded with the provided ECID in the "adobe_mc" parameter, the ECID on the page should be reset with the one provided in the URL, ensuring the same visitor is counted on both screens.

We have simulated the following 2 scenarios:
Scenario 1
The user accesses the first web view without the adobe_mc parameter.
A new ECID is generated on the web view.
Subsequent web views have the adobe_mc parameter appended, but all Adobe Analytics hits use the new ECID generated on the first page load.
This results in the Unique Visitor count and visit count being inflated to 2 in the reports. 

The app was installed freshly from the app store to test this scenario.

Scenario 2
The user accesses the first web view with the adobe_mc parameter.
The same ECID is synced on the web view for the page load.
A subsequent web view without the adobe_mc parameter still maintains the ECID synced with the native app session.
The Unique Visitor count and visit count remain as 1 in the reports. 

The app was installed freshly from the app store to test this scenario.

The main concern and expected resolution:
As observed in Scenario 1, ensuring the adobe_mc parameter is appended to the URL will sync the visitor ID correctly for new users. However, for users who have already encountered this issue, the new visitor ID generated on the web view will persist.
Why does the adobe_mc parameter not sync the ECID on the web view as expected?
Is it possible to correct this issue for users who have already been impacted? If yes, what would be the recommended approach?

Any documentation or recommendation is highly appreciated!

We are confident Scenario 1 is affecting our actual user base. Our data analysis of raw data feeds, comparing hits with the adobe_mc in the full page URL and the ECID value in the hit, shows that over the last 3 months, approximately 30% of iOS visitors and 10% of Android visitors have been impacted by this issue.

Thanks,

Nitesh

@Jennifer_Dungan @MandyGeorge @yuhuisg @Krishna_Musku 

[Jennifer_Dungan]

Hi @nitesh__anwani;

At this time, I haven't actually implemented the appendVisitorIDsTo (since we don't have enough WebViews in our apps yet to make this a priority)...however, that said, this part of the code seems to be working correctly..

The issue seems to reside on your website not properly reading those passed IDs and overriding the values... and since as far as I know, that is supposed to happen automatically (and doesn't appear to be), I think this is where you have to focus your efforts.

First off, are you using the old Client Side tracking on your website, or WebSDK?

Next, I would start by testing on the web with a sample URL (with the params), open up a new incognito window (no params), and have a new ECID generated... then try loading the URL passing the new ECID and watch specifically what happens... does the new ECID load in? Does it not (I suspect this is the case given your above issue)?

Try to capture what is going on.... you may need to reach out to client care, showing that the Visitor ID service is not using the passed values.

The only other thing I can think of would be to write some custom code to force the ECID, but you shouldn't have to do that, as this is supposed to be the default behaviour.

[nitesh__anwani]

Hi @Jennifer_Dungan ,

Thanks a lot for your response!

We are using client-side tracking on our website.

I tried replicating the scenario on the website and observed the same behaviour, the ECID is not being overridden by the one passed in the URL parameters.  

I tried to find the way on how to reset ECID value, but couldn't find any relevant method to do that.

I have opened case with adobe support.

Thanks,

Nitesh

[Jennifer_Dungan]

Ok, hopefully you will get a response soon! Please share it here, since I am very interested... 

Given the whole "passing the ECID to a target website" is specifically about trying to stitch users together; you would think that should force a change... unless all the stitching is done on the Adobe Site (the visid_high and visid_low in the Raw data that identifies the "Unique Visitor"... like maybe there is a many-to-one mapping table that says these multiple ECIDs all map to this visid.... 

[yuhuisg]

Firstly, I'm not sure why your're using ECID's appendVisitorIDsTo. That method works for web-to-web traffic only. Since you're asking about app-to-web traffic, and assuming that you are using Adobe Mobile SDK in your app, then you should be using Mobile SDK's appendToURL / appendVisitorInfoForURL. See https://developer.adobe.com/client-sdks/home/base/mobile-core/identity/api-reference/#appendtourl--a...

One thing that ECID's appendVisitorIDsTo does is that besides the "adobe_mc" parameter, it also attaches a "ts" parameter to the URL. This "ts" parameter has the value of the current timestamp when appendVisitorIDsTo was called. If the resulting URL is not opened after a certain duration after that "ts" value or the "ts" parameter is absent in the URL, then ECID ignores the "adobe_mc" parameter and uses its usual methods of getting the ECID value. I forgot what the duration is, but I recall that it's a very short duration, perhaps less than 2 minutes.

Since you're using ECID's appendVisitorIDsTo from the app's code, it could be that this "ts" parameter is missing or set wrongly.

But I suggest that you look at Mobile SDK's appendToURL / appendVisitorInfoForURL.

[fhusain]

Adding to @yuhuisg comment, the TS: A timestamp parameter that cannot be older than five minutes. https://experienceleague.adobe.com/en/docs/experience-platform/web-sdk/identity/id-sharing#:~:text=1...

[nitesh__anwani]

Hi @yuhuisg , @fhusain ,

Thanks a lot for your response!

I checked with the app development team, they are using the Adobe mobile SDK method appendVisitorInfoForURL itself to add ECID, MCORGID, and TS in the adobe_mc parameter.

the issue is that when a user lands on the web view at the very instance where the adobe_mc parameter is missing, the new ECID is generated, and later all the subsequent sessions of webview persist the new ECID generated regardless of the adobe_mc parameter passed to web view URL or not.

Thanks,

Nitesh

[nitesh__anwani]

We have received an update from Adobe support team.

team has recommended setting the overwriteCrossDomainMCIDAndAID as TRUE on the web view.

https://experienceleague.adobe.com/en/docs/id-service/using/id-service-api/configurations/overwrite-...

we are working on testing out this solution.

Thanks!

CC: @Jennifer_Dungan @yuhuisg @fhusain 

[Jennifer_Dungan]

OK, keep us up to date on if this works.. I will be keeping my fingers crossed for you.