The ‘None’ line item is a catch-all item that represents all conversions that happened without any touch points within the lookback window. To reduce the number of conversions attributed to the ‘None’ line item, try using a a Custom Lookback Window with a longer lookback period.
Some visit-based metrics, such as Entries or Bounce Rate, can attribute data to a period before the reporting window start date range. This situation is due to attribution models using a lookback window, which determines how far back attribution should look to give credit for metrics. The most common scenario is when visits span midnight. For example:
Hit-based metrics, like Page views, would produce expected output; data trended each day from September 8 - September 14. However, visit-based metrics would also show the above visit on September 7. The visit’s attributed entry occurred on September 7, and the lookback window by default is September 1 - September 31.
Bounce rate always shows 0% on September 7 in this example. This metric is defined as
Bounces divided by Entries, a hit-based metric divided by a visit-based metric. Bounces consist of a single image request, so they cannot span multiple days, Any bounces on September 7 happened outside the reporting window, causing the guaranteed 0% bounce rate for that day. Other hit-based metrics would also show 0 for September 7 in this report, since those hits are not within the reporting window either.
Consider another similar example. The only difference between the following example and the above example are the dates:
In this example, Entries and Bounce rate would not show data from August 31. The lookback window and reporting window both start on September 1, so data cannot be attributed from August 31.
The choice of attribution lookback depends on your use case. If conversions typically take longer than a single visit, a visitor or custom lookback is recommended. For longer conversion cycles, custom lookback windows are best as they are the only type that can pull in data from prior to the reporting window
Attribution is recalculated at report runtime, so there is no difference between a prop or eVar (or any other dimension) for the sake of attribution modeling. Props can persist using any lookback window or attribution model, and eVar allocation/expiration settings are ignored.
No. Attribution models use report time processing, which is only available in Analysis Workspace. See Report time processing for more information.
Attribution models are available outside of virtual report suites. While they use report time processing on the backend, attribution models are available to both standard report suites and virtual report suites.
The attribution panel supports all dimensions. Unsupported metrics include:
Yes, classifications are fully supported.
Yes, most data sources are supported. Attribution is not possible with summary-level data sources because they do not tie to an Analytics visitor identifier. Transaction ID data sources are also supported, unless they are used in a virtual report suite with report time processing enabled.
Metadata dimensions, such as match type and keyword, work with attribution. However, metrics (including impressions, cost, clicks, average position, and average quality score) use summary-level data sources, and are therefore incompatible.
When marketing channels were first introduced, they came with only first and last touch dimensions. Explicit first/last touch dimensions are no longer needed with the current version of attribution. Adobe provides generic ‘Marketing Channel’ and ‘Marketing Channel Detail’ dimensions so you can use them with your desired attribution model. These generic dimensions behave identically to Last Touch Channel dimensions, but are labeled differently to prevent confusion when using marketing channels with a different attribution model.
Since marketing channel dimensions depend on a traditional visit definition (as defined by their processing rules), their visit definition cannot be changed using virtual report suites.
Some dimensions in Analytics can contain multiple values on a single hit. Common examples include list vars and the products variable.
When attribution is applied to multi-value hits, all values in the same hit get the same credit. Since many values can receive this credit, the report total can be different than if you summed each individual line item. The report total is deduplicated, while each individual dimension item gets proper credit.
Attribution always runs before segmentation, and segmentation runs before report filters are applied. This concept also applies to virtual report suites using segments.
For example, if you create a VRS with a “Display Hits” segment applied, you could see other channels in a table using some attribution models.
If a segment suppresses hits containing your metric, those metric instances will not be attributed to any dimension. However, a similar report filter will simply hide some dimension items, without any impact on metrics processed per the attribution model. As a result, a segment can return lower values than a filter with a comparable definition.