I’m Alan Chapell. Over the past 20+ years, I’ve been outside privacy counsel to hundreds of digital media companies and write a monthly syndicated report called The Chapell Regulatory Insider. I’m also a regulatory analyst for The Monopoly Report.

Editor’s Note: This week, in addition to the podcast interview with Thomson, we’re sharing the Q&A notes, which go into additional depth in a variety of areas. We’ve resisted the temptation to attempt to counter some of Martin’s positioning on these pages, although Alan does so on the podcast. We are reprinting the Q&A with only light edits, and would strongly encourage you to listen to the podcast and review the comments provided via Github to get a more complete sense of Alan and Martin’s views. Hope you enjoy!

Alan: For my listeners who haven't followed the W3C’s Private Advertising Technology Working Group, give us the elevator pitch explanation for the Attribution API. What problem does the Attribution API solve that traditional forms of attribution in digital media (cookies, fingerprinting, and server-side attribution) do not?

Martin: A browser is in something of a unique position when it comes to helping ad measurement.

Traditionally ad measurement has taken something of a self-service approach. You see this in how third-party cookies and fingerprinting are used. Ad tech worked out how to take what they needed.

But the problem with that approach is that it depends on people’s online activity being something of an open book. Or it creates that situation, it’s hard to really know what cause and effect look like there. Either way, it’s a bit of a privacy nightmare. Browsers would like to be able to promise people that their activity on one website is not made available to other websites.

Of course, browsers end up seeing everything, so they could be very helpful in providing cross-site measurement. Attribution is browsers saying “we can help, but here are our terms.” That means that we have strong safeguards that prevent sites from using the API to recover your browsing history. The design intentionally gives people a lot of control over how their browser participates.

How does the Attribution API differ from Google's Privacy Sandbox attribution work, which also went through the W3C, and from the earlier IPA and PPA proposals? What did you learn from those efforts that shaped this one?

There are two main efforts in this area: Apple was the first to provide ad measurement, with Private Click Measurement (and a similar facility on iOS). That attempted to provide privacy essentially by not being very good. Limited information and long delays are the main “features.” The privacy ended up being not stellar. Google’s Privacy Sandbox included a more capable version of that same basic event-based design, using differential privacy, but the privacy was much worse.

The aggregated Attribution Reporting API in Google’s Privacy Sandbox isn’t fundamentally different from Attribution. It’s tuned differently, but anyone familiar with that should have a good idea of what to expect.

PPA is just an old name for this API.

IPA was a more ambitious effort. For us, this collaborative effort with Meta was so strange and wonderful — Mozilla and Meta are so often at odds — but the team there was great to work with. We produced a design and implementation that was clever and overall quite solid, all using the same privacy design. But we ultimately failed to get agreement on aspects of that design, despite it addressing some real shortcomings in the current approach. Maybe one day we’ll get there, who knows.

If this proposal didn't exist, what's the realistic alternative the industry lands on — and is it better or worse for the average person than what you're building?

The basic problem in the space of ad measurement is that there is a hard tension between the quality of measurement and privacy. Comprehensive tracking gives decent measurements, but it sucks for privacy. Full privacy — which is probably not achievable in practice — makes it virtually impossible to get useful measurements.

What we learned from previous attempts is that the midpoint tends to be very bad on both measures. Any attempt to back away from the panopticon approach leads to terrible measurement quality, but doesn’t help that much with privacy. The same in the other direction.

If you want to be strictly mathematical about it, participating in measurement has some privacy impact. But we think the actual meaningful impact on privacy is negligible.

Alternatives from the industry look far worse. They often involve asking people for email or phone numbers. This can work for some advertising objectives and interactions, but it leaves a lot to be desired in terms of measurement quality. That’s far worse for people. It’s annoying, because being badgered is annoying, and you always know that sharing contact information inevitably leads to more spam.

I think that there is also a fair expectation that this data, once handed out, is on the open market pretty promptly. No one believes the promises that companies make.

I’ve been pretty critical of the way PETs have been implemented in the ads space. The Privacy Sandbox is kind of the poster-child where my core issues are: First, the privacy or other benefits are a bit opaque. And second, there isn’t an earnest discussion of the tradeoffs in play. We can get into specifics in a bit, but at a high level, I’d love it if you’d walk us through what you see as the privacy wins in the spec: on-device attribution, aggregation, differential privacy noise. Where does the design actually move the needle versus the status quo? Why are those privacy wins important, how are they being measured?

