Case Study — Data Driven
Asynchronous Registration
Topic.
How can we reduce failure rates for domain registration?
Role.
Product Designer for end-to-end design process. Core team included 1 Product Manager, 2 Front-end, 4 Back-end Engineers and 1 Support Specialist.
Business Goals
When registering a domain with Squarespace, our customers wait an average of 18 seconds while we perform background tasks such as: charging the customer’s credit card, registering the domain, and configuring the DNS zone. This process also scales linearly, meaning a customer registering 10 domains would have to wait 3 minutes for the process to complete.
Decreased wait time and failure rates would lead to increased conversion, and by performing asynchronous actions, we would also decrease the risk of other dependent purchase failures such as G Suite.
0.6% of registrations failed
10% of purchases with > 1 domain in the cart would have at least one domain failure during registration
80% of G Suite purchases would fail following a newly purchase domain
User Goals
For many customers, buying a domain is their first interaction with Squarespace, and a long wait during registration was setting a bad impression. There was no reason a customer should have to wait while we perform these tasks, and it was a missed opportunity for product interaction and up-sell.
Customers would wait up to 18 seconds to register a domains. That time scaled linearly, meaning registering 10 domains could take 3 minutes. Process
Much of this project was backend work. There were two parts of the user experience that would change:
1. Given that the registration would be completed at a later time, we would be removing the confirmation receipt from the flow. We anticipated that this would confuse customers and look shady, so we needed a way to finalize the purchase flow but let the user know it wasn’t the final final.
Customers would no longer see a confirmation receipt from their purchase. This was a risk, and we hoped that the welcome modal would be clear. 2. When a customer completed the purchase flow, they customer would land on a Welcome Modal that included two up-sell paths; for a website, or G Suite. Given that G Suite purchases had been failing duration the domain propagation period, we decided that we should switch the order of the two up-sells, and prioritize websites. The up-sell of website trials would also highlight a path of high intent customers with LTV. We would also use this modal in place of the old receipt, and let customers know the status of their domain purchase.
The original welcome modal prioritized G Suite as the logical up-sell with a domain. With 80% of purchases failing due to propagation, we flipped the order and saw a 47% increase clicks to start a website.What would success look like?
We hoped to significantly decrease wait time for the average customer to less than one second when completing registration.
Results
Failure rates went down overall due to async reg as well as other improvements made by the team. Any failures were now are mostly related to billing errors.
For the Welcome Modal, we ran an A/B test, beginning at 5% and increasing to 50/50 after two weeks. We saw a 47% increase in clicks to start a website, and significant decrease to G Suite. We continued with this design as it met our goal to up-sell websites.
Why is this project important to me?
This optimization was well overdue for our customers, but became blocked many times by other initiatives. We knew that a handful of explicit tasks would save the business a lot of money as well as do right by the user.
