Comments (13)
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.
@roistaboola Just following up on this.
from attribution-reporting-api.
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.
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.
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.
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.
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.
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.
@roistaboola Just following up on this.
from attribution-reporting-api.
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.
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.
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.
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)
- <script src="https://platform.linkedin.com/badges/js/profile.js" async defer type="text/javascript"></script> HOT 2
- کیف پول نات کوین
- Attribution & Contribution reporting HOT 3
- Online-to-Offline attribution
- Nd HOT 1
- 89ec73911c9a2bb9 HOT 1
- احرازهویت دومرحله ای HOT 1
- Consider omitting Attribution Reporting request headers when there is none attribution support HOT 4
- Proposal for registering triggers in S2S
- Non valid reports of type "trigger-unknown-error" HOT 1
- Allow capping aggregated contributions for buckets HOT 6
- https://github.com/WICG/attribution-reporting-api
- https://github.com/WICG/attribution-reporting-api
- Fail to report click data from cross-origin subframe using ARA HOT 2
- Event-level report prioritization and deduplication interact unintuitively
- Jordan
- Scopes explainer should elaborate on reasoning for deletion logic
- Specification is inconsistent with regard to handling of non-monotonic time
- Specification conflates optional parameters with required ones that are nullable
- https://chromestatus.com/feature/5762222527610880
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from attribution-reporting-api.