Campaign Stacking, Lead Stacking, Product Stacking

Here’s another really simple customisation that you can and should do as part of your basic implementation, which helps you to further understand attribution.

Attribution is probably one of the hardest and most contested measurements available…which “thing” led your customer to do something.

Campaign Stacking

In SiteCatalyst, that’s called Stacking.  And there’s really no end to things you can “stack”.

Stacking essentially means that you store different values in the order that they occurred – and you can do it across multiple visits as well.  So, for example, if you’re stacking campaign codes, you’ll see in your reports:

campaign1> campaign2 > campaign3 > etc

From there, you can tie the success event, such as Lead, or Purchase, to the individual variations and have some visibility around how many times they interact with different elements before they convert.

Granted, it doesn’t generate the cleanest of reports, but there is insight to be gained from it.

At Murdoch Uni, we’ve done that for a number of different views:

1. Campaigns (the obvious one)
2. Internal Campaigns (the second obvious one)
3. Courses viewed (see the order of courses viewed before a conversion)
4. Lead Type (as we have multiple ways to generate leads, we want to know which tools they go through)

An example of campaign stacking report, broken down (due to full sub-relations being enabled on the eVar) is:

The above report has been filtered on “>” to only show those that have interacted with more than one campaign.

If you’re an avid reader of my blog, you’ll remember an earlier post of “People who liked this, also liked”, where I showed how to achieve the same for product views.

The above shows the unique ID of the course (or product), the number of times we saw that same sequence, the number of leads and apps generated from that sequence.  As I indicated in the previous post – our users don’t exhibit the behaviour of viewing multiple courses…

If we look at which tools (aka forms or flash devices) they interact with and become a lead through (as they can do it through multiple tools, we see the following:

Mmm, well, not a lot of data in this one as we’ve only just turned this one on – but you get the idea.

Getting smarter…

Another way that you could do it fairly easily, with a bit more custom code, is to stack not only campaign codes, but the referring domain, typein, paid search, organic search, etc instead of just leaving it at known campaign codes.

And so, to the nitty gritty

You use the plugin s.crossVisitParticipation.

The following is an example for traditional campaign code stacking:

/* Campaign Stacking */
s.eVar36=s.crossVisitParticipation(s.campaign,’s_evar36′,’90’,’10’,’>’,”);

The values in the plugin are as follows:

1^st = value to pass into the stack.

2^nd = Name of the cookie to set that stores the stack

3^rd = Days the cookie will last for

4^th = Number of things to store in the stack

5^th = Delimiter in stack

Can’t for the life of me remember what the final element is though (but whatever it is, we don’t use it).

You’ll also need an eVar to put it into, which you should add in via your Admin – enable full sub-relations if you can.

As with all of these, you should contact Client Care or Consulting to make sure you can get the plugin and that you implement it correctly.

Final thoughts

If you’ve got Test and Target too, you’re laughing!

You can target for re-engagement if they’ve met certain criteria (or haven’t met a certain criteria).  So, if someone’s got campaign code 1 and campaign code 2, but hasn’t converted, show them a different offer.

Discover also allows you to further gain insights by analysing results and traffic against this eVar.

That’s it really.  Happy stacking.