You are absolutely right to be critical. PETs have great potential in theory, but the practice is pretty bad. Lots of using PETs to dress up real privacy abuses.

Attribution is very much a PET, but it differs from industry efforts in a key way: how it distributes control. That, for me, is how you determine whether someone is serious about their privacy technology.

The question I start with when it comes to any PET is not so much about the information flows. It is who decides. That is, whatever it does, who is truly in control?

That means asking who decides how the system operates, with what, and to whom is it accountable?

In Attribution, we have several layers of answers to the basic question of who is in control. The first is about the overall shape of the system. That’s decided at the W3C, which has a decent track record of putting end users first. Browsers will also ultimately decide who is trusted to do aggregation. Those are answers we can give that are rooted in governance. There will be procedures and rules and reports and all that boring stuff.

Of course, governance like that is not exactly accessible. So those systems only exist to support the main answer, which is that the end user is the real decider. If your browser ships with the Attribution API, there will be a switch that allows you to turn it off (or maybe even down). And we protect that right, because there is no way anyone can be punished for their choices, because sites can’t know what the decision was.

That philosophy underpins the entire design. Attribution gives sites a way to query a cross-site database. Without constraints, that would be bad for privacy. So the people whose data fuels this remain in control. Not through some annoying cookie banner, but through having a functioning off switch.

All the design features we use (aggregation, DP, etc.) are all in service of bounding the privacy cost, but ultimately those are just the guardrails. The W3C is really only shaping those guardrails. The design fundamentally is geared to protect user agency.

What do you see as the tradeoffs in play with respect to the Attribution API (Assuming there must be some.) Were there any which were particularly difficult for you to swallow?

For folks using this API, I’m sure that the question of the epsilon parameter will be high on their list of concerns. Or maybe the size of histograms we are able to support.

Those are second-order concerns for me. Most of what we have I’m happy with in its present state, while acknowledging that there are a lot of unknowns that we won’t learn about until it gets used out there in the wild.

The most difficult decisions we had were around scoping. IPA had some nice features that we did not keep. For instance, IPA had what I think is a good story for conversion stealing, but the complexity of that approach — both in engineering it and in the nature of the agreements that need to be penned — was rightly considered a bit much.

Differential privacy is the headline feature. How does that and other features map against user perceptions? (e.g., user research found that consumers may not view these types of systems as a privacy benefit — is that simply a consumer education issue or is there some validity behind it?)

I’m aware of that research. And it’s entirely fair for people to look at differential privacy and reach a somewhat negative conclusion. There is a lot about differential privacy practice that doesn’t serve end user needs. And some people will conclude that it doesn’t serve them here either. That’s fair. That’s exactly the sort of decision we aim to support.

But DP remains the best tool we have for getting verifiable guarantees. The mathematical rigor we get is key to being able to make people firm promises. Given a goal of putting people in control of their online experience, then those promises are something DP helps us deliver.

However, I want to stress that differential privacy is not the only tool we use. The aggregation design is part of the response, and there are anti-abuse measures too.

Apple, Google, Meta, and Mozilla all have editors on this spec. One might look at that roster of companies and think that there’s some "incumbent coordination" taking place. What does Mozilla (with a relatively small albeit growing ads business) get out of being at this table?

Mozilla sees the positive potential of advertising to support the health of the Internet. It can be an equitable way to support online services. Advertising has a terrible track record on privacy, but that doesn’t mean that it can’t do better. Our interest here is in guaranteeing that people, not businesses, determine what is acceptable.

As far as incumbent coordination goes, I’ll be the first to acknowledge the high costs of participation in the development of a standard like Attribution. So it is understandable that well-resourced companies are able to invest the most effort.

The companies with deeper pockets are shouldering the burden of doing the work, but it’s far from the case that this work was exclusively determined by that small set of companies. It’s an open process, and there have been many smaller entities involved in the decision-making process.

What is the value of having standards bodies policing the privacy harms of interoperability? Is the long-term goal for this (or similar) standards to be addressing privacy harms in other contexts? (e.g., the harms that may or may not happen behind the walls of a few dominant platforms?)

“Interoperability” is such a loaded term in this context. It took me a long time to understand that my use of the term does not align with the way in which it is used in the advertising industry. Understanding that we have such a key word in common, with such a deceptive and subtle difference in meaning unlocked a lot for me. I know what you mean, and I could go on at length about how much damage that word — and the practices it describes — has done. But we really  don’t have the time.

I can’t speak for others here, because that’s not generally something that gets agreed between different people in standards. We each have our own reasons for coming to a project. Those reasons can often be set aside, provided that we agree on outcomes.

Going into this project, I had such grandiose dreams. We’d give end users the reins, so that we can demonstrate that it is possible to give people far more direct control over the systems in the world that affect their privacy.

I still think that’s a worthy goal, so it will continue to be a large factor in other things we build, but I’ve gained a greater appreciation of the role of other actors in the system. It’s not enough to give people that power; it needs to be an effective control.

I’ve gained an appreciation (and no small amount of distaste) for the governance processes that make it possible to create those levers. It shouldn’t come as a surprise that privacy is complicated and the tools that work for online advertising don’t fit as well in other contexts. When developing standards for the internet, we only deal with a tiny part of that complexity. For instance, gaining an appreciation for how governments deal with multiple industries has tempered my expectations there.

Critics in the research field argue that the spec standardizes an observational attribution framework that cannot distinguish correlation from causation—that it measures association, not incrementality—while the spec's own language promises to identify "effective" advertising. Is that a fair critique? And what steps are you and your colleagues taking to overcome those challenges?

I’ve had some constructive back and forth with Rick Bruner who has been the most vocal of the critics here. I think that there was (and probably still is) a bit of a conceptual gap more than there is a fundamental problem. And maybe an issue in how we presented the work.

My experience with Attribution is that it genuinely can drive the creation of more effective advertising. Rick makes the point that you can’t just do attribution and magically get information that makes advertising better. Attribution only gives you information. You need to structure that information in a way that allows you to use it effectively.

Attribution is a tool that you need to integrate into good experimental design. Use it poorly, and you can convince yourself of just about anything, with very little relation to reality. My sense is that ad techs believe the same: that Attribution can help deliver better results for advertisers.

If you had to name the single design decision in this spec you're least certain about — the thing that (at least metaphorically) keeps you up at night — what is it?

There are obviously aspects of the design that I think could be better, but the thing that concerns me most is how it will be received by people. The entire design is structured around giving people the necessary control, but ultimately we know that some people are vehemently opposed to anything that their browser might do that helps advertising in any way.

I am confident that the design delivers on that promise, but for some people that’s never going to be enough and even implementing something like this will be seen as a betrayal. We know that strongly polarizing positions end up getting a lot of traction in the modern media environment.

Critics raise a structural concern that these systems systematically favor lower-funnel channels — search, retargeting, retail media — because they sit closest to the conversion. Does the API bake in a bias that disadvantages brand-building and premium publishers?

I want to acknowledge that there are limitations in our approach that very much could lead to certain biases. A lot will depend on how this new tool ends up being used.

A big one here is that this can only see what happens in a browser. A lot of the efforts with brand awareness happen in places that this simply cannot touch. This is not going to be able to help measure brand awareness campaigns that rely on other mediums.

How this new tool can be used to account for effects outside of those obvious lower-funnel interactions is something that I don’t have a lot of information on right now. The general sense I get is that businesses are going to need to spend some time learning before we’ll have good answers.

I hear that people are concerned that dominant players might seek to use measurement to further entrench their market position. I’m sorry to say that we don’t have easy answers to that one. Of course they will if they can get away with it.

The spec indicates that fraudulent impression registration is an open problem, because impressions sit on the device where no server can vet them. Don Marti and other critics take that further — arguing that it creates an incentive to front-run conversions, to sneak an ad in front of someone already about to buy. Is that risk real, and what stops it?

It’s real, but it might be overblown. The delegation design we have allows a DSP to manage when impressions are saved. That can limit exposure to untrustworthy sites that attempt to snipe conversions.

The one thing that the IPA had over this was the ability to retroactively remove IVT from impressions. Here, we acknowledge that limitation, but that is a constraint on its (successful) use, not something we regard as a fatal flaw.

