Mapping for iOS context data

[Gav_R]

Hi all,

We’re experiencing an issue in our production environment where iOS orders are not being correctly tracked under the Platform (eVarX) dimension in Adobe Analytics. Instead, the data is falling under Unspecified. However, android traffic is being tracked correctly.

Here's our existing setup:

We’re using Processing Rules to map platform context data to eVarX. Here's the screenshot for your reference.

Despite this configuration, iOS traffic does not get mapped and appears under "Unspecified", while Android works as expected. We do not have a staging environment, so this is directly affecting our production reporting.

Has anyone else faced this issue with iOS mapping in processing rules?

Are there any debugging best practices you'd recommend to validate the exact context data values received?

Appreciate any insights or suggestions.
Thank you in advance!

[purnimajena]

Hi @Gav_R ,

Add a separate condition in the same rule to handle platform == ios, or use the context data value directly without conditions:

Example:
Set eVar36 = %platform% using "Value from Context Data" to capture both Android and iOS automatically.

Also, verify in Adobe Experience Platform Debugger or Charles Proxy that iOS hits are sending the platform context data

Hope It helps!

[Gav_R]

Hello @purnimajena,

Thanks for your input.

I’ve made the changes and added a condition to handle iOS. I placed an order from an iOS device, but it's still showing under "Unspecified."

[purnimajena]

Okay , In this case can you check Both platform and a.appid must be present in the same hit for the rule to apply. If either is missing, the rule won’t fire.
Also processing rules are case sensitive , If the app sends iOS or IOS, but your rule checks for ios, it won’t match.

try changing the rule for example platform contains "ios"/platform contains "iOS"/
platform contains "IOS"

and test if it resolves the issue .
unspecified generally comes when the eVar is not set on the hit where it is expected .

[Gav_R]

Even if a.appid was not there, it was working fine for android. 

[purnimajena]

if Android mapping works even when a.appid isn’t present, it seems either the Android hits are still sending a.appid, or the rule isn't relying on the second condition for Android due to how it's structured or triggered.

In your iOS case, even though platform = "ios" is correctly sent, the second condition (a.appid is set) now applies to both Android and iOS. Since both conditions must be true (platform and a.appid being set), and iOS hits likely don’t include a.appid, the rule does not fire.

As a result, eVar36 remains unset for iOS hits, which causes the data to fall under "Unspecified".

Check by removing the a.appid is set condition from the processing rule. That way, the rule will trigger as long as platform is present — ensuring both iOS and Android traffic is tracked correctly.

[Gav_R]

Hello @purnimajena,

The dev team said that App ID is only set during initialization and not sent with events.
The only change in the latest code is the shift from ACP Core to AEP Core due to some compatibility.
They are setting up the App ID at initialization in AEP Core, do you have any idea how this is handled in AEP Core? 

[Jennifer_Dungan]

App ID (a.appid) should be part of the standard data that the SDK sends on all events (states and actions), it's not something the developers have to stitch into your tracking calls (generally speaking)...

So long as you are using the SDK, that should be available to you on all events.

[EurosIMS]

Hi @Gav_R,

If you haven't already re-written this rule, then what I would do is an 'Otherwise do the following' & set all other hits to overwrite v36 with custom value iOS, as by definiton if it's not an Android hit, it has to be an iOS hit. (& also remove the 'Overwrite with iOS' in the 'Then do the following' section).

[KumarRishii]

You can Update the rule to include a second condition:

If platform equals "ios" → set eVarX = "ios"

Debugging Tips:

Use Adobe Experience Platform Debugger to verify if the platform context data is being sent correctly.
Use Charles Proxy to inspect the beacon data on mobile.
Temporarily map platform directly to a test eVar to capture raw values.

Also Checks:

Ensure case sensitivity (e.g., "ios" vs "iOS").
Make sure the SDK is sending the platform variable.
Confirm no earlier rule is overwriting eVarX.

Let me know if you'd like help rewriting the rule or validating a beacon payload.

[Gav_R]

Hi @KumarRishii.,

The second condition has been set to the rule for ios and i have also verified with the App Logs for the case sensitivity - it is "ios".

Could you please help us rewriting the rule? Let me know if you need any further info from my end.

Thanks much!

[KumarRishii]

@Gav_R  Add a Separate Processing Rule for iOS

IF platform (context data) equals "ios"
THEN set eVarX to "ios"

Processing rules are case-sensitive — make sure the value from the iOS app is exactly "ios" (not "iOS" or "IOS").

Let me know if this works.

[Jennifer_Dungan]

Do you have AEP Assurance (aka Griffon) installed in your app? This would make it a lot easier to see what is happening in real-time while testing your apps.

Not only will it show you all the data points (including context variables) that are being sent to Adobe, it will show you the results of the Post Processing...

This way you can check the status of the "app id" and if it's on each call, and also what is being sent in your platform context variable, and if the case sensitive rules are covering your needs.. or if there is a difference between how Android and iOS are sending data... 

In many cases, your Android and iOS apps can be build as completely separate builds, so what works in one may not work in the other...  the exception to this would be things like apps built in React Native that use the same fundamental code with bridges to Android and iOS behaviours... these are more likely to work the same... but the specific bridge code can still cause differences.

