Expand my Community achievements bar.

Join us for the next Community Q&A Coffee Break on Tuesday April 23, 2024 with Eric Matisoff, Principal Evangelist, Analytics & Data Science, who will join us to discuss all the big news and announcements from Summit 2024!
SOLVED

Marketing Channel on Pageview - VS - Marketing Channel on Custom Event Metric

Avatar

Level 3

Let's say I want to get a breakdown of which marketing channels were attributed to a pageview for page x.

 

Let's also pretend that I have a custom event set up to fire for each pageview of that same page (page x), and then want to see what the marketing channel breakdown looks like on that metric.

 

Conceptually the pageview metric and my custom event metric (the pretend pageview metric) are the same'ish thing right? At least on the surface.

 

But what would account for such a large discrepancy in the numbers reported against either scenario. Specifically, I am seeing "Paid search" getting a lot of volume in the first scenario, while in the second scenario I am seeing a lot of 'Referring domain' volume instead (where I would have expected it to remain consistent with the first scenario.

 

Any ideas on what might account for the differences here? 

1 Accepted Solution

Avatar

Correct answer by
Level 3

Looping back with the solution to this original post.

 

It ultimately had to do with my marketing channel processing rules. The initial pageview had the campaign variable (cid string) passed along with that hit, which was then subject to the marketing channel processing rules - qualifying the hit as originating from Paid Search. However, for the custom event emulating a pageview that fired off at the same time, a campaign variable was not passed along with that hit, and was therefore not caught by the "Paid Search" processing rule... and ultimately ended up qualifying for the "Referring domains" rule. 

 

In this case - the solution requires some modification to the processing rules (i.e. stricter / more explicit definitions) to support this use case.

View solution in original post

6 Replies

Avatar

Community Advisor

Dear Michael_Wills,

If your Custom Metric (i.e. Custom Page View) is firing in all Page View Calls without gaps (s.t() or trackState), then you should not see any difference. While selecting the Custom Metric, make sure that the attributions are default.

And, is that difference only for Marketing Channels? How about other dimensions including prop and eVar?

Thank You, Pratheep Arun Raj B (Arun) | NextRow DigitalTerryn Winter Analytics

Avatar

Level 3

Thanks so much for responding @PratheepArunRaj!

 

So the Custom Page View event is set to fire (from Adobe Launch) using a max-frequency condition of once per session. Yes, this might create an opportunity for the numbers to be wildly different, but you can see from the below images that they are fairly much identical (2839 for the custom event and 2990 for the regular pageview) - suggesting that in almost all cases people are only requesting the page once.

 

I am hoping these screenshots demonstrate the differences in attribution. Both panels refer to data collected between 14-15th September 2022. Referring domains is the dominant marketing channel for the custom event, however paid search is the dominant marketing channel for the pageview metric.

 

aa-debug-2.jpgaa-debug-1.jpg

 

Here's what a browser breakdown looks like for the same two metrics - some differences, but not wildly different like above.

 

aa-debug-4.jpgaa-debug-3.jpg 

Avatar

Community Advisor

Firstly, referring to your screenshots, you can actually use one freeform table with the 2 metrics "Page Views" and "Custom Pageview Event Name" side-by-side. Then you don't need to have 2 tables, let alone have different dimension/metric configurations per table (which can make it complicated to compare them easily).

Furthermore, your first set of screenshots where, in the first one you compare Marketing Channels x your Custom Pageview Event, vs the second one where you compare a specific Page broken down by Marketing Channels x Page Views. So again, this isn't a fair apple-to-apple comparison.

Avatar

Level 3

Hey @yuhuisg - thanks for your reply. I really appreciate it. And thank you for the tip re: side-by-side comparison in a freeform table.

 

RE: "Furthermore, your first set of screenshots where, in the first one you compare Marketing Channels x your Custom Pageview Event, vs the second one where you compare a specific Page broken down by Marketing Channels x Page Views. So again, this isn't a fair apple-to-apple comparison."

 

I appreciate its not apples for apples. But what I don't understand is why it is so drastically different. Why (in one case) is traffic being chalked up to "Paid search" (expected) while in another case it's being chalked up to "Referring Domains" - when the visit count to this page is essentially the same (note that I haven't shown/provided data on that above)? Is there a technical reason for this?

Avatar

Community Advisor

Dear Michael_Wills,

If Custom Page View will fire only one per session, then the Page View and Custom Event are not the same. If that is the case, you cannot compare both.

Fairly identical case can exist, because there is no back & forth or reloads happening on some of the Marketing Channels. But if there are back-and-forth navigations & reloads, these will fail.

So, the comparison is not absolute here and thus there are discrepancies.

Thank You, Pratheep Arun Raj B (Arun) | NextRow DigitalTerryn Winter Analytics

Avatar

Correct answer by
Level 3

Looping back with the solution to this original post.

 

It ultimately had to do with my marketing channel processing rules. The initial pageview had the campaign variable (cid string) passed along with that hit, which was then subject to the marketing channel processing rules - qualifying the hit as originating from Paid Search. However, for the custom event emulating a pageview that fired off at the same time, a campaign variable was not passed along with that hit, and was therefore not caught by the "Paid Search" processing rule... and ultimately ended up qualifying for the "Referring domains" rule. 

 

In this case - the solution requires some modification to the processing rules (i.e. stricter / more explicit definitions) to support this use case.