Offer same-site pixel "API" as alternative to a JavaScript API

[johnwilander]

We should offer a same-site pixel "API" on the attribute-on side of PCM to 1) remove the dependency on third-party pixels, and 2) not introduce a dependency on JavaScript. During a recent Privacy CG call, at least three people brought up that some advertisers/merchants/click destinations are very reluctant to deploy JavaScript for attribution purposes. So I suggested that we match the functionality of the JavaScript API (or parts of it) with a same-site “pixel” way of triggering attribution.

[annevk]

I wonder if instead of a .well-known request this could be a <meta> element that captures the conversion. This could be included on the (presumably static) conversion page and once the user agent appends it to the document it would register the conversion.

[johnwilander]

I wonder if instead of a .well-known request this could be a <meta> element that captures the conversion. This could be included on the (presumably static) conversion page and once the user agent appends it to the document it would register the conversion.

Thanks, Anne! Now I see what you're saying. I don't think this would work because many advertiser sites want to trigger attribution for events beyond page loads. It could be for clicks to add something to a cart, for reaching a certain level of engagement such as level N in a game or configuring a car, or for stages in a checkout flow. So whatever we build has to support in-page events.

[annevk]

How would you have those kind of events without navigations or JavaScript?

[jackfrankland]

Presumably in order for the pixel to be dynamically added to the page it would require some JavaScript right? If the pixel/tag is injected with a tag manager to avoid develoepr involvement, I think it's just as easy for the tag to be a script which interfaces with the JS API. This isn't to say it couldn't also be an img tag, but I don't see much benefit.

Having an additonal meta tag makes more sense to me, where the page's loading signifies a conversion itself (i.e. order confirmation page), and doesn't require JS or a tag in a tag manager.

[johnwilander]

How would you have those kind of events without navigations or JavaScript?

I don't think these pages are free of JavaScript. It's just that they don't want to include any JavaScript someone else hands them. That was my interpretation of it. I don't know if they generate markup in script or pull in markup from servers. @kdeqc, would it work if we tie this alternative "API" to page loads?

[kdeqc]

Sorry - didn't catch this earlier. To answer, though, the pages typically do have JS, but adding someone else's JS is seen as a bit of a security risk and/or sometimes difficult to debug. The folks who often manage ad campaigns and such aren't generally web developers so it can be an extra challenge for some folks too.

[annevk]

I feel like I'm still missing something. Why would they not be handed data that can be passed into the API? Why does the data have to be markup that is injected into the page that then does a well-known request? Maybe someone can explain the full setup here?

[johnwilander]

I'll let Kristen speak to merchants'/site owners' willingness to deploy pixels vs JavaScript calls. As for the request and required redirect, it actually gives the site owner a chance to control who can trigger attribution. Their server gets the final decision on any conversion triggered by the same-site pixel, or at least has a chance to make the final decision. That's different from a JavaScript API which any code on the site can call without the site owner's knowledge. You could even have rogue web extensions call such an API.

Those are the pros and cons we've discussed. I personally like the fact that a pixel "API" has zero risk of causing interoperability issues with browsers who don't support PCM or Attribution Reporting API. No feature detection or such needed. I.e. it has maximum chance of being easy to adopt.