Prior to e-commerce sales on the Internet, typically, a catalog company would trace 80% of their orders/revenue to a specific source or key code. Catalogers didn’t worry about the remaining 20%. They would simply allocate this portion proportionally across all source codes. Life was simple in those days! Today, tracing orders to a specific code is much more difficult and complex. That’s why the use of match-backs has become a way a life for catalogers. This month, I want to focus on the importance of tracing to a specific source code and through the use of a match-back.

A source code is simply an identifier that goes with a particular housefile segment, prospect list, etc. It really does not matter what the code is as long as it is unique to that particular segment and/or list being coded. Some catalogs prefer to build some intelligence into the code while other simply use a sequential numbering system. Alpha. Numeric. A combination of alpha and numeric. It really does not matter. Source codes are like leaving bread crumbs in the snow so you can find your way. Without them, you are lost! Source codes help us know which housefile segments to mail, which prospect lists to use (and those to eliminate), the “best” promotional offer to make and much more. A cataloger cannot remain in business very long without using source codes.

As catalogers, we should do everything possible to capture source codes. Some catalogers feel it is not as important to capture source codes on the front-end because the code will be identified when the match-back is done. While hopefully this is true, match-backs are not perfect. What’s more, match-backs cost money and are done infrequently. By not capturing source codes on the front-end it becomes even more difficult to know how prospect lists and/or segments of the housefile are performing on a daily or weekly basis.

A growing factor impacting the ability to track source codes has to do with co-mailing. There are two ways to co-mail; in-line and off-line. When co-mailing in-line while the catalogs are being bound, both the back cover and order form in the center of the catalog can be ink-jet imaged with the customer’s name, address and source code. This is how co-mailing was done initially. Off-line co-mailing which occurs after the catalogs have been bound is becoming more popular especially for smaller mailers because the catalogs do not have to be the same trim size. However, with off-line co-mailing, the printer can only ink-jet in one place, the back cover. By not ink-jetting the order form at centerfold, catalogers reduce the number of orders they are able to trace to a specific source code hoping once again a match-back will identify the proper code.

CONCLUSION: It is important to weigh the cost savings resulting from off-line co-mailing vs. the need to ink-jet the source code on the order form. Considering the recent postage rate increase, I too would want to maximize the savings. My only point is that off-line co-mailing does negatively impact source code tracking.

Here are a few ways to increase the amount of business traced to a specific source code:

1. Place the source code in a colored box on the back of your catalog.
2. Use as few of digits (alpha or numeric) as possible, i.e., 5 or 6 max.
3. Avoid using codes that can be mistaken for letters or numbers like “o” vs. “0” or “1” vs. “I” and so on.
4. Ink-jet image the source code on the back of the catalog (in the box) and on the order form at centerfold as well (not possible if you off-line co-mail). Best for the code to appear both places.
5. Train telephone sales people to ask the customer for the source code. (It is always a good idea to monitor calls to make certain reps are asking for the source codes.)
6. Be sure every catalog is coded including bulk copies used as bounce-back catalogs and to fulfill catalog requests (inquiries).
7. Make sure there is a place on your Website for the customer to add the catalog code when placing their order. (Having this option can increase the traceability of Internet orders by as much as 20% or more.)

To some degree, I feel catalogers have become more lackadaisical about capturing source codes on the front-end thinking the code will be identified by the match-back.  I am still of the old school feeling that we should attempt to identify as many source codes on the front-end as we possibly can. As mentioned earlier, match-backs are not perfect. There are issues with regard to date ranges, match-back logic used, timing of when the match-back is done, multiple catalog titles and more.

The process of matching back is not all that complicated. It is simple a matter of matching the mail files retained by your service bureau with your order file.  At Lett Direct, we have looked into doing match-backs at the Stock Keeping Unit (SKU) level. This seemed to be a logical solution for catalog companies who circulate more than one title to the same people with overlapping mail dates. This results in an extra step in order to identify which book the customer purchased from. The problem with this is that there is SKU duplication in both books therefore this “extra step” to identify the matches at the SKU level does not always help.

Another issue with match-backs has to do with allocating the Internet portion fairly. For example, if someone purchases a product from the Internet, they become an Internet buyer. However, they will receive a catalog in the mail. They may make a second purchase from the Internet. When we do a match-back, this person will always be considered a catalog buyer after their initial purchase because they were mailed a catalog with a housefile key code identifier. While the catalog remains the largest driver of traffic to the Web, this does make it difficult from the Internet Marketing Manager to verify that they are growing their business and remaining on budget since, in this case, the credit is going to the catalog. This factor will impact the repurchase stats for the Internet.

Date ranges are important to accurate match-back reporting. How many months should you match-back, for example. This varies by how often you mail and how much business is driven by the Web. The problem always occurs in the last catalog mailed during holiday. The match-back will favor this mailing. For example, let’s assume a cataloger make five different holiday mailings. A large portion of the sales from these mailings will occur the last three or four weeks prior to the Christmas holiday. In this example, the last mailing will receive a disproportional amount of the sales from the match-back. I do not favor making any assumption for the allocation of this factor because it means introducing yet another unknown. Any allocation at this point is really not necessary because what really matters is the performance of the housefile buyers by segment for all five mailings combined. Any analysis from names that are mailed more than once should be evaluated in total across all mailings and not necessarily by individual drop or mailing.

Please note how high the RPC (Revenue per Catalog) mailed was holiday 5. Again, this is due to the fact that the last mailing in the season is favored in the match-back logic. When we average the RPC for all five drops in our example, the overall performance by segment can be evaluated.

Source code tracking is as important as ever. The fact that match-backs are done on the back-end of a mailing does not mean we should not stress the importance of capturing source codes on the front-end. Continue to capture those source codes on the front-end and use the match-back to help allocate orders through the Web and miscellaneous non-traceable results. Recognize match-back methodology is not perfect. Certain assumptions must be made. Tracing orders and sales to a specific source or key code is critical to arriving at proper conclusions and making the best decision regarding future circulation plans.