Giter Site home page Giter Site logo

Comments (13)

apasel422 avatar apasel422 commented on September 8, 2024

Thanks for the request.

The source, if any, that the trigger is ultimately attributed to is unknown at the time of trigger registration, so there's no way the browser can provide the information you're asking for in a request header.

Additionally, even if the browser did know the source in question, it could not use that information to dynamically choose between processing the web trigger or the OS trigger because doing so would leak whether such a source existed for the unchosen platform, which would violate the API's privacy model.

That said, an OS trigger can only be attributed to an OS source, and a web trigger can only be attributed to a web source. If you want to be able to register using either platform (independent of whether a corresponding source actually exists), you can have a response like

Attribution-Reporting-Register-Trigger: ...
Attribution-Reporting-Register-OS-Trigger: ...
Attribution-Reporting-Info: preferred-platform=<platform>

where <platform> is either os or web. However, the registration used is solely based on the preferred-platform value and the browser's support, and does not dynamically depend on the attributed source (which, again, is unknown by the browser at this point in the attribution flow).

If you must be able to know ahead of time which type of registration to perform, you could use two reporting origins, e.g. https://web.example and https://os.example, and use only web registrations on the former and only OS registrations on the latter. In other words, you could segregate your registrations based on platform.

If I'm misunderstanding your request, feel free to clarify.

from attribution-reporting-api.

apasel422 avatar apasel422 commented on September 8, 2024

@roistaboola Just following up on this.

from attribution-reporting-api.

roistaboola avatar roistaboola commented on September 8, 2024

Hi @apasel422 Thanks for getting back on this one.
Have tries responding with the 3 header as suggested, however it did not produce the result hopped for.

Here are the tested scenarios:

#1:
Responding with following headers,
the chrome://attribution-insternals/ 'OS Registration' tab did not present the OS trigger:

Attribution-Reporting-Register-Os-Trigger: "https://trc.taboola.com/attribution-reporting/attribution_trigger?sdk_atw=yes"

Attribution-Reporting-Register-Trigger: {
"event_trigger_data" = (
{
"trigger_data" = 1;
}
);
}

Attribution-Reporting-Info: preferred-platform=os

#2:
Responding with these headers, the chrome://attribution-insternals/ 'OS Registration' tab did not contain the OS trigger::
Attribution-Reporting-Register-Os-Trigger: "https://trc.taboola.com/attribution-reporting/attribution_trigger?sdk_atw=yes"
Attribution-Reporting-Info: preferred-platform=web

#3:
Responding with these headers, the chrome://attribution-insternals/ 'OS Registration' tab did contain the OS trigger::

Attribution-Reporting-Register-Os-Trigger: "https://trc.taboola.com/attribution-reporting/attribution_trigger?sdk_atw=yes"
Attribution-Reporting-Info: preferred-platform=os

#4:
Responding with these headers, the chrome://attribution-insternals/ 'OS Registration' tab did contain the OS trigger::
Attribution-Reporting-Register-Os-Trigger: "https://trc.taboola.com/attribution-reporting/attribution_trigger?sdk_atw=yes"

@apasel422 am I missing anything here ?
Is there another headers settings that provides for both OS & Web source registration ?

Thanks !

from attribution-reporting-api.

apasel422 avatar apasel422 commented on September 8, 2024

What browser version are you using? For Chrome, preferred-platform is available starting in M124.

Also, your Attribution-Reporting-Register-Trigger header in (1) is not valid, though I'm not sure that matters for the purposes of this issue.

from attribution-reporting-api.

roistaboola avatar roistaboola commented on September 8, 2024

Hi @apasel422
chrome version is 124.0.6367.54

Thanks for noticing. I've corrected the Attribution-Reporting-Register-Trigger header, repeated test #1 having preferred-platform=os and run test #5 having preferred-platform=web ::

test #1:
Responding with following headers,
the chrome://attribution-insternals/ 'OS Registration' tab did present the OS trigger:

Attribution-Reporting-Register-Os-Trigger: "https://trc.taboola.com/attribution-reporting/attribution_trigger?sdk_atw=yes"
Attribution-Reporting-Register-Trigger: {"event_trigger_data":[{"trigger_data":"1"}]}
Attribution-Reporting-Info: preferred-platform=os

test #5:
Responding with following headers,
the chrome://attribution-insternals/ 'OS Registration' tab did not present the OS trigger:
Attribution-Reporting-Register-Os-Trigger: "https://trc.taboola.com/attribution-reporting/attribution_trigger?sdk_atw=yes"
Attribution-Reporting-Register-Trigger: {"event_trigger_data":[{"trigger_data":"1"}]}
Attribution-Reporting-Info: preferred-platform=web

As it goes, it is still required to identify if is OS or Web at handling the action and returning the 'preferred-platform' value.

Is there a response headers pattern that provides for both OS & Web registration ?

Thanks.

from attribution-reporting-api.

apasel422 avatar apasel422 commented on September 8, 2024

test 5:
Responding with following headers,
the chrome://attribution-insternals/ 'OS Registration' tab did not present the OS trigger:

This is expected, as preferred-platform=web tells the browser to not even bother inspecting the Attribution-Reporting-OS-Trigger header.

Is there a response headers pattern that provides for both OS & Web registration ?

No, a single response can register using web or OS, but not both.

Could you elaborate on why you need to register both?

from attribution-reporting-api.

roistaboola avatar roistaboola commented on September 8, 2024

This is the app-to-web case, a user may click an ad at the SDK app, or can click an ad at a web site.
either way, the user gets to the advertiser web page (chrome) where the conversion action takes place.
as the click (source) might have been generated at either platform, the response should apply for both.

from attribution-reporting-api.

apasel422 avatar apasel422 commented on September 8, 2024

This is the app-to-web case, a user may click an ad at the SDK app, or can click an ad at a web site. either way, the user gets to the advertiser web page (chrome) where the conversion action takes place. as the click (source) might have been generated at either platform, the response should apply for both.

Can you distinguish the two platforms using something in the URL? For example, on web you could have:

<img attributionsrc="https://x.example/register-trigger?platform=web">

and in an app you could have

<img attributionsrc="https://x.example/register-trigger?platform=os">

and then vary your response based on the platform query parameter.

from attribution-reporting-api.

apasel422 avatar apasel422 commented on September 8, 2024

@roistaboola Just following up on this.

from attribution-reporting-api.

roistaboola avatar roistaboola commented on September 8, 2024

Hi, we hopped an indication could be fetched based on the source inventory that is available at the OS & web and have it reported at the action request. can that be considered ?

from attribution-reporting-api.

apasel422 avatar apasel422 commented on September 8, 2024

Hi, we hopped an indication could be fetched based on the source inventory that is available at the OS & web and have it reported at the action request. can that be considered ?

Per #1240 (comment), this would violate the API's privacy model.

from attribution-reporting-api.

apasel422 avatar apasel422 commented on September 8, 2024

Another option here would be to try to register both a web trigger and an OS trigger using a self-redirect, i.e.

Attribution-Reporting-Register-Trigger: ...
Location: /register-os-trigger

followed by

Attribution-Reporting-Register-OS-Trigger: ...

from attribution-reporting-api.

roistaboola avatar roistaboola commented on September 8, 2024

Thanks technically this might work, however we are not using redirection for the web trigger, and not sure we would like to redirect, we will look into whether the request itself can indicate the headers that need to be returned.
can close this ticket. thanks

from attribution-reporting-api.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.