GoodWallet 2 Welcome Offer Modal & Redirect

[decentralauren]

Business Description

In order to begin migrating users from GW1 to GW2, we will make an offer to a select number of users to voluntarily start using the new wallet. The target number of users to migrate is 20k.

1. This offer will be made via a modal that is presented to a segmented number of users. That segmentation will be managed in Post-Hog and will be based on a combination of user behavior (including but not limited to how GW1 is accessed) and location
2. The modal will have a CTA that, when clicked, redirects the user in the same browser tab to the GoodWallet2 URL and begins the login process for GW2. See GW2 Figma screens for reference of what will happen after the user clicks the CTA
3. Users will still be able to access their GoodWallet1 at any point by navigating to the current GoodWallet URL

Detailed Description of Functionality

This ticket covers 3 specific activities:

1. Post-Hog Event Tracking

   • [x] event tracking requirements needed in Post-Hog for segmented offers

2. Modal Design & Implementation

   • See Figma design link below for modal design

3. Product Tracking (GA / Amplitude)

   • Event tracking for CTA clicks
   • Event tracking for "do not show again" [ See Comment from @drptiago below]

Technical Implementation

• [x] Create a newCustomDialog and apply design
• [ ] remember in storage 'do not show again'
• [x] add events
  • migration_invited
  • migration_accept
  • migration_denied
• [ ] create a feature-flag show-welcome-offer in posthog
• [ ] trigger modal on dashboard (TBD: either solely based on feature-flag, or feature-flag should be matched with wallet-addresses)

Design Reference

See Figma for full Welcome Rewards flow from GW1 to GW2.

Acceptance Criteria

Specify criteria that will be used to determine if the feature meets the requirements and functions correctly.

• [ ] (Should include a list of testing points for QA how to verify design/functionality) filled out by the development team or can contain suggestions._

Test Cases

Specify the happy path and unhappy path scenarios to test to verify the feature works as expected.

[decentralauren]

@L03TJ3 please estimate. I'll add to sprint once flow is ready :)

[drptiago]

I can't find the image of the invite modal @decentralauren

Considering that we have two buttons: "Try the New Wallet" and "Do Not Show Again."

The events can be:

migration_accept migration_denied

We also need an event for when the modal is displayed, so we know how many people are accepting, denying, or ignoring it.

migration_invited

[decentralauren]

@drptiago thank you! Please see a link in "Design Reference" above.

[decentralauren]

@sirpy moving your questions to here (the appropriate ticket):

Can you explain the requirements of a "valid" user to show the modal to? We need to add the events into Post-Hog to track first, so that we can get approximate cohort numbers and decide from there. We are trying to get to 20k migrated users and right now it's unclear how many users fit which criteria. Ideally we want to show the modal to

• all users in X markets (English speaking) who
• claim on both markets and
• do not use features that are not yet in GW2

The above is what informed the new event tracking that Lewis mentioned above.

Are there any other requirements than having X users to try to new wallet?

• I'm not sure what you mean. We want them to log in and claim in the new wallet, and ideally stay there. I have another thread to start between our team and GW2 on tracking churn between the 2 wallets (people who move from GW1 to GW2 but still use GW1).

My suggesting would be to randomly show it to X% of daily users until you have X users that tried the wallet. then you can close the campaign.

• Thank you for your suggestion. Based on the desire to avoid churn to GW1 due to limited features in GW2, we do not want to do that. And English is the only language supported in GW2 now.

[L03TJ3]

Latest updated decision for visibility:

For the migration we have decided:

We will create cohorts for the offer only on:

• Location
• Device type (target webapp users only)

TBD: We will sort through whether and if so how to track wallet address as a part of User ID when we discuss analytics (to also estimate cost).

[decentralauren]

@L03TJ3 I think all of the tasks in this are complete - mind updating?

Also does it show in our sprint report if it's in the "feature flag" pipeline?