Campaign surveys in GetFeedback for Apps are event-based. This means that an App Campaign is triggered when an event is fired. With the 2022 June release of the GetFeedback for Apps SDK, we're adding Standard Events to make the event-based triggering easier than ever. In this article, we'll go over the prerequisites, the different Standard Events, example use cases, campaign trigger queues, and provide you with an overview of helpful links.
Note: If you're not familiar yet with how GetFeedback for Apps event targeting works please refer to the support article at the bottom of the page.
To get started with Standard Events you'll first need to make sure that you're running the latest version of our App SDKs. The new Standard Events feature is available with the following SDKs:
- iOS version v6.12.0 and up
- Android version v7.6.0 and up
If your app is running on of the SDKs version above or a version higher you're ready to create your first campaign using Standard Events. If your app is using one of our SDK bridges please check the availability of the Standard Events in the release notes.
With Standard Events, we're standardizing key app lifecycle events and enabling them out-of-the-box with any GetFeedback for Apps SDK implementation.
This means that you won't need to implement these key events yourself, saving you valuable time so that you can start listening to your customers even faster. Since the Standard Events are implemented consistently across our SDKs you don't have to define different events for different platforms, simplifying the setup process. Using the Standard Events does not require any additional setup.
Tip: For the best results, make sure to follow the implementation guide in the Readme of the SDK. Not following, for example, the recommended moment to do the initialization of the SDK might result in certain Standard Events not working as expected.
When you set up a campaign you'll notice that there are 2 sections on the event targeting part of the page. When setting up a GetFeedback App campaign you'll be able to choose between using either a standard event or a custom event.
Standard Events are events that are included with the SDK. Custom Events on the other hand are the events you add yourself.
Note: Since the event targeting dictates WHEN the other targeting rules are evaluated you can only choose one type of event per campaign.
Now that we know how the Standard Events work we'll go over the different events to explain when they exactly trigger and what parameter you can set.
The app launch event triggers as soon as the GetFeedback SDK is initialized or when your App is launched after it was closed before.
For the App Launch events, you can set the "occurrences" parameter that indicates how many times the App has to Launch before the campaign would be triggered.
App Closed Early
The App Closed Early event will triggers in the next launch if the app was closed early. Whether the app was closed early is defined by you with the "time spent" parameter that indicates when the closing of the apps should be considered "early". The "timeSpent" is defined as the number of seconds. In addition, you're also able to define the "target" to narrow down the type of user for which this Standard Event triggers.
The App Updated event triggers as soon as the GetFeedback SDK is initialized or when your App is launched after it was closed before.
For the App Updated events, you can set the version number of your app using the "version" parameter to indicate which version of your app should be considered as "up to date" and should be used by the GetFeedback SDK to determine if it should fire the App Updated Event. The version number is written out as a number with dots used to indicate subversion (e.g. "1.0").
In addition, you're also able to set the number of app launches.
App Not Updated
The App Not Updated event triggers as soon as the GetFeedback SDK is initialized or when your App is launched after it was closed before.
For the App Updated events, you can set the version number of your app using the "version" parameter to indicate which version of your app should be considered "outdated" and should be used by the GetFeedback SDK to determine if it should fire the App Not Updated Event. The version number is written out as a number with dots used to indicate subversion (e.g. "1.0").
The Crash event triggers as soon as the GetFeedback SDK is initialized or when your App is launched after it has crashed.
For the App Crash event, you can set the number of times an App Crash needs to happen before the Standard Event will trigger.
The app updated event triggers as soon as the GetFeedback SDK is initialized or when your App is launched after it was closed before on a specific date.
For the Specific Date event, you can set the occurrence number and the specific date. The occurrence number lets define how many times your app needs to be launched on the specified date before the event will trigger.
Example use cases
The Standard Events make the creation of targeted surveys a lot easier as it takes the guesswork of creating the necessary events for targeting out of the equation. Some example use cases that we recommend that you try out:
- Using the App Launch event for targeting users that have used the app for a while.
- Using the App Closed Early event for targeting users that have left the app. This is great for asking for feedback from your users on why they left the app, aborting the customer journey.
- Using the App Updated event for targeting users that have recently updated the app. If you combined the Standard Event with a high number of app launches you'll be able to target specific users who updated to the latest version and who have used the new version of the App for a while. This is great for asking for feedback regarding newly released features.
- Using the App not Updated event for targeting users that have not updated the app. This is great for asking users why they are not updating. Or highlighting new features in a new release if they update.
- Using the App Crash event for targeting users that have experienced a crash. This is a great way to ask for qualitative feedback that can be combined with your crash logs for easier troubleshooting of bugs.
- Using the Specific Date event for targeting users on a specific day. This is a great way to ask for feedback about timed changes in your app or to highlight certain promotional messages.
Campaign Trigger Queues
You might have noticed that most of the Standard Events will result in the Campaign being shown after the app has been launched. If you've created several Campaigns that use similar targeting you might have more than 1 campaign eligible to show to the user.
When this happens the SDK will make use of a so-called Campaign Trigger Queue. The queue ensures that the user will only be presented with a single campaign per app launch. Doing so ensures that we don't cause survey fatigue with the user while also making sure we're still able to provide the users with the means to give feedback at the relevant moment.
You might wonder what happens when 2 identical Standard Event configurations are used and they are both placed in the queue. In the situation where multiple campaigns are queued to display to the user, we'll use a special priority system to determine the order of the queue.
The order is first based on the type of Standard Event users, with Launch taking the highest priority. Secondly, the priority is determined by the creation date of the campaign.
It's therefore recommended that you limit the number of campaigns using identical Standard Events and similar targeting options.
Down below you'll find several helpful links:
If you have any questions please do not hesitate to reach out to our Customer Support team. If you're looking for more detailed advice on how to use the Standard Events or just want a refresher on collecting feedback in your app, reach out to our Customer Success Team and they'll be happy to help.