Expand my Community achievements bar.

Join us January 15th for an AMA with Champion Achaia Walton, who will be talking about her article on Event-Based Reporting and Measuring Content Groups!
SOLVED

Tracking visitor from app to webview

Avatar

Level 4

Dear Community,

 

I have a hybrid app, that generate webviews at some points (for cart view and checkout for example).

At the moment, I'm getting 2 differents visits. Once the visitor is landing on the webview, Adobe is generating a new MID instead of keeping the same that has been generated during the app view session.

 

I didn't do the implementation myself. A dev team did it. I know that they followed this documentation, as I'm not a developer, I'm wondering how I can check that the implementation has been done correctly. 

From what I understand the dev team that worked on this subject, didn't use Experience Cloud visitor ID as I don't see the extension installed in launch.

 

I also saw this documentation: 

- iOS part

- Android part

 

I also know that we have only one report suite for everything Desktop version, Android App, iOS App. Do we absolutely need to get different report suites? 

 

I hope that I shared all the needed information to help you understand the situation.

 

My main question is:
How can I track visitors from app view through webview without generating 2 differents ID / visits?

 

Thanks a lot for your help.

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

@Swanan_ The Android SDK generates a unique visitor ID when an app is installed. This ID is stored in persistent memory on the mobile device, is sent with every hit, and is removed only when the user uninstalls the app.

 

Typical mobile web implementations use the same standard Analytics s_code.js or AppMeasurement.js that is used in desktop sites. However,  The JavaScript libraries have their own methods of generating unique visitor IDs, which causes a different visitor ID to be generated when you open mobile web content from your app in your case.

 

You would need to make sure through implementation the visitors are stitched across mobile and webviews

In order to do that, you would  call visitorAppendToURL: when opening the web view url.

 

Here is the documentation on the same which explains this in detail

https://experienceleague.adobe.com/docs/mobile-services/android/sdk-reference-android/hybrid-app.htm...

 

Hope this helps

 

 

 

View solution in original post

8 Replies

Avatar

Correct answer by
Employee Advisor

@Swanan_ The Android SDK generates a unique visitor ID when an app is installed. This ID is stored in persistent memory on the mobile device, is sent with every hit, and is removed only when the user uninstalls the app.

 

Typical mobile web implementations use the same standard Analytics s_code.js or AppMeasurement.js that is used in desktop sites. However,  The JavaScript libraries have their own methods of generating unique visitor IDs, which causes a different visitor ID to be generated when you open mobile web content from your app in your case.

 

You would need to make sure through implementation the visitors are stitched across mobile and webviews

In order to do that, you would  call visitorAppendToURL: when opening the web view url.

 

Here is the documentation on the same which explains this in detail

https://experienceleague.adobe.com/docs/mobile-services/android/sdk-reference-android/hybrid-app.htm...

 

Hope this helps

 

 

 

Avatar

Level 4

Hi @VaniBhemarasetty 

 

Sorry, but in the end the solution didn't help me to fix my issues.

 

My team shared a new information with me:

Apparently they have disabled third-party cookies via launch. So we are wondering if the demdex cookie  is a part of the problem / the solution ? Are we still able to track the visitor from app to webview even if these cookies are disabled ?

 

Thanks a lot.

Avatar

Employee Advisor

@Swanan_  MID is generated with the help of demdex cookie, disabling the third party domains and if you are not seeing a call to demdex , generation of MID would be an issue

 

You can check on how visitors are being identified by adobe analytics

 

https://experienceleague.adobe.com/docs/mobile-services/android/analytics-android/analytics-main.htm...

 

https://experienceleague.adobe.com/docs/core-services/interface/administration/ec-cookies/cookies-an...

 

You can reach out to client care with the mobile logs, so that team can assist you with the exact root cause even after implementing for webview. 

 

Because, it would be difficult to comment right now, without the mobile logs 

 

Regards

Vani

 

 

Avatar

Level 4

Hello @VaniBhemarasetty 

 

Thanks a lot for this information.

Unfortunately, we had to disable demdex cookie and the third party domains due to GDPR compliance matters.

 

Do you have a way around this problem?

Is there any solution to track users from app through webview without demdax cookie / third party domains ?

 

Thanks again for your help

Avatar

Level 3

Hi @Swanan_ ,

 

Not sure if you have solved the issue, but WebSDK will be a good option.

 

Thanks.

Avatar

Level 4

Hi @UserAP

Thanks for your help, the problem is still up. We are struggling to find a solution.

I'm not sure to understand what you're talking about. Do you have any documentation that I could read about the subject ?

Thanks a lot.

Avatar

Level 2

@VaniBhemarasetty, we followed this implementation and now our native code is appending the ECID and our Adobe Org ID in the webview URL. We can't observe the URL directly, but we can see it in development reporting. I did have one quick question. I tried to test this by appending the query string that I got from our development reporting to one of our webpages and I wasn't seeing the resulting s.t() or s.tl() call replacing the ECID with the one from the URL. Is this a viable way of testing this implementation? Or does this process only work if the user is sent from a native screen that has queried the Identity service to a webpage?