Versions Compared

Old Version 46

changes.mady.by.user Fagundes, Silvia

Saved on

compared with

New Version Current

changes.mady.by.user Fagundes, Silvia

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Contents

Table of Contents
stylenone

...

Once a BK App guest’s phone battery gets down to a low %, we trigger give them an offer for a free of Monster Drink. When the guest charges their phone the offer will disappear from the Offers Page.

We don’t need to store battery level information, we need to create a capability to read this info during user navigation and when our app is running runs in the background.

1. Business Requirements

During the campaign period, a special offer will be sent over to sign-in users whose phone battery gets down to a low %. When the user is navigating throughout the app and his battery level is below x%, we will trigger a special offer and an In-App message will be sent to notify the user about this offer. The battery level will also check when the App is running in the user’s device background. The offer will be available to redeem only once per day or week. If the user fulfills the expected battery level, gets the offer but ends up not redeeming it; then, if the user has a low battery again and fulfills the expected battery level he will see the offer once more.

...

  • Create a new ruleset User Attribute > Battery Level to be applied on SystemWide Offer.

  • The new ruleset will check the battery level according to the parameter inputted;

    • The User Attributes property, Battery Level will be checked when the user starts the app and then, every 2 minutes. This property will only be checked if at least one of the Systemwide Offers available has the Battery Level rule within its UserAttributes rules.

  • If the user’s battery level hits the parameter, an offer will be available on their Offers page, only App;

  • No latency between when the guest triggers the offer and when it appears in the App;

  • Display this offer on Kiosk, we need a development on our side and Acrelec also needs to have a development. So, the recommendation is go live only on App because the users receive a In-App notification and they can redeem the offer right-way in the App;

  • The offer will be available until the user battery becomes above the parameter;

  • To run the be able to run the battery level rule evaluation when the app is in background we're introducing @capacitor/background-runner package. This enables us to run JS scripts in the background for both Android and iOS:

    • We will schedule the background job successfully user first have to start the app.

    • When the app starts in the foreground, we persist all battery level rules from offers to be able to access this data later in the background. For user data we're accessing existing user data stored under RBI_USER key.

    • When the App enters the background, we schedule the background job. Currently, it's configured to run every 5 minutes10 minutes for iOS or 15 minutes for Android, however due to platform level battery optimizations, it's not guaranteed that the script will always run (see the docs for more details). In the script we initially check if:

      • User is signed in

      • Battery level rules are stored

    • When these two conditions are met, we then evaluate the battery level rule with the current device battery level, in case when the battery level has changed enough to enter/leave the configured battery threshold, we will send a local notification when the conditions are met. When the guest taps the notification it opens the Offers Page in the App and the mParticle event will be sent from foreground. This would be safer in terms of duplicating events from foreground/background.

      • Risks:

        1. Platform level battery optimizations:

          1. There are no guarantees the background job will ever run, especially when the battery level is low;

          2. Need to take into consideration iOS and Android battery optimizations feature which they might be kill our background job.

            1. We should use threshold above 20%. For instance 30%, based on iOS platform usually starts their battery optimizations function in 20%.

2. Sanity - Offer configuration

The new ruleset will allows allow us to show an offer to the guest, only if that user has user attributes that fulfill the rules set in Sanity.

...

Based on Update User Attributes event, select Battery Level and input the value to be checked.

...

...

4.

...

Tests in Staging

...

  1. Offer setup in Staging

...

UDID to test App Staging

...

  1. Braze Notification (e-mail)

User can directly access the Offers Page and the special offer will be available.

#

Scenarios

Test Steps

Test Result

Notes

1

The guest signs-in and it is navigating in the app and his phone has the battery level > 30%, so no special offer will be triggered.

  1. User is opens the App, logged in and navigating

  2. User’s device iOS or Android has more than 30% of battery

  3. Special offer is not available on the Offers Page

PASS

2

