Debugging AMPscript with Frontend JS and more

Debugging AMPscript with FrontEnd JS and more...

Sometimes, you might need to use information from SFMC Backend (AMPscript) in the Frontend JavaScript. The easiest option is to use this simple trick. It may come in handy on any Landing page. And in case you prefer SSJS, feel free to substitute AMPscript for SSJS!

Where and what?

This trick can be used on any Landing Page. You might even consider using it inside your Code Resources. However, it will not work in emails, as JavaScript is not of much use there.

As for use cases, that’s even better. In this article, I will focus on debugging and versioning your script, but here is couple more ideas, where you might want to consider this trick:

  • changing styles of your page using jQuery dynamically based on subscriber data,
  • reactive landing pages (loading or changing content based on user’s actions),
  • preparing content of Ajax calls without having to do API calls.

How to do this?

It is actually very easy. Just a few steps, and you are done!

  1. Set your AMPscript variable(s) as you normally would. Feel free to write your complete code. But over here, we are going to work with one variable only:
       VAR @myAmpVariable
       SET @ myAmpVariable = “myValue”
  2. Create front-end JavaScript block this must be on the same landing page. So, no separate code resource etc. It can be either in <head> element or at the very end of your page, just before the closing </body> tag:
  3. Now it’s time to write your JS code. In our case, we need just a simple console.log(), so that’s what we are doing here:
       var myJsVariable = “myValue”;
       console.log(‘My variable value is: ’, myJsVariable);
  4. And now the trick: exchange the assignment of the value, for a good old AMPscript!
       var myJsVariable = “%%=v(@myAmpVariable)=%%”;
       console.log(‘My variable value is: ’, myJsVariable);
       console.log(‘You can also log the value like this:  %%=v(@myAmpVariable)=%%’);

As you can see, this is a very simple process. There are however two potential catches: data typing and value of the AMPscript var. But let’s leave that for later.

Debugging AMPscript – the comfy way

Following code example shows how you can use this for easier debugging of AMPscript code:

  1. Copy & paste following code into a new landing page and then publish it.
  2. Open the published page.
  3. Open the Inspect panel of your browser (Right click => Inspect)
  4. Navigate to Console pane.
  5. Now you can just refresh your page and you will always find your debug code there.
  6. Before each publish, remember to update the @pageVersion variable.

Example Code:

<!DOCTYPE html>
  <html lang="en" xml:lang="en" class="en_us js">
  SET @pageVersion = '0.0.1'
  VAR @language, @header
  SET @language = RequestParameter("ClientLanguage")
  IF @language == "FR" THEN
    SET @header = "Salut monde!"
    SET @header = "Hello world!"
  <title>AMPscript 101</title>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
    console.log('Version: %%=v(@pageVersion)=%%.');
    console.log('Language: %%=v(@language)=%%');

What to be careful about?

1.    Data Types

Even though AMPscript does not enforce strict data types (and neither does JS), you still should consider managing the data types yourself. There are JS functions to handle data types of variables. This is however over the scope of this paper. You can read more in this article on JavaScript data types and this on data type conversion.

2.    Final values only

You also need to consider, that you will get final value of your variable. Because of that you might be obliged to use additional variables to log various states of your code and not change the original value after your desired debugging point.

3.    Publish time

Yes, that thing again. Publishing new version can take a bit, so don’t hit that refresh button too hard!

That’s why you might consider using and iterating a version number of your landing page with each new version as shown in the article.

4.    Readability

Be very careful, about what you write in this manner. The original as source code might get very hard to read!

A small showcase here (consider parameter lifeUniverseEverything = true):

<!-- ... -->
  var v = "0.0.1";
  var x = 41;
  console.log("script start!", v);
  %%[ IF RequestParameter("lifeUniverseEverything") == true THEN ]%%
    x += 1;
  %%[ ENDIF ]%%
  console.log("The answer is:", x, ".");
  console.log("script end!");
<!-- ... -->

 Some of you might know the answer already!

Please, don’t do this back home…

5.    Security of the console-debug

And here goes security – surprised?

Unfortunately, console log is accessible to anybody who can view the landing page. I do not recommend using this for any potentially sensitive or personal data. If you do so, then make sure to delete the log lines after you finish your code.
And be very careful with “commenting out” JS in this case, as the AMPscript would still fill the code and the values would be visible. Just in the front-end JS comments.

Geeky corner: how does this work?

The whole thing is possible thanks to the “Order of Execution”. It states how is the code of your landing page processed when it’s viewed by user (or “executed”). For landing pages, it works as:

  1. Page is requested by client – an HTTP request is made to SFMC.
  2. The code of landing page is being processed:
    1. Backend code (AMPscript and SSJS) is being processed top-to-bottom.
    1. After the code is processed, values are inserted into the page (e.g.:  “%%=v(@myVariable)=%%). This code can be located even in HTML/JavaScript’s string value (CSS would work too).
  3. The resulting HTML code is returned to the client.

Do not confuse with following article:


This article presents you with an easier option to develop your backend landing pages. The trick is in inserting small pieces of AMPscript into your regular JS code, which might be helpful to for example debug and version your code.

Spread the love

Filip Bostik

Filip is an experienced consultant with over 4 years of experience in custom implementations for clients from various industries including FinTech and Luxury. His main expertise is design and development of new solutions tailored to specific client needs, including API integrations, custom activities written in Javascript and hosted in Heroku or even smaller secure applications hosted in SFMC Landing Pages.​

Leave a Reply

Your email address will not be published. Required fields are marked *