You know Uber for its brand, its transportation offer, or even its engineering... but did you know that Uber is also one of the companies that best manages consent and preferences? The company has indeed set up a dedicated team of engineers to build and operate an impressive data privacy infrastructure. Are you wondering how it works or looking for advice on how to do the same? This article is for you.
- Uber acknowledges the era of consent
- Why build a privacy platform?
- A consent architecture with flexibility in mind
- 3 tips for building a solid consent platform
Uber acknowledges the era of consent
The introduction of privacy laws in the last couple of years, such as GDPR and CCPA, have shaken the digital ecosystem. Companies are faced with new privacy legal landscapes and evolving rules for defining, collecting, storing and using people’s personal data.
Why all these laws? Because consent and privacy are concepts that matter to people. Consent ensures that individuals have a choice and maintain control over their information and how companies use their data. It also makes sure organisations are transparent and accountable.
Properly managing consent is also good for business, as it is probably the best possible customer service you can provide. It puts people at the center of the relationship you have with them, and builds trust. It can strengthen your reputation, improve engagement levels and encourage the use of new services and products. It is a great way to set yourself apart from the competition.
Want to find out more about the “era of consent”? Check out our whitepaper “From Privacy to Preference, how data regulation is changing marketing for the better.”
In fact, privacy laws drive organisations to evolve from a data protection mindset to a data management mindset, and that is exactly what Uber did by building their own data privacy infrastructure.
In a recent webinar (shout out to Transcend!) dedicated to engineers working on privacy projects, Roche Janken, Privacy Engineer at Uber, talks about the necessity of having a useful privacy as a service, and walks us through the end-to-end consent platform that they are operating.
Her intervention is enlightening, so let’s take a closer look at it and discuss the crucial importance of consent infrastructures within companies.
Photo by Charles Deluvio on Unsplash
Why build a privacy platform?
First of all, let's make a small point of differentiation between a Consent Management Platform (CMP) and a privacy platform, or consent infrastructure.
A CMP provides you with a tool to collect and store users’ consents (on web, in-app, connected TV...) and pass all consent-related data to the respective technology partners. The software gives your company the capacity to inform users what kind of data they want to share with you through trackers (cookies, pixels...) and to ask for their consent for particular processing purposes.
A consent infrastructure is an integrated data engineering system that sits "below" user-facing interfaces like your CMP, or any other user-facing interface. In other words, a consent infrastructure is the backbone to a CMP. It is a data privacy solution which a both allows you to collect, store, update and distribute your users' preferences across your entire company.
Uber's technology operates billions of trips, meals and deliveries every year, for hundreds of millions of people across the globe through its many brands (Uber, Jump, Uber Eats, Uber Freight...). Its customers, individuals and companies from various countries, trust Uber to collect and use personal data only when necessary. This is why privacy technology is essential!
Photo by Charles Deluvio on Unsplash
What are the three main reasons why building a privacy platform is important?
Making privacy easy: implementing core privacy services within your company helps you provide proper tools for your internal stakeholders (like the Product Managers who build your app), reduce the engineering load, and incentivise adoption so that everyone aligns with your privacy practices.
Utilising expertise: it is important to have a team that specifically handles privacy (just like you might have teams that handle payments). They have the knowledge to implement various privacy requirements in a consistent and auditable manner. They are in close contact with Legal or Policy departments, and know who to go to if needed, and vice versa.
Standardising: to standardise is to implement data protection in a clear and unified way. These processes create clarity within your company and a climate of trust with all your stakeholders, who know exactly what to expect and where to find you.
Would your company benefit from a bespoke consent infrastructure? Organise a demo with Didomi.
A consent architecture with flexibility in mind
Roche Janken’s way to explain it is very simple: If you are collecting new data, or using existing data for new purposes, get consent. To do that, your consent platform acts as a RESTful microservice that stores consent and copy, to make sure there is high availability and no downtime.
She describes the basic consent flow at Uber as follows:
In order to collect new data, they must first get consent: they need proof that the user has seen the notice and agreed to it.
If yes, they proceed onto the feature, if no, they make a call to the backend to get the “locale copy” (words that are legally binding and translated into the language that the user has set as their language).
They display the locale copy on the screen, and whether the user says ‘yes’ or ‘no’ to the request, the information will be stored either way.
If they say yes, Uber pursues with the feature, if not, they don’t.
The strength of their consent architecture is that it was designed with flexibility in mind, so a lot of the customer teams have their own flows. The privacy team doesn’t tell other engineers how to build their features and their flows, they just provide them with the basic consents service that they can use, with features that they can easily integrate with.
Image by Uber, via Transcend
What services has Uber put in place to promote flexibility?
The “mobile consent library”: a service that can be shared between their different apps and that provides client-side caching. Indeed, as they can’t predict the network availability in the countries that their customers are based in, and because the onboarding and trip flows are so crucial, they want to be able to cache the information on the client side and send the data back to the consents service when users are connected.
“Consents service”: a co-service built on top of Glue (a Uber web scaffold built to standardize coding patterns across the Uber environment).
“Database”: a Cassandra database with a Dosa wrapper (Dosa is an open source database abstraction that Uber has built to make it easier for full-stack developers to use database technologies like Cassandra without having to worry about how it is deployed in the Uber environment).
“Localization service”: the primary dependency of the consents service.
“Customer service”: a service created for flexibility. Some feature teams may decide to bundle several payloads into one RPC call, or to bundle several RPC calls and have their service being in the middle between the front-end and the consents service. All this needs to be made possible for them.
Hierarchies within the consents service
“Entity hierarchy” are the entities within Uber’s consents service. It represents the legal entities and the hierarchical relationships between them.
At the top, there is the feature.
Beneath is the Disclosure, in order to provide re-consent. You’ll know that making changes in apps can take time. So to be able to create a new disclosure that automatically creates re-consent, they have what they call “Disclosure” beneath their features.
Beneath they have Disclosure versions, that have metadata about the consent. And beneath that, they have their locale copy, the actual legal text written by lawyers, adapted to each region and language.
Image by Uber, via Transcend
Uber's 3 tips for building a solid consent platform
In order to build a solid end-to-end consent infrastructure in a globally operating, fast-growing company like Uber, Roche Janken gives 3 pieces of advice drawn from her personal experience as a member of a mature privacy team:
Projects are open-sourced for contribution from other teams
Roche Janken gives the example of a feature team at Uber who asked for deferred consents (the “ask me again later” option). It is not a legal concept, but the team wanted to expand its scope from being purely legal in order to better serve their customers, who probably would not have used their service if they’d had to track a deferred state elsewhere.
Glue made it easy for them to implement deferred consents, and all teams could benefit from it. Indeed, all current and future users of the consents platform benefit from the various contributions.
You may choose to optimise user experience by providing additional notice
As a regulated company, Uber is required to share certain data with local government agencies. So, although a consents service is already in place in the mobile consent library, the feature team anticipated its needs and decided to add its own consent nodule whenever it knew it was going to collect a little more data.
The consents team simply made it easier by ensuring that users understood what data they were collecting and using, and by helping the team get their product to market.
Can we help you build your privacy infrastructure?
Thank you Transcend and Uber for sharing your experience! We have loved it so much we have written this blog post... Now are YOU inspired to build your own consent platform and offer privacy as a service?
A privacy company like Didomi can help you build and maintain a powerful consent management infrastructure. We bring our expertise and technology to advise you on consent collection, storage and sharing, and we can help you place privacy at the architectural and strategic level of your business.
Would you like to build a world-class consent infrastructure too? Contact us.