Clarifying tag key parameters

content/en/getting_started/tagging/_index.md

@@ -32,10 +32,10 @@ algolia:
 
 Tags are a way of adding dimensions to Datadog telemetries so they can be filtered, aggregated, and compared in Datadog visualizations. [Using tags][1] enables you to observe aggregate performance across several hosts and (optionally) narrow the set further based on specific elements. In summary, tagging is a method to observe aggregate datapoints.
 
-Tags are `key:value` pairs containing two parts:
+A tag can be formatted as `<key>:<value>` or `<value>`. It is recommended to use the `<key>:<value>` format, as it is often semantically clearer and allows for richer querying capabilities (for example, grouping by key). When using a `<key>:<value>` pair:
 
-- The tag **key** is the identifier. The tag key is case sensitive.
-- The tag **value** is the specific data or information associated with the key. Tag values are not unique per resource and can be used across many resources in a `key:value` pair.
+- The tag **key** is the identifier. Commonly used tag keys are `env`, `instance`, and `name`.
+- The tag **value** is the specific data or information associated with the key. Tag values are not unique per resource and can be used across many resources in a `<key>:<value>` pair.
 
 Tagging binds different data types in Datadog, allowing for correlation and calls to action between metrics, traces, and logs. This is accomplished with **reserved** tag keys:
 | Tag key   | Allows for                                                             |
@@ -54,31 +54,32 @@ Because containers and cloud environments regularly churn through hosts, using t
 
 ## Define tags
 
-Below are Datadog's tagging requirements:
+Tag strings (that is, the entire content of `<key>:<value>` or `<value>`) must meet the following requirements:
 
-1. Tags must **start with a letter** and after that may contain the characters listed below:
+- Tag strings must **start with a letter** (this applies regardless of whether the tag uses the format `<key>:<value>` or `<value>`). After the leading letter, the tag string may contain the characters listed below:
 
-    - Alphanumerics
-    - Underscores
+    - Letters (all Unicode letters are supported---for example, a, ó, 気, 녕, ك, and ดี)
+    - Numbers
+    - Underscores (leading/trailing underscores are stripped, and contiguous underscores are collapsed into one)
     - Minuses
     - Colons
-    - Commas
     - Periods
-    - Slashes
+    - Forward slashes
 
-    Other special characters are converted to underscores.
+    All other characters (including, but not limited to, commas, emoji, and spaces) are converted to underscores.
 
-2. Tags can be **up to 200 characters** long and support Unicode letters (which includes most character sets, including languages such as Japanese).
-3. Tags are converted to lowercase. Therefore, `CamelCase` tags are not recommended. Authentication (crawler) based integrations convert camel case tags to underscores, for example `TestTag` --> `test_tag`.
-4. A tag can be in the format `value` or `<KEY>:<VALUE>`. Commonly used tag keys are `env`, `instance`, and `name`. The key always precedes the first colon of the global tag definition, for example:
+- Tags can be **up to 200 characters** long. If the tag has the format `<key>:<value>`, the `<key>`, `:`, and `<value>` all count toward the character limit.
+- [Span tags][26] and metric tags are normalized to lowercase. Because of this, using `CamelCase` is not recommended. Authentication (crawler) based integrations also convert camel case tags to underscores before lowercasing, for example `TestTag` --> `test_tag`.
+    - Separate from tags, [span attributes][27] and log attributes are case-sensitive, and are not normalized.
+- When using the format `<key>:<value>`, the key always precedes the first colon of the global tag definition. For example:
 
     | Tag                | Key           | Value          |
     | ------------------ | ------------- | -------------- |
     | `env:staging:east` | `env`         | `staging:east` |
     | `env_staging:east` | `env_staging` | `east`         |
 
-5. Tags should not originate from unbounded sources, such as epoch timestamps, user IDs, or request IDs. Doing so may infinitely [increase the number of metrics][2] for your organization and impact your billing.
-6. Limitations (such as downcasing) only apply to metric tags, not log attributes or span tags.
+- Tags should not originate from unbounded sources, such as epoch timestamps, user IDs, or request IDs. Doing so may infinitely [increase the number of metrics][2] for your organization and impact your billing.
+
 
 ## Assign tags
 
@@ -171,4 +172,6 @@ For more information, see [Using Tags][1].
 [22]: /getting_started/tagging/using_tags/#developers
 [23]: /account_management/billing/usage_attribution/
 [24]: /getting_started/tagging/using_tags/#ci-visibility
-[25]: /containers/troubleshooting/log-collection?tab=datadogoperator#missing-host-level-tags-on-new-hosts-or-nodes
+[25]: /containers/troubleshooting/log-collection?tab=datadogoperator#missing-host-level-tags-on-new-hosts-or-nodes
+[26]: /tracing/trace_collection/tracing_naming_convention/#span-tags
+[27]: /tracing/trace_collection/tracing_naming_convention/#span-attributes

content/en/glossary/terms/span_tag.md

@@ -4,6 +4,6 @@ core_product:
   - apm
 ---
 
-A span tag is a tag that is applied to a [span][1], in the form of a key-value pair, to correlate a request with other telemetry (or to filter it in searches). Tags can be added to a single span or globally to all spans. 
+A span tag is a tag that is applied to a [span][1], in the form of a key-value pair, to correlate a request with other telemetry (or to filter it in searches). Tags can be added to a single span or globally to all spans. For more information, <a href="/tracing/trace_collection/tracing_naming_convention/">see the documentation</a>.
 
 [1]: /glossary/#span