From f86afa18908e958d11f093d669d9f9043c4d6ddc Mon Sep 17 00:00:00 2001 From: Anton Bershanskyi Date: Sat, 27 Jun 2026 13:32:47 +0300 Subject: [PATCH] [Guides] Delete guides for Attribution Reporting API --- files/en-us/_redirects.txt | 3 + .../generating_reports/index.md | 358 ------------------ .../api/attribution_reporting_api/index.md | 8 +- .../registering_sources/index.md | 289 -------------- .../registering_triggers/index.md | 232 ------------ .../htmlanchorelement/attributionsrc/index.md | 2 +- files/en-us/web/api/htmlimageelement/index.md | 2 +- .../htmlscriptelement/attributionsrc/index.md | 2 +- .../en-us/web/api/htmlscriptelement/index.md | 2 +- files/en-us/web/api/requestinit/index.md | 2 +- .../setattributionreporting/index.md | 2 +- .../web/html/reference/elements/a/index.md | 2 +- .../web/html/reference/elements/img/index.md | 2 +- .../html/reference/elements/script/index.md | 2 +- .../attribution-reporting-eligible/index.md | 6 +- .../index.md | 10 +- .../index.md | 10 +- files/jsondata/GroupData.json | 6 +- 18 files changed, 27 insertions(+), 913 deletions(-) delete mode 100644 files/en-us/web/api/attribution_reporting_api/generating_reports/index.md delete mode 100644 files/en-us/web/api/attribution_reporting_api/registering_sources/index.md delete mode 100644 files/en-us/web/api/attribution_reporting_api/registering_triggers/index.md diff --git a/files/en-us/_redirects.txt b/files/en-us/_redirects.txt index b88ee8c8c436b61..df19fed742a8aae 100644 --- a/files/en-us/_redirects.txt +++ b/files/en-us/_redirects.txt @@ -7937,6 +7937,9 @@ /en-US/docs/Web/API/Apps.mgmt.addEventListener /en-US/docs/Web/API/EventTarget/addEventListener /en-US/docs/Web/API/Apps.mgmt.removeEventListener /en-US/docs/Web/API/EventTarget/removeEventListener /en-US/docs/Web/API/ArrayBufferView /en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray +/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports /en-US/docs/Web/API/Attribution_Reporting_API +/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources /en-US/docs/Web/API/Attribution_Reporting_API +/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers /en-US/docs/Web/API/Attribution_Reporting_API /en-US/docs/Web/API/AudioBuffer.copyFromChannel /en-US/docs/Web/API/AudioBuffer/copyFromChannel /en-US/docs/Web/API/AudioBuffer.copyToChannel /en-US/docs/Web/API/AudioBuffer/copyToChannel /en-US/docs/Web/API/AudioBuffer.duration /en-US/docs/Web/API/AudioBuffer/duration diff --git a/files/en-us/web/api/attribution_reporting_api/generating_reports/index.md b/files/en-us/web/api/attribution_reporting_api/generating_reports/index.md deleted file mode 100644 index cbf5c7b49868707..000000000000000 --- a/files/en-us/web/api/attribution_reporting_api/generating_reports/index.md +++ /dev/null @@ -1,358 +0,0 @@ ---- -title: Generating attribution reports -slug: Web/API/Attribution_Reporting_API/Generating_reports -page-type: guide -status: - - deprecated ---- - -{{DefaultAPISidebar("Attribution Reporting API")}}{{deprecated_header}} - -This article explains how [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API) reports are generated — both attribution reports and debug reports — and how you can control the generated reports. This includes handling noise, prioritizing reports, filtering reports, and generating debug reports. - -## Basic process - -When a match occurs between a trigger and a source, the browser generates a report and sends it via an uncredentialed [`POST`](/en-US/docs/Web/HTTP/Reference/Methods/POST) request to a specific endpoint on the reporting origin: - -- For event-level reports, this is `/.well-known/attribution-reporting/report-event-attribution`. -- For summary reports, this is `/.well-known/attribution-reporting/report-aggregate-attribution`. - -The `` will be same-origin with the one that registered the source and trigger. - -The report data is contained in a JSON structure. - -## Event-level reports - -Event-level reports are generated and scheduled to be sent at the end of their containing **report window**. The length of the report window is determined by the values set in the [`"event_report_window"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Source#event_report_window) or [`"event_report_windows"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Source#event_report_windows) field set in the source's {{httpheader("Attribution-Reporting-Register-Source")}} header. - -If neither of these fields are specified, the report window falls back to the following defaults: - -- For [event-based sources](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#event-based_attribution_sources), the default report window ends at the source's expiry, which is set in the `Attribution-Reporting-Register-Source` [`"expiry"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Source#expiry) field. This defaults to 30 days after registration if not explicitly set. -- For [navigation-based sources](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#navigation-based_attribution_sources), the default report windows are 2 days, 7 days, and the source's `"expiry"`. - -See [Custom report windows](https://privacysandbox.google.com/private-advertising/attribution-reporting/custom-report-windows) for more details. - -Once an event-level report is received at the appropriate endpoint, how the data is processed, stored, and displayed is completely up to the developer. A typical event-level report might look like this: - -```json -{ - "attribution_destination": "https://advertiser.example", - "source_event_id": "412444888111012", - "trigger_data": "4", - "report_id": "123e4567-e89b-12d3-a456-426614174000", - "source_type": "navigation", - "randomized_trigger_rate": 0.34, - "scheduled_report_time": "1692255696", - "source_debug_key": 647775351539539, - "trigger_debug_key": 647776891539539 -} -``` - -The properties are as follows: - -- `"attribution_destination"` - - : A string, or an array of 2–3 strings, depending on whether the source was registered with multiple destinations or not. These strings represent the attribution [`"destination"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Source#destination) site(s) set in the source registration via the associated {{httpheader("Attribution-Reporting-Register-Source")}} response header. -- `"source_event_id"` - - : A string representing the attribution source ID. This is equal to the [`"source_event_id"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Source#source_event_id) set in the source registration (via the associated {{httpheader("Attribution-Reporting-Register-Source")}} response header). -- `"trigger_data"` - - : A string representing data originating from the attribution trigger, set in the trigger registration (the [`"trigger_data"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Trigger#trigger_data) set via the associated {{httpheader("Attribution-Reporting-Register-Trigger")}} response header). -- `"report_id"` - - : A string representing a [Universally Unique Identifier (UUID)](/en-US/docs/Glossary/UUID) for this report, which can be used to prevent duplicate counting. -- `"source_type"` - - : A string equal to either `"navigation"` or `"event"`, which respectively indicate whether the associated attribution source is [navigation-based](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#navigation-based_attribution_sources), or [event-based](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#event-based_attribution_sources). -- `"randomized_trigger_rate"` - - : A random number between 0 and 1 indicating how often [noise](#adding_noise_to_reports) is applied for this particular source configuration. -- `"scheduled_report_time"` - - : A string representing the number of seconds from the Unix Epoch until the browser initially scheduled the report to be sent (to avoid inaccuracies as a result of offline devices reporting late). -- `"source_debug_key"` {{optional_inline}} - - : A 64 bit unsigned integer representing the debugging key for the attribution source. This mirrors the value set in the associated {{httpheader("Attribution-Reporting-Register-Source")}} header's [`"debug_key"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Source#debug_key) field. See [Debug reports](#debug_reports) for more information. -- `"trigger_debug_key"` {{optional_inline}} - - : A 64 bit unsigned integer representing the debugging key for the attribution trigger. This mirrors the value set in the associated {{httpheader("Attribution-Reporting-Register-Trigger")}} header's `"debug_key"` field. See [Debug reports](#debug_reports) for more information. - -## Summary reports - -A summary report is created from several aggregatable reports received at the appropriate endpoint and then [batched](https://privacysandbox.google.com/private-advertising/attribution-reporting/summary-reports-intro#batching) to prepare them to be processed by an [aggregation service](https://privacysandbox.google.com/private-advertising/aggregation-service). When this has occurred, how the data is processed, stored, and displayed is completely up to the developer. - -An aggregatable report by default is generated and scheduled to be sent after a trigger is interacted with, with a random delay to help fuzz the timings and improve privacy. For a given registered attribution source, attribution source events will be recorded from registration up until the source expires - this is referred to as the **report window**. - -The expiry time is defined by the `expiry` value set in the associated {{httpheader("Attribution-Reporting-Register-Source")}} header, which defaults to 30 days after registration if not explicitly set. Bear in mind that the length of the report window can be further modified by setting an `aggregatable_report_window` value in the `Attribution-Reporting-Register-Source` header. See [Custom report windows](https://privacysandbox.google.com/private-advertising/attribution-reporting/custom-report-windows) for more details. - -> [!NOTE] -> To further protect user privacy, the summary report values associated with each attribution source have a finite total value — this is called the **contribution budget**. This value may very across different implementations of the API; in Chrome it is 65,536. Any conversions that would generate reports adding values over that limit are not recorded. Make sure you keep track of the budget and share it between the different metrics you are trying to measure. - -A typical aggregatable report might look like this: - -```json -{ - "shared_info": "{\"api\":\"attribution-reporting\",\"attribution_destination\":\"https://advertiser.example\",\"report_id\":\"123e4567-e89b-12d3-a456-426614174000\",\"reporting_origin\":\"https://reporter.example\",\"scheduled_report_time\":\"1692255696\",\"source_registration_time\":\"1692230400\",\"version\":\"3\"}", - "aggregation_service_payloads": [ - { - "payload": "[base64-encoded HPKE encrypted data readable only by the aggregation service]", - "key_id": "[string identifying public key used to encrypt payload]", - "debug_cleartext_payload": "[base64-encoded unencrypted payload]" - } - ], - "aggregation_coordinator_origin": "https://publickeyservice.aws.privacysandboxservices.com", - "source_debug_key": 647775351539539, - "trigger_debug_key": 647776891539539 -} -``` - -The properties are as follows: - -- `"shared_info"` - - : This is a serialized JSON object providing information that an aggregation service will use to put together a summary report. This data is [encrypted](/en-US/docs/Glossary/Encryption) using [AEAD](https://en.wikipedia.org/wiki/Authenticated_encryption) to prevent tampering. The following properties are represented in the serialized string: - - `"api"` - - : An enumerated value representing the API that triggered the report generation. Currently this will always be equal to `"attribution-reporting"`, but it may be extended with additional values to support other APIs in the future. - - `"attribution_destination"` - - : A string representing the attribution [`"destination"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Source#destination) URL set in the source registration (via the associated {{httpheader("Attribution-Reporting-Register-Source")}} response header). - - `"report_id"` - - : A string representing a [Universally Unique Identifier (UUID)](/en-US/docs/Glossary/UUID) for this report, which can be used to prevent duplicate counting. - - `"reporting_origin"` - - : The origin that triggered the report generation. - - `"scheduled_report_time"` - - : A string representing the number of seconds from the Unix Epoch until the browser initially scheduled the report to be sent (to avoid inaccuracies as a result of offline devices reporting late). - - `"source_registration_time"` - - : A string representing the number of seconds from the Unix Epoch until the attribution source was registered, rounded down to a whole day. - - `"version"` - - : A string representing the version of the API used to generate the report. -- `"aggregation_service_payloads"` - - : An array of objects representing payload objects containing the histogram contributions used by the aggregation service to assemble the data contained in the report. Currently, only a single payload is supported per report, configured by the browser. In the future multiple, customizable payloads may be supported. Each payload object can contain the following properties: - - `"payload"` - - : A [CBOR](https://cbor.io/) map encrypted via [HPKE](https://datatracker.ietf.org/doc/rfc9180/) and then [base64](/en-US/docs/Glossary/Base64)-encoded, with the following structure (using JSON for notation only): - - ```json - { - "operation": "histogram", - "data": [ - { - "bucket": "", - "value": "" - } - // … - ] - } - ``` - - The `operation` is always `"histogram"`; it allows for the service to support other operations in the future. - - - `"key_id"` - - : A string identifying the public key used to encrypt the payload. - - `"debug_cleartext_payload"` {{optional_inline}} - - : Optional debugging information. - -- `"aggregation_coordinator_origin"` - - : The deployment option for the aggregation service. -- `"source_debug_key"` {{optional_inline}} - - : A 64 bit unsigned integer representing the debugging key for the attribution source. This mirrors the value set in the associated {{httpheader("Attribution-Reporting-Register-Source")}} header's [`"debug_key"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Source#debug_key) field. See [Debug reports](#debug_reports) for more information. -- `"trigger_debug_key"` {{optional_inline}} - - : A 64 bit unsigned integer representing the debugging key for the attribution trigger. This mirrors the value set in the associated {{httpheader("Attribution-Reporting-Register-Trigger")}} header's `"debug_key"` field. See [Debug reports](#debug_reports) for more information. - -## Adding noise to reports - - - -Noise is added to reports in order to obscure the output associated with a particular source, and thereby protect user privacy. The exact source data cannot be identified and attributed back to individual users, but the overall patterns taken from the data will still provide the same meaning. - -For information on how noise works in attribution reporting, see: - -- [Understanding noise in summary reports](https://privacysandbox.google.com/private-advertising/attribution-reporting/understanding-noise). -- [Data limits and noise](https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#data-limits-and-noise) -- [Working with noise](https://privacysandbox.google.com/private-advertising/attribution-reporting/working-with-noise) - -## Report priorities and limits - -By default, all attribution sources have the same priority, and the attribution model is last-touch, meaning that a conversion is attributed to the most recent matching source event. For both event-level and aggregatable reports you can change source priority by setting a new value for the `"priority"` field in the associated {{httpheader("Attribution-Reporting-Register-Source")}} header. The default value is `0`; if you set a `"priority"` value of `1` on a particular source, that source will be matched first, before any priority `0` sources. Sources with `"priority": "2"` will be matched before `"priority": "1"` sources, and so on. - -Attribution trigger priorities work the same way; you can also set trigger priorities by adding a `"priority"` field to the associated {{httpheader("Attribution-Reporting-Register-Trigger")}} header, but only for event-level reports. - -Different source types have different default limits: - -- [Navigation-based attribution sources](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#navigation-based_attribution_sources) have a three-report limit by default. For example, say a user clicks an ad and converts four times: they visit the advertiser site homepage, then visit a product page, sign up to the newsletter, and finally make a purchase. The purchase report would be dropped, as it comes from the fourth conversion. -- [Event-based attribution sources](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#event-based_attribution_sources) have a one-report limit by default. - -> [!NOTE] -> The report limit can be adjusted by setting a different number of `"end_times"` in the [`"event_report_windows"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Source#event_report_windows) fields of the associated `Attribution-Reporting-Register-Source` header. - -When an attribution is triggered for a given source event, if the maximum number of attributions (three for clicks, one for images/scripts) has been reached for this source the browser will: - -- Compare the priority of the new report with the priorities of existing scheduled reports for that same source. -- Delete the report with the lowest priority to schedule the new report instead. If the new report is the one with the lowest priority, it is ignored and you won't receive it. - -If no priorities are set, the browser falls back to its default behavior: any conversion happening after the third conversion for clicks or the first conversion for views is dropped. - -## Filters - -You can define rules for which conversions generate reports using filters. For example, you could choose to only count conversions for a specific product category, and filter out conversions for other categories. - -To declare filters: - -1. On source registration, add a `filter_data` field to the {{httpheader("Attribution-Reporting-Register-Source")}} header that defines the filter keys you will use to filter the conversions over on the trigger side. These are completely custom fields. For example, to specify only conversions on particular subdomains, and for particular products: - - ```json - { - "filter_data": { - "conversion_subdomain": [ - "electronics.megastore", - "electronics2.megastore" - ], - "product": ["1234"] - } - } - ``` - -2. On trigger registration, add a `filters` field to the {{httpheader("Attribution-Reporting-Register-Trigger")}} header. The following, for example, causes trigger interactions to match the above source registration, as they both contain the `"electronics.megastore"` `"conversion_subdomain"` field. The `"directory"` filter on the other hand is ignored when a match is attempted, because it was not included in the above source registration. - - ```json - { - "filters": { - "conversion_subdomain": ["electronics.megastore"], - "directory": ["/store/electronics"] - } - } - ``` - -If the `"filter_data"` and `"filters"` fields contain matching subfields (like `"conversion_subdomain"` in the example above) but none of the subfield's values match, the trigger is ignored, resulting in no match. - -### Filtering trigger data - -The `event_trigger_data` field in the {{httpheader("Attribution-Reporting-Register-Trigger")}} header can be extended to do selective filtering to set `trigger_data`, `priority`, or `deduplication_key`, based on `filter_data` defined in the {{httpheader("Attribution-Reporting-Register-Source")}} header. - -For example: - -```json -{ - "event_trigger_data": [ - { - "trigger_data": "2", - "filters": { "source_type": ["navigation"] } - }, - { - "trigger_data": "1", - "filters": { "source_type": ["event"] } - } - ] -} -``` - -> [!NOTE] -> `"source_type"` is an automatically populated field available on the source's `"filter_data"`. - -> [!NOTE] -> `not_filters`, which filters with negation, is also supported. - -In this context, `filters` can be an object or an array of objects. When a list is specified, only one dictionary has to match for the trigger to be considered. - -```json -{ - "event_trigger_data": [ - { - "trigger_data": "2", - "filters": [ - { - "product": ["1234"], - "conversion_subdomain": ["electronics.megastore"] - }, - { - "product": ["4321"], - "conversion_subdomain": ["electronics4.megastore"] - } - ] - } - ] -} -``` - -If the filters do not match for any of the event triggers, no event-level report will be created. If the filters match for multiple event triggers, the first matching event trigger is used. - -## Debug reports - -You can enable debug reports to return troubleshooting information about your attribution reports. These can, for example, be used to check that your setup is working properly and understand gaps in measurement results between your old cookie-based implementation and your new Attribution Reporting implementation. Debug reports are sent immediately; they are not subject to the same scheduling as event-level and summary reports. - -There are two different types of debug report: - -- **Success debug reports** track successful generation of a specific attribution report. Success debug reports are generated and sent as soon as the corresponding trigger is registered. -- **Verbose debug reports** give you more visibility into the attribution source and attribution trigger events associated with an attribution report. They enable you to ensure that sources were registered successfully, or track missing reports and determine why they're missing (for example due to failure in source or trigger event registration or failure when sending or generating the report). Verbose debug reports are sent immediately upon source or trigger registration. - -> [!NOTE] -> To use debug reports, the reporting origin needs to set a cookie. If the origin configured to receive reports is a third party, this cookie will be a [third-party cookie](/en-US/docs/Web/Privacy/Guides/Third-party_cookies), which means that debug reports will not be available in browsers where third-party cookies are disabled/not available. - -### Using debug reports - -To use debug reports, you need to: - -1. Set the `ar_debug` cookie on your reporting origin. This needs to be present during both source and trigger registration: - - ```http - Set-Cookie: ar_debug=1; SameSite=None; Secure; Path=/; HttpOnly - ``` - -2. Set the `debug_key` field in any {{httpheader("Attribution-Reporting-Register-Source")}} and {{httpheader("Attribution-Reporting-Register-Trigger")}} response headers related to attribution reports that you want to expose debugging information for. Each `debug_key` value must be a 64-bit unsigned integer formatted as a base-10 string. Make each debug key a unique ID — you could for example set each one as Cookie ID + source/trigger timestamp (and capture that same timestamp in your older cookie-based system if you want to compare the two). - - ```json - { - "debug_key": "647775351539539" - } - ``` - - > [!NOTE] - > Make the source-side debug key different from the `source_event_id`, so that you can differentiate individual reports that have the same source event ID. - -3. Optionally, set the `debug_reporting` field to `true`, in both the `Attribution-Reporting-Register-Source` and `Attribution-Reporting-Register-Trigger` headers. If you do this, a verbose debug report will be generated. If you don't do this, a success debug report will be generated that mirrors the type of attribution report you are generating (event-level or aggregatable). - - ```json - { - "debug_key": "647775351539539", - "debug_reporting": true - } - ``` - -4. Set up appropriate endpoints to receive the debug reports you want to generate. Debug reports are sent to three separate endpoints in the reporting origin: - - Endpoint for event-level success debug reports: `/.well-known/attribution-reporting/debug/report-event-attribution` - - Endpoint for aggregatable success debug reports: `/.well-known/attribution-reporting/debug/report-aggregate-attribution` - - Endpoint for verbose debug reports: `/.well-known/attribution-reporting/debug/verbose` - -Generated success debug reports are identical to attribution reports, and contain the source-side and the trigger-side debug keys, in the `"source_debug_key"` and `"trigger_debug_key"` fields respectively. - -For further information and examples, see: - -- [Introduction to debug reports](https://privacysandbox.google.com/private-advertising/attribution-reporting/attribution-reporting-debugging/) on privacysandbox.google.com (2023) -- [Set up debug reports](https://privacysandbox.google.com/private-advertising/attribution-reporting/attribution-reporting-debugging/part-2/) on privacysandbox.google.com (2023) -- [Debugging cookbook](https://privacysandbox.google.com/private-advertising/attribution-reporting/attribution-reporting-debugging/part-3/) on privacysandbox.google.com (2023) diff --git a/files/en-us/web/api/attribution_reporting_api/index.md b/files/en-us/web/api/attribution_reporting_api/index.md index dd0cc4827b76439..fc3be04dbc39586 100644 --- a/files/en-us/web/api/attribution_reporting_api/index.md +++ b/files/en-us/web/api/attribution_reporting_api/index.md @@ -50,17 +50,11 @@ The steps involved are as follows: 3. When the user later visits `shop.example`, this site can register an **attribution trigger** when an interaction indicates that a conversion has occurred (for example, the user clicks the "Add to cart" button on `shop.example`). The browser will then send a request along with an {{httpheader("Attribution-Reporting-Eligible")}} header to indicate that the response is eligible to register an attribution trigger, and registration will be completed if the response includes an appropriate {{httpheader("Attribution-Reporting-Register-Trigger")}} header. The attribution trigger can be, for example: - An image such as a shopping cart icon or a 1x1 transparent tracking pixel. In this case, the interaction is the user visiting the page. The trigger is registered when the image loads, i.e., when the server responds to the image request. - A fetch request (i.e., a {{domxref("Window/fetch", "fetch()")}} or {{domxref("XMLHttpRequest")}}). In this case the interaction can be specified as whatever makes sense for your app — for example the fetch request could be invoked by a `click` or `submit` event. The trigger is registered once the response comes back. -4. When the trigger attribution completes, the browser attempts to match the data from the [Attribution-Reporting-Register-Trigger](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Trigger) header with a source data entry saved in the private local cache (see 2.). See [Registering attribution triggers](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers) for matching methodology and requirements. +4. When the trigger attribution completes, the browser attempts to match the data from the [Attribution-Reporting-Register-Trigger](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Trigger) header with a source data entry saved in the private local cache (see 2.). 5. If a match is made, the browser sends report data to an endpoint on a reporting server typically owned by the ad tech provider where it can be securely analyzed. Unlike with cookies, the data is only available to the specific site you send it to - there will be no data shared elsewhere. These reports can be either: - **Event-level reports**: Reports based on an attribution source event, where detailed source data is associated with coarse trigger data. For example, a report may look like "Click ID 200498 on `ad.shop.example` led to a purchase on `shop.example`", where "Click ID 200498" is the detailed source data, and "purchase" is the coarse trigger data. The detailed source data may encode first-party or contextual data from the source page, and the trigger data may encode the event from the trigger page. - **Summary reports**: More detailed reports that combine data from multiple conversions on both the source and trigger side. For example "Campaign ID 774653 on `news.example` has led to 654 sales of widgets on `shop.example` from users in Italy, with a total revenue of $9540." Compiling a summary report requires usage of an aggregation service (see for example the [Google aggregation service](https://github.com/privacysandbox/aggregation-service)). -For more information on implementing the functionality required for the above steps, see: - -1. [Registering attribution sources](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources) -2. [Registering attribution triggers](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers) -3. [Generating reports](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports) - ## Interfaces The Attribution Reporting API doesn't define any distinct interfaces of its own. diff --git a/files/en-us/web/api/attribution_reporting_api/registering_sources/index.md b/files/en-us/web/api/attribution_reporting_api/registering_sources/index.md deleted file mode 100644 index 62da482661298ca..000000000000000 --- a/files/en-us/web/api/attribution_reporting_api/registering_sources/index.md +++ /dev/null @@ -1,289 +0,0 @@ ---- -title: Registering attribution sources -slug: Web/API/Attribution_Reporting_API/Registering_sources -page-type: guide -status: - - deprecated ---- - -{{DefaultAPISidebar("Attribution Reporting API")}}{{deprecated_header}} - -This article explains how to register attribution sources when using the [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API). - -## Basic methodology - -Attribution sources take the form of links, images, or scripts contained within content that you want to measure interactions with (for example, they might be ads that you want to measure conversions on). These cause the browser to store source data in a private local cache (accessible only by the browser) when specific user interactions occur. The different attribution source types are registered and signal interactions in different ways — they are differentiated as: - -- Navigation sources, which cause the browser to store source data in response to navigation — for example when the user clicks on a link or activates it with the keyboard, or when a navigation occurs as a result of a {{domxref("Window.open()")}} call. See [Navigation-based attribution sources](#navigation-based_attribution_sources) for examples. -- Event sources, which cause the browser to store source data in response to events firing. See [Event-based attribution sources](#event-based_attribution_sources) for examples. - -What happens behind the scenes to register sources and retrieve and store the source data is the same in both cases: - -1. When the user interacts with an attribution source, it sends an {{httpheader("Attribution-Reporting-Eligible")}} header on a request to the server measuring the interactions (typically the advertiser's server), which indicates that the response is eligible to register a source. For example: - - ```http - Attribution-Reporting-Eligible: navigation-source - ``` - -2. When the server receives a request that includes an `Attribution-Reporting-Eligible` header, it can include an {{httpheader("Attribution-Reporting-Register-Source")}} header along with the response to complete source registration. Its value is a JSON string that provides the information the browser should store about the attribution source that was interacted with. The information included in this header also determines which types of report the browser will generate: - - The following example will cause an [event-level report](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#event-level_reports) to be generated when a [trigger](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers) is matched to a source: - - ```js - res.set( - "Attribution-Reporting-Register-Source", - JSON.stringify({ - source_event_id: "412444888111012", - destination: "https://advertiser.example", - trigger_data: [0, 1, 2, 3, 4], - trigger_data_matching: "exact", - expiry: "604800", - priority: "100", - debug_key: "122939999", - event_report_window: "86400", - }), - ); - ``` - - The only required field in this context is `destination`, which specifies 1–3 sites on which a trigger is expected to occur. These are used to match the attribution trigger to the source when a trigger is interacted with. The other fields specified above do the following: - - `"source_event_id"`: A string representing an ID for the attribution source, which can be used to map it to other information when the attribution source is interacted with, or aggregate information at the reporting endpoint (see [Generating reports > Basic process](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#basic_process) for endpoint information). - - `"trigger_data"`: An array of 32-bit unsigned integers representing data that describes the different trigger events that could match this source. For example, "user added item to shopping cart" or "user signed up to mailing list" could be actions happening at the trigger site that could match this source and indicate a conversion of some kind that the advertiser is trying to measure. These must be matched against `"trigger_data"` specified in [triggers](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Trigger#trigger_data) for event-level attribution to take place. - > [!NOTE] - > The values used to represent each event, and the number of elements in the array, are completely arbitrary and defined by you as the developer. The array may contain values that are not used, but values must be present in the array to be attributed to the source by the browser when a trigger is registered. - - `"trigger_data_matching"`: A string that specifies how the `"trigger_data"` from the trigger is matched against the source's `"trigger_data"`. `"exact"` is the value you'll nearly always use, which matches exact values. - - `"expiry"`: A string representing an expiry time in seconds for the attribution source, after which it will no longer be active (i.e., subsequent triggers won't be attributable to this source). - - `"priority"`: A string representing a priority value for the attribution source. See [Report priorities and limits](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#report_priorities_and_limits) for more information. - - `"debug_key"`: A base-10-formatted 64-bit unsigned integer representing a debug key. Set this if you want to generate a [debug report](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#debug_reports) alongside the associated attribution report. - - `"event_report_window"`: A string representing a time in seconds, after which subsequent triggers won't be attributable to this source for the purpose of producing event-level reports. - - See {{httpheader("Attribution-Reporting-Register-Source")}} for a detailed description of all the fields available on this header. - - - To make the browser generate a [summary report](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#summary_reports) when a trigger is matched to a source, you need to include some extra fields, _in addition_ to those required for generating an event-level report. - - ```js - res.set( - "Attribution-Reporting-Register-Source", - JSON.stringify({ - source_event_id: "412444888111012", - destination: "https://advertiser.example", - trigger_data: [0, 1, 2, 3, 4], - trigger_data_matching: "exact", - expiry: "604800", - priority: "100", - debug_key: "122939999", - event_report_window: "86400", - - aggregation_keys: { - campaignCounts: "0x159", - geoValue: "0x5", - }, - aggregatable_report_window: "86400", - }), - ); - ``` - - The additional fields in this example are: - - `"aggregation_keys"`: An object containing user-provided keys representing different data points to aggregate report values under. - - `"aggregatable_report_window"`: A string representing a time in seconds after which trigger data will no longer be included in generated aggregatable reports. - - Again, see {{httpheader("Attribution-Reporting-Register-Source")}} for a detailed description of all the fields available on this header. - -3. After a successful source registration occurs, the browser stores the provided source data in its private local cache. - -## Navigation-based attribution sources - -Navigation sources are useful for measuring interactions with links — for example, a user may see an ad on a publisher's page, and click it to navigate to the advertiser's page where a conversion will hopefully occur. - -There are a couple of different types of navigation-based attribution sources (for example, clicking on an ad) that can be registered — those based on HTML (which use the `attributionsrc` attribute) and those based on {{domxref("Window.open()")}} calls (which use an `attributionsrc` window feature). - -### HTML-based navigation sources - -To register a navigation-based attribution source you can add the `attributionsrc` attribute to an appropriate {{htmlelement("a")}} element, which specifies where the registration request will be sent. - -If you leave the attribute value blank, the registration request will be sent to the location being linked to. It is also possible to specify one or more additional URLs inside the value to send the registration request to; see the [Specifying URLs inside attributionsrc](#specifying_urls_inside_attributionsrc) for more details. - -`attributionsrc` can be added declaratively: - -```html - - Click to visit our shop - -``` - -Or via the {{domxref("HTMLAnchorElement.attributionSrc")}} property: - -```js -const aElem = document.querySelector("a"); -aElem.attributionSrc = ""; -``` - -In this case, the interaction occurs, causing the browser to store the source data associated with the navigation-based attribution source (as provided in the {{httpheader("Attribution-Reporting-Register-Source")}} response header) when the user clicks the link and the browser receives the response. - -### Window.open()-based navigation sources - -You can also add the `attributionsrc` feature keyword to the features property of a {{domxref("Window.open()")}} call. In this example we run it in response to a `click` event being fired: - -```js -elem.addEventListener("click", () => { - window.open("https://shop.example", "_blank", "attributionsrc"); -}); -``` - -In this case, the interaction occurs and the browser stores the source data when `Window.open()` is invoked, and the browser receives the response. - -> [!NOTE] -> When setting up a [`click`](/en-US/docs/Web/API/Element/click_event) event like in the above example, it is advisable to set it on a control where a click is expected, such as a {{htmlelement("button")}} or {{htmlelement("a")}} element. This makes more sense semantically, and is more accessible to both screen reader and keyboard users. - -> [!NOTE] -> To register an attribution source via `open()`, it must be called with [transient activation](/en-US/docs/Glossary/Transient_activation) (i.e., inside a user interaction event handler such as `click`) within five seconds of user interaction. - -## Event-based attribution sources - -Event-based attribution sources cause the browser to store source data in response to some kind of event firing, such as the `load` event in the case of an `` or ` -``` - -Or via the {{domxref("HTMLScriptElement.attributionSrc")}} property: - -```js -const scriptElem = document.querySelector("script"); -scriptElem.attributionSrc = ""; -``` - -In this case, the interaction occurs and the browser stores the source data when the browser receives the response containing the script. - -### JavaScript-based event sources - -Script-based attribution sources are more versatile than HTML-based attribution sources. You can set up a script to initiate a request that is eligible to register an attribution source based on whatever request suits your app. This is a flexible approach, useful when you want to store source data in response to custom interactions, for example, clicking a custom element or submitting a form. - -To set up a script-based attribution source, you can either: - -- Send a {{domxref("Window/fetch", "fetch()")}} request containing the `attributionReporting` option: - - ```js - const attributionReporting = { - eventSourceEligible: true, - triggerEligible: false, - }; - - // Optionally set keepalive to ensure the request outlives the page - function triggerSourceInteraction() { - fetch("https://shop.example/endpoint", { - keepalive: true, - attributionReporting, - }); - } - - // Associate the interaction trigger with whatever - // event makes sense for your code (does not have to be a - // DOM event/user interaction) - elem.addEventListener("click", triggerSourceInteraction); - ``` - -- Send an {{domxref("XMLHttpRequest")}} with {{domxref("XMLHttpRequest.setAttributionReporting", "setAttributionReporting()")}} invoked on the request object: - - ```js - const attributionReporting = { - eventSourceEligible: true, - triggerEligible: false, - }; - - function triggerSourceInteraction() { - const req = new XMLHttpRequest(); - req.open("GET", "https://shop.example/endpoint"); - // Check availability of setAttributionReporting() before calling - if (typeof req.setAttributionReporting === "function") { - req.setAttributionReporting(attributionReporting); - req.send(); - } else { - throw new Error("Attribution reporting not available"); - // Include recovery code here as appropriate - } - } - - // Associate the interaction trigger with whatever - // event makes sense for your code (does not have to be a - // DOM event/user interaction) - elem.addEventListener("click", triggerSourceInteraction); - ``` - -In this case, the interaction occurs and the browser stores the source data when the browser receives the response from the fetch request. - -> [!NOTE] -> The request can be for any resource. It doesn't need to have anything directly to do with the Attribution Reporting API, and can be a request for JSON, plain text, an image blob, or whatever else makes sense for your app. - -## Specifying URLs inside attributionsrc - -So far, in all the examples we have seen, the `attributionsrc` attribute/feature or `attributionSrc` property has been left blank, taking the value of an empty string. This is fine if the server that holds the requested resource is the same server that you also want to handle the registration, i.e., receive the {{httpheader("Attribution-Reporting-Eligible")}} header and respond with the {{httpheader("Attribution-Reporting-Register-Source")}} header. - -However, it might be that the requested resource is not on a server you control, or you just want to handle registering the attribution source on a different server. In such cases, you can specify one or more URLs as the value of `attributionsrc`. When the resource request occurs, the {{httpheader("Attribution-Reporting-Eligible")}} header will be sent to the URL(s) specified in `attributionsrc` in addition to the resource origin; these URLs can then respond with the {{httpheader("Attribution-Reporting-Register-Source")}} to register the source. - -For example, in the case of an `` element you could declare the URL(s) in the `attributionsrc` attribute: - -```html - - Click to visit our shop - -``` - -Or in JavaScript via the `attributionSrc` property: - -```js -// encode the URLs in case they contain special characters -// such as '=' that would be improperly parsed. -const encodedUrlA = encodeURIComponent("https://a.example/register-source"); -const encodedUrlB = encodeURIComponent("https://b.example/register-source"); - -const aElem = document.querySelector("a"); -aElem.attributionSrc = `${encodedUrlA} ${encodedUrlB}`; -``` - -In the case of a {{domxref("Window.open()")}} call, the different URLs would have to be listed as multiple separate `attributionsrc` features in the [`windowFeatures`](/en-US/docs/Web/API/Window/open#windowfeatures) parameter, separated by commas or whitespace: - -```js -// encode the URLs in case they contain special characters -// such as '=' that would be improperly parsed. -const encodedUrlA = encodeURIComponent("https://a.example/register-source"); -const encodedUrlB = encodeURIComponent("https://b.example/register-source"); - -elem.addEventListener("click", () => { - window.open( - "https://ourshop.example", - "_blank", - `attributionsrc=${encodedUrlA},attributionsrc=${encodedUrlB}`, - ); -}); -``` - -> [!NOTE] -> Specifying multiple URLs means that multiple attribution sources can be registered on the same feature. You might for example have different campaigns that you are trying to measure the success of, which involve generating different reports on different data. - -## See also - -- [Attribution Reporting Header Validation tool](https://wicg.github.io/attribution-reporting-api/validate-headers) diff --git a/files/en-us/web/api/attribution_reporting_api/registering_triggers/index.md b/files/en-us/web/api/attribution_reporting_api/registering_triggers/index.md deleted file mode 100644 index 52581281411cc3f..000000000000000 --- a/files/en-us/web/api/attribution_reporting_api/registering_triggers/index.md +++ /dev/null @@ -1,232 +0,0 @@ ---- -title: Registering attribution triggers -slug: Web/API/Attribution_Reporting_API/Registering_triggers -page-type: guide -status: - - deprecated ---- - -{{DefaultAPISidebar("Attribution Reporting API")}}{{deprecated_header}} - -This article explains how to register attribution triggers. - -## Basic methodology - -Once you have [registered attribution sources](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources), you need to register attribution triggers. These are interactions on a site where a conversion is to be measured (for example, clicking a "purchase" button on an advertiser's site can indicate that a conversion may have occurred). The browser will then attempt to match the attribution trigger to an attribution source entry stored in a private local storage partition, and [generate a report](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports) if a match is found. - -The different attribution trigger types are registered in different ways, which are detailed in the sections below — see [HTML-based attribution triggers](#html-based_attribution_triggers) and [JavaScript-based attribution triggers](#javascript-based_attribution_triggers). - -However, what happens behind the scenes to register triggers, look for matches, etc., is the same in all cases. - -1. All of the trigger types send an {{httpheader("Attribution-Reporting-Eligible")}} header on a request, which indicates that the response is eligible to register a trigger. For example: - - ```http - Attribution-Reporting-Eligible: trigger - ``` - -2. When the server receives a request that includes an `Attribution-Reporting-Eligible` header, it can include an {{httpheader("Attribution-Reporting-Register-Trigger")}} along with the response. Its value is a JSON string containing data that can be included in generated reports, such as the ID of the trigger, and priority and deduplication values. - - The following example is intended to match with an [event-level report](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#event-level_reports) attribution source: - - ```js - res.set( - "Attribution-Reporting-Register-Trigger", - JSON.stringify({ - event_trigger_data: [ - { - trigger_data: "4", - priority: "1000000000000", - deduplication_key: "2345698765", - }, - ], - debug_key: "1115698977", - }), - ); - ``` - - The fields specified here are as follows: - - `"event_trigger_data"`: An object representing data about the trigger. This includes: - - `"trigger_data"`: The data associated with the trigger, which is typically used to indicate events such as "user added item to shopping cart" or "user signed up to mailing list". This value will be included in the generated report, if any, although it will be subject to modification based on the attributed source's [`"trigger_data_matching"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Source#trigger_data_matching) field. - > [!NOTE] - > The values used to represent each event, and the number of elements in the array, are completely arbitrary and defined by you as the developer. The array may contain values that are not used, but values must be present in the array to be attributed to the source by the browser when a trigger is registered. - - `"priority"`: A string representing a priority value for the attribution trigger. See [Report priorities and limits](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#report_priorities_and_limits) for more information. - - `"deduplication_key"`: A string representing a unique key that can be used to prevent attributions from being duplicated — for example if a user were to add the same item to a shopping cart multiple times. See [Prevent duplication in reports](https://privacysandbox.google.com/private-advertising/attribution-reporting/prevent-duplication) for more information. - - `"debug_key"`: A number representing a debug key. Set this if you want to generate a [debug report](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#debug_reports) alongside the associated attribution report. - - See {{httpheader("Attribution-Reporting-Register-Trigger")}} for a detailed description of all the available fields. - - A trigger intended to match with a [summary report](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#summary_reports) attribution source requires the fields shown below: - - ```js - res.set( - "Attribution-Reporting-Register-Trigger", - JSON.stringify({ - aggregatable_trigger_data: [ - { - key_piece: "0x400", - source_keys: ["campaignCounts"], - }, - { - key_piece: "0xA80", - source_keys: ["geoValue", "nonMatchingKeyIdsAreIgnored"], - }, - ], - aggregatable_values: { - campaignCounts: 32768, - geoValue: 1664, - }, - debug_key: "1115698977", - }), - ); - ``` - - The fields in this example are: - - `"aggregatable_trigger_data"`: An array of objects, each one defining an aggregation key to apply to different source keys. - - `"aggregatable_values"`: An object containing properties representing a value for each data point defined in `"aggregatable_trigger_data"`. - - Again, see {{httpheader("Attribution-Reporting-Register-Trigger")}} for a detailed description of all the available fields. - -3. When the user interacts with the attribution trigger, the browser attempts to match the trigger against any attribution source entries stored in the browser's private local cache. For a successful match, the `Attribution-Reporting-Register-Trigger`'s [`"trigger_data"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Trigger#trigger_data) must match one of the values provided in the {{httpheader("Attribution-Reporting-Register-Source")}}'s [`"trigger_data"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Source#trigger_data), and the site (scheme + {{glossary("registrable domain")}}) of the top-level page on which the trigger is being registered must: - - match the site of at least one of the `destination`s specified in the source's associated data. - - be same-origin with the request that specified the source registration. - - > [!NOTE] - > These requirements provide privacy protection, but also flexibility — the source _and_ trigger can potentially be embedded in an {{htmlelement("iframe")}} or situated in the top-level site. - - There are many other factors that will prevent a successful match outcome; for example: - - The trigger's filters do not match the source's filter data (See [Filters](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#filters) for more details). - - The source's [`"trigger_data_matching"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Source#trigger_data_matching) setting results in no match occurring. - - The source's [`"max_event_level_reports"`](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Source#max_event_level_reports) limit has been reached. - - A successful match is not reported due to the browser's randomized response algorithm. See [Adding noise to reports](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#adding_noise_to_reports) for more details. - -4. If a successful match is found, the browser [generates a report](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports) based on the source and trigger data, and sends it to a reporting endpoint. - -> [!NOTE] -> Attribution triggers cannot be registered on {{htmlelement("a")}} elements or {{domxref("Window.open()")}} calls like attribution sources can. - -## HTML-based attribution triggers - -HTML-based attribution triggers can be used for detecting conversions on a page when it first loads — or more precisely when an `` or ` -``` - -```js -const scriptElem = document.querySelector("script"); -scriptElem.attributionSrc = ""; -``` - -In this case, the browser will attempt to match the trigger with a stored attribution source when the browser receives the response containing the script. - -## JavaScript-based attribution triggers - -JavaScript-based attribution triggers are more versatile than HTML-based attribution triggers. You can trigger the browser to attempt a match with a stored source based on a custom interaction, for example, clicking a custom element or submitting a form. - -To register a script-based attribution trigger, you can either: - -- Send a {{domxref("Window/fetch", "fetch()")}} request containing the `attributionReporting` option: - - ```js - const attributionReporting = { - eventSourceEligible: false, - triggerEligible: true, - }; - - // Optionally set keepalive to ensure the request outlives the page - function triggerMatching() { - fetch("https://shop.example/endpoint", { - keepalive: true, - attributionReporting, - }); - } - - // Associate the interaction trigger with whatever - // element and event makes sense for your code - elem.addEventListener("click", triggerMatching); - ``` - -- Send an {{domxref("XMLHttpRequest")}} with {{domxref("XMLHttpRequest.setAttributionReporting", "setAttributionReporting()")}} invoked on the request object: - - ```js - const attributionReporting = { - eventSourceEligible: false, - triggerEligible: true, - }; - - function triggerMatching() { - const req = new XMLHttpRequest(); - req.open("GET", "https://shop.example/endpoint"); - // Check availability of setAttributionReporting() before calling - if (typeof req.setAttributionReporting === "function") { - req.setAttributionReporting(attributionReporting); - req.send(); - } else { - throw new Error("Attribution reporting not available"); - // Include recovery code here as appropriate - } - } - - // Associate the interaction trigger with whatever - // element and event makes sense for your code - elem.addEventListener("click", triggerMatching); - ``` - -In this case, the browser will attempt to match the trigger with a stored attribution source when the browser receives the response from the fetch request. - -> [!NOTE] -> The request can be for any resource. It doesn't need to have anything directly to do with the Attribution Reporting API, and can be a request for JSON, plain text, an image blob, or whatever else makes sense for your app. - -## Specifying a URL inside attributionsrc - -In the above examples, the `attributionsrc` attribute is left blank, taking the value of an empty string. This is fine if the server that holds the requested resource is the same server that you also want to handle the registration, i.e., receive the {{httpheader("Attribution-Reporting-Eligible")}} header and respond with the {{httpheader("Attribution-Reporting-Register-Trigger")}} header. - -However, it might be the case that the requested resource is not on a server you control, or you just want to handle registering the attribution trigger on a different server. In such cases, you can specify one or more URLs as the value of `attributionsrc`. When the resource request occurs, the {{httpheader("Attribution-Reporting-Eligible")}} header will be sent to the URLs specified in `attributionsrc` in addition to the resource origin; the URLs can then respond with the {{httpheader("Attribution-Reporting-Register-Trigger")}} to complete registration. - -For example, in the case of an `` element you could declare the URL in the `attributionsrc` attribute: - -```html - -``` - -Or in JavaScript via the `attributionSrc` property: - -```js -const imgElem = document.querySelector("img"); -imgElem.attributionSrc = "https://my-separate-tracking-site.example.com"; -``` - -## See also - -- [Attribution Reporting Header Validation tool](https://wicg.github.io/attribution-reporting-api/validate-headers) diff --git a/files/en-us/web/api/htmlanchorelement/attributionsrc/index.md b/files/en-us/web/api/htmlanchorelement/attributionsrc/index.md index 65286c9111c36ba..09fa2985d5ebdb5 100644 --- a/files/en-us/web/api/htmlanchorelement/attributionsrc/index.md +++ b/files/en-us/web/api/htmlanchorelement/attributionsrc/index.md @@ -11,7 +11,7 @@ browser-compat: api.HTMLAnchorElement.attributionSrc {{APIRef("Attribution Reporting API")}}{{securecontext_header}}{{deprecated_header}}{{non-standard_header}} -The **`attributionSrc`** property of the {{domxref("HTMLAnchorElement")}} interface gets and sets the [`attributionsrc`](/en-US/docs/Web/HTML/Reference/Elements/a#attributionsrc) attribute on an {{htmlelement("a")}} element programmatically, reflecting the value of that attribute. `attributionsrc` specifies that you want the browser to send an {{httpheader("Attribution-Reporting-Eligible")}} header. On the server-side this is used to trigger sending an {{httpheader("Attribution-Reporting-Register-Source")}} header in the response, to register of a [navigation-based attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#navigation-based_attribution_sources). +The **`attributionSrc`** property of the {{domxref("HTMLAnchorElement")}} interface gets and sets the [`attributionsrc`](/en-US/docs/Web/HTML/Reference/Elements/a#attributionsrc) attribute on an {{htmlelement("a")}} element programmatically, reflecting the value of that attribute. `attributionsrc` specifies that you want the browser to send an {{httpheader("Attribution-Reporting-Eligible")}} header. On the server-side this is used to trigger sending an {{httpheader("Attribution-Reporting-Register-Source")}} header in the response, to register of a navigation-based attribution source. The browser stores the source data associated with the navigation-based attribution source (as provided in the {{httpheader("Attribution-Reporting-Register-Source")}} response header) when it receives the navigation response. diff --git a/files/en-us/web/api/htmlimageelement/index.md b/files/en-us/web/api/htmlimageelement/index.md index 6601366e516f6ce..b050fd9eed87a4c 100644 --- a/files/en-us/web/api/htmlimageelement/index.md +++ b/files/en-us/web/api/htmlimageelement/index.md @@ -23,7 +23,7 @@ _Inherits properties from its parent, {{domxref("HTMLElement")}}._ - {{domxref("HTMLImageElement.alt")}} - : A string that reflects the [`alt`](/en-US/docs/Web/HTML/Reference/Elements/img#alt) HTML attribute, thus indicating the alternate fallback content to be displayed if the image has not been loaded. - {{domxref("HTMLImageElement.attributionSrc")}} {{securecontext_inline}} {{deprecated_inline}} {{non-standard_inline}} - - : Gets and sets the [`attributionsrc`](/en-US/docs/Web/HTML/Reference/Elements/img#attributionsrc) attribute on an {{htmlelement("img")}} element programmatically, reflecting the value of that attribute. `attributionsrc` specifies that you want the browser to send an {{httpheader("Attribution-Reporting-Eligible")}} header along with the image request. On the server-side this is used to trigger sending an {{httpheader("Attribution-Reporting-Register-Source")}} or {{httpheader("Attribution-Reporting-Register-Trigger")}} header in the response, to register an image-based [attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#html-based_event_sources) or [attribution trigger](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers#html-based_attribution_triggers), respectively. + - : Gets and sets the [`attributionsrc`](/en-US/docs/Web/HTML/Reference/Elements/img#attributionsrc) attribute on an {{htmlelement("img")}} element programmatically, reflecting the value of that attribute. `attributionsrc` specifies that you want the browser to send an {{httpheader("Attribution-Reporting-Eligible")}} header along with the image request. On the server-side this is used to trigger sending an {{httpheader("Attribution-Reporting-Register-Source")}} or {{httpheader("Attribution-Reporting-Register-Trigger")}} header in the response, to register an image-based attribution source or attribution trigger, respectively. - {{domxref("HTMLImageElement.complete")}} {{ReadOnlyInline}} - : Returns a boolean value that is `true` if the browser has finished fetching the image, whether successful or not. That means this value is also `true` if the image has no {{domxref("HTMLImageElement.src", "src")}} value indicating an image to load. - {{domxref("HTMLImageElement.crossOrigin")}} diff --git a/files/en-us/web/api/htmlscriptelement/attributionsrc/index.md b/files/en-us/web/api/htmlscriptelement/attributionsrc/index.md index dcabb94bf1daeac..3d62dccd3808165 100644 --- a/files/en-us/web/api/htmlscriptelement/attributionsrc/index.md +++ b/files/en-us/web/api/htmlscriptelement/attributionsrc/index.md @@ -13,7 +13,7 @@ browser-compat: api.HTMLScriptElement.attributionSrc The **`attributionSrc`** property of the {{domxref("HTMLScriptElement")}} interface gets and sets the [`attributionsrc`](/en-US/docs/Web/HTML/Reference/Elements/script#attributionsrc) attribute on a {{htmlelement("script")}} element programmatically, reflecting the value of that attribute. `attributionsrc` specifies that you want the browser to send an {{httpheader("Attribution-Reporting-Eligible")}} header along with the script resource request. -On the server-side this is used to trigger sending an {{httpheader("Attribution-Reporting-Register-Source")}} or {{httpheader("Attribution-Reporting-Register-Trigger")}} header in the response, to register a JavaScript-based [attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#javascript-based_event_sources) or [attribution trigger](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers#javascript-based_attribution_triggers), respectively. Which response header should be sent back depends on the value of the `Attribution-Reporting-Eligible` header that triggered the registration. +On the server-side this is used to trigger sending an {{httpheader("Attribution-Reporting-Register-Source")}} or {{httpheader("Attribution-Reporting-Register-Trigger")}} header in the response, to register a JavaScript-based attribution source or attribution trigger, respectively. Which response header should be sent back depends on the value of the `Attribution-Reporting-Eligible` header that triggered the registration. > [!NOTE] > Alternatively, JavaScript-based attribution sources or triggers can be registered by sending a {{domxref("Window/fetch", "fetch()")}} request containing the `attributionReporting` option (either set directly on the `fetch()` call or on a {{domxref("Request")}} object passed into the `fetch()` call), or by sending an {{domxref("XMLHttpRequest")}} with {{domxref("XMLHttpRequest.setAttributionReporting", "setAttributionReporting()")}} invoked on the request object. diff --git a/files/en-us/web/api/htmlscriptelement/index.md b/files/en-us/web/api/htmlscriptelement/index.md index b99ef1556deec2c..ff756873044d9d1 100644 --- a/files/en-us/web/api/htmlscriptelement/index.md +++ b/files/en-us/web/api/htmlscriptelement/index.md @@ -21,7 +21,7 @@ JavaScript files should be served with the `text/javascript` [MIME type](/en-US/ _Inherits properties from its parent, {{domxref("HTMLElement")}}._ - {{domxref("HTMLScriptElement.attributionSrc")}} {{securecontext_inline}} {{deprecated_inline}} {{non-standard_inline}} - - : Gets and sets the [`attributionsrc`](/en-US/docs/Web/HTML/Reference/Elements/script#attributionsrc) attribute on a {{htmlelement("script")}} element programmatically, reflecting the value of that attribute. `attributionsrc` specifies that you want the browser to send an {{httpheader("Attribution-Reporting-Eligible")}} header along with the script resource request. On the server-side this is used to trigger sending an {{httpheader("Attribution-Reporting-Register-Source")}} or {{httpheader("Attribution-Reporting-Register-Trigger")}} header in the response, to register a JavaScript-based [attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#javascript-based_event_sources) or [attribution trigger](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers#javascript-based_attribution_triggers), respectively. + - : Gets and sets the [`attributionsrc`](/en-US/docs/Web/HTML/Reference/Elements/script#attributionsrc) attribute on a {{htmlelement("script")}} element programmatically, reflecting the value of that attribute. `attributionsrc` specifies that you want the browser to send an {{httpheader("Attribution-Reporting-Eligible")}} header along with the script resource request. On the server-side this is used to trigger sending an {{httpheader("Attribution-Reporting-Register-Source")}} or {{httpheader("Attribution-Reporting-Register-Trigger")}} header in the response, to register a JavaScript-based attribution source or attribution trigger, respectively. - {{domxref("HTMLScriptElement.async")}} - : A boolean value that controls how the script should be executed. For classic scripts, if the `async` property is set to `true`, the external script will be fetched in parallel to parsing and evaluated as soon as it is available. For [module scripts](/en-US/docs/Web/JavaScript/Guide/Modules), if the `async` property is set to `true`, the script and all their dependencies will be fetched in parallel to parsing and evaluated as soon as they are available. - {{domxref("HTMLScriptElement.blocking")}} diff --git a/files/en-us/web/api/requestinit/index.md b/files/en-us/web/api/requestinit/index.md index 7984dc05e6b156b..33074f072b698cd 100644 --- a/files/en-us/web/api/requestinit/index.md +++ b/files/en-us/web/api/requestinit/index.md @@ -16,7 +16,7 @@ You can also construct a `Request` with a `RequestInit`, and pass the `Request` ## Instance properties - `attributionReporting` {{optional_inline}} {{deprecated_inline}} - - : Indicates that you want the request's response to be able to register a JavaScript-based [attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#javascript-based_event_sources) or [attribution trigger](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers#javascript-based_attribution_triggers). `attributionReporting` is an object containing the following properties: + - : Indicates that you want the request's response to be able to register a JavaScript-based attribution source or attribution trigger. `attributionReporting` is an object containing the following properties: - `eventSourceEligible` - : A boolean. If set to `true`, the request's response is eligible to register an attribution source. If set to `false`, it isn't. - `triggerEligible` diff --git a/files/en-us/web/api/xmlhttprequest/setattributionreporting/index.md b/files/en-us/web/api/xmlhttprequest/setattributionreporting/index.md index af78e32a763db27..6f0ffb683752f44 100644 --- a/files/en-us/web/api/xmlhttprequest/setattributionreporting/index.md +++ b/files/en-us/web/api/xmlhttprequest/setattributionreporting/index.md @@ -12,7 +12,7 @@ browser-compat: api.XMLHttpRequest.setAttributionReporting {{APIRef("Attribution Reporting API")}}{{securecontext_header}}{{deprecated_header}}{{non-standard_header}} The **`setAttributionReporting()`** method of the -{{domxref("XMLHttpRequest")}} interface indicates that you want the request's response to be able to register a JavaScript-based [attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#javascript-based_event_sources) or [attribution trigger](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers#javascript-based_attribution_triggers). +{{domxref("XMLHttpRequest")}} interface indicates that you want the request's response to be able to register a JavaScript-based attribution source or attribution trigger. See the [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API) for more details. diff --git a/files/en-us/web/html/reference/elements/a/index.md b/files/en-us/web/html/reference/elements/a/index.md index 68b5ca85e4dff3f..95b571684e04bcf 100644 --- a/files/en-us/web/html/reference/elements/a/index.md +++ b/files/en-us/web/html/reference/elements/a/index.md @@ -34,7 +34,7 @@ li { This element's attributes include the [global attributes](/en-US/docs/Web/HTML/Reference/Global_attributes). - `attributionsrc` {{deprecated_inline}} {{non-standard_inline}} - - : Specifies that you want the browser to send an {{httpheader("Attribution-Reporting-Eligible")}} header. On the server-side this is used to trigger sending an {{httpheader("Attribution-Reporting-Register-Source")}} header in the response, to register a [navigation-based attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#navigation-based_attribution_sources). + - : Specifies that you want the browser to send an {{httpheader("Attribution-Reporting-Eligible")}} header. On the server-side this is used to trigger sending an {{httpheader("Attribution-Reporting-Register-Source")}} header in the response, to register a navigation-based attribution source. The browser stores the source data associated with the navigation-based attribution source (as provided in the {{httpheader("Attribution-Reporting-Register-Source")}} response header) when the user clicks the link. See the [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API) for more details. diff --git a/files/en-us/web/html/reference/elements/img/index.md b/files/en-us/web/html/reference/elements/img/index.md index 09c781c5a24f835..5e5ef6fc886737e 100644 --- a/files/en-us/web/html/reference/elements/img/index.md +++ b/files/en-us/web/html/reference/elements/img/index.md @@ -90,7 +90,7 @@ This element includes the [global attributes](/en-US/docs/Web/HTML/Reference/Glo - `attributionsrc` {{deprecated_inline}} {{non-standard_inline}} - : Specifies that you want the browser to send an {{httpheader("Attribution-Reporting-Eligible")}} header along with the image request. - On the server-side this is used to trigger sending an {{httpheader("Attribution-Reporting-Register-Source")}} or {{httpheader("Attribution-Reporting-Register-Trigger")}} header in the response, to register an image-based [attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#html-based_event_sources) or [attribution trigger](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers#html-based_attribution_triggers), respectively. Which response header should be sent back depends on the value of the `Attribution-Reporting-Eligible` header that triggered the registration. + On the server-side this is used to trigger sending an {{httpheader("Attribution-Reporting-Register-Source")}} or {{httpheader("Attribution-Reporting-Register-Trigger")}} header in the response, to register an image-based attribution source or attribution trigger, respectively. Which response header should be sent back depends on the value of the `Attribution-Reporting-Eligible` header that triggered the registration. The corresponding source or trigger event is set off once the browser receives the response containing the image file. diff --git a/files/en-us/web/html/reference/elements/script/index.md b/files/en-us/web/html/reference/elements/script/index.md index bc24bfa0351d5c9..5bc41f221255cac 100644 --- a/files/en-us/web/html/reference/elements/script/index.md +++ b/files/en-us/web/html/reference/elements/script/index.md @@ -30,7 +30,7 @@ This element includes the [global attributes](/en-US/docs/Web/HTML/Reference/Glo See [Browser compatibility](#browser_compatibility) for notes on browser support. See also [Async scripts for asm.js](/en-US/docs/Games/Techniques/Async_scripts). - `attributionsrc` {{deprecated_inline}} {{non-standard_inline}} - - : Specifies that you want the browser to send an {{httpheader("Attribution-Reporting-Eligible")}} header along with the script resource request. On the server-side this is used to trigger sending an {{httpheader("Attribution-Reporting-Register-Source")}} or {{httpheader("Attribution-Reporting-Register-Trigger")}} header in the response, to register a JavaScript-based [attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#javascript-based_event_sources) or [attribution trigger](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers#javascript-based_attribution_triggers), respectively. Which response header should be sent back depends on the value of the `Attribution-Reporting-Eligible` header that triggered the registration. + - : Specifies that you want the browser to send an {{httpheader("Attribution-Reporting-Eligible")}} header along with the script resource request. On the server-side this is used to trigger sending an {{httpheader("Attribution-Reporting-Register-Source")}} or {{httpheader("Attribution-Reporting-Register-Trigger")}} header in the response, to register a JavaScript-based attribution source or attribution trigger, respectively. Which response header should be sent back depends on the value of the `Attribution-Reporting-Eligible` header that triggered the registration. > [!NOTE] > Alternatively, JavaScript-based attribution sources or triggers can be registered by sending a {{domxref("Window/fetch", "fetch()")}} request containing the `attributionReporting` option (either set directly on the `fetch()` call or on a {{domxref("Request")}} object passed into the `fetch()` call), or by sending an {{domxref("XMLHttpRequest")}} with {{domxref("XMLHttpRequest.setAttributionReporting", "setAttributionReporting()")}} invoked on the request object. diff --git a/files/en-us/web/http/reference/headers/attribution-reporting-eligible/index.md b/files/en-us/web/http/reference/headers/attribution-reporting-eligible/index.md index 637aee21d11060c..84b2b69342271fe 100644 --- a/files/en-us/web/http/reference/headers/attribution-reporting-eligible/index.md +++ b/files/en-us/web/http/reference/headers/attribution-reporting-eligible/index.md @@ -42,11 +42,11 @@ Attribution-Reporting-Eligible: - `` - : A structured-header dictionary representing the registrations allowed in the corresponding response. Possible keys are: - `event-source` - - : An [event-based attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#event-based_attribution_sources) can be registered. + - : An event-based attribution source can be registered. - `navigation-source` - - : A [navigation-based attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources#navigation-based_attribution_sources) can be registered. + - : A navigation-based attribution source can be registered. - `trigger` - - : An [attribution trigger](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers) can be registered. + - : An attribution trigger can be registered. Every response in a redirect chain can register at most one source or one trigger. diff --git a/files/en-us/web/http/reference/headers/attribution-reporting-register-source/index.md b/files/en-us/web/http/reference/headers/attribution-reporting-register-source/index.md index 1882a40da2deb25..b2374d8f468329f 100644 --- a/files/en-us/web/http/reference/headers/attribution-reporting-register-source/index.md +++ b/files/en-us/web/http/reference/headers/attribution-reporting-register-source/index.md @@ -12,7 +12,7 @@ sidebar: http {{deprecated_header}}{{non-standard_header}} -The HTTP **`Attribution-Reporting-Register-Source`** {{Glossary("response header")}} registers a page feature as an [attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources). +The HTTP **`Attribution-Reporting-Register-Source`** {{Glossary("response header")}} registers a page feature as an attribution source. This header is included as part of a response to a request that contains the {{HTTPHeader("Attribution-Reporting-Eligible")}} header. It provides the information that the browser should store when a user interacts with the attribution source. The information you include in this header also determines the types of reports the browser can generate. See the [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API) for more details. @@ -54,11 +54,11 @@ Attribution-Reporting-Register-Source: - `"aggregatable_report_window"` {{optional_inline}} - : A string representing a time in seconds after which trigger data will no longer be included in generated aggregatable reports (this is called a **report window**). If not set, this defaults to the `"expiry"` value. - `"debug_key"` {{optional_inline}} - - : A base-10-formatted 64-bit unsigned integer representing a debug key. Set this if you want to generate a [debug report](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#debug_reports) alongside the associated attribution report. + - : A base-10-formatted 64-bit unsigned integer representing a debug key. Set this if you want to generate a debug report alongside the associated attribution report. - `"debug_reporting"` {{optional_inline}} - : A boolean value. If a `debug_key` is set, set this to `true` to specify that the generated debug report should be a verbose debug report. - `"event_level_epsilon"` {{optional_inline}} - - : A number equal to or greater than `0`, which controls the amount of [noise added to reports](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#adding_noise_to_reports). Lower values of epsilon result in more noise and therefore provide greater privacy protection. The maximum and default values will vary across implementations; Chrome for example has a maximum and default value of `14`. + - : A number equal to or greater than `0`, which controls the amount of noise added to reports. Lower values of epsilon result in more noise and therefore provide greater privacy protection. The maximum and default values will vary across implementations; Chrome for example has a maximum and default value of `14`. - `"event_report_window"` {{optional_inline}} - : A string representing a time in seconds, after which subsequent triggers won't be attributable to this source for the purpose of producing event-level reports (this is called a **report window**). If not set, the event report window falls back to the `"expiry"` value. > [!NOTE] @@ -72,11 +72,11 @@ Attribution-Reporting-Register-Source: - `"expiry"` {{optional_inline}} - : A string representing an expiry time in seconds for the attribution source, after which it will no longer be active (i.e., subsequent triggers won't be attributable to this source). The maximum allowable expiry time is 2592000 seconds (30 days), which is also the default value if `"expiry"` is not explicitly set. - `"filter_data"` {{optional_inline}} - - : An object defining custom data that can be used to filter which conversions generate reports. See [Filters](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#filters) for more details. + - : An object defining custom data that can be used to filter which conversions generate reports. - `"max_event_level_reports"` {{optional_inline}} - : A number between `0` and `20`, inclusive, which specifies the total number of event-level reports this source can generate. After this maximum is reached, the source is no longer capable of producing any new data. If not specified, `"max_event_level_reports"` defaults to `3` for navigation-based sources and `1` for event-based (image- or script-based) sources. - `"priority"` {{optional_inline}} - - : A string representing a priority value for the attribution source. By default, conversions are attributed to the most recent matching source. For both event-level and summary reports you set a higher priority number to prioritize specific sources. For example, a value of `2` takes priority over the default value of `1`. See [Report priorities and limits](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#report_priorities_and_limits) for more information. + - : A string representing a priority value for the attribution source. By default, conversions are attributed to the most recent matching source. For both event-level and summary reports you set a higher priority number to prioritize specific sources. For example, a value of `2` takes priority over the default value of `1`. - `"trigger_data"` {{optional_inline}} - : An array of 32-bit unsigned integers representing data that describes the different trigger events that could match this source. For example, "user added item to shopping cart" or "user signed up to mailing list" could be actions happening at the trigger site that could match this source and indicate a conversion of some kind that the advertiser is trying to measure. These must be matched against `"trigger_data"` specified in [triggers](/en-US/docs/Web/HTTP/Reference/Headers/Attribution-Reporting-Register-Trigger#trigger_data) for event-level attribution to take place. If omitted, `"trigger_data"` defaults to `[0, 1, 2, 3, 4, 5, 6, 7]` for navigation-based sources and `[0, 1]` for event-based (image- or script-based) sources. diff --git a/files/en-us/web/http/reference/headers/attribution-reporting-register-trigger/index.md b/files/en-us/web/http/reference/headers/attribution-reporting-register-trigger/index.md index 5f87edc01ab1402..4df6be185ee1ebc 100644 --- a/files/en-us/web/http/reference/headers/attribution-reporting-register-trigger/index.md +++ b/files/en-us/web/http/reference/headers/attribution-reporting-register-trigger/index.md @@ -12,7 +12,7 @@ sidebar: http {{deprecated_header}}{{non-standard_header}} -The HTTP **`Attribution-Reporting-Register-Trigger`** {{Glossary("response header")}} registers a page feature as an [attribution trigger](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers). This header is included as part of a response to a request that contains the {{HTTPHeader("Attribution-Reporting-Eligible")}} header. +The HTTP **`Attribution-Reporting-Register-Trigger`** {{Glossary("response header")}} registers a page feature as an attribution trigger. This header is included as part of a response to a request that contains the {{HTTPHeader("Attribution-Reporting-Eligible")}} header. See the [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API) for more details. @@ -53,11 +53,11 @@ Attribution-Reporting-Register-Trigger: - `"aggregatable_values"` - : An object containing properties representing a value for each data point defined in `"aggregatable_trigger_data"`. In each case, the property name is equal to the name defined in `"source_keys"`, and the property value is whatever arbitrary value you require. - `"debug_key"` {{optional_inline}} - - : A number representing a debug key. Set this if you want to generate a [debug report](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#debug_reports) alongside the associated attribution report. + - : A number representing a debug key. Set this if you want to generate a debug report alongside the associated attribution report. - `"debug_reporting"` {{optional_inline}} - : A boolean value. If a `debug_key` is set, set this to `true` to specify that the generated debug report should be a verbose debug report. - `"filters"` {{optional_inline}} - - : An object containing custom data that can be used to filter which triggers generate reports. See [Filters](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#filters) for more details. + - : An object containing custom data that can be used to filter which triggers generate reports. - `"event_trigger_data"` - : An object representing data about the trigger. Available sub-fields are as follows: - `"trigger_data"` @@ -67,11 +67,11 @@ Attribution-Reporting-Register-Trigger: > The values used to represent each event, and the number of elements in the array, are completely arbitrary and defined by you as the developer. The array may contain values that are not used, but values must be present in the array to be attributed to the source by the browser when a trigger is registered. - `"priority"` {{optional_inline}} - - : A string representing a priority value for the attribution trigger. By default, triggers are attributed to the most recent matching source. For both event-level and summary reports you set a higher priority number to make the trigger match older sources. For example, a value of `2` takes priority over the default value of `1`. See [Report priorities and limits](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#report_priorities_and_limits) for more information. + - : A string representing a priority value for the attribution trigger. By default, triggers are attributed to the most recent matching source. For both event-level and summary reports you set a higher priority number to make the trigger match older sources. For example, a value of `2` takes priority over the default value of `1`. - `"deduplication_key"` {{optional_inline}} - : A string representing a unique key that can be used to prevent attributions from being duplicated — for example if a user were to add the same item to a shopping cart multiple times. See [Prevent duplication in reports](https://privacysandbox.google.com/private-advertising/attribution-reporting/prevent-duplication) for more information. - `"filters"` {{optional_inline}} - - : An object containing filters that perform selective filtering to set `"trigger_data"`, `"priority"`, and `"deduplication_key"` based on the `filter_data` set in a corresponding {{HTTPHeader("Attribution-Reporting-Register-Source")}} header. See [Filters](/en-US/docs/Web/API/Attribution_Reporting_API/Generating_reports#filters) for more information. + - : An object containing filters that perform selective filtering to set `"trigger_data"`, `"priority"`, and `"deduplication_key"` based on the `filter_data` set in a corresponding {{HTTPHeader("Attribution-Reporting-Register-Source")}} header. ## Examples diff --git a/files/jsondata/GroupData.json b/files/jsondata/GroupData.json index e5659e31e995733..281fa5c797583b0 100644 --- a/files/jsondata/GroupData.json +++ b/files/jsondata/GroupData.json @@ -2,11 +2,7 @@ { "Attribution Reporting API": { "overview": ["Attribution Reporting API"], - "guides": [ - "/docs/Web/API/Attribution_Reporting_API/Registering_sources", - "/docs/Web/API/Attribution_Reporting_API/Registering_triggers", - "/docs/Web/API/Attribution_Reporting_API/Generating_reports" - ], + "guides": [], "methods": [ "Window.fetch()", "XMLHttpRequest.setAttributionReporting()",