My understanding is that Mozilla shipped an early version of the spec and enabled it by default, which drew some backlash. What did you learn from how that landed, and would you do the consent question differently today?

Not a lot to say here yet. Firstly, it’s important to point out that nothing was ever turned on in relation to the toggle that we shipped.

It was supposed to help us learn about how the API worked. We learned a lot about something else instead.

It’s funny, almost the same day, Apple announced that they were enabling their Private Click Measurement API in Private Browsing modes. Not a peep in the media on their side.

If you need evidence that Mozilla is special, that might be the best anecdote I have. Because the trust we build with our users is not unconditional; we really have to deliver.

I’ve been using an urban planner Robert Moses analogy lately where the infrastructure being created by standards bodies can be policy choices. Are there design decisions in the spec that you kept some level of optionality so that future engineers can change them?

Funny that you use lessons from building something like urban planning. That seems so much more immutable than the Internet.

But the analogy is sound. The history of the internet is littered with incautious choices that last decades. Cookies are a great example. The choices made in standards can and do affect the architecture of society. At least a little.

As for any specific choices, we’re drawing on a lot of experience about how to build for the web here. So there’s far less of this design that is baked in like that. What ultimately ends up being the unchanging infrastructure and what ends up being mutable will be determined more by how it ends up being used.

In short, I’ve learned that every decision needs to be one that can be unmade. What can’t be unmade is the decisions that the market/community/world-at-large makes for you. The ones you didn’t anticipate.

If this proposal is successful, what does the digital media world look like in a few years? 

I’d like to see a whole lot less tracking, collection of email/phone numbers, clean rooms, and the other bullshit privacy apparatus that the advertising industry created.

In practice, however, I don’t expect this to change anything significantly. Success here means that some businesses decide that this is enough. That they can get enough information from attribution without having to resort to those other things. If it is only a few who change, that’s a win.  

The IAB Tech Lab's AdMap and Project Rearc, and the experimental-design approaches from groups like Central Control, take a very different path — one compatible with Right to Know requests. What difference / advantages does a browser-native standard have over some of the other efforts?

I hope that the points I’ve made about end user control make it clear why it is hard for us to take AdMap seriously. As a whole, Rearc doesn’t represent a vision that is compatible with our vision for Attribution. It is more geared towards preserving control in the hands of advertising businesses and dealing with the consequences of that.

Critics have indicated that the privacy-budget mechanism favors large platforms whereby a single mistaken query can lock a small advertiser out, a constraint only a dominant firm could enforce. Does the design assume a power imbalance between platform and advertiser, and if so, does it entrench one?

I want to acknowledge that this is one of the hard parts. Large platforms have more data to use, so they are able to slice that data in more ways than the little guys. With noise, you can’t slice what you get into thousands of pieces unless you have many thousands of people involved. Or, more likely millions. Small players need to be more careful and make fewer queries. And a mistake will wipe out more of their potential learnings as a result.

On top of that, big players will be better able to develop the discipline necessary to get more out of the system. More people, more resources, all that.

We spent a lot of time thinking about this problem. But we concluded that this was one area where attempting to levy a technical control was unwise. Competition law — as ineffective as it has been in stemming the rise of monopoly power in this market, and others — has a better suite of tools available than we do.

Right now, the best I can say is that there are no structural advantages provided to large players, other than what they obtain naturally. I understand that this might be disappointing, but it’s the pragmatic outcome in this case.

Martin, thanks so much for your time.

If there’s an area that you want to see covered on these pages, if you agree or disagree with something I’ve written, if you want to tell me you dig my music, or if you just want to yell at me, please reach out to me on LinkedIn or in the comments below.

Blink and you’ll miss it. That’s true of summer, but it’s especially true for Marketecture Live: Chicago early bird pricing.

This fall, we're bringing Marketecture Live to the heart of the Midwest: Chicago. The Windy City serves as the hub for brand, retail, and media innovation, where the industry's biggest shifts are happening in real time.

If you’ve been wanting to attend Marketecture Live but find NYC to be out of range, meet us in Chicago on Sept. 23. Don’t miss your chance to lock in your seat and the lowest price of the season today.