There is still one big top­ic from this year’s Adobe Sum­mit stand­ing out in my mind. I attend­ed a few great ses­sions that dis­cussed Pro­cess­ing Rules, and I had a hard time not inter­rupt­ing when I heard atten­dees ask: “When should I use Pro­cess­ing Rules instead of a Tag Man­age­ment sys­tem? Clear­ly, a good Tag Man­age­ment tool can do prac­ti­cal­ly every­thing Pro­cess­ing Rules can?” Coin­ci­den­tal­ly, some­one asked a very good ques­tion on my pre­vi­ous post (the first in a series on mov­ing away from using plu­g­ins), won­der­ing how using Satel­lite to set a ?cid track­ing para­me­ter was dif­fer­ent from using a Pro­cess­ing Rule with­in the Site­Cat­a­lyst admin set­tings. Obvi­ous­ly, some clar­i­fi­ca­tion is in order.

Do you want to spend your efforts treat­ing the symp­toms of a lim­it­ed imple­men­ta­tion, or do you want to heal the dis­ease?

Pro­cess­ing rules, while an awe­some tool, can­not replace a good TMS: they have a few func­tions in com­mon but the meth­ods, inten­tion and poten­tial are so very dif­fer­ent. When peo­ple won­der what the dif­fer­ence is, it makes me won­der if some­times we’re miss­ing the for­est because we’re too busy focus­ing on the trees: the lit­tle things that a pro­cess­ing rule or tag man­age­ment sys­tem 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 big­ger pic­ture you real­ize you’ve been look­ing at the lit­tle issues so much that you nev­er were able to push your imple­men­ta­tion to the next stage- a stage that doesn’t require as much main­te­nance, giv­ing you time to actu­al­ly use the data you’ve worked so hard to get.

This isn’t to say you don’t need to fix the lit­tle things- most cer­tain­ly you do, and both Pro­cess­ing Rules and Tag Man­age­ment Sys­tems have some things in com­mon to help you do so. But nev­er for­get the big­ger pic­ture.

Treating the Symptoms

For those not very famil­iar with Pro­cess­ing Rules, they are a set of con­di­tions and cor­re­spond­ing actions that are applied in between data col­lec­tion and VISTA rules/data pro­cess­ing. For exam­ple, you can use a Pro­cess­ing Rule if you want to copy an eVar to a prop with­out chang­ing your code, set an event when­ev­er a spe­cif­ic eVar has a spe­cif­ic val­ue, or assign a con­text vari­able to a vari­able. Pro­cess­ing rules are free for all Adobe Cus­tomers,  but do require a cer­ti­fi­ca­tion before they can be set up.*

processing rules exampleExam­ple pro­cess­ing rule

### The Advan­tages

