Missing User Properties on Apphud server events

We have an integration of Apphud with Amplitude. App is iPadOS only.

The release 1.3.12 is OK, but >=1.3.13 are broken.

Screenshot from Apphud with integration enabled.

Apphud has it is own server events, that it sends to Amplitude, too.

I am going to speak about our own “trial_started” event and “[Apphud] trial_started”, but the situation is the same with other Apphud events.

Everything was all right with user properties, before one of our releases.

Segmentation chart of event “[Apphud] trial_started” grouped by Amplitude’s *Device Type*.

But after of this release (1.3.13 version) the amount of (none) Device Type’s grew up a lot, and only few users are getting it (they are just using 1.3.12). In the release we moved from using Amplitude’s legacy library, written in Obj-c to new Amplitude-Swift.

Amount of (none) *Device Type*’s after the release

We were using this migration guide and already had few more releases, with some other fixes of Amplitude-Swift bugs, like this one.

May be, we don’t set user properties? But no, if we check the same chart, but with “trial_started” event, everything seems alright.

Segmentation graph with “trial_started” event, grouped by *Device Type*.

Let’s now look a bit closer at some random user and check his User Properties.

And you see the issue. In the server event from Apphud there are missing: OS, Device Family and Device Type, at least. (the Platform is fixed in Amplitude-Swift 0.4.0 version, but now we are using 0.3.2 version)

The strange thing is here, that it doesn’t seem to be the bug of Amplitude-Swift package, because all other events have correct User Properties and as I know they have to be saved for each further event and for the user, but we experienced this issue after the update to Amplitude-Swift.

If you think, that these user properties were set only in “trial_started” event - that’s not true. Here is the proof:

Older events also contain correct User Properties.

But, may be Apphud must provide these properties? No, we spoke to Apphud developers and they didn’t change anything in their server events. Let’s proof that.

The same user in Apphud and his trial_started event.

Integration with Amplitude is sucessfull

The request body contains this JSON:

{<br />  "api_key": "API_KEY HIDDEN FOR QUESTION ON FORUM",<br />  "events": [<br />    {<br />      "event_type": "[Apphud] trial_started",<br />      "partner_id": "apphud",<br />      "event_properties": {<br />        "unit": "week",<br />        "offer_type": "trial",<br />        "product_id": "com.momwillbeproud.artworkout.v3.pro.6months",<br />        "units_count": 1,<br />        "family_shared": false<br />      },<br />      "user_properties": {<br />        "[Apphud] total_spent": 0,<br />        "[Apphud] paying": false,<br />        "[Apphud] payments_count": 0,<br />        "[Apphud] status-pro": "trial",<br />        "[Apphud] autorenew-pro": true,<br />        "[Apphud] status-untitled": "none",<br />        "[Apphud] autorenew-untitled": false<br />      },<br />      "user_id": "674435F5-F9CA-422A-907F-5514C69F3BBC",<br />      "time": 1682313198000,<br />      "ip": "IP HIDDEN FOR QUESTION ON FORUM",<br />      "platform": "iOS",<br />      "insert_id": "924b5058-8593-4ef4-a904-57f2395195ba"<br />    }<br />  ]<br />}

We see the override of platform property, that’s OK. And they don’t provide any other missing User Properties. May be Apphud were providing them earlier? Let’s check an event from 1.3.12 version, when we had legacy Amplitude-iOS and find the user in Apphud and his trial_started event

