Adobe’s Classification Rule Builder and Claravine
Every once in a while, we get a question about how Claravine is different from Adobe’s inbuilt Classification Rule Builder (CRB).
It’s a good question, and a pretty easy one to answer. The simplest and most important thing to say is this: use of Claravine and Adobe CRB is not an either/or kind of a thing. In fact, a best practice would be to use both.
The main difference is whether your tracking codes will be prepared and described before the campaign goes live (using Claravine), or only after the campaign goes live (using just Classification Rule Builder).
If you’re going to use Adobe CRB, it’s important to keep in mind that you need to take care that your ‘regular expression’ (aka your RegEx) does not overmatch. In other words, you must not use too broad a brush in your matching logic. If you do, you run the risk of inadvertently destroying or overwriting your previous rules — creating values for classifications that never should have been created. In designing your rules, you have to think not only of what data matches your logic, but of what might accidentally match, and of what doesn’t match. You can ruin good data accidentally by using a logic expression that isn’t constrained enough.
For example, suppose I create a rule that every person who lives in my house whose name has a C in it has to go get a job, to support my family. That list will include me, of course — I am the intended target of the rule. But it will also end up including my 14-year-old daughter Lucy — an unintended target of the rule. It turns out I should have been more careful, and specified that the rule only applied to people whose names start with C. But then, what if my nephew Charlie moves in with us? You have to think about how future changes can impact your rules.
Here’s a data collection example of the rule change: suppose I have a delimited pattern that has five parts. Later, someone comes in and says, “we don’t actually need some of this data,” and removes one field. A poorly executed RegEx might move every match one step from where it should be. Let’s say the form originated as Last Name, First Name, Middle Initial, Date of Birth, Date of Death. So, for me, the record would be Scribner, Craig, D., my date of birth, and then a blank field last — because I’m not dead yet. If someone comes along and removes the middle initial field, that causes problems, because for my record, that data was already collected. Now my birth date becomes nonsense (the letter D), instead of a number, and my date of birth suddenly looks like my date of death — all because of a change to the taxonomy for data flowing in.
Unless you have a matching logic (for example, you could require the data for the birth date to be formatted as a number, in dd/mm/yy format), you risk making your classification data less reliable, rather than more reliable, with an overly broad application of rules.
Adobe’s CRB is going to take whatever data matches the rule you put in place, and gobble up everything in its path. It will apply its logic everywhere, regardless of whether it should. Here’s why that is dangerous: there’s no permanent log of the changes that are made, there’s no way to see if mistakes creep in, and there is no undo feature. If used correctly, CRB can bring a lot of efficiency to your data capture. But if you accidentally match too much and change your data, it has the potential to be ruinous.
With that said, I DO want to promote the idea of using regular expression logic. You just need to be careful. You want a rule that is modest and incremental, but still applicable to a host of circumstances.
In fact, employing regular expression logic is the only way it makes sense to use Classification Rule Builder. If you have a bunch of tracking codes that include the data point “A,” and A always means the same thing, it makes sense to write a macro rule with specific directions: “whenever you see A over here, classify this other field to reflect that.” Otherwise, you could end up going code by code to tell your system, ABCDE means this, ACDEF means, this, A1234 means this. If you’re classifying codes one at a time, you’re not getting any value out of CRB. You want a rule that is tightly focused and not greedy. If your rule is constrained, but still applicable to a lot of codes that are going to come through, CRB can save you time.
The final consideration is this: Adobe’s classification rule builder isn’t just a parser, it can be a transformer. For the longest time I thought one of the restrictions of classification rule builder was that it was a good matcher, but that it could only yield a yes/no for whatever it finds. In other words, I thought it could only parse a code to see whether a variable is present without any ability to analyze or interpret the code.
That’s not true. You can transform codes in CRB, not just mimic their parts. Stay tuned for an upcoming blog post where I write more about that feature.