Session variables in an autoresponder?

Erland Sanborn

Some background: I'm trying to build a generic donation form that makes heavy use of session variables and embedded reusable content. It's a pagebuilder form that uses the donation api. When an s_src parameter is present, it will attempt to embed content from a reusable page whose name matches the s_src value.


So above the form markup, it uses [[E51:[[S80:src]]]] to style the page and inject whatever copy we need, solely based on the source code used in the email appeals we send. This part works great!


BUT, I'd like to do this with the autoresponder as well. Statically embedding a reusable page in the autoresponder body works fine, but I can't seem to get the source code to render - worse, when we submit a test donation, the autoresponder never arrives, so it appears it might be causing an error behind the scenes.


Is there a different way to achieve this, or am I barking up the wrong tree? Any guidance would be greatly appreciated!

Erland Sanborn

False alarm, I've found a solution! I know I'm talking to the wind here, but in case anyone stumbles on this and finds it useful...


I created a custom data element on the generic form, and hid it from the transaction summary. This will be populated on the pagebuilder form container, and accessed via the S120 transaction summary tag.


Now my generic form autoresponder body just looks like:


[[E51:[[S120:dc:custom:custom_string73]]_autoresponder]]


Where E51 embeds reusable content where the page name is "<sourcecode>_autoresponder"


Now whenever we want to build a new email appeal with a customized donation form, all I have to do is build three reusable pages with titles like: 


SummerAppeal

SummerAppeal_thankyou

SummerAppeal_autoresponder


Then link to the form in email with s_src=SummerAppeal. SO MUCH FASTER than building new campaigns/forms for every appeal!

Erland Sanborn

I received a bit of interest for this post, so I figured I would do a really quick writeup here to explain in more detail what I've been working on, and hopefully this will make someone's life a little easier!


Basically, I set out to leverage S-Tags and session variables to create a simplified method for rapid execution of email appeals, without having to set up brand new campaigns and/or forms every time. By creating reusable pages named with a prefix matching the source code used in our links, I found that I could dynamically replace all of the important elements on our generic donation process automatically, using just the S51, S120 and S80 tags, and a little bit of conditional trickery.


This is a barebones explanation for what I've developed, and I hope to make a better writeup in the near future. I'm also working to get this into a single-page template form, where all content - header, thankyou copy, autoresponders, and even subject line - is contained in a single reusable HTML template, but it involves heavy use of the RPN tag (E130) to extract HTML elements and is just a little bit daunting...


That said, here's the basic process.

Donation Form Setup

I first created a campaign for email appeals, with a shell form for use with the donation API. In addition to the standard required fields, I created a new data element called Email Appeal Source. This will be populated with the source code and retrieved from the transaction summary in order to render the autoresponders correctly. This is because session variables cannot be passed through to the autoresponders directly. Be sure to hide this field from the user and the transaction summary (the S120:dc tag can still see it!).



Autoresponder Setup


The S-Tag structure in the autoresponders will make sure that email content exists for the given source code before embedding it, or fall back on the default copy if either the content wasn't created, or a constituent somehow arrives on the form without the required s_src parameter. Content inside the HTML and Plaintext autoresponders should look something like this: 




Be sure to replace the "custom_string73" with the correct field name associated with the Email Appeal Source field in your instance. Skipping this part will break your autoresponders! Insert the field from Personalization->Other->Donation Custom Fields, then copy and replace "custom_string73" with your own.




Default Content Organization

Now that the basic donation form setup is complete, you'll need to create pages where default content lives, and a new PageBuilder page to host your custom donation form. DefaultEmailAppealContent contains the header design/copy that will render above the form, so treat this as though it were an HTML Caption area in the donation page setup. This is a good opportunity to make use of the folder hierarchy if you don't already.



Appeal Content Organization

When you create new email appeals, place the required pages in a subfolder to separate assets and keep things tidy. In this example, if I wanted to use s_src=DemoSourceCode as the source code in an email link, I'd create the following files:




