Easily plan your migration from Swrve to OpenBack for push & in-app messaging without interruption.
Before migrating, we recommend updating your app to include the OpenBack SDK, then users won’t be lost between app updates. The base setup steps for adding OpenBack are:
- Create your OpenBack app on our dashboard.
- (Recommended) Add your APNs certificate/Firebase Cloud Messaging Key to your OpenBack app.
- Complete the basic SDK integration for Native Android/iOS or Plugin.
Integrating OpenBack will not interfere with any other services you may have - as such, you can run services alongside each other during migration.
For help with migrating to OpenBack from Swrve, feel free to contact the onboarding team email@example.com and we can help guide you through the process including setting up a simple plan.
1 - Feature Explanations across Platforms
|Custom user properties ->||Custom Segments & Attributes|
|Segment users based on custom in-app information. Send notifications to users within these segments. User properties can be used to personalize the content of a notification.||Segment users based on custom in-app information and send notifications to these users. Attributes are used to store clientside information about users that is then used to personalize the content of a notification.|
|Custom Events ->||Custom Events|
|Swrve uses events to segment users.||Send notifications to users based on in-app actions.|
|Swrve uses Virtual Economy/Custom Events and In-App Purchases to segment users and track KPI performance.||OpenBack Goals can be used to track user actions or changes to user data. The Goal completion is recorded device-side and provides metrics for goal value, currency, goal completion time and if the goal was completed immediately after clicking a notification or within a conversion window.|
|Swrve uses Custom Payloads to send extra information and perform an action when a push notification is received.||OpenBack uses Payloads to send extra information and perform an action when a push notification is received.|
|OpenBack requires no custom setup or migration - out of the box you will get a full set of metrics on messaging.|
|Allow/Block - Opt-Out Status|
|As this is handled on the device side, OpenBack automatically picks up the user's current status without any work required to or migrate or transfer user preferences. Users will NOT be shown the OS permission dialogue again.|
|Deep Links & Deep Linking|
|As these are defined by you at an app level, there is no work to migrate across. To make things easier for sending messages, you may want to setup shortcuts in the OpenBack Dashboard under App Settings -more details here|
2 - Attributes & Custom Segments
For help with deciding whether your user information should be stored as an Attribute or a Custom Segment, contact firstname.lastname@example.org anytime.
OpenBack uses Attributes to personalize the content of a notification with user information that is stored on the device, such as a user’s first name. When migrating from Swrve, any Swrve Custom user properties that would have been used to personalize the notification content should be setup as OpenBack Attributes in your mobile app.
Here are examples of your existing Android code for Swrve, and also the updated Android code for OpenBack Attributes:
OpenBack uses Custom Segments to store user information in OpenBack on the user’s device which can then be used to target specific segments of users as well as personalizing the content of the messages.
When migrating, any Swrve Custom user properties that would have been used to segment your users can be converted to OpenBack Custom Segments.
The Swrve Android SDK only supports string values. The OpenBack Android SDK supports string, int, float and time values.
Here are examples of your existing code for Swrve, and also the updated code for OpenBack Custom Segments:
3 - Custom Events
For help with deciding whether your user actions should be stored as a Custom Event or a Custom Segment, contact email@example.com anytime.
Custom Events can be used to deliver notifications to users based on in-app actions. A Custom Event can deliver the notification immediately or after a specific delay that can be set on device or by the OpenBack dashboard.
When migrating from Swrve, any Custom Events that would have been used for segmenting users and delivering notifications can be converted to Custom Events.
Here are examples of your existing code for Swrve, and also the updated code for OpenBack Custom Events:
4 - Goals
For help with deciding which user actions should be stored as Goals, contact firstname.lastname@example.org anytime.
Goals are used to track the value of actions that users complete in your app after they have received a message.
When migrating from Swrve, any IAP or Virtual Economy events that would have been used for tracking KPIs can be converted to Goals.
Here are examples of your existing code for Swrve, and also the updated code for OpenBack Goals:
5 - Payloads & App Inbox
Custom payload content can be added to App Inbox messages and then used within your app. Payload content can be any form of text, for example
JSON/CSV/XML, as long as your app can read and process it.
The payloads are currently for use with our App Inbox feature on both Android and iOS, on Android however, you can also send a payload alongside a Dynamic Push message.
When migrating from Swrve, any silent push payload events can be converted to App Inbox payloads for Android and iOS.
Here are examples of your existing code for Swrve, and also the updated code for OpenBack Payloads:
5 - Importing Push Tokens
This is typically not required as by default the OpenBack SDK handles the user’s push token and syncs the token with the OpenBack Engine (backend), which starts once the OpenBack SDK is included in the app, so importing push tokens is not usually relevant, but can be supported.
A push token is a unique key, created and assigned by Apple(APNs) or Google(FCM) to create a connection between a specific mobile app on a specific iOS or Android device. The push token is then used by conventional platforms when sending push notifications from their backend systems to APNs/FCM who then make efforts to deliver the notification to that device. Push tokens change from time to time, and sometimes go stale. Push tokens are a key source of the deliverability issues which OpenBack resolves, you can read more about that here.
While not strictly necessary, OpenBack recommends setting up APNs/FCM as then a silent push notification is sent out to apps whenever there is updated content & settings for faster updates.
If you have a collection of your user’s push tokens, usually in .CSV format, we can bulk import them for you. Contact email@example.com to finalize an import plan; and also for help exporting Push Tokens from existing platforms including Airship, OneSignal and others.
Android push tokens are always mixed casing whereas iOS push tokens can sometimes be all lower case or all upper case. If importing existing push tokens into OpenBack, pay attention to the casing of iOS push tokens to avoid duplicate records.
6 - Detailed SDK Comparisons
|iOS Size||4.9MB zipped||900kB or less|
|React Native Plugin||Yes||Yes|
|Titanium Plugin||Not Available||Yes|
|Deliverability Optimisation||Not Available||Yes|
|Moment of Delivery Control||Not Available||Yes|
|Full Notification Metrics||Not Available||Yes|
|Client-side Real-Time Content Personalisation||Not Available||Yes|
|Dynamic Push (Auto-Remove/Update)||Not Available||Yes|
|App Inbox||Not Available||Yes|
|In-app Video Message||Not Available||Yes|