Criteo has started testing the single sign-on (SSO) solution – called OpenPass – that will serve as the consumer-facing component of Unified ID 2.0, the open source industry initiative that aims to use email as an alternative to third-party cookies.
In November, Criteo was one of the first companies to join Unified ID 2.0, which is being spearheaded by The Trade Desk, with the task of building an SSO interface and a transparency portal.
Criteo is handling most of the testing among users and publishers in GDPR countries, while The Trade Desk will conduct testing in the United States.
SSO is a critical piece of the puzzle if UID 2.0 has any chance of reaching scale.
Participating publishers will need to clearly explain why they’re asking for consent and what their visitors will get in return for sharing their email address – and “Gimme your data so I can target you with ads and you don’t have to pay” probably isn’t a compelling enough value proposition in the long term.
“We’re looking to improve the overall value of a person’s internet experience and not just create a safer way to personalize an ad,” said Todd Parsons, Criteo’s chief product officer. “Achieving that is relevant for our business and for the entire industry.”
Come to pass
Exactly what that souped up value exchange will be is TBD – and up to the publisher – but the one thing that’s non-negotiable about the SSO mechanism itself is that the experience has to be simple, consumer-friendly and as frictionless as possible.
Criteo is testing multiple variations of the SSO with publishers and users, including a logged-in experience with verification and an unlogged traffic experience for people that agree to see personalized advertising but don’t want to share their email address.
In the first scenario, users are presented with a pop-up module prompting them to enter an email address and a verification code that’s sent to their inbox. Once they do, they can continue to the site.
Meanwhile, in the backend, the domain passes the email address to the UID 2.0 service, which returns a hashed identifier that is stored on the client-side as a first-party cookie so that other websites can recognize the ID.
The next time those already opted-in users visit a website in the UID 2.0 network, they’re hit with another OpenPass pop-up that’s prepopulated with their email address. All the user has to do at that point is click “continue” in order to visit the site.
But, of course, not everyone is going to share an email.
For those who don’t want to authenticate but are willing to see targeted ads, a pop-up module asks them to agree to the OpenPass terms, including that a pseudonymous ID that doesn’t personally identify them will be shared with “trusted advertisers.” (Perhaps not the most user-friendly language of all time, but anyway … )
From there, users can continue onto the site and a unique identifier in the form of a non-PII alphanumeric string is generated on the backend.
Similar to the logged-in experience, the ID is stored on the client side by the SSO domain as a first-party cookie that can be read and recognized by other sites that users visit during their browsing session.
An open exchange
Still, many open questions remain.
How will OpenPass work with existing sign-on solutions, like Auth0, and will it be interoperable with more nascent efforts, like SWAN.community (Secure Web Addressability Network), a global consent mechanism for anonymous browsing? Will the OpenPass technology support identity initiatives beyond Unified ID 2.0? And will publishers that have a first-party relationship be able to access a user’s actual email address or just the hashed UID 2.0 token? What type of SSO user experience drives the highest opt-in rate?
These were all topics of conversation at the first meeting, held last week, of a new project management committee devoted to the sign-on experience hosted under the auspices of Prebid.org. Members of the committee, chaired by Parsons, include representatives from around 50 publishers and ad tech companies. Parsons is currently looking for a publisher co-chair so that all interests are represented.
The next meeting will take place on Tuesday, April 6, and over the next week or so, the committee will finish preparing the OpenPass code and add it to a new GitHub repository.
Although there’s still a lot that’s unsettled about how identity will function on the open web, there’s no reason everything can’t coalesce in a manner that makes sense for businesses and for the user experience. It just requires collaboration.
For example, Parsons said that he’d be open to merging the OpenPass project with SWAN.community, which focuses exclusively on non-logged in browsing, if that effort ends up being as transparent and open as advertised.
“I mean, why not?” Parsons said. “We all need to put our self interests aside and try to build something that’s better for the consumer.”
