Processing Rules vs Satellite: do you want a band-aid or a doctor?

Cross-post: I originally published this on SearchDiscovery’s blog in April 2013.

There is still one big topic from this year’s Adobe Summit standing out in my mind. I attended a few great sessions that discussed Processing Rules, and I had a hard time not interrupting when I heard attendees ask: “When should I use Processing Rules instead of a Tag Management system? Clearly, a good Tag Management tool can do practically everything Processing Rules can?” Coincidentally, someone asked a very good question on my previous post(the first in a series on moving away from using plugins), wondering how using Satellite to set a ?cid tracking parameter was different from using a Processing Rule within the SiteCatalyst admin settings. Obviously, some clarification is in order.

Do you want to spend your efforts treating the symptoms of a limited implementation, or do you want to heal the disease?

Processing rules, while an awesome tool, cannot replace a good TMS: they have a few functions in common but the methods, intention and potential are so very different. When people wonder what the difference is, it makes me wonder if sometimes we’re missing the forest because we’re too busy focusing on the trees: the little things that a processing rule or tag management system can both fix, and the day-to-day headaches that plague those responsible for maintaining a SiteCatalyst implementation. 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 implementation to the next stage- a stage that doesn’t require as much maintenance, giving you time to actually 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 Processing Rules and Tag Management Systems have some things in common to help you do so. But never forget the bigger picture.

Treating the Symptoms

For those not very familiar with Processing Rules, they are a set of conditions and corresponding actions that are applied in between data collection and VISTA rules/data processing. For example, you can use a Processing Rule if you want to copy an eVar to a prop without changing your code, set an event whenever a specific eVar has a specific value, or assign a context variable to a variable. Processing rules are free for all Adobe Customers,  but do require a certification before they can be set up.*

processing rules example

The Advantages

