YOUR ACTION MAY BE REQUIRED

If you use or plan to use in-app messages, you need to move to a newer SDK (iOS 3.7.1.2+, Android 3.7.1.2+, Cordova 3.6.0+, Xamarin 3.3.2.0+) by August 07, 2018.

With the release of iOS 10, you might have noticed that users who reboot their devices do not receive in-app messages until after running your app. After iOS 11 was released, delivery of in-app messages was haphazard. Only users who frequently kept your app in the foreground were able to receive in-app messages reliably. This behavior was due to an Apple design decision that restricted delivery of silent push notifications.

To resolve this delivery problem for in-app messages, IBM has reworked the in-app message system. The new system removes dependencies on push providers, and instead puts the responsibility of delivering in-app messages on IBM Watson Campaign Automation (WCA) servers.

What does this mean for you?

If you use in-app messages, you must upgrade your SDK to a version that supports the new in-app message delivery mechanism by August 07, 2018. IBM will continue to support the current in-app message system on Android until then, after which apps with older SDKs will no longer receive in-app messages.

If you do not use or intend to use in-app messages, there’s no need to change anything yet. IBM recommends you upgrade to the latest SDK to take advantage of defect fixes and new features, but this is not required.

Which SDK versions support the new in-app messages?

  • iOS SDK 3.7.1.2 (and later)
  • Android SDK 3.7.1.2 (and later)
  • Cordova SDK 3.6.0 (and later)
  • Xamarin SDK 3.3.2.0 (and later)

My app is Android only. Does this change affect me?

Yes, if you use in-app messages. The way in-app messages are delivered has been moved from the push provider to IBM WCA servers for both Apple and Google push providers. If you want to receive in-app messages after the switchover date of August 07, 2018, you will need to upgrade the IBM WCA SDK that is built into your app, and publish a new version of your app to the Google Play and Apple App stores.

Will there be any changes to the UI for in-app messages?

The way you send an in-app message using the UI will not change, nor will there be any template changes. In-app messages will be retrieved when you bring the app to the foreground, so in-app messages delivered as the result of a location- or beacon-triggered program will not be available until the user puts the app in the background and brings it to the foreground at least once, or triggers a location change, after the delay associated with phone home expires. (This delay may be up to 24 hours.)

Will there be any changes to REST APIs for in-app messages?

Yes. Because the in-app message is no longer associated with a push message, you will need to make changes to the payload of your in-app messages.

In-app messages now look similar to inbox messages. You have to publish the in-app message first, get an inAppContentId for that message, and then refer to the inAppContentId when you use the API to send a message.

If you create a custom in-app messages with unique information for each of your users, contact support to find out the best solution for you.

Publishing the message
To publish your in-app message, send a POST to /channels/push/inappcontent with a payload that represents your in-app message.
For example:
{
"payload": {
"gcm": {
"rules": [ "all" ],
"template": "default",
"maxViews": 5,
"content": {
"mainImage": "http://imgur.com/aoeu.jpg",
"title": "Hello %%First_Name%%",
"text": "Hello %%First_Name%%, this offer expires at %%expiration_date%% starting now %%cust_timestamp%%",
"color": "#0000ff",
"icon": "note",
"action": {
"type": "url",
"value": "https://www.google.com"
}
}
},
"apns": {
"rules": [ "all" ],
"template": "default",
"maxViews": 7,
"content": {
"mainImage": "http://imgur.com/aoeu.jpg",
"title": "Hello %%First_Name%%",
"text": "Hello %%First_Name%%, this offer expires at %%expiration_date%% starting now %%cust_timestamp%%",
"color": "#ff0000",
"icon": "note",
"action": {
"type": "url",
"value": "http://www.apple.com"
}
}
}
},
"personalizationDefaults": {
"First_Name": "Valued Customer",
"expiration_date": "",
"cust_timestamp": ""
},
"personalizationFormulas": {
"cust_timestamp": "format(Dated, \"dd-MM-yyyy\")",
"expiration_date": "format(Customer_Date, \"dd-MM-yyyy\")"
}
}

After executing the POST, you will receive an ID similar to the following:
{
"meta": {
"attributes": {},
"generalErrors": [],
"fieldErrors": {},
"links": [],
"nextPageUrl": null
},
"data": {
"location": "https://api0.silverpop.com/rest/channels/push/inappcontent/MqUONG7y",
"id": "MqU8NG7y"
}
}

You will need to use the value from the “id” field when you send your in-app message. There is no place to see this ID in the user interface. If you misplace it, you will need to publish the message again to generate a new ID.

Sending an in-app message to a user
After publishing the message, POST to /channels/push/sends or /channels/push/sends/usingAppFrequency to send it. Note that the value of inAppContentId in the inAppMessage section of the payload is the same value you received for “id” when you published the in-app message:
{
"channelQualifiers": [

],
"content": {
"inAppMessage": {
"expirationDate": "2018-08-25T22:34:51.123+00:00",
"maxViews": 3,
"inAppContentId": "MqU8NG7y"
}
},
"personalizationDefaults": {
"first_name": "Valued",
"last_name": "Customer"
},
"contacts": [
{
"contactId": 13507,
"personalization": {
"first_name": "Michael",
"last_name": "iOS iPhone"
}
}
] }

Note also that if you use /channels/push/sends/usingAppFrequency, in-app messages will count towards your total messages sent. Sending one in-app push will reduce by one the total number of other messages you can send during a time period. Do not confuse message frequency with maxViews. A single in-app message may permit multiple viewings (up to maxViews) after delivery.

Sending an in-app message to a contact source (segment)
Similarly, you can send an in-app message to a contact source. To send an in-app message to a contact source, you would POST to /channels/push/sendjobs, and would need both the contact source ID and the in-app message ID:
{
"contactSourceId": 10111,
"campaignName": "In-app only",
"messageName": "In-app only 2016-06-15",
"appKeys": [

],
"content": {
"inAppMessage": {
"expirationDate": "2018-08-25T22:34:51.123+00:00",
"maxViews": 3,
"inAppContentId": "MqU8NG7y"
}
}
}

Setting Maximum Views
If you specify a value for maxViews in the push, it will override what is specified in the published in-app message. maxViews is not required in the publish payload.

If you send more than one push with the same inAppContentId, you will be sending multiple in-app messages, with their associated personalizations. For instance, if you were to send a push with “inAppContentId“: “MqU8NG7y” and “maxViews“: 1, and then another with “inAppContentId“: “MqU8NG7y” and “maxViews“: 2, you would be able to see the message 1+2=3 times on the device. The first viewing would have personalization associated with the first push, and the second and third viewings would have personalization associated with the second push.

Join The Discussion

Your email address will not be published. Required fields are marked *