Cross device tracking with user ID (authenticated sites/apps) | Community
Skip to main content
F
fern1
Level 5
January 23, 2023
Solved

Cross device tracking with user ID (authenticated sites/apps)

  • January 23, 2023
  • 1 reply
  • 3789 views

I´ve many questions in regard of cross-device tracking:

1. We have many websites and a couple of apps (authenticated ones) that we would like to track the users. For instance, one of our products has an app and web version and some customers use both. But on a monthly basis, this user is the same for us, regardless of the platform it used, so we would like it to be unique (active user). What would be the best way to track this user? Would it be using our authentication ID (userID) since this ID is unique for each user?

We do have a global report suite that we would also like to know about this user journey among all our authenticated products. 
What are the options to accomplish that?

2. setting up a user ID.
for our websites we already have that, we have an userID eVar that is the same in all our report suites, including the global one, and getting the userID from a data layer. However, we are struggling to do the same for our app. 

In the app, I do understand the general idea that context data should be added in the app, and then a processing rule created to overwrite this value with the eVar. 
But going deeper (I'm no dev here), how will the context data pass the user ID information? what should be inserted in the code? we did a test previously that we managed to send this ID with track state (i think it was it), but first, we need to see all the IDs in the eVar and cross it with the other sites and guarantee we are not sending extras pageviews. 

The idea would be like the web, to know all the pages that each ID visited. 

3. Considering our app is not native, is there a way for this context data to be created via launch instead of inserted in the SDK? but again, if via launch, how will we point out how to get the unique user ID?

4. How would the processing rule look like?
Sorry that I'm asking step by step but it's really difficult to find documentation and information about mobile apps that are detailed and/or show step by step of processes, even more now with the mobile services UI end of service.

Thank you so much in advance!

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Jennifer_Dungan

So right now, there is always going to be some issues between your website and mobile app user identification...

 

There is a feature in Adobe that can be used that WHEN the website is opened via the app, then you can append the ECID to the website url, then the website will be overwritten with the app id (to try and get these to associate as the same UV... but there are still problems with this... 

 

1. The user MUST open the website via the app (if the two never interact this won't work)

2. This doesn't work going the opposite direction, Web to App....

 

 

Now, from an authenticated user perspective...  your developers know the logged in user ID when the user logs in... they can set this as a context variable and add it to your trackState / trackAction calls (and this should match how you collect on the website)... if you track this only on a login, then use Adobe's expiry period to retain the information, you can do the same on the app.. if you sent the data on every call in the website while the user is logged in, then you need to do that in the app.

 

In order to make sure your aren't sending multiple calls, that comes down to testing...  You either need to test with a proxy connection using Charles or Fiddler, or use AEP Assurance extension in your mobile app...

 

However, I am a bit confused, I've worked with you in the past, it seems like you are using the Adobe Launch Mobile App property, which is for native apps... I don't really understand how you can be using this, but also say you don't have a native app?

 

There are 2 options.. you either have a native app (which means using a language the is specifically coded to create a mobile application), or your are using a native app wrapper around a website using website analytics.... (or maybe you are using a wrapper that communicates with a wrapped website, but that sends the data through the native app wrapper - for all intents and purposes when it comes to analytics, this would be considered a native app since you would be using the SDK to send the data -  and you would need to be sure the web part was not sending web data). Also, since you say you are using the SDK (and I am assuming it's the mobile SDK and not the new Web SDK, this would indicate you are using a native app)

 

The biggest mistake I see people make on the SDK implementation is to send a trackState for their page, then send a second trackAction with all their context variables.. this is what you need to avoid.... 

 

TrackState is the equivalent of an s.t() call... just like your website has props, eVars, events, etc on that call, so too should your trackState.

TrackAction is the equivalent of an s.tl() call, and just like trackState, it should have the context data as part of the call.

 

As for using Launch, you cannot use Launch on a Mobile App property to set values that are unique to the page/user/etc... the developers need to set these as these values will change with the usage of the app (not logged in to logged in, on page A then on Page B, etc)... 

 

 

First, get how you are sending the data down.. it sounds like you need to get that sorted before you even start trying to figure out your processing rules.

1 reply

Jennifer_Dungan
Community Advisor and Adobe Champion
Jennifer_DunganCommunity Advisor and Adobe ChampionAccepted solution
Community Advisor and Adobe Champion
January 23, 2023

So right now, there is always going to be some issues between your website and mobile app user identification...

 

There is a feature in Adobe that can be used that WHEN the website is opened via the app, then you can append the ECID to the website url, then the website will be overwritten with the app id (to try and get these to associate as the same UV... but there are still problems with this... 

 

1. The user MUST open the website via the app (if the two never interact this won't work)

2. This doesn't work going the opposite direction, Web to App....

 

 

Now, from an authenticated user perspective...  your developers know the logged in user ID when the user logs in... they can set this as a context variable and add it to your trackState / trackAction calls (and this should match how you collect on the website)... if you track this only on a login, then use Adobe's expiry period to retain the information, you can do the same on the app.. if you sent the data on every call in the website while the user is logged in, then you need to do that in the app.

 

In order to make sure your aren't sending multiple calls, that comes down to testing...  You either need to test with a proxy connection using Charles or Fiddler, or use AEP Assurance extension in your mobile app...

 

However, I am a bit confused, I've worked with you in the past, it seems like you are using the Adobe Launch Mobile App property, which is for native apps... I don't really understand how you can be using this, but also say you don't have a native app?

 

There are 2 options.. you either have a native app (which means using a language the is specifically coded to create a mobile application), or your are using a native app wrapper around a website using website analytics.... (or maybe you are using a wrapper that communicates with a wrapped website, but that sends the data through the native app wrapper - for all intents and purposes when it comes to analytics, this would be considered a native app since you would be using the SDK to send the data -  and you would need to be sure the web part was not sending web data). Also, since you say you are using the SDK (and I am assuming it's the mobile SDK and not the new Web SDK, this would indicate you are using a native app)

 

The biggest mistake I see people make on the SDK implementation is to send a trackState for their page, then send a second trackAction with all their context variables.. this is what you need to avoid.... 

 

TrackState is the equivalent of an s.t() call... just like your website has props, eVars, events, etc on that call, so too should your trackState.

TrackAction is the equivalent of an s.tl() call, and just like trackState, it should have the context data as part of the call.

 

As for using Launch, you cannot use Launch on a Mobile App property to set values that are unique to the page/user/etc... the developers need to set these as these values will change with the usage of the app (not logged in to logged in, on page A then on Page B, etc)... 

 

 

First, get how you are sending the data down.. it sounds like you need to get that sorted before you even start trying to figure out your processing rules.

F
fern1Author
Level 5
January 23, 2023
@jennifer_dungan wrote:

So right now, there is always going to be some issues between your website and mobile app user identification...

 

There is a feature in Adobe that can be used that WHEN the website is opened via the app, then you can append the ECID to the website url, then the website will be overwritten with the app id (to try and get these to associate as the same UV... but there are still problems with this... 

 

1. The user MUST open the website via the app (if the two never interact this won't work)

2. This doesn't work going the opposite direction, Web to App....

In this case, it is not when a user opens another website via the app. Is more like today I used the products app, next week I did it via desktop, next app again, etc.. Considering app and web are the same product, in that month I'm only unique once, regardless if I accessed it via app or desktop. So I would need a cross-platform track to know that I'm unique. does it make sense?

Now, from an authenticated user perspective...  your developers know the logged in user ID when the user logs in... they can set this as a context variable and add it to your trackState / trackAction calls (and this should match how you collect on the website)... if you track this only on a login, then use Adobe's expiry period to retain the information, you can do the same on the app.. if you sent the data on every call in the website while the user is logged in, then you need to do that in the app.

 

In order to make sure your aren't sending multiple calls, that comes down to testing...  You either need to test with a proxy connection using Charles or Fiddler, or use AEP Assurance extension in your mobile app...

On the website, we have data layer getting the user Id, and we are sending them to an eVar. The idea would be to do the same with the app, to have an eVar getting the userID (and that I could also know the page screens that this user went), same way I can do with the web.

However, I am a bit confused, I've worked with you in the past, it seems like you are using the Adobe Launch Mobile App property, which is for native apps... I don't really understand how you can be using this, but also say you don't have a native app?

 

There are 2 options.. you either have a native app (which means using a language the is specifically coded to create a mobile application), or your are using a native app wrapper around a website using website analytics.... (or maybe you are using a wrapper that communicates with a wrapped website, but that sends the data through the native app wrapper - for all intents and purposes when it comes to analytics, this would be considered a native app since you would be using the SDK to send the data -  and you would need to be sure the web part was not sending web data). Also, since you say you are using the SDK (and I am assuming it's the mobile SDK and not the new Web SDK, this would indicate you are using a native app)

For this last part, I didn't know launch was for native only. So yes, that is our #1 mistake now.
Yes, we talked about it before and our app is not native. we do use a wrapper. We have a plugin cordova where there is javascript code along javascript code for android and objective-c for iOS, and on those native code the Adobe SDKs is implemented. After a wrapper is used adding the plugin to it (had to ask our devs)!  

 

The biggest mistake I see people make on the SDK implementation is to send a trackState for their page, then send a second trackAction with all their context variables.. this is what you need to avoid.... 

 

TrackState is the equivalent of an s.t() call... just like your website has props, eVars, events, etc on that call, so too should your trackState.

TrackAction is the equivalent of an s.tl() call, and just like trackState, it should have the context data as part of the call.

 

As for using Launch, you cannot use Launch on a Mobile App property to set values that are unique to the page/user/etc... the developers need to set these as these values will change with the usage of the app (not logged in to logged in, on page A then on Page B, etc)... 

 

 

First, get how you are sending the data down.. it sounds like you need to get that sorted before you even start trying to figure out your processing rules.

Whenever we need to add a context variable, we have to ask the core team to insert it inside this original cordova plugin. That´s why I'm afraid of this implementation and I'm extra checking here. I want to make sure the UserID is cough in every single page a user enters once signed on but not to hit a new pageview and overflood the visits.

Do you have an example of context data code that should be inserted that I can show the devs just to illustrate it?

Jennifer_Dungan
Community Advisor and Adobe Champion
Jennifer_DunganCommunity Advisor and Adobe Champion
Community Advisor and Adobe Champion
January 23, 2023
In this case, it is not when a user opens another website via the app. Is more like today I used the products app, next week I did it via desktop, next app again, etc.. Considering app and web are the same product, in that month I'm only unique once, regardless if I accessed it via app or desktop. So I would need a cross-platform track to know that I'm unique. does it make sense?

There is no way to tie the UV together in this case.. the mobile browser and the app are considered separate entities... and yes, you can tie users together with an internal id, unless you are using CJA and using the cross device graph, Adobe will treat these as separate UVs. It's just like using multiple computers or multiple browsers... the ECID will be set per browser per device.

 

On the website, we have data layer getting the user Id, and we are sending them to an eVar. The idea would be to do the same with the app, to have an eVar getting the userID (and that I could also know the page screens that this user went), same way I can do with the web.

You will need to get your developers to set Context Variables in their code and attach them to your trackState and trackAction events based on how you need to process the data.

 

For this last part, I didn't know launch was for native only. So yes, that is our #1 mistake now.
Yes, we talked about it before and our app is not native. we do use a wrapper. We have a plugin cordova where there is javascript code along javascript code for android and objective-c for iOS, and on those native code the Adobe SDKs is implemented. After a wrapper is used adding the plugin to it (had to ask our devs)!  

The wrapper is still native.. but IF this is wrapping your actual website, you will be sending web data.. and IF you are also sending data via the wrapper, you will likely have double tracking.

 

Even IF you have AEP Assurance, I highly suggest you use proxy testing, as you should see all the calls and IF web calls are being made in addition to app tracking calls.

 

IF you are getting web calls, you don't need the wrapper to send anything... what you might need to do is have the web developers add some sort of data layer or variable you can read and add to your web tracking to determine IF the website is being loaded via your app so that you can identify and segment it...

 

But the same issue as above with UVs will persist... the native wrapper will generally be treated like a separate browser and likely will have issues fingerprinting the user with the same ECID... but your testing should be able to see what is happening.

 

Whenever we need to add a context variable, we have to ask the core team to insert it inside this original cordova plugin. That´s why I'm afraid of this implementation and I'm extra checking here. I want to make sure the UserID is cough in every single page a user enters once signed on but not to hit a new pageview and overflood the visits.

Right, IF you do still need the SDK (as in your website isn't already capturing traffic) then as long as they aren't making secondary calls to set the context, you should be fine. Again, you need to test... you will see if when a page loads if there are more than one call, and what data is attached to that call.

 

Do you have an example of context data code that should be inserted that I can show the devs just to illustrate it?

You should check first that this is even needed...

 

Years ago, our apps were websites loaded inside a native wrapper... we didn't use the SDK, we used website tracking... in our case, our mobile app was a separate sub-domain, and therefore I could track the www. (website) separate from the app. (mobile app) variants... of course, IF someone loaded the mobile app website directly, I couldn't tell.. but the spillover was pretty small so we didn't worry about it....

 

If you already have website tracking in this framed in version, you can use that and save yourself the headache of the SDK and Processing Rules... this is a toss up of course, you won't get mobile specific metrics like Launches, Crashes, Updates, etc...  but you also don't need to suppress the web tracking in lieu of a more complicated implementation (which IF you have web tracking already, you will have to figure out how not to track this when loaded via your app (and make sure that you don't over suppress it for thinks like website loaded via Facebook, Twitter, Reddit, etc apps)

Terms & ConditionsAccessibility statement

Loading footer...