User ID for mobile App

[fern1]

Hi!
Today I have a question regarding the User ID for the mobile App.

For our websites, we are using the experience cloud ID plugin and created a user ID evar, to get the ID using data layer (after the user login). 
However, how can we also get the ID from an app? Our dev team already did the setup so the app is sending us the ID but I don't know how to config it on the Adobe side since there is no experience cloud if plugin for mobile app. 
Should I also create an eVar for that and create a rule and data element for it in launch?

thanks in advance

[Jennifer_Dungan]

Yes, this one is a bit baffling to me too... while the app is sending the MID value to the tracking server, you can't actually access it directly (or map the value into an eVar using processing rules).

I had our developers grab the MID value, set in in a context variable, and mapped that to a custom eVar with processing rules.....

However, you should be aware, that like a user using multiple browsers, the MID is going to be set to a different value in the website and in the app, even when accessing from the same device...

There is a way to append the mobile app MID to URL from the app, so that if the website is opened from the app (external link, or maybe an in-app webview) you can forcibly override the MID on the website to match the App (but there is no way to send the web MID to the app at this time.. it's only in one direction)

https://aep-sdks.gitbook.io/docs/foundation-extensions/mobile-core/identity/identity-api-reference#a...

[Jennifer_Dungan · Accepted solution]

Upon re-read, I was thinking you were asking about the user's MID / ECID... or are you actually talking about your user authentication id? You can have your developers set that value into a context variable and map it to your eVar.

Are you sending both Web and App traffic into one global suite? There is no need to set up a new eVar to track the User ID, you can map it into the same eVar.

One thing that I did is set up contextual eVars that I can use to create segments of data... such as "Experience" - on the website, I can pass "web" on the app I can pass "app" (these values are sent on all page views and actions)... so I can see all my data together in the global suite, but I have segments to see "web only" data, and "app only" data. I can use these as Virtual Report Suites, but I also use them in my Workspace segment dropdowns, or I use them in columns to visualize data side by side.

If you have the ability to easily separate the data, you definitely should be mapping the same data into the same eVars whether coming from the website or from the app (or from any other variant, like AMP)

[fern1]

Hey Jen!
I was referring to the user authentication id.

We do have a global suite but I just realized that it does not allow mobile app data, how can I change that? On data collection when I try to add the global report suite to the app property says that the report doesn't support mobile data. 

Meanwhile, I´m trying to get the user ID directly on our app report suite. I created an eVar for that but how can I set its processing rule? is this correct? our dev team set up the user Id as a trackAction and named it "userid" 
userid: (userid do user)

[Jennifer_Dungan]

So in your implementation, you set the User Id once? The I assume your eVar is set to a long running expiry?

Is this how your User Id is set on your website? To be honest, you should try and keep the behaviour as similar as possible to avoid headaches when analyzing your data, and a unique action just to set User Id doesn't exactly sound like the best approach.


So for example, we have user authentication, contrary to popular implementation, I only have the expiry of my eVar set to Visit (people could be using shared computers, I don't want the authentication potentially tied to the device for all time unless overwritten). I then send the User ID on ALL page views and ALL clicks / actions, etc (the visit level expiry is a fall back in case something fails to set, OR the user visits on of the subdomains during the visit where the data may not be available, etc).

So in our mobile app, I use the same approach. If the user is logged in, the User Id is set as a content variable on all trackStates and all trackActions, then in my processing rules I set the value of my eVar to the context variable (let's call it "site.userId").

When creating processing rules, I like to explicitly target data coming from our mobile app by adding the main rule conditions "a.appid is set"

In this case, this is my main "global rules" for general mappings

Then when I map my user id, I look for the specific context variable:

In your screenshot and description, it sounds like "userid" is the name of the action, not the context variable.. right now, your rule is setting the "action name" as the value of your eVar, which in this case would result in literal "userid" being passed into your eVar.

IF you are going to set the user id via a trackAction, you would change the rule conditions to be something like:

However, this feels like an inefficient way to set your values.... remember, every trackState and trackAction call is a server call that you pay for on your contract.... this is why both trackActions and trackStates are designed to pass sets of context variables, so that you can include the data you want in conjunction with the page view or "custom link" tracking that you are performing.

[fern1]

Thank you again!!
So I'm still trying to figure out this user ID topic..
I do realize that using tracking action for that is not the way to go, so I'm trying to set it up as you first suggested. So like the example you sent, I don´t have the userid(context data) (in your case site.userid(context data) showing for me.

I asked the devs, and they said this is how they named it "userid:"

 in real time they are getting the ID. 
we use the cordova plugin so IDK if the implementation of the context data is different.

I was checking, is there a way for me to set up the context data via launch? Otherwise, how can a context data for user id should be added in the app? the documentation I've been reading doesn't mention this case. Our appID one is working correctly, it gives us the current version of the app. 

Thanks as always 

[Jennifer_Dungan]

So for me, I had my developers set up a context variable namespace (i.e. "site") to group all our context variables under.

When you are in processing rules you will see the standard Adobe namespaces ("a").

For instance, Adobe's context data like a.appId or a.hourofday, etc

I like to group my custom context variables under a defined namespace so that I can find them easily, it's not a mandatory thing

However, looking at your screenshot.... I would say you have a big problem... that user id isn't being set as a context variable... and worse than that, it's actually being tracked as a page with a pagename "userid:xxxx" (this is going to inflate your page views).

I've not had a lot of success setting up context variables in Launch... the problem is getting the values.. I had a little success early on concatenating context variables into a new context variable, but the data still had to be sent to me from the developers... and since I can concatenate in processing rules I abandoned that approach... that's not to say you can't try it... but if your developers keep sending data the way they are you are, I don't think you can prevent the server call from firing or using up your server call allocations.

Also, if you only want to track "49454" as your id, there is no way to split data in processing rules, you would have to set up a classification rules... assuming your developers were sending that value in the correct context.

Regardless of the technology used, there are basic principals of the Adobe Mobile tracking that are consistent... how the data is sent (State or Action) and the context data attached to those beacons which give context.

Just like on the web, you have a page view event (and in that page view you have multiple props, evars, and other dimensions) or you have an action (like a click, that also contains a set of props, evars and other dimensions)..... Mobile tracking is the same.... trackStates and trackActions that pass a set of data, and that data is mapped via processing rules to the proper Adobe dimensions.

Right now, it looks like your developers are using:

trackState("userId:xxxxx")

Which basically says, trigger a page view, call the page "userId:xxxxx", and that is definitely not what you want.