What can a pro­cess­ing rule offer that a Tag Man­age­ment Sys­tem can not? Here are some ideas we came up with, with the help of Bret Gun­der­sen at Adobe:

  1. Most obvi­ous­ly, they are includ­ed for free in your Adobe prod­uct. They are already acces­si­ble, wait­ing to be used with­out any big changes to your over­all approach to imple­men­ta­tion. (Of course, some might argue that big changes are* need­ed* for most orga­ni­za­tions out there.) You don’t need to over­haul or fix your cur­rent imple­men­ta­tion in order to use them.
  2. Pro­cess­ing rules require zero code knowl­edge: There is no need to touch JavaScript or Reg­u­lar Expres­sions. Many Tag Man­age­ment Sys­tems will claim this “code-less imple­men­ta­tion” as well, but we all know that unless you have a sim­ple, well-con­struct­ed web­site and the most basic of report­ing require­ments, even with a great TMS some code work is nec­es­sary. Of course, some Tag Man­age­ment Sys­tems are less code-heavy than oth­ers, for exam­ple, Satel­lite was designed to need as lit­tle code as pos­si­ble with­out los­ing any of the pow­er and flex­i­bil­i­ty that a lit­tle bit of code can give you.
  3. Pro­cess­ing rules pro­vide con­trol in places where there is no access to a tag man­age­ment tool, such as third-par­ty pages where you can’t change your code to put a Tag Man­age­ment snip­pet on.
  4. Pro­cess­ing rules can be enabled with­out a test cycle, com­plete­ly inde­pen­dent of IT or QA teams. This could be both a good and a bad thing (a lit­tle test­ing 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 ner­vous IT team, and the changes can be imme­di­ate.
  5. *Pro­cess­ing rules are set at the report-suite lev­el. *In some cas­es, like if you are mul­ti-suite tagged, it can be use­ful to have a way to change one data set with­out chang­ing anoth­er.

I’m thrilled that this rel­a­tive­ly new piece of Site­Cat­a­lyst func­tion­al­i­ty exists. It’s already been used to solve pre­vi­ous­ly show-stop­ping prob­lems, to clean up imple­men­ta­tions, and to slow­ly move the whole indus­try to a not-page-code-depen­dent place—all good things. They are great for what they are intend­ed for, but they are not a mag­i­cal pill to heal all that ails your imple­men­ta­tion.

How Satellite and Processing Rules differ

  1. Satel­lite can work with your cook­ies, DOM, meta tags, JavaScript objects, cus­tom code, or data ele­ments from pre­vi­ous pages.
    *A pro­cess­ing rule can only work with the data sent by your code, such as con­text data or exist­ing Site­Cat­a­lyst vari­ables. It can’t pull data out of your cook­ies, DOM, or meta tags. While it may be eas­i­er to tell your devel­op­er to set *s.contextData[‘section’] to “prod­ucts” than explain what a prop is and which prop is used for what, your devel­op­er must still  know what must be cap­tured, where to get the val­ues for the vari­able, and be con­sis­tent in HOW it is set across the site. A tag man­age­ment sys­tem allows you to access ele­ments in your page, using your exist­ing code. For instance, Satel­lite could “grab the val­ue of this form field and put it into eVar40″ or “on the search results page, grab the search term from out of the head­er 1 tag in the con­tent”.
  2. *Satel­lite requires no cer­ti­fi­ca­tion, has a sup­port team, and you can focus your learn­ing on the things you need.*
    **To enable pro­cess­ing rules, you must be cer­ti­fied. The test is free but asks a lot of ques­tions that require a deep knowl­edge of not just pro­cess­ing rules, but of Site­Cat­a­lyst as a whole. I’ve seen clients farm out their pro­cess­ing rules work because it is sim­pler than train­ing some­one to pass the test, or because they don’t have enough con­fi­dence in their abil­i­ty to use the tool and don’t want to mess with real, live data. Of course, this lim­i­ta­tion could be a prob­lem even with a TMS: there is a cer­tain amount of knowl­edge and con­fi­dence you must have when mak­ing changes to live data, which leads to the next point.
  3. *Satel­lite has flex­i­ble, fast test­ing capa­bil­i­ties.*
    **Pro­cess­ing rules can be dif­fi­cult to test before let­ting 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 work­ing the way intend­ed. You also can’t copy just one rule from one Report Suite to anoth­er, which can add anoth­er lay­er of dif­fi­cul­ty to set­up and test­ing.
  4. *Satel­lite can scale for the most com­plex enter­prise needs.*
    **Each report suite is lim­it­ed to only 50 pro­cess­ing rule sets. I know that sounds like it should be more more than suf­fi­cient, but I’ve already seen 2 or 3 clients hit that mark- it’s easy to do since they cur­rent­ly don’t allow nest­ed con­di­tions (as in “if … then… else…”) . Also, if an orga­ni­za­tion is using many con­text vari­ables (which the newest App­Mea­sure­ment libraries do), this lim­it can become even more prob­lem­at­ic.
  5. *Since Satel­lite code lives client-side, it can work with plu­g­ins and oth­er code solu­tions you already have. *
    Depend­ing on oth­er report­ing require­ments, you may still have plu­g­ins that require cer­tain 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-vis­it-par­tic­i­pa­tion plu­g­in. Many of these plu­g­ins could be worked around with a good TMS, but not with pro­cess­ing rules alone.
  6. *Satel­lite can access any Site­Cat­a­lyst vari­able- includ­ing RSIDs.*
    **Pro­cess­ing rules can’t access/change cer­tain vari­ables or set­tings, such as the report suite, hit type (page view vs. link), link type (cus­tom, down­load or exit link), or prod­ucts string.
  7. *Satel­lite leaves your imple­men­ta­tion vis­i­ble to exist­ing free tools like Charles and fire­bug, and Satel­lite has user roles and work­flow so you can man­age who has vis­i­bil­i­ty and con­trol of your rules.
    Vis­i­bil­i­ty into pro­cess­ing rules is restrict­ed to the Admin Con­sole 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­cal­ly the one report suite where they might be set, since you can’t view how they are set across mul­ti­ple report suites like you can with your cus­tom vari­ables. This may seem like it isn’t a big deal, but it is def­i­nite­ly 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 reg­u­lar expres­sions, giv­ing much greater flex­i­bil­i­ty. You don’t have to use it, but it’s there if you want it.
    Pro­cess­ing rules don’t cur­rent­ly allow for Reg­u­lar Expres­sions. I know I list­ed this as a perk (“no cod­ing skills need­ed”), but it can also be very lim­it­ing. It does have the stan­dard Site­Cat­a­lyst options in the con­di­tions (equals, con­tains, starts with, is set*…) but the actions do not allow you to parse out or match val­ues from a string. For instance, (and this is a real life recent use case), I couldn’t set up a con­di­tion to only cap­ture the first 5 dig­its of the val­ue of a query string para­me­ter.
  9. Satel­lite can total­ly change the way your orga­ni­za­tion approach­es dig­i­tal mea­sure­ment.

In truth, list­ing the things that pro­cess­ing rules lack real­ly miss­es the point: Pro­cess­ing Rules are a tool to help Band-Aid (or in some cas­es 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 con­text vari­ables to cre­ate a clean new imple­men­ta­tion, even with many of the above lim­i­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 view­ing Tag Man­age­ment as just anoth­er “mode of deploy­ment”. As Evan right­ful­ly put in his post a while back, Tag Man­age­ment shouldn’t resem­ble anoth­er tick­et­ing sys­tem. Satel­lite was built so that it doesn’t mere­ly fill in the gaps of your Site­Cat­a­lyst Deploy­ment Guide. It helps you iter­a­tive­ly rewrite it, from the Busi­ness Require­ments on down. So while yes, many of my tac­ti­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 eas­i­er to play the cur­rent game. The busi­ness stake hold­er shouldn’t have to find some­one cer­ti­fied in pro­cess­ing rules to tell them what they can and can’t track. Data col­lec­tion shouldn’t be so far removed from your web­site that the user expe­ri­ence doesn’t even fac­tor into the col­lec­tion process.

So if you find your­self ask­ing “how is this different/better than pro­cess­ing rules”, please reach out and let us show you that both can be good: while they do have a few tasks in com­mon, pro­cess­ing rules are still a method of imple­men­ta­tion; Satel­lite address­es a much big­ger pic­ture. It not only makes the day-to-day imple­men­ta­tion eas­i­er, it can change the way you view dig­i­tal mea­sure­ment: the data you can bring in, the ques­tions you can ask, and the actions you can take.

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

*More infor­ma­tion on how to set pro­cess­ing rules can be found at *Kevin Rogers’ blog or the Pro­cess­ing Rules sec­tion of the Adobe Mar­ket­ing Cloud Ref­er­ence site.*