> For the complete documentation index, see [llms.txt](https://addressable.gitbook.io/knowledge-base/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://addressable.gitbook.io/knowledge-base/solution-suite/insights-and-analytics/how-attribution-works.md).

# How Attribution Works

The Addressable Attribution Engine is designed to determine the most relevant marketing channel for each tracked user interaction. It processes data from multiple sources, resolves identities across platforms, and classifies traffic into predefined channels using structured rules and prioritization. 

This document outlines the logic of the engine and explain how it works.

### Identity Resolution

Addressable employs various tracking methods to monitor user sessions and the events they perform on your website. If individual user tracking is not permitted due to cookie policies or similar restrictions, Addressable calculates a user fingerprint using technical attributes and assigns it to an individual user or group.

The engine resolves user identities across multiple platforms and sessions by using unique identifiers and clustering them to create an AddressableID for the user or group. This process ensures accurate attribution of user interactions, even when they span multiple sessions or devices.

Identity data is carefully mapped to maintain consistent tracking of users. Parameters such as session duration and bounce rate are constructed, enabling the interface to display all events at a distinct user level.

<mark style="color:red;">**Note:**</mark> In case tracking is prohibited by your organization policy, please contact your account manager for adjusting the above behavior.

### Traffic Classification

The engine classifies each interaction into one of the predefined marketing channels based on UTM parameters, referrer information, and campaign data ([See how classification works](/knowledge-base/solution-suite/insights-and-analytics/marketing-channels-classification.md))

* **Direct Traffic**: Identified when no UTM parameters or referrer data is present.
* **Display Advertising**: Recognized through specific UTM parameters or using internal mapping in case Addressable Display campaign was used.
* **Paid Social**: Includes traffic from social platforms like X and Reddit, identified via UTM parameters and platform-specific identifiers.
* **Organic Search**: Traffic from search engines without paid advertising.
* **Paid Search:** Traffic from search engines that is a part of a paid campaign with a UTM Term parameter.
* **Referrals**: Traffic from external domains that act as referrers.
* **Email Marketing**: Traffic originating from email campaigns.
* **Other Campaigns**: Captures traffic not fitting the above categories but containing UTM parameters.

Custom logic ensures that traffic misclassified initially (e.g., due to missing UTM parameters) is reassigned to appropriate channels based on referrer data and context.

<mark style="color:red;">**Note:**</mark> Customers are responsible for ensuring the correct setup of UTM parameters for accurate tracking and channel mapping. Misclassifications may occur if UTM parameters are used incorrectly.

<mark style="color:red;">**Note:**</mark> To accurately map X campaigns created through the system to the Paid Social category, customers must use the correct UTM parameters as recommended by the system during campaign generation.

### **Prioritization and Attribution Logic**

The engine applies a **first-touch attribution model** with prioritization rules to determine the most impactful channel for each interaction:

* Channels are ranked by relevance (e.g., Paid Social, Display, Paid Search prior to Direct Traffic).
* For each user session, the first interaction from a high-priority channel is selected as the attributed channel.
* If multiple channels are eligible in a single session, the first channel in selected resolve ties.&#x20;

In a typical scenario, a user will have multiple sessions, with each session potentially attributed to a different channel. For example, the user journey begins with encountering the brand's landing page during an Organic Social campaign or Organic Search. This often prompts the user to visit the website to learn more about the brand.

However, purchases rarely occur during the first session. Instead, users are likely to return directly to the website in a subsequent session or through another interaction, such as a Display brand awareness campaign or an affiliate referral, before completing their purchase.

Multiple touch-points play a critical role in guiding users down the funnel, and our attribution engine accounts for this behavior. The engine uses a **first-touch attribution approach** within a 30-day window, classifying the channel through which Addressable first tracked the user.

For example, if a user views a **Display** Ad as part of a brand awareness campaign, visits the website **Directly** without taking any action, and then re-engages a week later by clicking on an **Organic Social** tweet on X, connecting their wallet, and completing a purchase, our attribution engine attributes the conversion to the **Display** channel.

This approach ensures that the initial point of contact, which plays a crucial role in driving user awareness and engagement, is recognized in the attribution model.

### **Attribution Outputs**

The final output of the engine includes detailed attribution metrics for each user interaction:

* **Attributed Channel**: The primary marketing channel responsible for driving the interaction.
* **UTM Parameters**: Campaign, source, medium, and term details associated with the session.
* **Referrer**: The external site or platform that directed the user to the interaction.
* **Campaign Details**: Specific information about the campaigns, including platform and creative identifiers.

These outputs enable marketers to analyze performance and optimize their campaigns effectively.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://addressable.gitbook.io/knowledge-base/solution-suite/insights-and-analytics/how-attribution-works.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.