Are you suffering from source code insanity?

Marketing source codes have been around for decades. But are they suited to today’s data-intensive, highly-integrated marketing model?

Source codes were originally created to provide a simple answer to a seemingly simple business question: how are people interacting with my marketing assets? The practice began with the growing sophistication of direct mail in the 1980’s. Purveyors of paper catalogs would print a code on the back. When the customer called the toll-free number to place an order, it was the first thing the customer service team was trained to collect. This code would typically identify the actual marketing piece in the customer’s hand, and very often, the customer themselves. But it also identified the specific creative execution that motivated the customer to call and order: highly valuable data.

Then the Internet happened. The source code made a clumsy transition to the digital world and when it made that migration, it inexplicably brought some of its analog baggage with it.

Intelligence in the naming convention

At some point, marketers decided to build intelligence into their source codes. Specifically, the code comprised a series of values which together created a unique identifier for the marketing asset. For example DM-0691-MS might mean: Direct Mail (channel), June of 1991 (date), Men’s Spring Catalog (content or version). Three important dimensions: channel, date and execution, were all captured in the code itself. Genius, right?

I can speculate on the reasons this makes so much sense to the marketer.
First, the marketer likes to look at the code and just know what it means. I have heard this coast to coast and on at least two other continents. Seeing a code and being able to translate it is convenient. There is comfort in instant recognition. However, this approach has unforeseen and undesirable side effects.

The propagation factor

One of those side effects is a function of the modern marketing technology stack. Applications, web sites and databases are typically tightly integrated. So, as an example, you create a new web form to collect information about people that may be interested in attending a conference. The web form has been tagged with a code: 123-XYZ-0317. Every time a user fills out the form that newly acquired record will be tied to that code. Perfect!

Monday at 9:00 AM the form goes into production. Within an hour or two you have started collecting names and new registrants with that code are showing up in your automation platform, subscribed and ready to receive email. A couple hours after that, they sync to your CRM system as new leads. 24 hours later, they are in your data warehouse and the code is displaying on your “New Lead Acquisition” report.

This is the propagation factor. Within 24 hours your new code has shown up in a minimum of three systems and tied to dozens of valuable new leads. It’s everywhere. And you can’t get rid of it or change it. History is written.

Then disaster strikes. When you created the code you thought the relevant product was XYZ, which corresponds to, say… navigation equipment. Sadly, the navigation equipment code is actually XYY and the code you used has associated all your new, hard-earned leads tied to code XYZ which is fishing tackle.

So now you’re stuck. The cat is out of the proverbial bag. The code has “propagated” into the operational infrastructure. I don’t want to go into the fixes for this kind of problem, but I can tell you I have been asked to make them many, many times over the years. Most solutions are expensive, time consuming and amount to cover-ups. The code is out there… forever. The error will most painfully manifest itself in the reporting layer when the folks over in fishing tackle are both thrilled and slightly perplexed by their new leads.

Reverse engineering

I have worked with dozens (hundreds?) of clients over the past 15 years. There is this inevitable moment in the lifecycle of a data warehousing/reporting project where the client says, “I need you to parse these values out of the code for me.” This usually arises when the marketer is designing a report or doing an analysis and they need access to the campaign hierarchy that is buried in their code structure. It seems like an easy request and data geeks love a challenge. But, it never really works. No matter how carefully they’ve been managed, there will inevitably be errors, spaces, hyphens, underscores and basic typos. It also begs the question, why put all that intelligence in the code string if you are just going to pull it back out?

What’s in a code?

It’s important to take a moment and consider what these codes are used for. Sometimes they are limited to response mechanisms like web forms, or direct mail coupons. But there are organizations out there that use them for ALL the marketing assets that a customer might interact with. They are used to organize reports, analyze marketing performance, directly or indirectly allocate new resources, pay bonuses, and determine the success or failure of marketing efforts worth millions of dollars per year. Even with so much at stake, most organizations do not apply the rigor and quality control to these codes that they deserve.

Some steps to take

• Centralize the source code production. Don’t kid yourself, there are two or three people in your organization that are creating these codes and storing them in spreadsheets…on their laptops… while working from their kitchen. Admit it. You know I’m right! That’s where the errors begin. Have a centralized application for deriving these codes. Build your own (not as hard as it sounds), ask a consultant to build something for you (short money) or leverage functionality in one of your existing applications.

• Integrate the code repository. Make sure when you decide to build a centralized code system, it is readily available to be accessed by other applications. Most importantly, the data warehouse or BI system that does your reporting. Your data team will be thrilled to have a single, concise source for this valuable information they see showing up in all the other systems in the marketing technology stack.

• Make the codes meaningless. Break the habit of trying to embed meaning in the code itself. This sounds like marketing heresy, but stick with me. If there is meaning in the code (channel, date, product, program, campaign, customer segment, etc.) then when the inevitable error occurs, that error is immediately propagated.

• Make your codes numeric, as in the first code is 1 the second code is 2 and so on. Remember, the centralized code repository has all the attributes of the code stored. A quick lookup will tell you everything you need to know about codes 1, 2 and 3.

This seems like an obvious thing, but I’ll say it anyway. If you remove the intelligence from the code, you mitigate the risk of a code mistakenly propagating bad data all over the enterprise. If you accidently classify code 2 as fishing tackle, don’t sweat it. Just make the change in the repository, set it back to navigation equipment and all the reports in your enterprise will correct themselves.

This also allows you to add further meaning to the code and scale your operation. Let’s say you want to add an attribute to your set of codes, for example, product group. This is just a matter of adding a column to the repository and letting your data team know you added it. The new attribute can be applied to all the codes on day one. This is impossible in your old environment. You can’t retroactively update old codes like “123-XYZ-0317” already in MAP and CRM with the new product group value “123-PG-XYZ-0317.”

Conclusion

Take care to consider how you are managing this important corporate asset. Your marketing codes deserve the same due diligence your IT department gives to other enterprise data on inventory, finance, purchasing and of course, your customer data. It deserves a scalable, centralized and carefully managed strategy.