High drop-off rate during Safe Creation flow

[johannesmoormann]

Part 1: Define the problem

What problem are you trying to solve?

Between creating a Safe (82%), the tx being minded (56%), loading the Safe (46%) and opening the loaded Safe (39%) we have a drop-off rate of 43%. While there is one important data point missing, that is the tx actually being signed by the connected wallet, it is already very much worth exploring the reasons for the behavior we can observe. Especially the drop-off rate between the transaction being mined and the loaded Safe being opened should tend towards 0%. Drop-off rates between chains vary but are significant for all relevant chains.

What is your hypothesis?

If we can identify reasons for the drop-off rate between these steps in the onboarding flow and find potential solutions, then the trust and emotions connected with the Safe (web application) in the first interactions will drastically improve, making it far more likely that the user will use the Safe out of real product interest/enjoyement and not only necessity.

What value does this bring to our customer and/or our mission? What is the goal?

Generating trust
Moving the Safe from a product being used out of necessity and security to a product that is also loved and trusted
Saving user funds being lost in failed transactions

How do we measure it?

https://analytics.google.com/analytics/web/#/analysis/p308247657/edit/557AG-gqTwGrCzUq0hj4Ug

Links:

Working document see https://www.notion.so/gnosis-safe/Safe-Creation-7ec069306e8c4101bffd7c17299eec53

Part 2: Shaping the problem

Problem Owner

@usame-algan

Solution

Solution 1

Overview

Improving the drop-off rate after the transaction has been submitted

At this stage the user has taken the decision to actually create the Safe and pay the associated transaction fee. We therefore suggest taking a series of design and technical measures to bring the drop-off rate down and as close to 0 as feasible.

Measures include:

• further improve analytics around Safe creation e.g. adding extra funnel events such as transaction submission through the wallet provider, transaction fails and retries
• remove unnecessary steps and improve progress bar
• remove Back button and replace with refresh button after transaction submission
• solve retry issues when Safe is already created
• full list can be found in the Working document

Solution 2

Improving conversion rate before the transaction has been submitted

• reduce the information load and introduce reactive
• remove and possibly relocate steps such as naming of Safes to after the Safe has been created and loaded
• conduct user tests with prototypes and use A/B testing
• full list can be found in the Working document

Solution 3

Pre-defined user type creation flows e.g. individual and organization onboarding

• Research user type flows
• create and test prototypes

Alternative solutions & ideas

Open Questions