One of the best aspects of working in Salesforce Marketing Cloud is the ability to use AMPscript. It allows coded emails to be highly dynamic, personalized to subscribers, and is easy to learn. But when you have been working with AMPscript for a long time, it is easy to fall into some potholes when moving higher, further, faster. Here are some pitfalls to try and avoid when using AMPscript in Salesforce Marketing Cloud.
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 and interpret the code. If you don’t have two, it will not work. While this seems simple, it is also easy to overlook. When you have a subject meant to dynamically render and it doesn’t, start by double checking the percentage marks.
It is also important to use the correct delimiter depending on whether you are using AMPscript blocks or inline AMPscript, and, to use the same one for opening and closing or your code will be ignored. As a refresher, the AMPscript blocks are for defining your code for interpretation, and is where you declare and then set variables. AMPscript blocks are defined using an inner bracket delimiter ( %%[ ]%% ) . The inline AMPscript is for interpreting and executing within message context and are defined with the equal sign (%%= =%%). When typing quickly, it can be easy to hit the wrong key which leads to validation errors or content not showing.
VARIABLES AND ORDER OF OPERATIONS
Along with the syntax, variable declaration and setting is 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, 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 are setting a state once so you can pull dynamic content, but then have the same named variable to display the correct state in the footer it can break the entirety of personalization. If you need to reset your variables, be clear about where you are doing this so as not to inadvertently break the entire message.
In line with this is something that is overlooked by more marketers than would care to admit it: the order of operations for AMPscript. The order starts with the email preheader, then HTML body, then text body, then 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 versatile, 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 marketers down the slippery slope of “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 your data extension. Setting a variable and validating may pass, but when you test, you can see what is truly happening.
One thing that can help assure 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 to diagnose any issues down the line and explain the thought process of the coder from original production.
One of the most user-friendly things in AMPscript is the functions. However, you always have to be absolutely sure that the function you choose matches the data you are transforming. Case in point: you cannot use FormatDate if the data field is not set as a date. This can cause much consternation when trying to pull out month, day and year to transform within an email, if the field you try to change is set as text. Also, with the advent of moving from Classic Content to Content Builder, the function for pulling content areas has been eliminated as they are now considered content blocks.
One of the best pieces of advice for AMPscript coding is to code defensively. To some this may sound harsh, but it is one thing that assists in many ways. Data is ever changing and evolving in SFMC and as this evolves, it can cause issues to current running programs, or even new programs. Marketers must always keep this in mind and ensure there is a default 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 are ones 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, it 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 on a regular basis.
What pitfalls have you run into using AMPscript? How have you overcome these challenges? Let us know so we can address it in future issues of SFMC Smarts.