There is still one big topic from this year’s Adobe Summit stand­ing out in my mind. I attended a few great sessions that discussed Process­ing Rules, and I had a hard time not inter­rupt­ing when I heard atten­dees ask: “When should I use Process­ing Rules instead of a Tag Manage­ment system? Clearly, a good Tag Manage­ment tool can do prac­ti­cally every­thing Process­ing Rules can?” Coin­ci­den­tally, someone asked a very good ques­tion on my previ­ous post (the first in a series on moving away from using plugins), wonder­ing how using Satel­lite to set a ?cid track­ing para­me­ter was differ­ent from using a Process­ing Rule within the Site­Cat­a­lyst admin settings. Obvi­ously, some clar­i­fi­ca­tion is in order.

Do you want to spend your efforts treat­ing the symp­toms of a limited imple­men­ta­tion, or do you want to heal the disease?

Process­ing rules, while an awesome tool, cannot replace a good TMS: they have a few func­tions in common but the methods, inten­tion and poten­tial are so very differ­ent. When people wonder what the differ­ence is, it makes me wonder if some­times we’re missing the forest because we’re too busy focus­ing on the trees: the little things that a process­ing rule or tag manage­ment system can both fix, and the day-to-day headaches that plague those respon­si­ble for main­tain­ing a Site­Cat­a­lyst imple­men­ta­tion. But when you step back and look at the bigger picture you realize you’ve been looking at the little issues so much that you never were able to push your imple­men­ta­tion to the next stage- a stage that doesn’t require as much main­te­nance, giving you time to actu­ally use the data you’ve worked so hard to get.

This isn’t to say you don’t need to fix the little things- most certainly you do, and both Process­ing Rules and Tag Manage­ment Systems have some things in common to help you do so. But never forget the bigger picture.

Treating the Symptoms

For those not very famil­iar with Process­ing Rules, they are a set of condi­tions and corre­spond­ing actions that are applied in between data collec­tion and VISTA rules/data process­ing. For example, you can use a Process­ing Rule if you want to copy an eVar to a prop without chang­ing your code, set an event when­ever a specific eVar has a specific value, or assign a context vari­able to a vari­able. Process­ing rules are free for all Adobe Customers,  but do require a certi­fi­ca­tion before they can be set up.*
*

processing rules exampleExample process­ing rule

### The Advan­tages

What can a process­ing rule offer that a Tag Manage­ment System can not? Here are some ideas we came up with, with the help of Bret Gunder­sen at Adobe:

  1. Most obvi­ously, they are included for free in your Adobe product. They are already acces­si­ble, waiting to be used without any big changes to your overall approach to imple­men­ta­tion. (Of course, some might argue that big changes are* needed* for most orga­ni­za­tions out there.) You don’t need to over­haul or fix your current imple­men­ta­tion in order to use them.
  2. Process­ing rules require zero code knowl­edge: There is no need to touch JavaScript or Regular Expres­sions. Many Tag Manage­ment Systems will claim this “code-less imple­men­ta­tion” as well, but we all know that unless you have a simple, well-constructed website and the most basic of report­ing require­ments, even with a great TMS some code work is neces­sary. Of course, some Tag Manage­ment Systems are less code-heavy than others, for example, Satel­lite was designed to need as little code as possi­ble without losing any of the power and flex­i­bil­ity that a little bit of code can give you.
  3. Process­ing rules provide control in places where there is no access to a tag manage­ment tool, such as third-party pages where you can’t change your code to put a Tag Manage­ment snippet on.
  4. Process­ing rules can be enabled without a test cycle, completely inde­pen­dent of IT or QA teams. This could be both a good and a bad thing (a little testing is a good thing before touch­ing live data), but there is no need to prove there are no adverse effects on the page to a nervous IT team, and the changes can be imme­di­ate.
  5. *Process­ing rules are set at the report-suite level. *In some cases, like if you are multi-suite tagged, it can be useful to have a way to change one data set without chang­ing another.

I’m thrilled that this rela­tively new piece of Site­Cat­a­lyst func­tion­al­ity exists. It’s already been used to solve previ­ously show-stop­ping prob­lems, to clean up imple­men­ta­tions, and to slowly move the whole indus­try to a not-page-code-depen­dent place—all good things. They are great for what they are intended for, but they are not a magical pill to heal all that ails your imple­men­ta­tion.