The guest not signs-in and it is navigating in the app and his phone has the battery level <= 30%

  1. User is opens the App, it not logged in and navigating

  2. User’s device iOS or Android has <= 30% of battery

  • User gets the special offer via In-App message via Braze notification (due to latency the user can get the message after some minutes)

  • When the guest clicks on the message sent by Braze, the Offers Page is opened and the special offer will be available.

    1. Special offer will be available on the Offers Page, but when the clicks on the offer, we prompt him to Sign Up/Sign In to redeem the offer when the user is not logged.

    PASS

    25/10: Akhil Mohammed can you please re-test this scenario and add a video? Thank you (smile)
    Akhil: Re-tested and it is PASS

    ScreenRecording_10-25-2024 18-18-12_1.MP4

    Offer is available for NOT signed In User and User able to navigate to Sign up screen as expected

    3

    The guest signs-in and it is navigating in the app and his phone has the battery level <= 30%.
    The special offer will be available on the Offers Page.

    The guest will receive an In-App message or the guest can access directly the Offers Page.

    If the guests charge

    The guest does not redeem the offer.

    The guest charges their phone and the offer will disappear from the Offers Page

    in case the offer was not redeemed it the first time it showed

    .

    1. User opens the App and navigating

    2. User’s device iOS or Android has <= 30% of battery

    3. User gets the special offer via In-App message via Braze notification (due to latency the user can get the message after some minutes)

    4. When the guest clicks on the message sent by Braze, the Offers Page is opened and the special offer will be available.

    5. User can directly access the Offers Page and the special offer will be available.

    6. User does not redeem the offer

    7. User charges his phone to 100%

    8. The offer will disappear from the Offers Page.

    PASS

    In-App message are not received.

    3

    We tested navigating directly to Offers section.

    4

    The guest signs-in and it is navigating in the app and his phone has the battery level <= 30%.
    The special offer will be available on the Offers Page.

    The guest will receive an In-App message or the guest can access directly the Offers Page.

    The guest redeem the offer.

    In the same day, the guest charges his phone to 100% and opens the app again. The special offer will be not

    triggered

    show in the app because the guest already redeem the offer in the same day.

    1. User opens the App and navigating

    2. User’s device iOS or Android has <= 30% of battery

    3. User gets the special offer via In-App message via Braze notification (due to latency the user can get the message after some minutes)

    4. When the guest clicks on the message sent by Braze, the Offers Page is opened and the special offer will be available.

    5. User can directly access the Offers Page and the special offer will be available.

    6. User redeem the offer

    7. User charges his battery to 100%

    8. Some hours later, user’s device iOS or Android has <= 30% of battery

    9. User opens the app and the special offer will not triggered twice because he has redeemed the offer the first time it showed

    4

    The guest

    FAIL

    ScreenRecording_10-25-2024 17-02-53_1.MP4

    File (43)-20241025-111331.jpgImage Added

    User able to see the offer even after redeem in restaurant.
    For Mobile orders continue button is not working at check out screen for STG (Issue exist for all items)

    5

    The guest signs-in, opens the app, navigating and move to another app.

    BK app is running in the background and the battery level is still checking by our app each 10 minutes for iOS and 15 minutes for Android.

    The guest has the battery level > 30%, so no local notification will be triggered and no special offer will be available on the Offers Page.

    1. User is logged in, opens the App and navigating and move to another app

    2. BK App is running in the background checking the battery level (each 10min iOS/ 15min Android)

    3. User’s device iOS or Android has more than 30% of battery

    4. Local notification is not triggered

    5. Offer is not available

    PASS

    7

    The guest signs-in, opens the app, navigating and move to another app.

    BK app is running in the background and the battery level is still checking by our app each 10 minutes for iOS and 15 minutes for Android.

    The guest has the battery level <= 30%.

    The local notification will be triggered and when the guest clicks on the notification, we will redirect him to the Offers Page.

    The special offer will be available on the Offers Page.

    The guest does not redeem the offer.

    The guest charges their phone and the offer will disappear from the Offers Page.

    1. User’s device iOS or Android has <= 30% of battery

    2. User receives a local notification

    3. User clicks on the local notification and he is redirecting to the Offers Page

    4. The special offer will be available

    5. User does not redeem the offer

    6. User charges his phone to 100%

    7. The offer will disappear from the Offers Page

    FAIL

    • Local notification is not triggered.

    • Offer is not triggered.

    8

    The guest signs-in, opens the app, navigating and move to another app.

    BK app is running in the background and the battery level is still checking by our app each 10 minutes for iOS and 15 minutes for Android.

    The guest has the battery level <= 30%.

    The local notification will be triggered and when the guest clicks on the notification, we will redirect him to the Offers Page.

    The special offer will be available on the Offers Page.

    The guest redeem the offer.

    In the same day, the guest charges his phone to 100%, the local notification will be not triggered and no special offer will be available on the Offers Page.

    1. User’s device iOS or Android has <= 30% of battery

    2. User receives a local notification

    3. User clicks on the local notification and he is redirecting to the Offers Page

    4. The special offer will be available

    5. User redeem the offer

    6. User charges his battery to 100%

    7. The offer will disappear from the Offers Page

    8. The local notification will be not triggered

    9. Some hours later, user’s device iOS or Android has <= 30% of battery

    10. User receives a local notification

    11. User clicks on the local notification and he is redirecting to the Offers Page

    12. The special offer will not triggered twice because he has redeemed the offer the first time it showed

    FAIL

    User able to see the offer even after redeem in restaurant.
    For Mobile orders continue button is not working at check out screen for STG (Issue exist for all items)

    5. Local notification is not triggered - Core FE investigation

    Date 12th Nov 2024

    After 2 weeks of testing, App Staging and QA, we noticed the background task was not triggered the local notification which means the some how the iOS and Android system is blocking it.

    After further investigation from Core FE Team, the binaries and the configuration were reviewed and both of them are correct. There are some system level issues with scheduling the background task
    Unfortunately there's not much we can investigate about the system level battery optimizations as mentioned above the risks. The battery optimizations feature on iOS and Android is killing our background job and because of that, the local notification is not triggering and then the offer will be not available.

    Date 13th Nov 2024

    The background task is running every 5 minutes and we will change the interval to 30min/1 hour to test if the iOS and Android will still keep kill the background task.

    Core FE team will change and generate a new App Shell in QA to restart the tests.

    https://ionic.io/blog/create-background-tasks-in-ionic-with-capacitor