{<br />  "api_key": "API_KEY HIDDEN FOR QUESTION ON FORUM",<br />  "events": [<br />    {<br />      "event_type": "[Apphud] trial_started",<br />      "partner_id": "apphud",<br />      "event_properties": {<br />        "unit": "week",<br />        "offer_type": "trial",<br />        "product_id": "com.momwillbeproud.artworkout.v3.pro.6months",<br />        "units_count": 1,<br />        "family_shared": false,<br />        "product_bundle_id": "com.momw"<br />      },<br />      "user_properties": {<br />        "[Apphud] total_spent": 0,<br />        "[Apphud] paying": false,<br />        "[Apphud] payments_count": 0,<br />        "[Apphud] status-pro": "trial",<br />        "[Apphud] autorenew-pro": true,<br />        "[Apphud] status-untitled": "none",<br />        "[Apphud] autorenew-untitled": false<br />      },<br />      "user_id": "ABBFC846-5D14-47F7-B942-4D6D587C776E",<br />      "time": 1676725739000,<br />      "ip": "IP HIDDEN FOR QUESTION ON FORUM",<br />      "platform": "iOS",<br />      "insert_id": "31bc69f4-e625-404f-8b21-91e0a4eba8cd"<br />    }<br />  ]<br />}

Almost nothing changed, no user properties provided by Apphud. But the user has User Properties.

“[Apphud] trial_started” event from 1.3.12 Version with old Amplitude package.

And they correspond to the JSON and User Properties in out “trial_started” event.

“trial_started” event from 1.3.12 Version with old Amplitude package.

As I said, the same is with any other Apphud event. This one for example:

We have no idea what’s going on, we couldn’t figure how to resolve this issue by ourselves. Help

Are we event in the right place to ask for help?

Find more posts tagged with

Reporting

Integrations

Instrumentation

SDK

Event

Track

Accepted answers

belinda.chiu

Hi levochka ! Thank you so much for your patience. After discussing with the Engineering team, I have come to re-remember that the platform field is a part of a grouped user property. What that means is if any of the grouped user properties are updated, all user properties in the group will be updated even if the other fields are null. Here’s reference in our Identify documentation that applies to both the HTTP API and Batch API: https://www.docs.developers.amplitude.com/analytics/apis/identify-api/#status-codes

You must update the fields (platform, os_name, os_version, device_brand, device_manufacturer, device_model, and carrier) together. Setting any of these fields resets all the other property values to null if aren't explicitly set on the same identify call. All property values otherwise persist to later events if the values aren't changed to a different string or if all values are passed as null. Amplitude tries to use device_brand, device_manufacturer, and device_model to map the corresponding device type.

To explain, here’s an example:
Let’s say event 1 came in with the value of only {“os”: “iOS 10”} and event 2 came in with the value of only {“platform”: “iOS”}.

After processing those events in order, because these properties come as a set/group, all subsequent events will have the resulting user props of os = null and platform = iOS. This is because the second event had a different platform value than what already existed so we assume the properties from the 2nd event are more “correct” and would sync those properties onto future events.

BUT if the value is same, we won’t consider it an update to the group. We only do this group-based override if the props values are “conflicting”.

So what happened before was that the Platform property listed in the iOS SDK events were the same as the values listed in the Apphud events - “iOS”. Since the value was the same, we did not do an override and the user properties from the user’s previous events would sync onto the Apphud events.

But, when you had the new SDK version, you noticed that the Platform value no longer was iOS on the SDK events. Because the value was not the same as the value on the Apphud events, we assume that the Platform property value with the Apphud event is “more” correct. Therefore the grouped user properties from the user’s last event don’t sync onto the Apphud event and you’ll just get what came with Apphud - hence the other OS, device type values were null because the Apphud events didn’t have those properties.

Effectively, to solve for this, fixing the Platform property on the iOS SDK events to go back to the “iOS” value will trigger the grouped user property syncing behavior you are expecting to see. Otherwise, you will need to figure out how to get all of the properties to manually appear on Apphud events or remove the Platform property from appearing on Apphud events so that there isn’t this conflict that would happen and a normal user property sync will happen.

Hope this clarifies why the change suddenly happened with the new iOS SDK version given the conflicting Platform values and how to fix this moving forward!

All comments

Esther Trapadoux

levochka thanks for sending all of this info over! I’ve asked our support team to look into the Apphud integration and help troubleshoot this.

belinda.chiu

Hi levochka ! Welcome to the Amplitude Community 👋

To summarize your issue, it looks like only Apphud events are missing some of the Amplitude user properties since the upgrade to 1.3.13 iOS Swift SDK version.