How Satellite and Processing Rules differ

  1. Satel­lite can work with your cookies, DOM, meta tags, JavaScript objects, custom code, or data elements from previ­ous pages.
    *A process­ing rule can only work with the data sent by your code, such as context data or exist­ing Site­Cat­a­lyst vari­ables. It can’t pull data out of your cookies, DOM, or meta tags. While it may be easier to tell your devel­oper to set *s.contextData[‘section’] to “prod­ucts” than explain what a prop is and which prop is used for what, your devel­oper must still  know what must be captured, where to get the values for the vari­able, and be consis­tent in HOW it is set across the site. A tag manage­ment system allows you to access elements in your page, using your exist­ing code. For instance, Satel­lite could “grab the value of this form field and put it into eVar40″ or “on the search results page, grab the search term from out of the header 1 tag in the content”.
  2. *Satel­lite requires no certi­fi­ca­tion, has a support team, and you can focus your learn­ing on the things you need.*
    **To enable process­ing rules, you must be certi­fied. The test is free but asks a lot of ques­tions that require a deep knowl­edge of not just process­ing rules, but of Site­Cat­a­lyst as a whole. I’ve seen clients farm out their process­ing rules work because it is simpler than train­ing someone to pass the test, or because they don’t have enough confi­dence in their ability to use the tool and don’t want to mess with real, live data. Of course, this limi­ta­tion could be a problem even with a TMS: there is a certain amount of knowl­edge and confi­dence you must have when making changes to live data, which leads to the next point.
  3. *Satel­lite has flex­i­ble, fast testing capa­bil­i­ties.*
    **Process­ing rules can be diffi­cult to test before letting them affect live data. You can’t see them being set on your pages, with the debug­ger or Charles, for instance, and it can take a day or two to be sure they are working the way intended. You also can’t copy just one rule from one Report Suite to another, which can add another layer of diffi­culty to setup and testing.
  4. *Satel­lite can scale for the most complex enter­prise needs.*
    **Each report suite is limited to only 50 process­ing rule sets. I know that sounds like it should be more more than suffi­cient, but I’ve already seen 2 or 3 clients hit that mark- it’s easy to do since they currently don’t allow nested condi­tions (as in “if … then… else…”) . Also, if an orga­ni­za­tion is using many context vari­ables (which the newest AppMea­sure­ment libraries do), this limit can become even more prob­lem­atic.
  5. *Since Satel­lite code lives client-side, it can work with plugins and other code solu­tions you already have. *
    Depend­ing on other report­ing require­ments, you may still have plugins that require certain vari­ables like s.campaign to be set client-side, so that it can be used in script on the page- for instance, for the cross-visit-partic­i­pa­tion plugin. Many of these plugins could be worked around with a good TMS, but not with process­ing rules alone.
  6. *Satel­lite can access any Site­Cat­a­lyst vari­able- includ­ing RSIDs.*
    **Process­ing rules can’t access/change certain vari­ables or settings, such as the report suite, hit type (page view vs. link), link type (custom, down­load or exit link), or prod­ucts string.
  7. *Satel­lite leaves your imple­men­ta­tion visible to exist­ing free tools like Charles and firebug, and Satel­lite has user roles and work­flow so you can manage who has visi­bil­ity and control of your rules.
    *
    Visi­bil­ity into process­ing rules is restricted to the Admin Console in Site­Cat­a­lyst. Site­Cat­a­lyst users must have admin access to see how they are set, and must know specif­i­cally the one report suite where they might be set, since you can’t view how they are set across multi­ple report suites like you can with your custom vari­ables. This may seem like it isn’t a big deal, but it is defi­nitely a pet peeve of mine to not be able to see how vari­ables are being set, for instance while QAing an imple­men­ta­tion.
  8. Satel­lite allows for for regular expres­sions, giving much greater flex­i­bil­ity. You don’t have to use it, but it’s there if you want it.
    *
    Process­ing rules don’t currently allow for Regular Expres­sions. I know I listed this as a perk (“no coding skills needed”), but it can also be very limit­ing. It does have the stan­dard Site­Cat­a­lyst options in the condi­tions (equals, contains, starts with, is set*…) but the actions do not allow you to parse out or match values from a string. For instance, (and this is a real life recent use case), I couldn’t set up a condi­tion to only capture the first 5 digits of the value of a query string para­me­ter.
  9. Satel­lite can totally change the way your orga­ni­za­tion approaches digital measure­ment.

In truth, listing the things that process­ing rules lack really misses the point: Process­ing Rules are a tool to help Band-Aid (or in some cases expand) exist­ing imple­men­ta­tions. And they’re good for that: I’ll freely admit I have used them, and been grate­ful for them as a Band-Aid. But even when used with context vari­ables to create a clean new imple­men­ta­tion, even with many of the above limi­ta­tions removed, they are *still meant to be just a mode of deploy­ment. *

Healing What Ails You

We need to get the indus­try to stop viewing Tag Manage­ment as just another “mode of deploy­ment”. As Evan right­fully put in his post a while back, Tag Manage­ment shouldn’t resem­ble another tick­et­ing system. Satel­lite was built so that it doesn’t merely fill in the gaps of your Site­Cat­a­lyst Deploy­ment Guide. It helps you iter­a­tively rewrite it, from the Busi­ness Require­ments on down. So while yes, many of my tacti­cal blog posts will be about “treat­ing symp­toms”, don’t think for a moment that that is all there is to Satel­lite. We need to change the game, not just make it easier to play the current game. The busi­ness stake holder shouldn’t have to find someone certi­fied in process­ing rules to tell them what they can and can’t track. Data collec­tion shouldn’t be so far removed from your website that the user expe­ri­ence doesn’t even factor into the collec­tion process.

So if you find your­self asking “how is this different/better than process­ing rules”, please reach out and let us show you that both can be good: while they do have a few tasks in common, process­ing rules are still a method of imple­men­ta­tion; Satel­lite addresses a much bigger picture. It not only makes the day-to-day imple­men­ta­tion easier, it can change the way you view digital measure­ment: the data you can bring in, the ques­tions you can ask, and the actions you can take.

(A big thanks to Bret Gunder­sen and the folks at Adobe for their insight into process­ing rules for this post, and for the work they’ve done on that tool.)

*More infor­ma­tion on how to set process­ing rules can be found at *Kevin Rogers’ blog or the Process­ing Rules section of the Adobe Market­ing Cloud Refer­ence site.*