How To Check Ecid Of Your Iphone
Raymond Freedman
Ive 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.
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...
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....
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)...
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.
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.
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)!