{"id":328,"date":"2018-01-10T21:48:07","date_gmt":"2018-01-10T21:48:07","guid":{"rendered":"https:\/\/www.digitaldatatactics.com\/?p=328"},"modified":"2020-09-17T21:19:13","modified_gmt":"2020-09-17T21:19:13","slug":"participation-and-linear-allocation-in-adobe-analytics","status":"publish","type":"post","link":"https:\/\/www.digitaldatatactics.com\/index.php\/2018\/01\/10\/participation-and-linear-allocation-in-adobe-analytics\/","title":{"rendered":"Participation and Linear Allocation in Adobe Analytics- behavior I expected, and some I did not"},"content":{"rendered":"

I recently posted<\/a> about some of the implications and use cases of using Linear Allocation (on eVars) and participation (props\/events) and in my research, I thought I had encountered a bug in Analysis Workspace. After all, for this flow:<\/p>\n\n\n\n\n
<\/td>\nPage A<\/strong><\/td>\nPage B<\/strong><\/td>\nPage C<\/strong><\/td>\nPage D<\/strong><\/td>\nNewstletter Signup event (s.tl)<\/strong><\/td>\n<\/tr>\n
prop1<\/strong>
\n eVar1<\/strong>
\n events<\/strong><\/td>\n		“Page A”
\n“Page A”
\n“event1”<\/td>\n		“Page B”
\n“Page B”
\n“event1”<\/td>\n		“Page C”
\n“Page C”
\n“event1”<\/td>\n		“Page D”
\n“Page D”
\n“event1”<\/td>\n		“”
\n“”
\n“event2”<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

I saw this<\/em> in Reports and Analytics (so far, so good):<\/p>\n

\"\"<\/a><\/p>\n

But then in Analysis Workspace for that prop, trying to recreate the same report, I saw this, where the props were only getting credited for events that happened on their beacon (none got credit for the newsletter signup):
\n\"\"<\/a><\/p>\n

Basically, I lost that participation magic.<\/p>\n

Similarly, for the eVar, I saw this report in Reports and Analytics:<\/p>\n

\"\"<\/a><\/p>\n

And in Workspace, it behaved exactly like a “Most Recent” eVar:
\n\"\"<\/a><\/p>\n

Again, it lost that linear magic.<\/p>\n

Calculated Metrics to the Rescue<\/h2>\n

With the help of some industry friends (thanks, Jim Kultgen at Kohler and Seth Burke at Adobe) I learned that this is not a\u00a0bug<\/em>, necessarily- it’s the future! Analysis Workspace has a different way of getting at that data (one that doesn’t require changing the backend settings for your variables and metrics).
\nIn Analysis Workspace reports, allocation can be decided by a Calculated Metric<\/a>, instead of the variable’s settings. In the calculated metric builder, you can specify an allocation by clicking the gear box next to the metric in the Calculated Metric Definition:<\/p>\n

\"\"<\/a><\/p>\n

A Note On “Default” Allocation here<\/h4>\n

On further testing, in Analysis Workspace, it seems that eVars with the back-end settings of either “Most Recent” and “Linear” allocation are treated the same: both will act like “Most Recent” with a metric brought in, and both will act like “Linear” when you bring in a calculated metric where you specified to have Linear Allocation. One might say, if you use Analysis Workspace exclusively, you no longer would need to ever set an eVar to “Linear”.<\/p>\n

“Default” does<\/strong><\/em> still seem to defer to the eVar settings when it comes to Most Recent or Original (just not Linear). So in an eVar report where the eVar’s backend setting is “Original”, whether I used my “normal” Newsletter Signups event (column 2), or my Calculated one with Linear Allocation (column 3), credit went to the first page:
\n\"\"<\/a><\/p>\n

So, the Calculated Metric allocation did NOT overwrite my eVar setting of “Original”.<\/p>\n

So how do I replicate my Linear eVar report?<\/h2>\n

To get back that Linear Allocation magic, I would create a new Calculated Metric, but I would specify “Linear Allocation” for it in the Calculated Metric Definitions. Then I can see that linear metric applied to that eVar (the original metric in blue, the new calculated one with linear allocation in purple) :
\n\"\"<\/a>
\nNote that it’s 40-20-20-20, rather than 25-25-25-25. I’ll admit, this isn’t what I expected and makes me want to do more testing. I suspect that it’s looking at my FIVE beacons (four page views, one success event) and giving that Page D double credit- one for its page view beacon, and one for the success event beacon (even though it wasn’t set on that beacon, it WAS still persisting). So it isn’t perfectly replicating my R&A version of the report, but it is helping me spread credit out between my four values.<\/p>\n

And my participation prop?<\/h3>\n

Similarly, with the prop, when I bring in my new “Linear Allocation” calculated metrics I just set up for my eVar (in blue), I now see it behave like participation for my Newsletter Signup metric, unlike the original non-calculated metrics (in green):
\n\"\"<\/a><\/p>\n

…but those Page View numbers look just Despite clearly remembering learning about it my first week on the job at Omniture in 2006, I realized recently that I did not have a lot of confidence in what participation and linear allocation would do in certain situations in Adobe Analytics. So I put a good amount of effort into testing it to confirm my theories, and I figured I’d pass along what I discovered.<\/p>\n

First, the Basics: eVar Allocation<\/h2>\n

You may already know this part, so feel free to skip this section if you do. Allocation is a setting for Conversion Variables (eVars) in Adobe Analytics, with three options:<\/p>\n

\"\"<\/a><\/p>\n

Let’s take a simple example to show what how this effects things. Let’s say a user visits my site with this flow:<\/p>\n\n\n\n\n
Page A<\/td>\nPage B<\/td>\nPage C<\/td>\nPage D<\/td>\nForm Submit- Signup<\/td>\n<\/tr>\n
s.eVar5=”Page A”<\/td>\ns.eVar5=”Page B”<\/td>\ns.eVar5=”Page C”<\/td>\ns.eVar5=”Page D”<\/td>\ns.events=”event1″<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Most Recent (Last)<\/h3>\n

Most eVars have the “defaultiest” allocation of “Most Recent (Last)”, meaning in an event1 report broken down by eVar5, “Page D” would get full credit for the event1<\/strong>\u00a0that happened, since it was the last value we saw before event1. So far, pretty simple.<\/p>\n

Original Value (First)<\/h3>\n

But maybe I want to know which LANDING page contributed the most to my event1s (there are other ways of doing this, but for the sake of my example, I’m gonna stick with using allocation). In that case, I might have the allocation for that eVar set to “Original Value (First)” so then\u00a0“Page A” would get full credit for this event1<\/strong>, since it was the first value we saw for that variable. If my eVar is set to expire on visit, then it’s still nice and straightforward. If it’s set to never\u00a0<\/em>expire, then the first value we ever<\/em> saw for that user will always get credit for any of that user’s metrics. If it’s set to expire in two weeks, then we’ll see the first value that was passed within the last two weeks.<\/p>\n

This setting is frequently used for Marketing Campaigns (it’s not uncommon to see s.campaign be used for “Most Recent Campaign in the last 30 days” and then another eVar capture the exact same values, but be set to “Original Campaign in the last 30 days”).<\/p>\n

Linear Allocation<\/h3>\n

If I’m feeling a bit more egalitarian, and want to know ALL the values for an eVar that contributed to success events, I would choose linear allocation. In this scenario, all four values would split<\/strong> the credit for the one event, so they’d each get one fourth of the metric<\/strong>:<\/p>\n

\"\"<\/a><\/p>\n

(Though it may not actually look like this in the report- by default it would round down to 0. But I’ll talk about decimals later on).<\/p>\n

So, that’s allocation.<\/p>\n

Then what is participation?<\/h2>\n

Participation<\/strong> is a setting you can apply to a prop<\/strong>, so that if you bring a Participation-enabled metric<\/strong> into the prop’s report, you can see which values were set at some point before that event took place. Repeat: to see participation you must have a prop that is set to “Display Participation Metrics”:<\/strong><\/p>\n

\"\"<\/a><\/p>\n

And<\/strong> the metric you want to see needs to have participation enabled (without this, in the older Reports and Analytics interface, that event won’t be able to be brought into the prop report):<\/p>\n

\"\"<\/a><\/p>\n

Unlike linear allocation for an eVar, participation for a prop means all the values for that prop get full credit<\/strong> for an event that happened. So, given this flow:<\/p>\n\n\n\n\n
Page A<\/td>\nPage B<\/td>\nPage C<\/td>\nPage D<\/td>\nForm Submit- Signup<\/td>\n<\/tr>\n
s.prop1=”Page A”<\/td>\ns.prop1=”Page B”<\/td>\ns.prop1=”Page C”<\/td>\ns.prop1=”Page D”<\/td>\ns.events=”event1″<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

You would see a report like this, because each value participated in the single instance of that event<\/strong>:<\/p>\n

\"\"<\/a><\/p>\n

New Learnings (for me): Content Velocity<\/h2>\n

One thing these settings can be used for is measuring\u00a0content velocity<\/strong>: that is, how much a certain value contributed to more content views later on. For instance, if I have a content site, and I want to know how much one piece of content tends to lead to the reading of MORE content, I might use a participation-metric-enabled prop with a participation-enabled Page View custom event, or I might use an eVar with linear allocation against a Page View custom event (whether or not the event has participation enabled doesn’t matter for the eVar). For my test, I did both:<\/p>\n\n\n\n\n
Page A<\/td>\nPage B<\/td>\nPage C<\/td>\nPage D<\/td>\n<\/tr>\n
s.prop1=”Page 1″
\ns.eVar1=”Page 1″
\ns.events=”event1″<\/td>\n		s.prop1=”Page 2″
\ns.eVar1=”Page 2″
\ns.events=”event1″<\/td>\n		s.prop1=”Page 3″
\ns.eVar1=”Page 3″
\ns.events=”event1″<\/td>\n		s.prop1=”Page 4″
\ns.eVar1=”Page 4″
\ns.events=”event1″<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The prop<\/h3>\n

The prop version of this report would show me that Page 1 contributed to 4 views (its own, and 3 more “downstream”). Whereas Page 2 contributed to 3 (its own, and two more downstream), etc…<\/p>\n

\"\"<\/a><\/p>\n

The eVar<\/h3>\n

Alternatively, the eVar would show me some thing pretty odd:<\/p>\n

\"\"<\/a><\/p>\n

Those weird numbers don’t make sense on this small scale (how could 0 get 6.3%?), because it is rounding, and not showing me decimals. If I want to see the decimals, I can create a really simple calculated metric that brings in my custom Page View event (event1) and tells it to show decimals:<\/p>\n

\"\"<\/a><\/p>\n

The report then makes a\u00a0little\u00a0<\/em>more sense and show us where the rounded numbers came from (and how Page 4, with “0” Page Views, got 6.3% of the credit), but may still seem mysterious:<\/p>\n

\"\"<\/a><\/p>\n

Those are some odd numbers, right? Here’s the math:<\/p>\n\n\n\n\n\n\n\n
\u00a0Value<\/strong><\/td>\nCredit<\/strong><\/td>\nWhy?\u00a0<\/strong><\/td>\n\u00a0Explanation<\/strong><\/td>\n<\/tr>\n
Page 1<\/td>\n2.08<\/td>\n1+0.5+0.33+0.25<\/td>\nIt got full credit for its own view, then half the credit (shared with page 2) for the event on Page 2, then a third of the credit (shared with Page 2 and Page 3) on Page 3…<\/td>\n<\/tr>\n
Page 2<\/td>\n1.08<\/td>\n0.5+0.33+0.25<\/td>\nIt only got half credit for the event that took place on its page (shared with Page 1), then a third of the credit (shared with Page 1 and Page 3) on Page 3, etc…<\/td>\n<\/tr>\n
Page 3<\/td>\n0.58<\/td>\n.33+.25<\/td>\nIt only gets a third of the credit that took place on its page, and a quarter of the credit for the fourth page.<\/td>\n<\/tr>\n
Page 4<\/td>\n0.25<\/td>\n0.25<\/td>\nThe event that happened on this page is shared with all four pages.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Crazy, right? I’m not going to tell you which an analyst should prefer, but as always, you should ask the question: “What will you DO with this information?”<\/p>\n

What happens when multiple values appear in the same flow?<\/h2>\n

Let’s say the user does something like this, where they hit one value a couple page views in a row (Page B in this example), or they hit a value 2 separate times (Page A in this example):<\/p>\n\n\n\n\n
<\/td>\nPage A<\/td>\nPage B<\/td>\nPage B
\n(again)<\/strong><\/td>\n		Page C<\/td>\nPage D<\/td>\nPage A
\n(again)<\/strong><\/td>\n		Conversion event<\/td>\n<\/tr>\n
prop1
\neVar1
\nevents<\/td>\n		“Page A”
\n“Page A”
\n“event1”<\/td>\n		“Page B”
\n“Page B”
\n“event1”<\/td>\n		“Page B”
\n“Page B”
\n“event1”<\/td>\n		“Page C”
\n“Page C”
\n“event1”<\/td>\n		“Page D”
\n“Page D”
\n“event1”<\/td>\n		“Page A”
\n“Page A”
\n“event1”<\/td>\n		events=”event2″<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

For the prop, it’s pretty straightforward. This will look like 6 event1s, where Page A gets value for all 6, and Page D gets credit for just 2 (itself, and the Page A that came afterwards):<\/p>\n

\"\"<\/a><\/p>\n

For the eVar, it gets a little more complicated (I added in a calculated metric so you can see the decimals). Page A (accessed twice at separate times) got double credit for the conversion (which I might have predicted), but Page B (accessed twice in a row) ALSO gets double credit for the conversion (which I didn’t predict, probably because I’m too used to thinking in terms of the CVP plugin):<\/p>\n

\"\"<\/a><\/p>\n

Caveats<\/h2>\n

A couple things to be aware of:<\/p>\n