What can a processing rule offer that a Tag Management System can not? Here are some ideas we came up with:

  1. Most obviously, they are included for free in your Adobe product. They are already accessible, waiting to be used without any big changes to your overall approach to implementation. (Of course, some might argue that big changes are* needed* for most organizations out there.) You don’t need to overhaul or fix your current implementation in order to use them.
  2. Processing rules require zero code knowledge: There is no need to touch JavaScript or Regular Expressions. Many Tag Management Systems will claim this “code-less implementation” as well, but we all know that unless you have a simple, well-constructed website and the most basic of reporting requirements, even with a great TMS some code work is necessary. Of course, some Tag Management Systems are less code-heavy than others, for example, Satellite was designed to need as little code as possible without losing any of the power and flexibility that a little bit of code can give you.
  3. Processing rules provide control in places where there is no access to a tag management tool, such as third-party pages where you can’t change your code to put a Tag Management snippet on.
  4. Processing rules can be enabled without a test cycle, completely independent of IT or QA teams. This could be both a good and a bad thing (a little testing is a good thing before touching 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 immediate.
  5. *Processing 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 changing another.

I’m thrilled that this relatively new piece of SiteCatalyst functionality exists. It’s already been used to solve previously show-stopping problems, to clean up implementations, and to slowly move the whole industry to a not-page-code-dependent 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 implementation.

How Satellite and Processing Rules differ

  1. Satellite can work with your cookies, DOM, meta tags, JavaScript objects, custom code, or data elements from previous pages.
    *A processing rule can only work with the data sent by your code, such as context data or existing SiteCatalyst variables. It can’t pull data out of your cookies, DOM, or meta tags. While it may be easier to tell your developer to set *s.contextData[‘section’]to “products” than explain what a prop is and which prop is used for what, your developer must still  know what must be captured, where to get the values for the variable, and be consistent in HOW it is set across the site. A tag management system allows you to access elements in your page, using your existing code. For instance, Satellite 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. *Satellite requires no certification, has a support team, and you can focus your learning on the things you need.*
    **To enable processing rules, you must be certified. The test is free but asks a lot of questions that require a deep knowledge of not just processing rules, but of SiteCatalyst as a whole. I’ve seen clients farm out their processing rules work because it is simpler than training someone to pass the test, or because they don’t have enough confidence in their ability to use the tool and don’t want to mess with real, live data. Of course, this limitation could be a problem even with a TMS: there is a certain amount of knowledge and confidence you must have when making changes to live data, which leads to the next point.
  3. *Satellite has flexible, fast testing capabilities.*
    **Processing rules can be difficult to test before letting them affect live data. You can’t see them being set on your pages, with the debugger 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 difficulty to setup and testing.
  4. *Satellite can scale for the most complex enterprise needs.*
    **Each report suite is limited to only 50 processing rule sets. I know that sounds like it should be more more than sufficient, but I’ve already seen 2 or 3 clients hit that mark- it’s easy to do since they currently don’t allow nested conditions (as in “if … then… else…”) . Also, if an organization is using many context variables (which the newest AppMeasurement libraries do), this limit can become even more problematic.
  5. *Since Satellite code lives client-side, it can work with plugins and other code solutions you already have. *
    Depending on other reporting requirements, you may still have plugins that require certain variables 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-participation plugin. Many of these plugins could be worked around with a good TMS, but not with processing rules alone.
  6. *Satellite can access any SiteCatalyst variable- including RSIDs.*
    **Processing rules can’t access/change certain variables or settings, such as the report suite, hit type (page view vs. link), link type (custom, download or exit link), or products string.
  7. *Satellite leaves your implementation visible to existing free tools like Charles and firebug, and Satellite has user roles and workflow so you can manage who has visibility and control of your rules.
    Visibility into processing rules is restricted to the Admin Console in SiteCatalyst. SiteCatalyst users must have admin access to see how they are set, and must know specifically the one report suite where they might be set, since you can’t view how they are set across multiple report suites like you can with your custom variables. This may seem like it isn’t a big deal, but it is definitely a pet peeve of mine to not be able to see how variables are being set, for instance while QAing an implementation.
  8. Satellite allows for for regular expressions, giving much greater flexibility. You don’t have to use it, but it’s there if you want it.
    Processing rules don’t currently allow for Regular Expressions. I know I listed this as a perk (“no coding skills needed”), but it can also be very limiting. It does have the standard SiteCatalyst options in the conditions (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 condition to only capture the first 5 digits of the value of a query string parameter.
  9. Satellite can totally change the way your organization approaches digital measurement.

In truth, listing the things that processing rules lack really misses the point: Processing Rules are a tool to help Band-Aid (or in some cases expand) existing implementations. And they’re good for that: I’ll freely admit I have used them, and been grateful for them as a Band-Aid. But even when used with context variables to create a clean new implementation, even with many of the above limitations removed, they are *still meant to be just a mode of deployment. *

Healing What Ails You

We need to get the industry to stop viewing Tag Management as just another “mode of deployment”. As Evan rightfully put in his post a while back, Tag Management shouldn’t resemble another ticketing system. Satellite was built so that it doesn’t merely fill in the gaps of your SiteCatalyst Deployment Guide. It helps you iteratively rewrite it, from the Business Requirements on down. So while yes, many of my tactical blog posts will be about “treating symptoms”, don’t think for a moment that that is all there is to Satellite. We need to change the game, not just make it easier to play the current game. The business stake holder shouldn’t have to find someone certified in processing rules to tell them what they can and can’t track. Data collection shouldn’t be so far removed from your website that the user experience doesn’t even factor into the collection process.

So if you find yourself asking “how is this different/better than processing rules”, please reach out and let us show you that both can be good: while they do have a few tasks in common, processing rules are still a method of implementation; Satellite addresses a much bigger picture. It not only makes the day-to-day implementation easier, it can change the way you view digital measurement: the data you can bring in, the questions you can ask, and the actions you can take.

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

*More information on how to set processing rules can be found at *Kevin Rogers’ blog or the Processing Rules section of the Adobe Marketing Cloud Reference site.*

Leave a Reply

Your email address will not be published. Required fields are marked *