Surrogate Offers
Overview
Surrogate offers are shown to new users after completing their registration and immediately verifying their ID successfully. If ID verification was not successful, then the user will be redirected to a different screen and will not be shown the Surrogate Offer screen right after Signing Up. If the user decides to skip this step or select and accept an Offer from the Surrogate Offer screen, the user will be redirected to Account Deposit screen. The list of Surrogate Offers available to choose will be pulled from an API call, with the default expectation of 3 offers for both Ladbrokes and Neds. The number of offers may vary, and both Variant A and Variant B are capable of displaying any number of offers. These offers are part of an A/B test aimed at determining the most effective presentation method to maximize user engagement and offer acceptance rates. Users are shown these offers in one of two variants, Variant A or Variant B, based on the outcome of the A/B test.
Variant A (Pager)
In Variant A, offers are displayed with rich imagery in a view pager format. Each offer is presented one at a time, showing a detailed description, an image, and an Apply Offer CTA. Users can swipe horizontally to navigate through the offers. This variant is visually appealing and designed to provide a more immersive experience. However, it requires users to actively swipe through each offer, which may affect the ease of comparison and selection. By default, it is expected to show 3 cards, each of them having it's own image, specific per brand. If more than 3 offers are present, then the images will repeat in a cycle starting from the first one. Each offer card will have a badge with a text below the image icon. The following badge are displayed in the following order: "Most Popular", "Kickstarter" and "Great for Racing Punters".
Variant B (List)
In Variant B, offers are displayed in a vertical list format with radio buttons. The first offer in the list is pre-selected by default. Also, the first offer will always have a the "Most Popular" badge on the top left section of the offer item. Users can browse through the list and select their preferred offer by tapping the corresponding item. The Apply Offer CTA is positioned below the list, allowing users to submit their selection easily. This variant is more straightforward and user-friendly, enabling quick comparison and selection of offers without the need for extensive scrolling.
Branding
The designs for Surrogate Offers at the moment are defined only for Ladbrokes and Neds but may incorporate other brands in the future. The main differences between both brands are in the color themes for both Variant A and B. Also for Variant A, the background images for each brand are different and have their own URL path.
Integrations
Feature Flags
signup-offers-paging-test-native- Defines whether to show Surrogate Offer Variant A if true, or Variant B if false.
Inputs
State: Client Details
- The logged-in user's first name is displayed.
REST: GET /v2/offers/postSignUpOffers
- Used to get a list of surrogate offers available for the newly created user.
Outputs
REST: GET v2/offers/ClaimOffer
- Used to apply a surrogate offer to the user's account.
Onward Navigation
- Deposit - navigates to RN
AccountDepositscreen. - Phone Number - launches phone app.
- Terms and Conditions - launches browser to 'Terms and Conditions' page with path
rules-terms-and-conditions.
Third-Party Dependencies
Android
On the Android platform, the primary components for the Surrogate Offers can be found in signup/presentation/offers/SignUpOffers.kt.
To name the most important parameters in the main component, SignUpOffers:
variant: SignUpOffersVariantoffers: List<Offer>onSubmit: () -> Unit
The value of SignUpOffersVariant comes from the state managed by the ViewModel (signup/presentation/offers/SignUpOffersViewModel.kt). This value is determined by evaluating the feature flag signup-offers-paging-test-native. If the flag is active, Variant A is displayed, otherwise, Variant B is shown.
The list of offers also comes from the state of SignUpOffersViewModel.kt, which are retrieved using the GetOffersUseCase. These offers are available only if the registered user has not previously accepted an offer and if the user's ID was immediately verified upon Sign Up.
Finally, the onSubmit() function is executed when the user clicks on the Accept Offer CTA. This triggers the ClaimOfferUseCase from the viewModel SignUpOffersViewModel.kt.
For Variant A, the OffersVariantA component will call SignUpOfferPager composable (SignUpOfferPager.kt). For Variant B, the OffersVariantB component will call SignUpOfferListCard.kt component to display the offer cards.
Also, Variant A uses brand-specific images, which URL paths are defined in SignUpOffersTheme.kt file (located in /brand/../signup/presentation/theme/SignUpOffersTheme.kt). Along with paths to these images, this file also defines the badge colors and other visual elements.
This file centralizes the theme settings and should be modified if there are differences between Ladbrokes and Neds. As for Variant B, there are no major differences between brands except for color themes.
Consideration when adding a new brand:
Ensure to define the image URL paths used by Variant A and also the color themes.
Amplitude Experiment
Used for feature flags and experiments. On this screen the experiment drives the A/B test.
iOS
On the iOS platform, the primary components for the Surrogate Offers can be found in PresentationLayer/SignUpUI/Screens/Offers.
Both Variant A and Variant B are driven by a shared View Model, SignUpOffersViewModel. This view model stores which variant should be shown, and also supplies the full list of offers, the button to be shown, and the currently selected offer.
The SignUpOffersView is a shared View that provides the background and footer views common between both variants. It is also responsible for switching between Variant A and B based on viewModel.offerViewStyle.
Both Variants will then call SignUpOffersPresenter.applyOfferAction(code: String) when their action buttons are pressed, which will begin the process of making the API call to actually apply an offer to the users account. Once this succeeds, the SignUpOffersCoordinator will navigate the user to the deposit screen.
Variant A is implemented in SignUpOffersCardView which uses a manually implemented pager. We use a ScrollView that snaps to each view on iOS 17+, rather than a pager, due to a SwiftUI issue with not being able to theme paging dots. As a result there are no paging dots implemented at all. On iOS 16 the ScrollView won't snap, this is an accepted difference.
Variant B is implemented in SignUpOffersListView, which is a simplier list of buttons, and a single action button at the bottom. The haptic feedback will only work on iOS 17+, it's accepted that it won't work on iOS 16.
Consideration when adding a new brand:
Add the Variant A images to EntainComponentLibrary/Resources/Media, specifically surrogate-1, surrogate-2 and surrogate-3.
Troubleshooting
Identify any points of failure or dead-ends with logs to look out for. It is expected that these details will be platform specific.
Android
SignUpOffers.kt file contains the main components to draw both Variant A and B. It's important to know that making changes to the main component SignUpOffers will affect both Variants A and B
iOS
SignUpOffersView contains the main components to draw both Variant A and B. Making changes to SignUpOffersView will affect both Variants A and B
Resources
| Role | Contact |
|---|---|
| PM | Lily Sommers |
| Android Lead | Anthony Librio |
| iOS Lead | Nicholas Vella |