Page Comparison

\uD83D\uDDD3 Date

...

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.

Designs

...

Overall Complexity

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

2. Database does not allow for adding multiple users with the same e-mail address (it’s not a problem anymore since we don’t store the guest data within the user entries in monotable)

Legal Requirements

...

1. 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) the code needs to be created in both places.

Legal Requirements

3. If we wanted to create fake users- we’d had to determine how to authenticate guest users (dummy sessions)- once user enters checkout, we create an account in the background, 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 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

   User identifiable data cannot be passed to mParticle then Ill be distributed to other, anonymous guestID need to be created

   1. - to do

6. Initially thought we should not pass data to mParticle but we have decided 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

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

   1. ConsentDecision on consent- storing
      

      

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 arrived, they have no way to retrieve this page, if we want . One solution is to send a unique link via email to retrieve the confirmation page, however this would require the token would have to be passed that which increases the complexity or include . Another solution is to include a warning modal upon leavingexit.

6. Instrumentation and adding appropriate events to track success metrics

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

Additional considerations:

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

   1. Allow for email address edit 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
   
   

...