"Platform" isn't a standard dimension... this sounds like a custom prop or eVar....
I assume you are sending your mobile app traffic into the same suite as your website data... so you see Platform populated for web, and not for app.
While you cannot set this the same way likely, knowing what value you expect to see here will help you to create appropriate mapping in your mobile app rules....
Hi @Jennifer_Dungan ,
Yes it's a custom eVar.
We have different report suite for web and app.
We are expecting only two values from "Platform" dimension - Android and iOS.
As per the app dev, we could see the value iOS being correctly passed in the eVar, but in reports it shows undefined.
You can't pass to eVars directly from the app... or at least I have never seen this, since it goes against recommended app implementation...
Do you have AEP Assurance extension installed in your app? This will show you what your developers are sending, and how the information is being mapped to your metrics and dimensions....
Typical app implementation is to set context variables... those variables are attached to your trackState and trackAction functions; then you use processing rules to map the context variables to your dimensions (you can even create logic to trigger custom events... if X then fire eventY).
If you don't have AEP Assurance, I can't see what the result of your processing is doing, but can you at least share what you see coming from your app? Is Android working?
We are using context data and processing rules sorry didn't mention earlier.
AEP Assurance we aren't using.
If the context variable is being send correctly, it sounds like this may be a processing rule mapping issue... double check that all the conditions are correct...
I assume you are doing a straight passing of the context variable, such as:
Overwrite value of (prop/evarX) with contextVariableY
But what are the conditions for the this rule to trigger?
Yes, Overwrite value of (prop/evarX) with contextVariableY is how we are using.
No rules have been used in launch.
Everything done from app dev., so probably the dev will know the conditions.
It's not a launch rule I am talking about.. it's the Processing Rule rule...
Processing rules have 3 parts...
So you have #2, the Action... (this is where you set you overwrite value)... but what condition did you add to this rule... without a condition, this rule will never fire.
Update... actually, it looks like if you have no condition, the rules should Always Execute.. I've never used that... I always have conditions for my rules (but I am sending data from web and app into one suite, so I always need to target specific platform rules).
So if you have no conditions.. are you sure you are referencing the correct context variable? Maybe you have a spelling mistake, or a case mismatch?
That sounds like it should be working.. I would double check the spelling and case of your context variable... are your developers using a context variable namespace?
Basically, I have our developers set a custom namespace for the apps (let's use "ourapp" as an example).
So if the context variable is called "platform"... it's actually passed as ourapp.platform... and when I use this in processing rules, I have to reference the full nomenclature "ourapp.platform"
Be sure if you have a namespace, then you are referencing that in all your logic