One of my favorite aspects of working in Salesforce Marketing Cloud is the ability to use AMPscript. It allows the emails I code to be highly dynamic and personalized to subscribers, and it’s easy to learn. But when you have been working with AMPscript as long as I have, it is easy to neglect the basics when moving higher, further, faster. Here are some pitfalls to try and avoid when using AMPscript:
AMPscript is wonderfully easy to learn, but the rules are finite. For the script to work properly, you have to use two (count them: TWO) percentage marks to begin, end, and interpret the code. If you don’t have two, it will not work. While this seems simple, the simplicity is exactly what makes it easy to overlook. When you have a subject line set to dynamically render and it doesn’t, start by checking the percentage marks.
It is also important to use the correct delimiter–which depends on if you are using AMPscript blocks or inline AMPscript–AND be sure to use the same one for opening and closing or else your code will be ignored. As a refresher, the AMPscript blocks are for defining your code for interpretation, and they are where you declare and set variables. AMPscript blocks are defined using an inner bracket delimiter ( %%[ ]%% ). The inline AMPscript is for interpreting and executing within message context, and it is defined with the equal sign (%%= =%%). When typing quickly, it can be easy to hit the wrong key. Hitting the wrong key leads to validation errors or content not showing.
VARIABLES AND ORDER OF OPERATIONS
Along with the syntax, variable declaration and variable setting are both necessary but very easy to skip, especially declarations. While it is considered “best practice” to declare your variables, most marketers I know go straight to setting. While this is fine to do, it really is best to declare and then set, if only to maintain sanity. Declaring will add the variable name to the Variables Dictionary, which can save some headaches for anyone viewing the code after the original setup to find out what is needed AND what is already present in the code.
Knowing what is present in the code can help avoid some problematic issues, such as setting variables more than once in the code for different purposes. If you set the state once so you can pull dynamic content from it, but then you have a variable with the same name to display the correct state in the footer, you can break the entirety of personalization. If you need or want to reset your variables, be clear about where you are doing this so that you do not inadvertently break it all.
Along the same lines, one thing more marketers overlook more than they care to admit is the order of operations for AMPscript. The order starts with the email preheader, then the HTML body, then the text body, and then the subject line. What this means is if you duplicate your AMPscript by allowing the text body to be automatically created by Marketing Cloud, the AMPscript for ANYTHING is pulling from the text body. While HTML is most important, marketers do need to remain aware of the text version to best serve their customers as well as assist their deliverability metrics. While using the auto-generated version can save time, it can cause you headaches down the road.
AMPscript is very powerful and elastic, which means it also relies on a steady eye when setting variables. While you can pull from profile attributes, the usage I have seen most often is when using data extensions. As we know, data extensions are also very elastic, which can lead further down the slippery slope to“Why is my code not working?” When setting your variables, you have to be sure to include any spaces that could be in the field name and also surround it in brackets. You also want to be sure you spell the field name correctly and that the field exists in the referenced data extension. It will lead to fewer headaches when you proceed to preview and test and are confronted with the red bar of invalidation.
One thing that can assist in assuring your data integrity is the usage of comments. (/* ) opens and (*/) closes the comments, which can be used to include notes on what a particular function or variable is doing and how all of the code flows together. These are especially powerful with emails that just run, such as triggered sends, because they help diagnose any issues down the line and explain the thought process of the coder from the original production.
I have found some of my favorite things in AMPscript are the functions. However, you always have to be absolutely sure that the function you choose matches the data you are transforming. Here’s an example: You cannot use FormatDate if the data field is not set as a date. This caused much consternation for myself when I tried to pull out a month, a day, and a year to transform within an email only to find the date field I was trying to change was set as text. With Content Builder now being the standard, it is helpful to also be able to browse content blocks rather than having to remember the exact number of what you want to reference when creating an email and writing script.
One of the best pieces of advice I have been given in my career of AMPscript coding is to code defensively. To some, this may sound harsh, but it is one thing that can assist in many ways. Data is ever-changing and evolving in SFMC, and as this evolves, it can cause issues to currently-running programs or even new programs. One must always keep this in mind and ensure there is a default condition set if data acts unexpectedly. Though a final ELSE statement is not required, it should be used as the final fallback to ensure the logic works and something will show or not show according to the statement rules. Once this is coded, it should then be tested again.
These are only a few of the pitfalls you can run into while working with AMPscript, but these are some I have personally experienced. While I have learned many things from trial and error, another great resource is the AMPscript Guide by Eliot Harper and Adam Spriggs. As it states on their site, their guide truly is “the definitive scripting manual for Salesforce Marketing Cloud.” It is a great resource that has already improved my coding several times over, and I consult it on a regular basis.
What pitfalls have you run into using AMPscript? How have you overcome these challenges?
This post was originally posted on November 1, 2018. It has since been updated to reflect Salesforce Marketing Cloud updates.