Request to .well-known endpoint from Step 2 vs Step 3

[HeyMultiverse]

Hello Team,

When a valid conversion happens, search.example does a redirect in step 2, by setting the Location header to the .well-known endpoint. The browser could, potentially, follow-through this redirect by making a request to the https://search.example/.well-known/ad-click-attribution with the conversionData and priority. Eg: Step 2 redirect Location (using the same example values) https://search.example/.well-known/ad-click-attribution/20/12 while 20 is the conversionData and 12 is the priority. This happens within few seconds after the actual conversion event.

For the same conversion, by the virtue of step 3, there will be a request originating from browser in 24-48 hours as HTTP POST to attribute the conversion event that contains the conversionData and campaignID. https://search.example/.well-known/ad-click-attribution/20/55.

On the server(search.example) for .well-known endpoint, how do we differentiate the request originating out of the step 2 and step 3, given that both follow the same route pattern with similar ranges for query parameters 0-63?

[johnwilander]

Hello Team,

When a valid conversion happens, search.example does a redirect in step 2, by setting the Location header to the .well-known endpoint. The browser could, potentially, follow-through this redirect by making a request to the https://search.example/.well-known/ad-click-attribution with the conversionData and priority. Eg: Step 2 redirect Location (using the same example values) https://search.example/.well-known/ad-click-attribution/20/12 while 20 is the conversionData and 12 is the priority. This happens within few seconds after the actual conversion event.

For the same conversion, by the virtue of step 3, there will be a request originating from browser in 24-48 hours as HTTP POST to attribute the conversion event that contains the conversionData and campaignID. https://search.example/.well-known/ad-click-attribution/20/55.

On the server(search.example) for .well-known endpoint, how do we differentiate the request originating out of the step 2 and step 3, given that both follow the same route pattern with similar ranges for query parameters 0-63?

I’m not married to path parameters and we’ve already discussed moving to a json structure in the body for step three (see #30).

However, the two requests are easy to tell apart since step 2 is an idempotent GET and step 3 is a (potentially) state changing POST.

[HeyMultiverse]

Thanks for John for clarifying that.

It would be really good to have path parameters removed from Step 3, and made as request payload. Do you have a timeline that you tracking for this being generally available ?

[johnwilander]

Thanks for John for clarifying that.

It would be really good to have path parameters removed from Step 3, and made as request payload. Do you have a timeline that you tracking for this being generally available ?

I was hoping for more engagement from the Google folks on how to layer our two proposals. Maybe they are waiting for something from me? I'd prefer to make changes to our implementation once we've settled on the interoperability issues.

[hober]

Duping to #30.