In this post, I'm going to provide an Adobe Analytics implementation-based solution that will allow you to apply a non-standard attribution (i.e., Attribution IQ-based) model to common metrics like Page Views, Visits, and Occurrences.
The Problem
To demonstrate the need for this solution, let me start off by creating a simple Marketing Channel report. I have added some common metrics to this report, including "Visits", "Page Views", "Orders", and "Revenue". The result – using real-world data in this example – looks something like this:
If I wanted to apply a non-standard attribution model – say, "Last Touch with a Lookback Window of 30 Days", for instance – to all of these metrics, I would be mostly out of luck. Applying a non-standard model to the Orders and Revenue metrics works just fine, as the following result shows…
…but trying to apply the model to either the Visits or Page Views metric presents an unwelcome surprise: when I'm presented with the option, the "Use non-default attribution model" checkbox is grayed-out!
Unfortunately, the out of the box "Unique Visitors", "Visits", "Page Views", and "Occurrences" metrics cannot leverage Attribution IQ.
The Solution
Luckily, all custom metrics (available via Analytics' custom events) leverage Attribution IQ; and so, we can use them to solve the problem. Specifically, I will show here how to setup and use custom "Visits", "Page Views", and "Occurrences" metrics.
Step 1 – Setup the Events
Add three new custom success events to your Analytics implementation with the following configuration settings:
Many clients I work with have already set up a custom "Page Views" event. If that's the case for you as well, then set up only the new Visits and Occurrences events.
Step 2 – Implement Visits and Occurrences
Modify your implementation to force the new Visits metric - event1 in this example - and Occurrences metric - event3 in this example - to be added to every single hit of your visit. The easiest way to pull this off is to create a new processing rule that will set both events equal to the value of "1" – no conditions necessary. With no conditions applied to the rule, these actions will run on every single Analytics hit that Adobe collects and processes.
A notable caveat(!): The custom Visits metric – event1 here – will be added to every hit, but the "Record Once Per Visit" value under its Unique Event Recording setting will force the Adobe Data Collection servers to ignore any instance of event1 beyond the first one that was recorded in each visit. Hence, all event1 instances will be equal to the number of visits overall but will be tied to only the first hit of each visit.
Thus, you should never use the custom Visits metric for analyzing any dimensions that would have been captured after the first hit of a visit. For example, if you use a dimension like "Pages" in your breakdown, the custom Visit metric will be allocated to only the first page seen during the visit even though a visitor (in reality) might have seen hundreds of different pages during the visit. Marketing Channel (as shown in this article) is a better dimension to use with the custom Visits metric since marketing channels are meant to be captured on the first page of every visit.
Step 3 – Implement Page Views
Implementing the custom Page Views metric will require one of two methods depending on the Adobe Data Collection library you are using.
AppMeasurement
For AppMeasurement-based data collection, add a single block of code to the doPlugins function that determines whether the linkType variable has been set or not. If linkType hasn't been set, then add the custom page view event to your list of events. For example:
s.doPlugins = function() {
if(!s.linkType || s.linkType == 0)
s.events = s.events + ",event2";
};
AEP Mobile/Web SDK
For Edge-based data collection – both Mobile SDK and Web SDK deployments apply here – you would create a calculated field in Data Prep that determines whether the "data.__adobe.analytics.linkType" field or the fields in the webInteraction data type are contained in an incoming server call's payload. If these fields are not contained in the payload – the screenshot below checks for the "non-existence" of web.webInteraction.type as an example – then you would set the appropriate "_experience.analytics" event field - event2 in this case - equal to 1.
The Results
When we apply the non-standard attribution model to the new custom metrics and compare them to the original metrics, we see this difference:
Original Metrics
Metrics with 30-Day Last Touch Attribution
Further Analysis
Once you see the difference in the results, you can go wild with any additional analysis you can think of! For example, I created the following, which shows the Marketing Channels that provide a higher conversion rate over an extended period of time. It looks like push notifications help provide lots of repeat business for this client!
Conclusion
I hope you find this to be another useful solution to add to your Analytics toolbox. If you have your own ideas to share, then leave a comment or feel free to reach out to me directly. Thanks for reading!