Skip to main content

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 “nApphud] 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.

“trial_started” event
“5Apphud] trial_started” event

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:

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

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

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

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

“

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:

Apphud] billing_issue

 

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?

@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.

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. 

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?

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! 

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! 

 

This should be marked as Answer

Reply


Terms & ConditionsCookie settings