I may be missing something, but I am not convinced that this API is necessary? Let’s assume that third-party cookies are gone, fingerprinting is blocked, redirects are not permitted, and the ad-tech industry has given up on trying to track users across domains. Even then, the ad-tech industry could implement better conversion measurement using the remaining, currently existing APIs than will be provided by this new API (or the Apple alternative). We have the following ad-tech players:
• The publisher (P)
• The advertiser (A)
• The user (U)
• The ad platform/supply side platform (SSP)
• The demand side platform (DSP)
P uses SSP to place ads on their site (nothing changes from today, except that SSP doesn’t have a cross-site identifier for U, so ad personalization is based solely on U’s interactions with P, which P knows because of their first party cookie, UP, containing P’s ID for U). SSP holds an auction for the ad. DSP wins bid for A’s ad, X (summer promotion for widget W). SSP serves X to P (recording ad instance AI). DSP and SSP record AI, X, A, P, DSP/SSP (and perhaps details about interactions derived from UP that influenced the bid) to backend databases.
X is viewed on P by U, then clicked by U. Link takes U directly to a landing page L on A. A generates a first-party ID, UA, for U, if U does not already have one, storing UA in a first-party cookie. The ID for X is embedded in L (as a query parameter or in the path or a sub-domain). A has browser fire a pixel to DSP and SSP that notifies them of the click and includes UA, X and the eTDL+1 of P (obtained from the stripped down referrer). Note this does require changes to A’s site compared to their implementation today, changes which are not required with your proposal. Smaller advertiser’s may not be able to implement this, but in most cases, their DSP should be able provide the necessary code.
There is also nothing stopping L from containing AI, which could then be included in the pixels sent to the DSP and SSP. This would allow them to link UM and UP, but we’ll assume A doesn’t provide AI to them, because these parties are not attempting cross-site tracking. (However, in practice I don’t see any way to prevent AI or X from being embedded in L, where L leads the user to the correct landing page on A. Safari attempts to make this harder by reducing the lifetime of UA, if it is created client-side after arriving via a link with query parameters).
When a conversion occurs on A, A can directly pass the conversion to the DSP and/or SSP, including the type of conversion, the value of the conversion and UA (all values with zero fuzziness or randomness). If A does this via the browser using a pixel, then A may encode the value of the conversion in such a way as to hide it from the user, but that is completely up to A and DSP/SSP. If A does a server-to-server call, then that conversion report is completely out of the control of the browser. The DSP and SSP can then associate this conversion with all ads clicked on by UA, including X. They can then compute attribution based on last-click, first-click, all recent clicks, or more advanced techniques. DSP/SSP can use the full ad history for this user, across multiple conversions, rather than having an arbitrary limit on the number of conversions that an ad click can contribute to.
Note that if the user has opted out of first-party cookies on P, then UP isn’t created and the user gets less-personalized ads (only those related to the site and current page), but everything else works. If the user has opted out of cookies and A, then they may find it difficult to place an order as a cookie might be needed for their cart. However, GDPR and similar laws might still allow A to use cookies that don’t uniquely identify the user (block storage of UA, but not other cookies), such that A could still do conversion reporting. To handle this situation, A could store in a first-party cookie the list of ads the user has clicked on to arrive at A, including X. When a conversion occurs, A would report this conversion to the DSP/SSP with the list of ads that contributed to the conversion, but this would now be anonymous.
SSPs will dislike the above solution, because their revenue is based partially on clicks and if redirects are disallowed, then they have to rely on A to report clicks and it will be cheaper for A if they don’t. So as long as redirects are supported, I would expect that SSPs will use them. In this use case, though, the SSP only knows that X was clicked by UP, but still needs the pixel callback from A to associate X with UA for attribution purposes.
As long as the above is feasible, I don’t see the ad tech industry adopting your more restrictive proposal, and the current proposal from Apple offers so little value to ad-tech that I don’t think they would ever adopt it. I’m not trying to be pessimistic and I would really like to come up with better solutions than we have today. However, I am worried that the current browser privacy efforts are going to drive many in ad-tech into even more privacy compromising alternatives. Obviously fingerprinting is an example that you’re also working to eliminate and I fully support that effort. What I am seeing though is that publishers are moving toward requiring a “free” login in order to access content/services. When logging in with Facebook, Google, or an email address, they then take a hash of the email address (or of an ID from a DB of all accounts known to be associated with the individual) and store it in a first party cookie. The corresponding first-party cookie ID on all sites visited by the user will have the same value, so tracking continues as it does today with third-party cookies. In some ways, it is even worse, because now the ID will be consistent across all of the user’s devices and browsers (including private browsing if they have to login). The one benefit is that at least the user has to consent to provide the cross-site ID, and may not be willing to provide it on sites they rarely visit or don’t trust.
As a side-note, I am working on a new proposal for privacy preserving ads (including personalization and conversion reporting). I hope to share it soon.