As a digital data consultancy working with clients across multiple verticals utilising Adobe Analytics, DMPG see the same frustrating reporting issues cropping up day in day out. We like to focus our time and effort on solving the really complex challenges for clients that lead to incremental growth/value. To help us do this though we also need to be able to diagnose and solve simple and frequent issues quickly for our clients.
Here is a run down of our top 3 relatively simple but annoyingly regular Adobe Analytics reporting issues over the past year or so along with solutions to gain back control of the numbers.
Issue 1: Unexplained Increase in ‘Direct’ Channel Traffic and Orders
Fig. 1 Direct Load Channel Share of orders increasing YoY since March 2019
Symptoms:
Since March 2019 Direct Load channel has started to take on a larger proportion of overall visits at the expense of other tracking-code based channels, whilst actual marketing mix used has remained the same.
Issue:
March 2019 saw the introduction of Apple’s Intelligent Tracking Prevention (ITP) 2.1 initiative. The changes aimed at tightening up privacy on Safari devices prevented any 1st party JavaScript cookie being stored on the Safari browser for more than 7 days. As a result Marketers using attribution windows longer than 7 days lost visibility on channel activity beyond 7 days when analysing Safari devices. In behavioural terms users that were previously being counted as a Paid Search visit when they returned to site directly 14 days after using a Search Engine will no longer be counted as Paid Search and instead the visit will be attributed to Direct channel. Other browsers such as Chrome have plans to introduce similar measures in the future.
Solution:
Adobe Analytics offers a work around which necessitates using CNAMES. Switching to CNAMEs involves configuring “your data collection server domain to match your website domain so the visitor ID cookie is set as a first-party cookie.” It requires both internal effort to configure the servers domains and actions on the Adobe side but the whole process is easily achievable. Configuring CNAMES will combat ITP on Safari devices for the immediate time by additionally dropping a first party http-cookie that can keep the first p[arty Javascript cookie alive longer. An additional complication can be websites that have journeys which are split over multiple domains/top level domains where further steps are needed.
Issue 2: Declining Tablet Device Share %
Fig. 2 Tablet Device Share of visits decreasing YoY since Sep 2019
Symptoms:
Since September 2019 Tablet Device Share % has been sharply declining as a proportion of overall visits. Desktop (Other) appears to be picking up the slack.
Issue:
In September 2019 Apple made a change during the rollout of iPadOS13. Apple decided that all Tablets should request the Desktop version of websites. Instead of Tablets using User-Agent strings that identify them as “iPads”, the User-Agent string now identifies them as “Macintosh;” a Desktop device from Adobe Analytics perspective There is a buried iOS option to turn this option off but most users will not do this. Whilst Google decided to inform their customers of this change at the time, Adobe did not, so many were left scratching their heads…
Solution:
There are currently two solutions which can be employed to separate back out Tablet traffic from Desktop and regain a realistic view on Device split. Both involve setting flags in your datalayer when certain device properties are observed.
The first, relies on surfacing a difference between the graphics rendering that is used by each Device. This fix has been explained elsewhere, but relies on the fact that iPads use ‘Apple GPU’ whereas Macintosh use ‘Intel Iris OpenGL Engine.’ This fix will work while this remains the graphics rendering configurations used.
The other fix DMPG has employed keys off screen resolution. The overwhelming majority of Safari Tablet and Desktop experiences can be separated into iPad and Desktop devices based on the size of their screen resolution.
Issue 3: When I breakdown a Marketing Channel dimension by a Tracking Code (Campaign eVar) I get Tracking Codes that don’t relate to that Channel.
Fig. 3 Email Tracking Codes reported against PPC Channel.
This one comes up a lot. You may have an issue but you may not – it depends what your dashboard looks like and how you use Tracking Codes. When I refer to “Tracking Code,” I mean the out-the-box ‘Campaign variable/eVar’, ‘v0’, which seems to take this name in most implementations. You may have called yours something else.
Firstly, if you are reporting on a Visit-level metric such as ‘Visits’, it is perfectly expected to see Tracking Codes from other marketing channels present. This can happen if a user uses more than one Tracking Code during a Visit. Adobe is telling you that in a visit where the Paid Search was Last Touch Channel, ‘at some point’ certain other Tracking Codes were also used in that same Visit. This is notably different to how Google Analytics works (where most people build their experience) as GA starts a new session each time the referrer data changes regardless of the timing of that change in referrer. This isn’t an explanation when reporting on hit level dimensions such as Entries though.
The second factor then to understand is the relationship between Tracking Codes and Marketing Channels. Tracking Code values are processed and used to set a particular Marketing Channel via “Marketing Channel Processing Rules (MCPR).” Tracking Codes and Marketing Channel are independent dimensions with different characteristics and have their own configuration options in Adobe, in particular Expiration. There is one final piece to the puzzle which is the “Marketing Channel Detail” group of dimensions. These allow you to capture additional information at the time of setting a Marketing Channel, utilise the same First/Last Touch attribution and hold it with the same expiry conditions as the Marketing Channel dimension itself.
The expiration period you choose for your Tracking Code then will impact the data you see reported against your Marketing Channels. Two of the most popular options are as follows:
- Visit expiry for your Tracking Code. If you choose this option you will only get Tracking Code values reported against the Marketing Channel for the Visit in which the user actually uses the tracking code. As a result you can distinguish between a Visit where a user enters using the tracking code and sets the Marketing Channel vs a Visit where the Marketing Channel has simply persisted from a previous setting, not been overwritten by the new entry Channel and no tracking code has actually been used to enter the site. The second visit will have no Tracking Code information attached, yet the Channel will persist.
- Same expiry period as Marketing Channel. If you set your tracking code expiry to 30 days, for example, to match your Marketing Channel settings, then you will see more Tracking Code data reported against Channels. In particular not all Marketing Channels are set with a reference to a Tracking Code – for example Natural Search/SEO. As a result Tracking Codes that have been set on a previous site entry that is still within the expiration period can bleed over and still be present when users enter via a ‘Non-Tracking-Code’ channel. As a result you could see Natural Search entries with Tracking Codes from other channels reported against them.
In both the above scenarios an improved reporting method could be to set the value from Tracking Code into the Marketing Channel Detail dimension. In scenario a) the original Tracking Code information would then still be available for the 30 days afterwards for use in reporting and you could break down that second type of visit by the original tracking code. In scenario b) Natural Search would be set up to overwrite its own Detail value hence clearing the previous Tracking Code data and making more sense to the analyst looking at the entry..
If Tracking Code expiry is set to be longer than Marketing Channel expiry, the prevalence of Entries from non-tracking code Channels such as Direct which had Tracking Code information attached to them would become higher.
Fig. 4 Natural Search Entries broken down by other Tracking Codes
Finally a similar scenario can also occur in a different way unrelated to Expiry: if you have not enabled the “Override Last Touch Channel” option for a particular channel. When a user hits your site with that Channel’s tracking code the “Marketing Channel” dimension will be set, but the “Last Touch Marketing Channel” will not be set unless it was previously empty.
In the example below when a user hits the site via a Organic Social Media tracking code it will not override a “Last Touch Marketing Channel” value of “Aggregators.” When an analyst breaks down a “Last Touch Marketing Channel” “Aggregators” value then they will see Organic Social Media tracking codes. For any channels that you want an accurate view of last-touch conversion events and tracking codes you should tick the “Override Last Touch Channel” option.
Fig. 5 Override Last-Touch Channel option settings
One final thing to consider is the order of your Marketing Channel Processing Rules. Rules are processed from the top of the list down. If you have traffic with a tracking code attached that also meets the criteria of a rule higher up the list, the traffic will be allocated to that Channel instead. The Tracking Code will become reported against that Channel despite not setting it. Consider placing all rules involving Tracking Codes first before other rules.
To sum up then, if you see Tracking Codes in a report that do not relate to the Channel you are breaking down you should:
- Check you are not reporting on a Visit level metric.
- Check your expiry settings for Tracking Codes vs Marketing Channels and how this may be impacting the data you are viewing, especially when considering non-Tracking Code Channels. Consider implementing/using Marketing Channel Detail.
- Ensure the order of your Marketing Channel Processing rules is watertight.
- Ensure your Channels are configured correctly with respect to “Override Last Touch Channel” options.
Ultimately, DMPG is increasingly recommending a move away from Marketing Channel Process rules functionality to a simpler implementation solely based on Tracking Codes. But that is an article for another day.