Re: Rendering problems when View as Web Page is clicked

Michael_McGowa1
Level 3

Rendering problems when View as Web Page is clicked

Hello all,

My company wants to send out a triggered email to people who would like to send an article to their mailbox. The flow works like this.

  1. Person comes to our site and clicks on the share article button
  2. Fills out a non-Marketo form and clicks submit
  3. Upon clicking submit, an API call is sent to Marketo. The API call contains the text for the requested article.

In the email template, the text for the article is handled by a rich text token.

The above flow works as designed. However, the issue is that if someone clicks on the “View as Web Page” link, then the article does not render in that version. I have filed a support ticket and they responded by saying that the "view as web page" link is not going to update dynamically along with the token. When the lead clicks the "View as Webpage" link, the link goes back to the program's actual my.token value (which reads “Article body here”).

One suggestion was to have copies of the articles and their HTML in Marketo. However, there are (potentially) hundreds of articles and they do get updated periodically so this is not a viable solution.

Has anyone come across this problem? Any suggestions for me? For the time being, the plan is to send the email without the View as WebPage link.

1 REPLY 1
SanfordWhiteman
Level 10 - Community Moderator

Re: Rendering problems when View as Web Page is clicked

The runtime tokens that you pass via the Schedule and Request Campaign APIs are ephemeral -- they do not exist after the send is complete.

But in the world of Web Page View, similar behavior also exists with non-runtime tokens, including any dynamic value or token in Marketo, even seemingly "static" {{my.tokens}}.

For example, the output of a Velocity token is not stamped into an email at the time it is sent. When you visit the Web Page View at a later time, the VTL is reexecuted. Likewise for lead tokens and Program-level tokens. These are not necessarily bad things if you want to do after-the-fact fixes -- but can be unexpected if you want the email to look exactly as it did when sent.

The only way to work around this behavior is to add the Visit Web Page link manually to your emails and append to the query string the (probably Base64-encoded) token value. Then customize the Web Page view (I've written about this before on my blog) using Velocity, so it reads data from the query string and populates the email content accordingly. This way the webview will look as close as possible to the received email. (The code to do this is not really complex, but this world is obscure enough to the average developer that it will probably seem so!)