To troubleshoot this, I have confirmed that Apphud events do not send values for these Amplitude user properties: https://docs.apphud.com/docs/parameters-and-properties#user-properties

It does look like the Platform property does get sent over though given the Apphud payloads.

But in any case, since Apphud payloads show that no OS, Device Family and Device Type properties were sent with the events, that means that past Apphud events inherited these properties from other events. A similar behavior should also be happening now where Apphud events would just inherit the property values from what already exists in the user’s user property table. But as we can see, almost all user properties were inherited except for OS, Device Family and Device Type.

It’s rare that events would only inherit some of the user’s user properties without overrides either on the event itself or sent before the event. I’ll check in with the Engineering team about this but can you also check in with your Development team to see if there’s any iOS SDK calls that somehow nulls out the property before the Apphud event or causes the values not to sync?
For example, the Platform value gets overrode by the iOS value sent by Apphud instead of inheriting value iPadXX. This is because the Apphud event has the Platform property sent along with the event.

levochka

Hi belinda.chiu ! Thank you for the reply.

1.3.13 is our app version, when the problem started and it corresponds with update to Amplitude-Swift library.

Yeah, I believe, that it is rare, but It’s happening consistently after the update. Soon we are releasing a new app version, where we updated Amplitude-Swift version, I will write if it gets better/worse or stays the same.

I’m from our Development team and I’m sure, that there are no calls, from our code, that nulls properties. Apphud doesn’t even now these properties and doesn’t send them.

Yes, as I remember, platform value gets overrode, but what about Device Family/Type?

belinda.chiu

You must update the fields (platform, os_name, os_version, device_brand, device_manufacturer, device_model, and carrier) together. Setting any of these fields resets all the other property values to null if aren't explicitly set on the same identify call. All property values otherwise persist to later events if the values aren't changed to a different string or if all values are passed as null. Amplitude tries to use device_brand, device_manufacturer, and device_model to map the corresponding device type.

To explain, here’s an example:
Let’s say event 1 came in with the value of only {“os”: “iOS 10”} and event 2 came in with the value of only {“platform”: “iOS”}.

BUT if the value is same, we won’t consider it an update to the group. We only do this group-based override if the props values are “conflicting”.

Hope this clarifies why the change suddenly happened with the new iOS SDK version given the conflicting Platform values and how to fix this moving forward!

levochka

Hi belinda.chiu !

Updating to Amplitude-Swift SDK 4.0.0 should fix the problem https://github.com/amplitude/Amplitude-Swift/pull/43, according to this pull request. We just had no time for this.

Thank you for clarifying the issue!

levochka

This should be marked as Answer

Quick Links

Unanswered Questions

Guide and Survey Analytics not Working
Hey there I've been playing around for a couple of hours with the guide and analytics which fires properly on the UI but wouldn't give me any analytics. I read that there is another script that should be installed for the analytics part of things. Would anyone be able to guide me towards the potential script or some…
How can I connect my Google Analytics Data with Amplitude
All my data is being collected through Firebase I want to export all this data in Amplitude and keep it synced with GA4, I tried adding data sources as BigQuery and GA4 both but for some reason it only partially imported the data and now its not working, I cant even see connected sources. Any help will be appreciated.
Import data from one amplitude account to another
How do I transfer data from one amplitude account to another? It seems all the community chats about this have completely broken links. Easy to export, no way to import, very frustrating. :(
@amplitude/plugin-web-vitals-browser build fails on CRA v4 (react-scripts@4.0.3)
When using @amplitude/plugin-web-vitals-browser with Create React App v4 (react-scripts@4.0.3), the build fails with: ./node_modules/@amplitude/plugin-web-vitals-browser/node_modules/web-vitals/dist/web-vitals.js<br /><br />SyntaxError:…
Question about Amplitude Export API Data Delay
Hello, I'm using SpringBoot and Kotlin to integrate with the Amplitude Export API. The official Amplitude documentation (https://amplitude.com/docs/apis/analytics/export) states that "data is available to export at a minimum within 2 hours of when the servers received it." However, there's no clear information about the…