Solved

os version incorrect when importing from segment

  • 23 November 2021
  • 5 replies
  • 176 views

Badge

I am using Segment to log screen data in my iOS app and import them to Amplitude. I found out that the `os` field on the event in amplitude is something like `WebKit 605` instead of the ios version. I inspect the event data on Segment and it has the correct os version data like `"os": { "name": "iOS", "version": "15.0.2" },`. Is there anything I set up incorrectly? Please help. Thanks!

icon

Best answer by yliuaaron 2 December 2021, 06:08

View original

5 replies

Userlevel 5
Badge +8

Hi @yliuaaron ! Welcome to the Community and I’m happy to help! :wave:

Can you share with me on how you are instrumenting Segment data to Amplitude? Are you using cloud-mode or device-mode or Amplitude Actions? 

If you are using cloud-mode or Amplitude Actions, then the value you see in Amplitude is what Segment provided to us. If you are using device-mode then this is the value that our SDKs picked up. 

By the way, Webkit is a browser engine created by Apple. Version 605 is specifically for non-windows. When you see the value WebKit 605, you should be seeing this for browser events correct? 

If so, it looks like Apple is now using Webkit v. 605.x.x for their iOS browsers as well:
https://developers.whatismybrowser.com/useragents/explore/layout_engine_name/webkit/

This value will appear if iOS Apps have built in browser (think opening a link in the mail app that opens a browser within the mail app instead of opening in Safari). Does this situation sound familiar to you? 

Badge

Thanks @belinda.chiu for you reply!

I believe we are using cloud-mode: iOS app sends data to Segment and Segment sends it over to Amplitude. 

When I look at the data Segment receives, it has this filed in `context`: 

"os": {
"name": "iOS",
"version": "15.1.1"
},

it also has user agent as well:

    "userAgent": "Mozilla/5.0 (iPhone; CPU iPhone OS 15_1_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148"

But when I look at the same event that Amplitude collects, the OS field becomes `WebKit 605`. But I really needs it to be `iOS 15.1.1`. 

I am pretty sure this event is collected in our native app instead of an in-app browser. 

Do you have any idea where went wrong and how i can further debug this issue? Thank you @brandonatbuzzr !

Userlevel 5
Badge +8

@yliuaaron Hmm interesting, if you’re using cloud-mode, it should just be like our HTTP API where we will grab whatever was sent to us. I’ll double check this on my end and also raise this internally in case there’s something I missed! Will get back to you 

Badge

Thanks @belinda.chiu .

I got to contact support at Segment and found the problem, indeed Segment is sending “Webkit 605” to Amplitude so that’s why event displays this OS. 

Here is quote from Segment support:

I see that you are using our analytics-swift library and Amplitude is connected in cloud-mode. I understand you are having some issues with how OS Platform is being displayed on Amplitude.

Our server-side (cloud-mode connection) Amplitude mapping logic is the following: we check first if parsedUserAgent.browser.name & parsedUserAgent.browser.major ​exist - these are the values from the userAgent string. If these values are not available, we use context.os.name and context.os.version​respectively.

One of the differences of analytics-swift library is that, unlike analytics-ios, it collects userAgent ​, so it looks like this is where the values like "Webkit 605" come from.

A potential solution here  is to use Amplitude (Actions) destination instead of Amplitude classic. With Amplitude actions, you can explicitly set how you want to map the OS name and version and these are the default settings...

 

With Amplitude Actions destination, I could successfully ingest events with correct OS field.

Thanks!

Userlevel 5
Badge +8

@yliuaaron That’s awesome to hear! Thank you for contacting Segment Support on this! Glad to hear that it’s expected behavior based on how the library works - although unfortunately not what you’re looking for in this case. 

But glad that they were also able to provide a workaround in the meantime! 

Appreciate you again for following up on this and sharing this knowledge with us! :star2:

Reply