Exploring Data Custody Preferences

A study on self vs server custody among ETHDenver attendees
rachel
May 7, 2024

We partnered with IYK in Feb 2024 to create ZK-powered quests that ETH Denver attendees could embark on to win chipped goods at IYK’s store. These quests required you to collect signatures by tapping chipped attendee badges and chipped IYK discs at booths. To complete a quest, you needed to ZK prove that you finished the requirements to avoid revealing your precise interaction data.

In a situation where people are given the opportunity to create data about their interactions and utilize it to make purchases, would they choose to store it unencrypted on our server or would they opt to store their interaction data encrypted on our server and be responsible for managing an encryption key? We A/B tested with thousands of participants to find out.

While 64% of participants chose self-custody, we learned that default UI selections have a strong influence over an individual’s choice, and more in-depth A/B testing will need to be conducted to learn about particular group’s perceptions of privacy.

Background

We created an experience for ETH Denver attendees to collect BUIDL by tapping NFC-enabled conference badges and sponsor booths.

We assumed that the particular audience attending ETH Denver, with an interest in decentralization, might lean towards the privacy preserving option – and they did. 64% of participants chose self-custody.

User experience (UX) theory tells us that default selections in the user interface (UI) and copy choices can have an impact on user behavior so we A/B tested multiple scenarios to mitigate bias.

Results

ParticipantsServer vs self stepsListed firstPre-selectionuser switched selection
9457 vs 8selfrandom38%
9975 vs 4serverselfn/a

Key takeaways

More than half of the participants chose to self custody their data. They were likely influenced by both the copy and the default selection they saw on their screen.

Our metrics reveal that there was a slightly higher chance of a participant switching their pre-selected settings to self ownership over switching to server ownership. But the majority — 62% of participants — did not change the custody option that was pre-selected for them.

Custody selection% of users
kept pre-selection62%
switched to self11%
switched to server8%

Two different versions of the copy were tested. The first included more direct language about the benefits of ZK tech, while the latter said less about the tech’s affordances but mentioned the ability to unlock prizes by making a proof about one’s private data.

Influence of pre-selection

Version 1

53% self-custody

The first half of participants experienced a longer and slower registration process where they had to complete 4 steps before making the choice to custody their data or not. This included verifying email with a code and pre-selecting socials. For users who chose server-custody, they had one less step at setup, as they could skip choosing a master password. The default selection was randomized and self-custody was listed first.

changed pre-selection to%
self22
server16
Registration Version 1

Version 2

74% self-custody

The number of steps in the registration flow was cut in half for the second half of participants. There were actually fewer steps to complete the setup when choosing to self-custody, as we skipped the email verification for those users. Server custody was listed first, but self custody was auto selected.

changed pre-selection to%
server26
Registration Version 2

Influence of language

We are building experiences like this one to allow people to get a taste for owning and utilizing their data and to imagine what it would be like to have a different experience online. Instead of forcing them into this alternative experience, our goal was to provide users with benefits and drawbacks of both server and self custody options so that we could observe the choices people make when their options are transparently presented.

There are a few key differences between the copy included in Version 1 vs 2 of the data custody selection page. To make it easier to compare, the copy featured on the images of mobile screens above is presented in tables below.

Version 1Version 2
IntroIYK has partnered with Cursive to integrate ZK tech into this experience to enable full data ownership and authenticity. Choose if you want to enable it.Custody options, built with ZK tech by Cursive.
NotesExplains benefits of zk tech and points out that the user has to opt-inLike version 1, says who has provided the ZK tech but does not mention its benefit
Version 1Version 2
Self Custody DescriptionYour ETHDenver interaction data is private to you, encrypted by a master password set on the next page. ZK proofs are used to prove quest completion.Your socials and contacts are private to you, but you must save a master password for encrypted backups, ZK is used to verifiably unlock prizes.
NotesPoints out a privacy benefit, a potential drawback and an explanation of what proofs are used for.Points out a privacy benefit, a potential drawback and includes an incentive.
Version 1Version 2
Server Custody DescriptionYour socials and contacts can be read by app server, but login by just verifying an email code.Your socials and contacts can be read by app server, but login by just verifying an email code.
NotesPoints out both a potential drawback and benefit of the optionPoints out both a potential drawback and benefit of the option

It’s hard to tell from the metrics how much the copy impacted the users decision. In the future we would like to collect insights about the language from interviews with users. It could be highly insightful to write copy for the specific audiences we want to work with and A/B test more persuasive copy that leans in either direction.

Summary

Overall:

  • 64% of ETH Denver attendees chose to self custody their signed interaction data
    • When we randomized self/server pre-selection and required an extra step for self-custody (setting master password), 53% of attendees chose self-custody
    • When self-custody was pre-selected and there was an extra step for server custody (opening email for verification code), 74% of attendees choose self-custody
  • 38% of attendees changed their pre-selected option
    • This tells us that pre-selection influenced users even more than the copy and maybe even their own understanding
    • Even though it was less than majority, revealed potential value in giving people a choice in their custody options

While the results of this experience indicate a slight preference for data privacy and ownership, they do not tell us how deeply people care about or desire data privacy or which types of data they care the most about owning or verifiably proving. It could however, be a step in that direction. From this experiment it is evident the role that builders play in influencing the decisions that individuals make when using products.

We did learn that the particular audience that attended ETHDenver in 2024 - who avidly collected signatures and made proofs about their interactions at the event - had a preference towards data privacy. They verifiably proved that they met people and visited sponsor booths until the IYK store completely sold out of merch. We wonder what these numbers would have looked like if more ETHDenver attendees knew they could tap their badge to access the app.

Questions for continued research

  • How does the simplicity of sign up influence a users choice to self-custody? (Are people more likely to defer responsibility in a challenging or simple situation?)
  • How trusting of an experience/ how confident in a product does a person have to feel to take ownership of their data?
  • Does the perceived value of the data influence one’s choice to self-custody? Some pretty cool stuff could be redeemed at the BUIDL store, but the fact that it couldn’t be spent elsewhere and was only valuable the duration of the conference made it less risky to self-custody.
  • How might the results differ the listed order and pre-selection are fully randomized?
ScenarioListed firstPre-selection
Aselfself
Bserverserver
Cselfserver
Dserverself