I agree with the others, I am glad to see that you have added a rule for iOS (and as others specified, because of the case sensitivity, you might need to add multiple variants in your contains logic)... but there may be other things at play, and the best way to determine that is using testing tools like AEP Assurance... if you don't have that, then at least testing with a proxy tool like Charles, Fiddler, or HTTP Toolkit so you can at least see what info is sent to Adobe (even if you can't see the Post Processed results)

[Gav_R]

Hi @Jennifer_Dungan,

I’ve made the changes by removing the a.appid condition from the processing rules. After that, I placed a few test orders on the iOS app, Android app, Android web, and iOS web.

And found that orders from all platforms are being captured correctly in Adobe, except for iOS app orders, which are appearing under "unspecified."

If a.appid needs to be set manually in AEP Core, it raises the question: why are the other platforms, under the same condition, producing the expected results while the iOS app is not?

I have attached screenshots for your reference.

Looking forward to your thoughts on this.

[Jennifer_Dungan]

Hmm... I really don't think you should need to remove a.appid... I have that on ALL my app rules to ensure they only trigger for the app. And since removing it still isn't working for you, I really think that your iOS app has an issue with your Platform Context variable... 

As I mentioned in another message, app id should be set by the SDK... it shouldn't need to be set or specifically added to each call by your developers....

However, when something goes wrong, it doesn't hurt to check everything.

What testing tools do you have at your disposal? Do you have a proxy testers (like Charles, Fiddler, HTTP Toolkit) or do you have AEP Assurance?

I think we need to look at the calls coming from iOS to figure out what is happening.

[Gav_R]

Hi @Jennifer_Dungan,

We have configured httptoolkit and charles proxy on our windows laptop with ios mobile app.
we have installed certicificates and everything has been done according to the official documentation except neither of the tool is capturing adobe analytics calls.
Can you please guide us if there is any specific integration needs to be implemented.
Thanks!

[Jennifer_Dungan]

Can you explain more about what is happening?

• Are you see other resource requests in the tools, but not seeing Analytics?
  
  All request should be showing up if everything is configured correctly, the analytics call may be hard to recognize...
• Are you seeing nothing from your mobile app?
  • And if so, is the internet no longer working on your device, or the device is loading everything fine?
    
    If your mobile app is loading everything, but nothing is showing in Charles or HTTP Toolkit, it means that your phone is likely not actually connected to the proxy... if nothing is loading on the phone, then there is something not quite configured correctly...
    Both your laptop and your phone need to be on the same wifi connection for this to work, you may need to unplug your laptop from a network cable as the laptop may be deferring to the hardwire internet.
    Are you sure you are using the correct IP Address and Port on your phone to connect to your computer? As I said, it needs to be the same wifi, and if your computer is plugged in and on VPN you will have IP addresses for those connections too...

This is the guide I used for HTTP Toolkit:

https://httptoolkit.com/docs/guides/ios/

I also found a few YouTube videos that might help?

https://www.youtube.com/watch?v=uALd9FfRZi4

or

https://www.youtube.com/watch?v=qNC9uFavIK4

(I scanned this one quickly, I am not sure if they covered iOS...)

I will be hard for me to help debugging here, since I can't see what has been done or what behaviours you are experiencing, but I will do my best to support however I can.

[Gav_R]

Hello @Jennifer_Dungan,

Thank you so much for helping.

Here’s what we’ve observed so far:

• I can see other resource requests in the tools, but no Adobe Analytics server calls.

• The mobile app itself is functioning normally, and we do see other network calls related to Adobe Analytics.

• Internet connectivity is stable.

• The phone is connected to the proxy on port 8000 for HTTP Toolkit. Both the laptop and iPhone are on the same Wi-Fi network.

• I've double-checked and confirmed that the correct Windows IPv4 address and port are set in the manual proxy settings on the iPhone.

We have followed the very same steps mentioned in the guide. Have we overlooked any Windows or iOS versions?

Currently, we’re noticing a daily loss of iOS data in our Adobe Analytics reports.
Could you please advise what further troubleshooting steps we or our developers could take to resolve this issue?

Thanks again for your support.

[Jennifer_Dungan]

Interesting....

---

I can see other resource requests in the tools, but no Adobe Analytics server calls.

And you can confirm that these are resources coming from the phone (and not your computer?) Since any proxy testing tool will collect information about everything going through the computer's connection.

The mobile app itself is functioning normally, and we do see other network calls related to Adobe Analytics.

---

Are these AA calls from your computer? Or you mean you are seeing some of the general connection calls from the app?

Currently, we’re noticing a daily loss of iOS data in our Adobe Analytics reports.

Hmmm that doesn't sound good... it almost sounds like your latest iOS build has broken Analytics - as in, the data you are getting for iOS might be coming from older builds.... and the more people upgrade their apps, the less data you are collecting....

Do you have a clear app version tracking.. generally this is collected by default by Adobe (assuming that your developers are setting a version id properly in your apps)... this is usually in a standard dimension called "App Id"... see if you can see if newer app builds are missing from here?