> For the complete documentation index, see [llms.txt](https://docs.userlane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.userlane.com/intelligence/tags.md).

# Tags

A tag is a tracking marker attached to a single element in a customer's application. It counts how many times end users click that element, without showing anything on screen.

Tags are invisible to the people using the application: someone clicks a button or a link as they normally would, and a tracking event fires in the background. Tags sit under Intelligence[^1] because they produce measurement data, even though they are authored in the Editor[^2]. Creating and managing tags is covered in [Create a tag in the Editor](/intelligence/tags/create-a-tag-in-the-editor.md).

## How tags differ from tasks

Tags and [Tasks](/intelligence/tasks.md) both measure what end users do, and neither is visible on screen. The difference is scope. A tag tracks a single interaction: one element, one click. A task tracks a multi-step workflow from start to finish and measures whether people complete it.

<table><thead><tr><th width="178.765625"></th><th width="270.359375">Tag</th><th>Task</th></tr></thead><tbody><tr><td>What it tracks</td><td>A single interaction with one element</td><td>A multi-step workflow from start to finish</td></tr><tr><td>What it measures</td><td>Click count per element, broken down by time and audience</td><td>Completion rate, median time to complete, per-action drop-off</td></tr><tr><td>What it feeds</td><td>Standalone analytics on the Tasks page in the portal</td><td>The <a href="/intelligence/heart/task-success.md">Task Success</a> dimension of HEART</td></tr><tr><td>When to use it</td><td>Tracking whether a specific button, link, or feature gets used</td><td>Measuring whether people complete a defined process end to end</td></tr></tbody></table>

## What a tag measures and how it works

A tag counts clicks on its target element and reports the total on the Tasks page in the portal. To see tag data, open **Intelligence** > **Tasks** in the sidebar, then select the **Tags** toggle at the top of the page. The view shows two summary figures (total interactions and total users), an interactions-over-time chart, and a table listing every tag with its name, the date it was tagged, total interactions, unique users, and the percentage of all users who interacted.

<div data-with-frame="true"><figure><img src="https://259567114-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FF6bxg8i3T6U4vZ3k7PHi%2Fuploads%2FvNvoE2IcB8xQTlMrNZih%2Ftags.png?alt=media&#x26;token=c4de853c-4642-4893-95e3-519c2b4e8933" alt="Tags view on the Tasks page in the Userlane portal"><figcaption><p>The Tags toggle on the Tasks page shows interactions for every tag.</p></figcaption></figure></div>

Tags are created in the Editor by selecting the element to track, either visually or by entering a CSS selector. Each tag gets an automatic name based on the element's text (for example, "Submit button" or "Accounts link"), which you can edit afterwards. By default a tag tracks the element everywhere its selector matches, but you can scope it to specific pages through display rules.

## What people usually use tags for

Tags work best as lightweight probes. They answer narrow questions about whether particular elements get used, without the overhead of defining a full workflow.

**Validating a new feature or layout change.** After a UI update ships, place a tag on the new element and watch whether interaction volume meets expectations. If a redesigned navigation menu replaces an old one, tags on both the old and new paths show whether users have found the change.

**Establishing a starting point before deploying a guide.** Tag the action you plan to guide users toward, measure the current click rate for a few weeks, then compare after the guide goes live. The before-and-after difference is direct evidence of whether the guide changed behavior.

**Answering ad-hoc questions from stakeholders.** When someone asks "does anyone actually use the advanced search?", a tag on that element gives a concrete answer by the next analytics refresh, without waiting for your engineering team to add instrumentation.

**Monitoring critical actions without building a full task.** Some interactions matter on their own, not as part of a sequence. A **Submit** button on a compliance form, a **Log out** link in a secure environment, or an **Approve** action in a review workflow are all cases where a single click count is the right measurement.

## Limitations

1. Tags track left clicks only. Hover, form submission, keyboard actions, and right-click are not tracked.
2. Tags have no audience scoping. A published tag tracks every user who clicks the target element, regardless of role or audience. Filtering by audience is available in the portal's analytics views, but not in the tag definition.

## Relevant articles

{% content-ref url="/pages/DbuU3EtVubYDfoPt5F6W" %}
[Create a tag in the Editor](/intelligence/tags/create-a-tag-in-the-editor.md)
{% endcontent-ref %}

{% content-ref url="/pages/nJSkeXwSmCTopscQ7Fmx" %}
[Tasks](/intelligence/tasks.md)
{% endcontent-ref %}

{% content-ref url="/pages/eQPgnZdiJgIJ0ByK3cM1" %}
[Creating selectors](/assistance/in-app-guidance/creating-selectors.md)
{% endcontent-ref %}

{% content-ref url="/pages/pFJIN3rpdCcXyo6ifg4j" %}
[Export HEART, NPS, Survey, Tag, and Task data via API](/developer-reference/export-heart-nps-survey-tag-and-task-data-via-api.md)
{% endcontent-ref %}

## FAQ

<details>

<summary>What is the difference between a tag and a task?</summary>

A tag tracks a single interaction: one click on one element. A task tracks a multi-step workflow and measures completion rate, time, and per-action drop-off. Use a tag when a single action is the question, and a task when a process is.

</details>

<details>

<summary>Are tags visible to end users?</summary>

No. Tags run in the background. The end user clicks the element as they normally would, and a tracking event fires without any visible change to the application.

</details>

<details>

<summary>Do tags feed HEART?</summary>

No. Tags are standalone. Task Success is calculated from tasks, not tags. Tag analytics are reported separately on the Tasks page in the portal, under the **Tags** toggle.

</details>

<details>

<summary>Can a tag be scoped to specific pages?</summary>

Yes. By default a tag tracks the element everywhere its selector matches, but you can scope it to specific pages through display rules. The **Choose where the tag is tracked** setting in the Editor controls this.

</details>

<details>

<summary>What happens when a tag is deactivated?</summary>

Tracking stops and no new events are recorded, but historical analytics data is kept on the Tasks page. The tag returns to a private (draft) state in the Editor and can be reactivated later.

</details>

<details>

<summary>Do tags work on self-hosted deployments?</summary>

No. Tags require the cloud-hosted Userlane deployment. Self-hosted environments do not support tag tracking.

</details>

[^1]: Intelligence is the part of Userlane that shows how well each application works for the people using it and proves what changed. It includes the HEART Score, Goals, Tasks and Tags, and Surveys.

[^2]: The Editor is the workspace where Userlane content is built and managed, separate from the portal where content is targeted and analytics are viewed.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.userlane.com/intelligence/tags.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
