Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

User ID for mobile App


Level 3

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

4 Replies


Community Advisor

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)


Community Advisor

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)


Level 3

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)





Community Advisor

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.