Pauraque
NextRoll’s Profile-based API for User Attribute Queries (Pauraque) enables marketers to engage people with interest attributes, with additional user-level controls over which attributes will be available to marketers.[1]
Pauraque adopts Google’s Privacy Sandbox goal of disintermediating publishers from the marketers that fund their digital properties.
Overview
Pauraque proposal relies on a local client user profile containing attributes that can be used to improve the matching of content. These attributes are visible to the user, who can enable which organizations may have access to their profile and to particular attributes. Pauraque leaves open whether the attributes could be expanded to interests. “Should there be a standard set of interest, e.g. modeled after IAB categories, or should they remain freely settable and purely rely on the market to establish this on its own?”[2]
Pauraque focuses on B2B marketing use cases, where interest-based activity is often far less important than “firmographic data such as industry, company size, and location.”[3] The two use cases the Pauraque proposal aims to address are:
- Match content to people based on the job function or working at companies on a Target Accounts List (TAL).
- Report on spend, clicks, impressions, page views, view-through conversions, and click-through conversions with company-level granularity.
The proposal offers three mechanisms for people to add attributes to their local profile:
- User explicitly declares an attribute to be added to their profile
- A site the user is interacting with requests adding the attribute to the user profile
- The web client can recommend an attribute to be added to the user profile
Pauraque relies on a sufficient k-anonymity for any attribute to be available to be added to the profile. Users can choose to remove any added interest at any time.
Pauraque raises the important concern regarding the trustworthiness of the attribute data. “A user could put false values for company or job title. Or, the user could change jobs without updating their profile.”[4] While Pauraque suggest that some third-party service could verify the attribute linkage to the device, but does not describe how such could be done, especially without reidentifying the untrusted individual, for example if the attribute (a job title) were unique to a given organization. “A third-party service could be used to provide this verification and issue a certification or Trust Token which could be attached to the attribute.” [5]
The proposal assumes that the auction logic will be analogous to Turtledove/Fledge, where the publisher will not receive any information about what products the organization wishes to suppress users from.
Impact
Similar to Fenced Frames and Turtledove/Fledge, Pauraque states that content matching systems should not be able to learn which ads were correlated to which conversion events. This will impair marketer effectiveness and negatively impact publisher revenues.
Pauraque describes how people could manage the attributes in their local profile, but not which attributes would be made available to the various advertising solutions that marketers rely on to engage audiences. If a given user were in the market for a delivery service, let us assume they have added such an attribute to their profile and want to share it with interested parties that can help them with their need. How would the user know which organizations can help them with their need before seeing prior advertising to know which organizations to allow? This may inadvertently bias established players and artificially raise barriers to entry for new competitors and startups.
Pauraque does not describe what taxonomy ought to be used for people to describe attributes or for marketers to make them aware or engage them with their solutions. For example, in our shipping example above, should the attribute be “shipping,” “mailing” or “delivery services”? What level of granularity helps best match marketers’ solutions to the individual’s needs?
Pauraque suggests that a k-anonymity threshold will be applied per attribute, but does not describe how the array of attributes itself can be a unique identifier. For example, there may be only one organization in a given city at a given time that is interested in shipping and Kosher food delivery services. If the individual sourcing these services has declared such an interest to one vendor, then this unique combination could be re-identified if both attributes were made available via their web client on any given site. Of course, the mere possibility of re-identification should not be a deciding factor alone, especially if the recipients of the information have made obligations on their privacy policy about inappropriate re-identification of pseudonymous personal information.
Pauraque does not address the decision process whereby content is often matched based on correlations to information that itself does not directly describe the service being advertised. For example, a shipping service may have found a correlation for business users that have the “Kosher food delivery service” attribute, such that the user would not know that by removing the “Kosher food delivery service” will impact receiving shipping ads from this shipping service. Even if such attributes were made known (e.g., the user sees a “shipping“ ad that was matched due to “Kosher food delivery service”), the user may wish to continue to receive “Kosher food delivery service” but not shipping ads. Thus, removing attributes is an imprecise method of signaling a desire to stop seeing shipping ads or shipping ads from a particular brand.
The proposal moves per-organization attribute storage to the client, which will use greater client storage than needed at present. This forces people to absorb the cost of B2B storage and processing, that may require them to update older devices to continue to access ad-funded sites.
As with other user-controlled attribute proposals, Pauraque confuses the concern people have regarding receiving output content with the attribute data input that may or may not have been used to match the content. If someone would prefer not seeing running shoes, removing “sports” or “shoes” from their profile does not prevent matching on current context, geography or even registration data. To more directly address such user concerns, these proposals could be improved by storing sets of “paused” ads or brands, rather than unlimited number of potential inputs that might lead to the unwanted content.
Open Questions
- How will any interests scale if each organization wants its topic information to remain proprietary?
- As there are millions of organizations, if each is assigning custom nodes what is the impact on local storage or classification process of interests?
- How many organizations can be allowed from a given sandboxed element without impacting user experience?
- Is the allow setting at a controller (e.g., marketer) level or at a vendor (e.g., verification vendor) level?