Email Personalisation - Bad Data

[Colin_Ryder]

Hi guys

Like a lot of you we use the standard lead.first name token for email personalisation in either the body (common) or sometimes in the subject line.

Example; Dear {{lead.First Name:default=Sir/Madam}}

For small blasts this is fine because we can check the data prior and make sure it's one or the other but what do recommend to use/fix when you have bad data such as someone's first name being one character or common rubbish such as "Test" or other examples

ie. T Smith. > this would show as "Dear T"

or

Test Test > this would show as "Dear Test"

I'm pretty sure there were some great recommendations on here but I couldn't find them when I did a search.

I know we can use Email Scripting (not using it yet ) for fixing issues with capitals etc. I wonder if we could use something like that for this as well.

Any suggestions, most welcome

Thanks

Colin

ps - I did think we could suspend anyone with "Test" or something so they wouldn't receive emails - thoughts on this - and is there a common list someone could share

[Nicholas_Manojl]

You would probably be better off having a weekly review of your data in Excel, or setting up some sort of QA process for new leads.

I don't think there is much of a shortcut.

Scripting isn't great because there is just too much variation. For example, you need to write a relatively complex script for the odd cases someone has a double barrel first name - otherwise you'll say "Dear John paul". Similarly, you wouldn't want to do this sort of thing with their last name, because you'll send an email to Maria Von Trapp, instead of Maria von Trapp.

You also can't mix scripting with a dynamic email, so whatever gain you make in personalisation you've lost a limb anyhow. The email scripting also only renders at send time - it can't be inserted into a campaign flow. So whilst you could write a script that checks the length of the first name in seconds, you would still need to check it is working correctly. But here is an example anyhow:

#if (${lead.FirstName.length()} == '0') //or maybe less than 2 for your purposes

#set ($firstname = "there")

Hi $firstname

#else

#set ($firstname = ${lead.FirstName.toLowerCase()})

$display.capitalize($firstname)

#end

I have forgotten his name (he is on this forum), but you could ask the guy at Bright Hooks to write you a fancy webhook that might take care of some of your common issues - his demo stuff is good but I haven't used him professionally. That would have the advantage of fixing your data.

Personally, if I was a CEO, and I'm not, I'd ditch paying for any sort of premium support and instead hire a junior to do QA on all my new leads. 

[SanfordWhiteman]

You also can't mix scripting with a dynamic email

Ah, but you can.  Watch my blog.  (Hint: Text {{my.tokens}} actually evaluate in a Velocity context, though this order of operations is not documented.)

[A webhook] would have the advantage of fixing your data.

A simple FlowBoost script to do this:

var firstName = {{Lead.FirstName}}.replace(/(\w)(\w*)/g, function(match,$1,$2){ 
  return $1.toUpperCase() + $2.toLowerCase(); 
});

Personally, if I was a CEO, and I'm not, I'd ditch paying for any sort of premium support and instead hire a junior to do QA on all my new leads.

I approve of this message.

[Frank_Breen2]

Colin, here's a great article that might help you: A Few More Email Scripting Examples.

[Grégoire_Miche2]

Hi Colin,

Velocity is great to fix format issues or generate the final output, but is not really recommended for fixing bad data.

I recommend rather to use a proxy field and run some smart campaigns to fill that field in.

• If the first name is in a list of known / correct ones (you can update it on a regular basis) -> proxy field = first name. Else Proxy field = "friend".

Then you can use the velocity to fix Uppercase and other formatting issues.

Greg

[SanfordWhiteman]

List of allowed first names? Is this one of those French things again?

Anyway, one-letter first names or last names don't represent junk data. They're used professionally by tens of millions of people in India (and beyond). (By "professionally" I mean they aren't using shorthand on a form, that's the way their name is written in most other contexts, too.)

One-letter first and last names is probably not culturally linked. But they still may be the person's actual initials, so I don't know why you'd "fix it up." I can see omitting one-letter names using Velocity because they look iffy in some layouts, but treating them as bad data seems even stranger to me!

[Nicholas_Manojl]

Another common example is "M." for people with the first name Mohammed.

[SanfordWhiteman]

Yep.

[Grégoire_Miche2]

I meant list of recognised first names, not allowed ones

-Greg

[SanfordWhiteman]

Yeah, but what's the difference?

[Grégoire_Miche2]

I prefer to send a "Dear Friend" to quite a few people than taking the risk of send someone a "Dear Qwerty" because that person even forgot they had provided this first name 8 months ago on my web site. I latin culture, people prefer that someone be a litlle distant than making a big mistake on their first name, even if THEY provided that mistaken name in the first place.

And also because we have the problem of ladies and gents. "Dear" in english becomes "Chère" for ladies and "Cher" for gentlemen in French. And this is the same in Spanish, Italian, ...

-Greg

[SanfordWhiteman]

So you mean a blacklist of disallowed names, not a whitelist of allowed names. That makes more sense. The way you phrased it was "if in list, then use the name they entered" -- thus a whitelist.

[Grégoire_Miche2]

Yes, exactly.

-Greg

[Grégoire_Miche2]

We had that conversation already, I remember