Question for the Community -
We are doing some simple ABM email campaigns, and we house all of our emails in one "ABM Content" program so we don't create emails over and over and there's one area for all of our past email content, and then we create individual programs for each of our accounts and bring those emails into those smart campaigns. The problem we are coming across is that when we want to personalize with the company's name we are sending to, we want a more casual use of their company name, not "ABC Company Inc." but "ABC."
A remedy would be to create local tokens in each program for the company name (I think) but because all the emails are housed outside of each program, from my understanding this wouldn't' work because there are no emails in the program to put the local tokens on, correct? A local token can only work on an email that's inside the corresponding program right? I could be wrong and there could be a way to make this work, but I'd appreciate any input you all have!
Thanks!
Alec
Tokens work fine in emails that are stored centrally - e.g., Design Studio - and then referenced from a program in Marketing Activities. So yes, you can use a {{my.CompanyName}} token for these.
As long as your Token names are consistently used. If you create
{{my.CompanyName}} in an email (wherever it is) and then your local Program/Engagement that uses this email has instead
{{my.CompanyIDnumber}} and not the correct token inside the Email, the token will fail.'
You can also create new fields to generate new Global Lead tokens that would not fail. Generally, avoid creating new fields for tokenization unless you plan to use them regularly.
I kinda assumed he would be using a same-named token in the email and what's used in the program. But yes, this will only work if the tokens in the email are named exactly the same as they are within the local program.
BTW, we use DemandBase to enrich our form submits with about 12 additional company attributes (they also offer a batch append for existing names in Marketo). Things like industry, # employees, annual revenue, SIC code, website URL, etc. One of those attributes is "Marketing Alias". It's basically the known name of the company, without the use of LLC, Inc., etc. So this is alternate way of using person-level tokens to achieve a similar outcome. The program level tokens would obviously give you greater control though.
At a previous role we used a similar Account-level field - something like "Business Friendly Name" or something - as the colloquial name of the business should it differ from the name of the Account (with rules to populate with Account name if left empty). Agree with Josh re: token solutions > new fields but this was a helpful one on a number of occasions.
In our business model we have only a select handful of companies that we would include in ABM programs - the more companies you have the more campaigns you'll need. Also, in our business use-case, we do not have an excess of fields. Those two things must be taken into consideration prior to the solution that I've created for my own use case:
I created a new field "generic company name". I created scheduled campaigns for the initial fill that, once complete, are followed by trigger campaigns.
Campaign logic is: If "company name" Contains (), change "generic company name" new value (). Example: "Company name" contains (General Electric; GE Aviation, GE Power, GE Oil and Gas, etc.) change "generic company name" to (GE).
For trigger campaigns: If "company name" changes to (General Electric; etc.) change "generic company name" to (GE)
Using "contains" will help with variations in the user-submitted name (GE Power Houston, GE Power Boise, etc)
I've found making a new field for this is helpful on several fronts. 1) it can be called for in any asset or campaign; 2) It can be called for in any list - this is especially helpful if you don't target by site/division; 3) it can help with DB reporting on company.