\uD83D\uDDD3 Date

21 Sep 2023

\uD83D\uDC65 Participants

...

Magdalena Dlugolecka

\uD83E\uDD45 Goals

• Review the complexities and challenges

Designs

Figma: Burger King

https://rbidigital.slack.com/archives/C05RQBE90C9/p1694083887304829

\uD83D\uDDE3 Challenges

1. Storing User Data- cognito-

   Based on the 2023-08-24 Guest checkout PoC works we go with the approach of not creating the User entity in the Cognito and DB. All Guest data will be stored in the Order DB entry.

Overall Complexity

Overall Complexity

How to save these customers in the database and how to handle the case when such customers return again for an additional purchase.

1. Lots of services rely on user data, therefore there is a high level of dependency if we decided to store user information in User entries (record = sk= v0_User in monotable) - we’d have to figure out how other services can consume guest data

   1. Eventually, based on the 2023-08-24 Guest checkout PoC works we went with the approach of not creating the User entity in the Cognito and DB. All Guest data will be stored in the Order DB entry.
      

2. Database does not allow for adding multiple users with the same e-mail address

   1. (it’s not a problem anymore since we don’t store the guest data within the user entries in monotable)
      

3. We need to create functionalities that are usable for all markets and due to architectural differences per market (transition from whitelabel-gql to fulfillment-service, currently DE uses whitelabel-gql but will have to transition to fulfillment-service eventually) , this posed a need for code duality since the code needs to be created in both places.

Legal Requirements

...

How to treat guest users?

3. Our initial approach required creating a “fake/dummy” user for the guests- in this case we’d had to determine how to authenticate guest users (dummy sessions)- once user enters checkout, we create that’d involve creating an account in the background, once user enters checkout, but the account would be created with a dummy email, their real email would be stored in meta of order entries -It’s be problematic if they did not finalize an order, because in this case we don’t have the right to retain their data- Decision

   1. decision was to store guest data in Order meta data.
      

4. We had to determine what to do with the session if a user abandons the checkout process- should we hold on to the cart data.
   

5. We cannot store guest information in our marketing tools- need to find an alternative way to provide them with transactional emails

   1. Transitioning transactional emails from Braze to AWS SES - dependency on another internal team- yet to do
      

6. Initially we thought we should not pass data to mParticle but we have decided that we’ll still collect events but with anonymous guestID, assuring that it does not get passed on to Braze.

Yet To be determined

...

3. Decision on whether to allow a user to checkout as a guest with an email that's already registered

   1. recommendation: to optimize conversion that’d be advisable
      

4. Legal copy for terms and conditions + Privacy Policy for a new static page
   

   Decision on consent- storing
   

   Image Modified

5. User may be unable to inform the kitchen they have arrived if they abandon the confirmation page -. User does not have any order reference number, and once confirmation is closed they cannot click I arrivedon the “I arrived” button, they have no way to retrieve this page.

   1. One solution is to send a unique link via email to retrieve the confirmation page, however this would require the token to be passed which increases the complexity.

   2. Another solution is to include a warning modal upon exit.
      

6. Instrumentation and - adding appropriate events to track success metricsnew events capturing new user interactions
   

7. Still a few non-critical designs and design adjustments are pending
   

8. Support Tool adjustment is not required at this moment as DE market users VR Payments directly to perform Customer Support actions, however it’ll be required for the loyalty launch if Support tool is intended to be used from that time on for refunds etc.
   

...

3. How to store user data on the FE, prevent certain functionalities that are dedicated for registered users (for example: loyalty, so far adjusted only for registered users)
   

4. Modifying sign in flow to a modal is quite complex

Additional considerations

7. Showcase email for verification purposes to users to avoid errors in email addresses

   1. Allow for email address edit during the process
      

8. Marketing consent excluded - high complexity, how to process and store this data
   Some of the estimations are split into two parts whitelabel-gql (one large repo, one app, and fulfillment-service (separate services, easier mangement, clear domain borders). It's because some markets use whitelabel and some of them the fulfillment service or it's mixed. Because of that, we have the same functionalities in the two places. We could think about skipping the whitelabel part and implementing it only in the fulfillment service, but it requires the rollout of the fulfillment service. We have this movement in the plans: TRX-655: Tech Debt Fulfilment Service RolloutTO DO
   

...

...

2 MD

...

Engagement Team

...

...

• whitelabel-gql: 1MD

• fulfillment-service: 2MD

...

Transactions Team

...

...

• whitelabel-gql: 2MD

• fulfillment-service: 3MD

...

Transactions Team

...

...

2 MD

...

Transactions Team

...

...

3 MD

...

Transactions Team

...

...

3 MD

...

Transactions Team

...

...

14 MD [guesstimate - estimation without a SPIKE]

...

Haris' Team -

...

...

21 MD [guesstimate - estimation without a SPIKE]

...

...

...

• whitelabel-gql: 2 MD

• fulfillment-service: 3 MD

...

Transactions Team

...

^{[added 2023-09-13]}

Add metrics to track the success rate
Not ticketed yet (waiting for more spec) - thread

✅ Action items

...