These four files can now completely redesign the entire donation experience!

Basic Form Structure

At this point, the form is ready to receive donations, and knows how to replace autoresponder content with reusable pages that match the source code used in your email appeal. The last step is building the custom donation form inside the EmailAppealDonation page, and the basic markup structure looks like this (sorry, formatting is hard):

<div id="header">

    <!-- if no source code is present, render default header content -->

    [[?NU[[E51:[[S80:src]]]]LL::NULL::

        [[S51:DefaultEmailAppealContent]] 

    ::

        <!-- embed reusable content from source code -->

        [[E51:[[S80:src]]]]

    ]]

</div>


<div id="form">

    <form action="https://[[S29:SECURE_DOMAIN]]/[[S29:SITE_ID]]/site/CRDonationAPI" method="post" id="donation_form">

        <input type="hidden" name="method" value="donate" />

        <input type="hidden" name="api_key" value="[[S0:CONVIO_API_KEY]]" />

        <input type="hidden" name="v" value="1.0" />

        [[?[[S334:df_preview]]::true::<input type="hidden" name="df_preview" value="true">::]] <!-- protip! -->

        

        <!-- default to generic donotion form if no source code is present. -->

        [[?NU[[E51:[[S80:src]]]]LL::NULL::

            <!-- default form and level ID if page is loaded with no source code -->

            <input type="hidden" name="form_id" value="1000" /> 

            <input type="hidden" name="level_id" value="2000" /> <!-- level ID for other amount -->

        ::

            <!-- Email Appeal specific form and level ID -->

            <input type="hidden" name="form_id" value="2000" />

            <input type="hidden" name="level_id" value="3000" /> <!-- other amount level on eAppeal form -->

            <!-- populate Email Appeal Source data element with the source code -->

            <input type="hidden" name="email_appeal_source" value="[[S80:src]]" />

        ]]

        

        <!-- if no thankyou page is defined for this source code, redirect to default thankyou page -->

        [[?NU[[E51:[[S80:src]]_thankyou]]LL::NULL::

               <input type="hidden" name="thankyou_redirect" value="https://[[S29:SECURE_DOMAIN]]/[[S29:SITE_ID]]/site/SPageNavigator/DefaultEmailAppealThankyou.html">

        ::

            <input type="hidden" name="thankyou_redirect" value="https://[[S29:SECURE_DOMAIN]]/[[S29:SITE_ID]]/site/SPageNavigator/[[S80:src]]_thankyou.html">

        ]]

        

        <!-- Insert all other required form inputs below this line -->

                  

    </form>

</div>

Once you flesh out the form with required inputs, layout and design, it's ready to use.

The idea here is that the EmailAppealDonation page serves as both a generic evergreen donation page as well as a fully customizable, appeal-specific form that requires no extra setup within the Fundraising module.

When a donor reaches the donation page, it will automatically embed the donation header content based on the source code, copy that source code value into the Email Appeal Source field, and render the appropriate thank_you redirect url. After the donation is made, the autoresponder body reads the original source code from the transaction summary, and renders the correct copy inside the HTML and Plaintext versions before sending.


One drawback to keep in mind that may not work for some clients is that every organic donations and email appeal donation will be lumped into a single Campaign within LCRM, so reporting on campaign revenue must be based on source code.

A Quick Preview


This is our standard donation form as it normally appears:


Same page, with our next e-appeal source code added:


Email appeals can now be rapidly developed simply by creating four small reusable pages that contain the header content, thankyou page, and autoresponder versions. So long as the page names all start with the same source code used in your links, everything renders automatically from start to finish.


This technique can be adapted to be even more granular, in which other sections are replaced and redesigned, like design elements on the confirmation page, adding donation tribute fields to a specific campaign, or injecting javascript for purpose-built behaviors... pretty much anything!

Erland Sanborn

Can't seem to edit my post, but wanted to clarify a couple minor typos in the autoresponder conditionals. Code should actually look like this, explicitly testing for the existence of the autoresponder page, rather than just the header content: