Token for Last Downloaded Item

[Danielle_Wong]

Right now, I have subjects that are generated whenever a form is filled out for an ebook or whitepaper. I want to use that information to generate text. For example:

Subject Lines that say:

          Filled Out Form: the_evol_of_data_2

I want to be able to generate the email text:

          The Evolution of Data Part 2

So in an email where there's a space for the title of the last downloaded item, it will say, thank you for downloading The Evolution of Data Part 2.

As of now, "The Evolution of Data Part 2" is not a field on the lead and so it can't be directly called upon.

I hope i'm not all over the place with this. I'm looking forward to some expertise in this. Thanks!

[SanfordWhiteman]

My question would be why you're using opaque form names. If you want to include the form's "friendly" name, why not have that be its actual name in Marketo, so you can use it in a trigger token?

If that's not possible, you could post the friendly name as a hidden field on the form.

[Danielle_Wong]

I am not sure why it was set up that way. I took over this account. And I don't want to change too much, especially if i don't know what complications that may lead to.

If i create a hidden field on the form for Form A, will the same hidden field be replaced if Form B is filled out after?

[Grégoire_Miche2]

Hi Sanford,

From my experience, friendly names and program naming conventions do not go along very well

-Greg

[SanfordWhiteman]

Certainly that can be true, but if every form has both a "real name" and a "friendly name" you have something else to maintain.

I would not generally expect the form name to be used *at all* as a name for the asset, since I'd use a global form. But once you're dedicating forms to assets it may make sense to use a user-publishable name.

[Grégoire_Miche2]

Hi Sanford,

I am missing something here. What are you calling the "friendly name" of the form? I know of the name and the description, but not the friendly name.

-Greg

[SanfordWhiteman]

Just talking about the form name, which has the major -- though perhaps sole -- advantage of being available as the built-in token {{trigger.name}}.

There are clear advantages to strict, non-user-facing program naming conventions, but I think those advantages fall away for forms if you're dedicating a form to an asset as Danielle is here.  Being unable to show the user {{trigger.name}} simply because it's called "the_evol_of_data_2" (I shouldn't have called that "opaque" as it's more like just "non-user-presentable", as opposed to technical names like "F2.55.4") but then having to maintain {{my.formFriendlyName}} separately is just something else to break.

Once you move to a fully tokenized approach as Edward recommends, you'd also use a global form, so the {{trigger.name}} would no longer be useful in a response no matter what the value.

[Grégoire_Miche2]

Hi Sanford,

Thx for clarifying. In fact, what you call the form friendly name is just a program token I had the impression you were talking about a property of the form itself and that I had completely missed something.

Then I fully agree with the interest of the approach. It's funny, because I had this discussion with a customer this PM about the lack of readability of the {{trigger.name}} values for sales and the interest of using a program token instead.

the related idea is here:

-Greg

[Edward_Unthank_]

Hey Danielle, we do this through program tokens.

Have an auto-response smart campaign in each content program, with a flow step of "Send Email." This "Send Email" sends a fully tokenized Universal Fulfillment Email that is housed in the Design Studio.

Here's our content program template and the local assets:

The Auto-Response smart campaign is triggered when someone fills out a specific form on a landing page, and it triggers email auto responses to whomever filled out the form. Here's the flow step that sends the email itself:

Here's the trigger that kicks off that email send:

That specific email is fully tokenized and housed in the Design Studio. Emails are slightly unique in that program tokens will be applied to the email based on the smart campaign that sends it, instead of based on what program it's contained in (like smart campaigns and landing pages). Note specifically the {{my.Content - Asset_Title}} program token that I circled in red below:

The program itself for each piece of content has program tokens to fill in lots of values. In this case, focus again on the red circled token that has a friendly name of the asset title:

The actual email send renders the token values that show up in the program, so here's what that above in those tokens. You can see the circled red of the {{my.Content - Asset_Title}} showing up in the email as it lands in my inbox after filling out the form in this program.

Program tokens are how you'll want to do it. For more information on how they work, I wrote this here post on Marketo tokens. The easiest way to scale the tokens is through Marketo Program Templates, so you can clone program templates with all the right values and just swap out token values, without having to worry about recreating all the structure from scratch with every new asset that you want to create.

Cheers,

Edward Unthank | Founder, Etumos

[Danielle_Wong]

Hmm, thanks Edward. I looked at your post too and that was informative.

I am just having difficulty wrapping my head around the initial setup to be able to do something like this. I think there are still missing pieces on my end. Because I'm not able to use the token I want to use. The information is not there. But I guess my next question would be whether I can take an existing field such as "last form filled out" and map it to a value that includes the friendly form name?