<title>A File Format for the Discoverable Use of Analytics</title>
<metacontent="Frederik Ring"name="author">
<metacontent="Hendrik Niefeld"name="author">
<metacontent="
Internet privacy has become an important feature for users of websites and services.
This document proposes a way for websites and services to declare and disclose their usage of analytics and tracking software.
analytics.txt aims to be an elaborate file format that describes the privacy related characteristics of analytics and tracking software in a non-biased way.
An analytics.txt file is understandable for a non-technical audience, while also useful for the automated consumption by tools and software.
<pid="section-abstract-1">Internet privacy has become an important feature for users of websites and services.
This document proposes a way for websites and services to declare and disclose their usage of analytics and tracking software.
analytics.txt aims to be an elaborate file format that describes the privacy related characteristics of analytics and tracking software in a non-biased way.
An analytics.txt file is understandable for a non-technical audience, while also useful for the automated consumption by tools and software.<ahref="#section-abstract-1"class="pilcrow">ΒΆ</a></p>
<ahref="#name-status-of-this-memo"class="section-name selfRef">Status of This Memo</a>
</h2>
<pid="section-boilerplate.1-1">
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.<ahref="#section-boilerplate.1-1"class="pilcrow">ΒΆ</a></p>
<pid="section-boilerplate.1-2">
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
at <span><ahref="https://datatracker.ietf.org/drafts/current/">https://datatracker.ietf.org/drafts/current/</a></span>.<ahref="#section-boilerplate.1-2"class="pilcrow">ΒΆ</a></p>
<pid="section-boilerplate.1-3">
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."<ahref="#section-boilerplate.1-3"class="pilcrow">ΒΆ</a></p>
<pid="section-toc.1-1.1.2.2.1"class="keepWithNext"><ahref="#section-1.2"class="xref">1.2</a>.Β Β <ahref="#name-scope-of-this-proposal"class="xref">Scope of this proposal</a></p>
<pid="section-toc.1-1.1.2.2.2.1.1"class="keepWithNext"><ahref="#section-1.2.1"class="xref">1.2.1</a>.Β Β <ahref="#name-about-providing-a-human-rea"class="xref">About providing a human readable format</a></p>
<pid="section-toc.1-1.1.2.3.1"><ahref="#section-1.3"class="xref">1.3</a>.Β Β <ahref="#name-definition-of-the-term-anal"class="xref">Definition of the term "analytics" in the scope of this document</a></p>
<pid="section-toc.1-1.2.1"><ahref="#section-2"class="xref">2</a>.Β Β <ahref="#name-conventions-and-definitions"class="xref">Conventions and Definitions</a></p>
<pid="section-toc.1-1.3.2.5.2.1.1"><ahref="#section-3.5.1"class="xref">3.5.1</a>.Β Β <ahref="#name-a-site-using-analytics"class="xref">A site using analytics</a></p>
<pid="section-toc.1-1.3.2.5.2.3.1"><ahref="#section-3.5.3"class="xref">3.5.3</a>.Β Β <ahref="#name-a-site-not-using-any-analyt"class="xref">A site not using any analytics</a></p>
<pid="section-toc.1-1.4.1"><ahref="#section-4"class="xref">4</a>.Β Β <ahref="#name-location-of-the-analyticstx"class="xref">Location of the analytics.txt file</a></p>
<pid="section-toc.1-1.5.2.1.1"><ahref="#section-5.1"class="xref">5.1</a>.Β Β <ahref="#name-incorrect-or-stale-informat"class="xref">Incorrect or stale information</a></p>
<pid="section-1.1-1">User tracking and the utilization of analytics software on websites has become a widely employed routine, visibly and invisibly affecting the way the user facing internet works and behaves.
Yet, there is no well-defined way of accessing information about what software is being used and what kind of data it is collecting in a standardized way.
Legislation can only ever cover a subset of the range of existing technological implementations, creating incentives for software to find workarounds, thus allowing them to hide their presence from users.
Automated audits are limited to aspects that are possible to detect in clients, but cannot disclose other important implementation details.<ahref="#section-1.1-1"class="pilcrow">ΒΆ</a></p>
</section>
</div>
<divid="scope-of-this-proposal">
<sectionid="section-1.2">
<h3id="name-scope-of-this-proposal">
<ahref="#section-1.2"class="section-number selfRef">1.2. </a><ahref="#name-scope-of-this-proposal"class="section-name selfRef">Scope of this proposal</a>
</h3>
<pid="section-1.2-1">This document defines a way to specify the privacy related characteristics of analytics and tracking software.
We aim for this information to be consumable both by humans as well as software.<ahref="#section-1.2-1"class="pilcrow">ΒΆ</a></p>
<pid="section-1.2-2">The file "analytics.txt" is not intended to replace the requirement for complying with existing regulations, but supposed to give insights beyond the scope of these regulations.<ahref="#section-1.2-2"class="pilcrow">ΒΆ</a></p>
<divid="about-providing-a-human-readable-format">
<sectionid="section-1.2.1">
<h4id="name-about-providing-a-human-rea">
<ahref="#section-1.2.1"class="section-number selfRef">1.2.1. </a><ahref="#name-about-providing-a-human-rea"class="section-name selfRef">About providing a human readable format</a>
</h4>
<pid="section-1.2.1-1">A fundamental design goal of the "analytics.txt" format is to make such a file human readable.
While the percentage of consumers that are actually human beings will likely be low - browser extensions or search engines would be good examples of possible consumers - this tenet can drive the specification into a direction where the format will focus on providing information that is useful for human beings, even when captured and processed further by other software.<ahref="#section-1.2.1-1"class="pilcrow">ΒΆ</a></p>
<ahref="#section-1.3"class="section-number selfRef">1.3. </a><ahref="#name-definition-of-the-term-anal"class="section-name selfRef">Definition of the term "analytics" in the scope of this document</a>
</h3>
<pid="section-1.3-1">Analytics as referred to in this document involves the collection of usage statistics in order to generate reports that can help the providers of websites and services to better understand and optimize their services towards real world user behavior.
This can also include measuring different content against different groups of users.<ahref="#section-1.3-1"class="pilcrow">ΒΆ</a></p>
</section>
</div>
<divid="verifying-the-provided-information">
<sectionid="section-1.4">
<h3id="name-verifying-the-provided-info">
<ahref="#section-1.4"class="section-number selfRef">1.4. </a><ahref="#name-verifying-the-provided-info"class="section-name selfRef">Verifying the provided information</a>
</h3>
<pid="section-1.4-1">"analytics.txt" is designed to provide insights beyond what is technically auditable from a client perspective.
While some characteristics could be determined automatically or manually at client level, others won't, and will rely on implementors providing correct information about what is happening at layers that are opaque to users.
This means consumers of an "analytics.txt" file will implictly need to trust the implementor to provide correct information, implicating two design goals for the format (technical implications are discussed in <ahref="#incorrect-information"class="xref">Section 5.1</a>).<ahref="#section-1.4-1"class="pilcrow">ΒΆ</a></p>
<pid="section-1.4.1-1">All of the given datapoints are purely informational, there is no right or wrong option to choose from, and the format will never provide guidelines on how to assess or rate an "analytics.txt" file.
Based on this, implementors don't have strong incentives for providing incorrect information, but choose implementation because they are wishing to disclose information about their site that they otherwise couldn't.<ahref="#section-1.4.1-1"class="pilcrow">ΒΆ</a></p>
<pid="section-1.4.2-1">An "analytics.txt" file should never be the canonical source of truth for making automated decisions or ratings about a site.
It is supposed to be one of multiple signals that can be used for assessing the behavior of a website, creating the possibility to connect and compare the provided data with what has been surveyed using other channels of information.<ahref="#section-1.4.2-1"class="pilcrow">ΒΆ</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<divid="conventions-and-definitions">
<sectionid="section-2">
<h2id="name-conventions-and-definitions">
<ahref="#section-2"class="section-number selfRef">2. </a><ahref="#name-conventions-and-definitions"class="section-name selfRef">Conventions and Definitions</a>
</h2>
<pid="section-2-1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <span>[<ahref="#RFC2119"class="xref">RFC2119</a>]</span><span>[<ahref="#RFC8174"class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals, as shown here.<ahref="#section-2-1"class="pilcrow">ΒΆ</a></p>
<pid="section-2-2">The term "implementors" refers to the providers of services and websites that wish to use an analytics.txt file.<ahref="#section-2-2"class="pilcrow">ΒΆ</a></p>
<pid="section-3-1">This document defines a text file format that can be used by implementors to signal information about their usage of analytics software to both users and software.<ahref="#section-3-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3-2">By convention, this file is called "analytics.txt".
Its location and scope are described in <ahref="#location"class="xref">Section 4</a>.<ahref="#section-3-2"class="pilcrow">ΒΆ</a></p>
<pid="section-3-3">This text file contains multiple fields with different values.
A field contains a "name" which is the first part of a field all the way up to the colon (for example: "Author:") and follows the syntax defined for "field-name" in section 3.6.8 of <span>[<ahref="#RFC5322"class="xref">RFC5322</a>]</span>.
Field names are case-insensitive (as per section 2.3 of <span>[<ahref="#RFC5234"class="xref">RFC5234</a>]</span>).
The "value" comes after the field name and follows the syntax defined for "unstructured" in section 3.2.5 of <span>[<ahref="#RFC5322"class="xref">RFC5322</a>]</span>.
The file MAY also contain blank lines and comments.<ahref="#section-3-3"class="pilcrow">ΒΆ</a></p>
<pid="section-3-4">A field MUST always consist of a name and a value (for example: "Author: Jane Doe <ahref="mailto:jane.doe@example.com">jane.doe@example.com</a>").
Each field MUST appear on its own line.
Unless specified otherwise by the field definition, multiple values MUST be chained together for a single field (for example: "Implements: gdpr, ccpa") using the "," character (%x2c).
A field MAY NOT appear multiple times.<ahref="#section-3-4"class="pilcrow">ΒΆ</a></p>
<pid="section-3-5">Implementors SHOULD aim for authoring an analytics.txt file that is easy to understand by non-technical audiences.<ahref="#section-3-5"class="pilcrow">ΒΆ</a></p>
<pid="section-3.1-1">Any line beginning with the "#" (%x23) symbol MUST be interpreted as a comment.
The content of the comment may contain any ASCII or Unicode characters in the %x21-7E and %x80-FFFFF ranges plus the tab (%x09) and space (%x20) characters.<ahref="#section-3.1-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.1-4">Implementors SHOULD make deliberate use of comments to make an analytics.txt file more accessible for non-technical audiences.<ahref="#section-3.1-4"class="pilcrow">ΒΆ</a></p>
<pid="section-3.2-1">Every line MUST end either with a carriage return and line feed characters (CRLF / %x0D %x0A) or just a line feed character (LF / %x0A).<ahref="#section-3.2-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.3-1">Like many other formats and protocols, this format may need to be extended over time to fit the ever-changing landscape of the Internet.
Special attention is required for defining the allowed values in enumerations to ensure they are a. extendable and b. do not become obsolete too quickly.<ahref="#section-3.3-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4-1">Field names are case-insensitive, yet implementors SHOULD use the capitalized style used in this document for consistency.<ahref="#section-3.4-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4-2">Field values are case-insensitive.
Unless otherwise specified, implementors MUST refer to the allowed values for a field given by the specification.<ahref="#section-3.4-2"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.1-1">This REQUIRED field holds an OPTIONAL display name and a REQUIRED email address ("name-addr") as per section 3.4 of <span>[<ahref="#RFC5322"class="xref">RFC5322</a>]</span> providing information about a person or entity responsible for maintaining the contents of the file.
The field MUST contain a valid email address which shall be used for inquiries about the correctness and additions to the data provided in the file.<ahref="#section-3.4.1-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.2-1">This REQUIRED multi-value field indicates which potentially privacy relevant user specific data is being collected or used in session identification or other procedures.
These values MUST also be specified if a property is not persisted as-is, but stored or processed in a hashed and/or combined form.
Some of the allowed values overlap to a certain extent, e.g. a User Agent string might be used in a Browser Fingerprint.<ahref="#section-3.4.2-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.2.1.1-1">No analytics data is collected at all. This value MUST NOT be used in conjunction with other values.<ahref="#section-3.4.2.1.1-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.2.1.2-1">The URL of a visit, including its path, is collected and used.
This MUST also be specified in case URLs are stripped of certain parameters or pseudonymized before being stored.<ahref="#section-3.4.2.1.2-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.2.1.7-1">Browser Fingerprinting is used.
Such mechanisms usually try to compute a unique identifier from properties of the host Operating System, allowing them to re-identify users without having to persist an identifier.<ahref="#section-3.4.2.1.7-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.2.1.8-1">The user's device type (e.g. mobile / tablet / desktop) is being determined and collected.
The categories and rules for this distinction might be different for different software solutions.<ahref="#section-3.4.2.1.8-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.2.1.9-1">The Referrer of a visit is collected and used. This MUST also be specified if the referrer value is stripped of potential path fragments.<ahref="#section-3.4.2.1.9-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.2.1.10-1">The duration of a visit, either on page- or on session-level is measured and used.<ahref="#section-3.4.2.1.10-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.2.1.11-1">Custom events like conversion goals are defined and used.
This MAY be left out in case the analytics software in use offers such functionality, but implementors chose not to use the feature.<ahref="#section-3.4.2.1.11-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.2.1.12-1">Detailed behavior like mouse movement and scrolling is recorded and can possibly be played back when analyzing the analytics data.<ahref="#section-3.4.2.1.12-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.3-1">This field is REQUIRED unless the only value of the Collects field as per <ahref="#collects-field"class="xref">Section 3.4.2</a> is none.
The multi-value field indicates whether data is persisted on the client during the collection of analytics data and declares the browser features used for doing so.
In case no data is being persisted at all, the value none MUST be used as the single entry for this field.<ahref="#section-3.4.3-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.3.1.2-1">First party cookies are in use.
There is no differentiation between session or persistent cookies, just like HTTP and JavaScript cookies are considered equal.<ahref="#section-3.4.3.1.2-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.3.1.3-1">Third party cookies are in use.
There is no differentiation between session or persistent cookies, just like HTTP and JavaScript cookies are considered equal.<ahref="#section-3.4.3.1.3-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.3.1.4-1">Data is persisted on the client using non-cookie JavaScript APIs like <code>localStorage</code>, <code>sessionStorage</code>, <code>WebSQL</code> or <code>IndexedDB</code><ahref="#section-3.4.3.1.4-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.3.1.5-1">The analytics software leverages browser cache mechanisms to store identifiers.
For example, ETag headers can be used to identify users based on their browser caches' contents.
This value is not required in case the analytics software sends static resources with cache headers, but does not make use of the request headers on subsequent requests for purposes other than managing caching of assets.<ahref="#section-3.4.3.1.5-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.4-1">This field is REQUIRED unless the only value of the Collects field <ahref="#collects-field"class="xref">Section 3.4.2</a> is none.
The multi-value field indicates the technical implementation details for how analytics data is being collected.<ahref="#section-3.4.4-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.4.1.2-1">A static resource - typically a pixel - transferred via HTTP is being used to collect data through the request parameters.<ahref="#section-3.4.4.1.2-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.5-1">This field is REQUIRED unless the only value of the Collects field <ahref="#collects-field"class="xref">Section 3.4.2</a> is none.
The multi-value field discloses information about whether user consent is being acquired before collecting analytics data, and if it is possible for users to opt out of the collection of usage data.<ahref="#section-3.4.5-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.6-1">This field is REQUIRED unless the only value of the Collects field <ahref="#collects-field"class="xref">Section 3.4.2</a> is none.
The single-value field indicates the duration for which the analytics data is being stored before being deleted. This duration MUST also cover periods where data might transition to be stored in aggregated form only.
The value is either a duration in days (including the days suffix), or the token "perpetual" in case data is retained without expiring it at some point.
A day is defined as 24 hours.
In case the retention period does not divide evenly into days, it MUST be brought up to the next round figure.<ahref="#section-3.4.6-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.7-1">This OPTIONAL, RECOMMENDED multi-value field indicates which browser level privacy controls are being honored when collecting data.<ahref="#section-3.4.7-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.7.1.2-1">User-Agents that have DoNotTrack <span>[<ahref="#DNT"class="xref">DNT</a>]</span> enabled will be excluded from the collection of analytics data.<ahref="#section-3.4.7.1.2-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.7.1.3-1">User agents that have Global Privacy Control <span>[<ahref="#GPC"class="xref">GPC</a>]</span> enabled will be excluded from the collection of analytics data.<ahref="#section-3.4.7.1.3-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.8-1">This OPTIONAL, RECOMMENDED multi-value field indicates the coverage in session and user lifecycle tracking.<ahref="#section-3.4.8-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.8.1.2-1">Metrics that source from a single browser session can be grouped and distinguished as such.<ahref="#section-3.4.8.1.2-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.9.1.2-1">Content experiments are performed by grouping users randomly into buckets and serving them different content.<ahref="#section-3.4.9.1.2-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.9.1.3-1">Content experiments are performed by targeting user based on their geographic location.<ahref="#section-3.4.9.1.3-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.9.1.4-1">Content experiments are performed by grouping users into buckets based on their behavior and serving them different content.<ahref="#section-3.4.9.1.4-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.10-1">This OPTIONAL, RECOMMENDED multi-value field indicates whether data is shared with select users, the general public or third parties.<ahref="#section-3.4.10-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.10.1.1-1">The data collected is not shared with any party unless directly affiliated with the implementor, e.g. employees.<ahref="#section-3.4.10.1.1-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.10.1.2-1">Users can access the usage data that is associated with them in a non-aggregated way, isolating all data that is specific to their current means of re-identification.<ahref="#section-3.4.10.1.2-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.10.1.3-1">Usage statistics for the site or service are available to the general public.<ahref="#section-3.4.10.1.3-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.11-1">This OPTIONAL field indicates conformance with existing regulations and legislation. Values for this field SHOULD use all lowercase tokens with whitespace being replaced by the dash character (%x2d).<ahref="#section-3.4.11-1"class="pilcrow">ΒΆ</a></p>
<pid="section-3.4.12-1">This OPTIONAL field indicates which software is being used for collecting analytics. Values for this field SHOULD use all lowercase tokens with whitespace being replaced by the dash character (%x2d).<ahref="#section-3.4.12-1"class="pilcrow">ΒΆ</a></p>
<ahref="#section-3.5"class="section-number selfRef">3.5. </a><ahref="#name-examples-of-analyticstxt-fi"class="section-name selfRef">Examples of analytics.txt files</a>
</h3>
<divid="a-site-using-analytics">
<sectionid="section-3.5.1">
<h4id="name-a-site-using-analytics">
<ahref="#section-3.5.1"class="section-number selfRef">3.5.1. </a><ahref="#name-a-site-using-analytics"class="section-name selfRef">A site using analytics</a>
<ahref="#section-3.5.3"class="section-number selfRef">3.5.3. </a><ahref="#name-a-site-not-using-any-analyt"class="section-name selfRef">A site not using any analytics</a>
<ahref="#section-4"class="section-number selfRef">4. </a><ahref="#name-location-of-the-analyticstx"class="section-name selfRef">Location of the analytics.txt file</a>
</h2>
<pid="section-4-1">By default, an analytics.txt file SHOULD be placed in the ".well-known" location as per <span>[<ahref="#RFC8615"class="xref">RFC8615</a>]</span> of a domain name or IP address.<ahref="#section-4-1"class="pilcrow">ΒΆ</a></p>
<pid="section-4.1-1">In case implementors are unable to meet this requirement, other options are available.<ahref="#section-4.1-1"class="pilcrow">ΒΆ</a></p>
<pid="section-4.1.1-1">Implementors MAY signal the location of an analytics.txt file in the context of a HTML document using a link element of rel "analytics"<ahref="#section-4.1.1-1"class="pilcrow">ΒΆ</a></p>
<pid="section-4.1.2-1">Implementors MAY send an HTTP header of <code>X-Analytics-Txt</code> with a response, sending the URI of the applicable file.<ahref="#section-4.1.2-1"class="pilcrow">ΒΆ</a></p>
<ahref="#section-4.3"class="section-number selfRef">4.3. </a><ahref="#name-scope-of-a-file"class="section-name selfRef">Scope of a file</a>
</h3>
<pid="section-4.3-1">An analytics.txt file located in the ".well-known" location MUST only apply to the domain or IP address of the URI used to retrieve it, and SHALL NOT apply to any of its subdomains or parent domains.
If the location is signaled using the HTTP Header or in the document markup itself, its scope SHALL be limited to the requested resource only.<ahref="#section-4.3-1"class="pilcrow">ΒΆ</a></p>
<pid="section-4.3-2">If distributed in non-standard locations, an analytics.txt file MAY also apply to products and services provided by the organization publishing the file (e.g. desktop or mobile applications) and which cannot be mapped to a domain name or IP address.
In such cases, implementors MUST add sufficient commentary describing the applicable scope.<ahref="#section-4.3-2"class="pilcrow">ΒΆ</a></p>
<ahref="#section-5.1"class="section-number selfRef">5.1. </a><ahref="#name-incorrect-or-stale-informat"class="section-name selfRef">Incorrect or stale information</a>
</h3>
<pid="section-5.1-1">If information given in an "analytics.txt" file is incorrect or not kept up to date, this can result in usage of services under wrong assumptions, thus exposing users to possibly unwanted data collection and handling.
Not having an "analytics.txt" file may be preferable to having incorrect or stale information in this file.
This guideline also applies to field level: in case of ambiguities or uncertainties, it's recommended to omit a field or a value rather than providing incorrect information.
Implementors MUST use the "Author" field (see <ahref="#author-field"class="xref">Section 3.4.1</a>) to allow inquiries about the correctness of the given information.<ahref="#section-5.1-1"class="pilcrow">ΒΆ</a></p>
<pid="section-5.2-1">Implementors should be aware that disclosing mandatory author information as per <ahref="#author-field"class="xref">Section 3.4.1</a> in such a file exposes them to possible Spam schemes or spurious requests.<ahref="#section-5.2-1"class="pilcrow">ΒΆ</a></p>
<pid="section-5.3-1">In multi-user / multi-tenant environments, it may possible for a single user to take over the location of the "/.well-known/analytics.txt" file which would also apply to others.
Organizations should ensure the ".well-known" location is properly protected. Implementors can instead use other locations as per <ahref="#location"class="xref">Section 4</a> in such scenarios.<ahref="#section-5.3-1"class="pilcrow">ΒΆ</a></p>
<pid="section-6.1-1">The "Well-Known URIs" registry should be updated with the following additional values (using the template from <span>[<ahref="#RFC8615"class="xref">RFC8615</a>]</span>):<ahref="#section-6.1-1"class="pilcrow">ΒΆ</a></p>
<spanclass="refAuthor">Bradner, S.</span>, <spanclass="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <spanclass="seriesInfo">BCP 14</span>, <spanclass="seriesInfo">RFC 2119</span>, <spanclass="seriesInfo">DOI 10.17487/RFC2119</span>, <timedatetime="1997-03"class="refDate">March 1997</time>, <span><<ahref="https://datatracker.ietf.org/doc/html/rfc2119">https://datatracker.ietf.org/doc/html/rfc2119</a>></span>. </dd>
<spanclass="refAuthor">Berjon, R.</span>, <spanclass="refAuthor">Zimmeck, S.</span>, <spanclass="refAuthor">Soltani, A.</span>, <spanclass="refAuthor">Harbage, D.</span>, and <spanclass="refAuthor">P. Snyder</span>, <spanclass="refTitle">"Global Privacy Control (GPC)"</span>, <span>n.d.</span>, <span><<ahref="https://globalprivacycontrol.github.io/gpc-spec/">https://globalprivacycontrol.github.io/gpc-spec/</a>></span>. </dd>
<ddclass="break"></dd>
<dtid="RFC5234">[RFC5234]</dt>
<dd>
<spanclass="refAuthor">Crocker, D., Ed.</span> and <spanclass="refAuthor">P. Overell</span>, <spanclass="refTitle">"Augmented BNF for Syntax Specifications: ABNF"</span>, <spanclass="seriesInfo">STD 68</span>, <spanclass="seriesInfo">RFC 5234</span>, <spanclass="seriesInfo">DOI 10.17487/RFC5234</span>, <timedatetime="2008-01"class="refDate">January 2008</time>, <span><<ahref="https://datatracker.ietf.org/doc/html/rfc5234">https://datatracker.ietf.org/doc/html/rfc5234</a>></span>. </dd>
<ddclass="break"></dd>
</dl>
</section>
</section>
<divid="acknowledgments">
<sectionid="appendix-A">
<h2id="name-acknowledgments">
<ahref="#appendix-A"class="section-number selfRef">Appendix A. </a><ahref="#name-acknowledgments"class="section-name selfRef">Acknowledgments</a>
</h2>
<pid="appendix-A-1">The authors would like to acknowledge the feedback and input provided during the creation of this document as given by Michiel Leenaars, Cyrill Kraehenbuehl, Lasse Voss.<ahref="#appendix-A-1"class="pilcrow">ΒΆ</a></p>
