The products pictured below are herbal teas from Poland. Whilst we were in Europe, herbal teas were not a part of normal conversation, but we've learned through keen observation that there's an herbal fix, remedy or aid for most common ailments. Generally speaking, these products have English translation stickers- I didn't look at the translation for the first one, but I'm guessing it has something to do with one's solid or liquid waste, and the regulation thereof.
The next one is an aid for varicose veins. I showed this to a coworker (who is married to an OTB [off-the-boat, born in Poland] woman, and he said that in no way would a woman that had those legs have varicose veins. I guess truth in advertising is abused everywhere. The last one shows a young mother breastfeeding. I'm guessing by the brown flower or leaf decorations at the bottom left and right that, when taken an hour before feeding, will allow the newborn and infant to enjoy chocalatey mother's milk. What will they think of next?
Oh, well, enough of herbal tea. Let's talk about data.
As some readers are probably aware, I work for a company that produces large volumes of "high quality" direct mail. That's "junk mail" to most readers. We print stuff for a wide variety of clients- insurance, video services, sweepstakes, nonprofits and Federal agencies, to name a few. As a programmer, I look at LOTS of data. Some is good. Some is very good.
And some is atrocious.
The sad part about the last comment is that in some cases, the client actually OWNS the data- it doesn't come from a rented list. In other words, the person who is receiving the mailpiece has actually done business with our client before.
In the wonderful world of programming, we have the ability to at least skirt some bad data. For example, if the first name and last name are mere initials, we can throw some logic in to substitute "Dear Neighbor" in a salutation or "Current Plutonium Purchaser" in the address block. We often alert clients to these situations, and the clients themselves are often aware that these situations may arise, and they give us instructions to cover these situations.
Sometimes, though, an unforseen situation arises, and despite all safeguards, the best option available to the programmer is to warn the press that the imaging is not a mistake- the data is messed up.
I was recently QCing a job prior to printing, and came across an interesting record. Normally, when we pull signoff records for a client, we include a "longest name", and often a "shortest name". The longest name shows the client that a name will fit where it needs to fit. The shortest name shows them what a short name looks like. The problem is this: the shortest name is often an initial, and rather than spending a few extra bucks on programming or data cleanup, the client often lets the data go to press "as is". This particular client had a special field for a "first+middle name". The problem I ran into was that the middle name was not properly cased in 100% of the records I looked at. So, I alerted the press to the situation so that they would not stop running- which can be expensive.
That's all for now- next up, an update on overtime.
As always, I am hochspeyer, blogging data analysis and management so you don't have to.
That's all for now- next up, an update on overtime.
As always, I am hochspeyer, blogging data analysis and management so you don't have to.
No comments:
Post a Comment