ActionKit: The Blog

The Page Drilldown Dashboard is a built-in ActionKit report that gives detailed stats on action takers, new subscribers, donations, and and related mailings for a given page.

Like other dashboards, it pulls information from multiple reports and displays them all on a single page, and it’s great for getting an all-in-one overview of how a page has performed.

For actions, you can see how many unique action takers you’ve received, how many new-to-list users joined on this page, and your net new-to-list count (minus unsubscribes) to see if you grew your list.

You can also see a summary of the sources of actions on this page, including how many new-to-list users you had from each.

For related mailings, you can see how many users received a mailing that led to actions on this page, including the number of mailings sent to people who had already received an ask to take action on this page.

Each related mailing is also shown, with a performance breakdown for opens, clicks, actions, and unsubscribes. Confirmation mailing performance is shown if you’ve set one up for this page, and if you have a notification mailing set up, you’ll see performance for that too.

Finally, there’s a section for shares so you can see the number of users who shared this page, plus a breakdown of shares by platform and clicks, actions, and new-to-list by shares.

If you aren’t sure what the Net NTL refers to, for instance — don’t worry! All of the terms are defined below the fold:

That’s a lot of information packed into one dashboard — give it a try! From the Reports tab, go to Browse All and search for Page Drilldown Dashboard:

I think the Page Drilldown Dashboard is really useful not only as a dashboard report, but also as an example of how to build out a dashboard report that’s descriptive and clear. Try it yourself!

In part one of this series, we saw how to customize the dashboard that appears on the ActionKit homepage by adding helpful resources like links to the documentation.  Use the same approach to add your own staff trainings, and any other resources that staff frequently use, like mailing calendars, style guides, or where you get your photos for campaigns.

You can also add standard reports to your homepage so all staff can quickly check progress toward shared goals or use of shared resources.  The built-in “Your Progress” report provides some examples.  Let’s look at another.

If you have several mailings going in a single day, you may need to do a bit of mental math to add up all of the people on your list who have received an email today and who haven’t yet.

Better yet, you could create a report to do it for you.

For clients using a re-engagement list, you may want to adjust your filter criteria slightly by excluding people on your re-engagement list, like this:

Now that I’ve created my report, I’ll need to add it into my your_progress dashboard.

<h3 style="background-color: blue; color: white; padding: 10px;">Members who haven't received an email today</h3>

<p style="margin-left: 10px;">{{ reports.members_who_havent_heard_us_today }}</p>

Finally, let’s return to the homepage to admire our dashboard.

Adding reports to your ActionKit homepage dashboard is easy, just keep in mind that it’s best for at-a-glance information. And since this dashboard won’t load until all of its reports have run, don’t use this section for reports that take a long time to complete.

Usually your action pages add action takers to your mailing list.  But sometimes you’ll have a form where you want users to opt in or you want to avoid subscribing them at all. Perhaps the page is collecting feedback, or it’s part of a coalition campaign. Maybe you’re looking to improve deliverability by requiring an opt-in.

The examples here show two ways to add a checkbox  so users are required to opt in or, alternately, hide the checkbox and don’t provide a way for action takers to subscribe.

Step 1: Create the custom field so you can turn opt-in on and off depending on the page:

• Pages > Other > Custom Page Fields > + Add a custom page field
• Create a custom page field like this:
  • Display Name: Opt In
  • Name: optin
  • Field Type: Select From List
  • Field Choices

   
  yes=Yes, require users to opt in before subscribing
  nosub=Do not subscribe any users to the page

The database will store yes and nosub as the case-sensitive values (which you’ll use in the code below) but staff will see the longer text as they’re editing the page.

Step 2: Add the custom page field to a test action page: 

On the Action Basic screen, expand Custom Page Fields, select the Opt-In field from the drop down, and set the value to Yes.

Step 3: Edit the template.

For one page type

If you’re only adding opt-ins to just one type of page — we’ll work with letter pages here — you can use this simple example.

• Pages > Appearance > Templateset > (whichever templateset this page is using) > letter.html
• Wherever you want the opt-in checkbox to appear, insert this code:

{% if page.custom_fields.optin %}
<!-- require an opt-in -->
<input type="hidden" name="opt_in" value="1" />
<!-- show a checkbox if optin=yes -->
{% if page.custom_fields.optin = "yes" %}
<!-- set value to the ID of your mailing list -->
<input type="checkbox" id="id_list_1" name="lists" value="1" /> <label for="id_list_1"> Keep me informed</label>
{% endif %}
{% endif %}

• Use the plus sign on the right side of the screen to preview and test the page by submitting with a new email address.

Try not checking the box and submitting, then checking and submitting.  View the user record for the email address you used to confirm your results.   When you’re satisfied, go back to the letter.html template you were working on and click publish.

For multiple page types

If you want to include opt-ins across multiple page types, it makes sense to separate out the opt-in code so that you can edit it once and affect all your page types.

• Pages > Appearance > Templateset > (whichever templateset this page is using) > Add a file — let’s call it optin.html

  {% if page.custom_fields.optin %}
  <!-- require an opt-in -->
  <input type="hidden" name="opt_in" value="1" />
  <!-- show a checkbox if optin=yes -->
  {% if page.custom_fields.optin="yes" %}
  <!-- set value to the ID of your mailing list -->
  <input type="checkbox" id="id_list_1" name="lists" value="1" /> <label for="id_list_1"> Keep me informed</label>
  {% endif %}
  {% endif %}

• Publish that file.
• Edit one of the page types you want to allow opt-ins on, like letter.html. Add {% include_tmpl optin.html %} wherever you’d like the checkbox to appear.
• Use the plus sign on the right side of the screen to preview and test the page as described above. When you’re satisfied, go back to the letter.html template you were working on and click publish from there.
• Edit the other relevant page types (like donate.html, letter.html, signup.html) in the template  the same way, adding {% include_tmpl optin.html %} wherever you’d like the checkbox to appear. Again preview and test the pages.

Step 4: Train your team

Make sure anyone who will be creating pages knows when to use each of the options:

• Leave the field blank (or don’t add it to the page) when you want to subscribe all users as they take action.
• Set the value to Yes, require users to opt in before subscribing when you want to show a checkbox.
• Set the value to Do not subscribe any users to the page when you don’t want any users to be subscribed.

Many clients like to use UTM tracking codes to track clicks and performance in Google Analytics. (Ever see utm_medium=email at the end of a URL?) In fact, you could add these UTM tracking codes to all of your URLs in a mailing.

Of course, ActionKit already adds some information to your URLs to enable user recognition and link click tracking — this blog post is about additional customizations you can do.

The {% filter tag_links %} tag allows you to add some text to the end of every URL that appears between this tag and {% endfilter %}.

Let’s say we wanted to add utm_medium=email to the end of each of our links. In our mailing or email wrapper, we would add:

{% filter tag_links:”utm_medium=email” %} near the top, and {% endfilter %} near the bottom.

If you want to append the UTM tracking code on most or all of your URLs, it’s easiest to do this in your wrapper.  However, you may want to test using these tags in a test mailing’s body and move the code to the email wrapper once everything works the way you want. If you’re making these edits in your email wrapper be sure to save it then look at a mailing that uses that email wrapper to confirm.

Using |urlencode

Some clients have written into support asking how to append other values, like a recipient’s country, to links.

Let’s say we wanted to add our recipient’s country to the end of our URL as the URL parameter “country”. That’s easy enough to accomplish with a snippet: https://actionkit.com/?country={{ user.country }}

But we run into problems with many countries (like “United States”), because URLs can’t have spaces in them. So we end up with the URL https://actionkit.com/?country=United

To fix this, we need to tell this snippet that we’re going to use it in a URL. Use the |urlencode filter: https://actionkit.com/?country={{ user.country|urlencode }}

Once we’ve done that, our URL changes that space into a “%20”, which is the URL code for a space, and the URL works as expected.

If you’re using any snippet that might possibly have a space in the URL, like postal code, be sure to use |urlencode.

Combining |urlencode with the tag_links filter tag

This is a good start, but let’s say I want to include the recipient’s country and use the utm_campaign code.

Let’s go back and edit our tag. This time, we’ll also need to use some {% with %} tags in order to create variables that we can use in our snippets.

The first {% with %} tag creates a variable called user_country that has the |urlencode filter applied, so we don’t have to worry about any spaces.

The second {% with %} tag concatenates our UTM tracking code and the user_country variable we just created. Now those two pieces of information have been smushed into one piece and saved as the variable utm_tags, which is then used in the {% filter tag_links %} tag.

This might seem more complicated than necessary — why do we need to use one {% with %} tag, let alone two? This has to do with the way the tags and filters get parsed and applied. Should the entire text get |urlencode applied to it, or just the country? And using |concatenate inside the {% filter tag_links %} tag doesn’t work at all the way we might expect. Using the {% with %} tags sidesteps all of these problems.

So even though the above method uses more tags, it works and is ultimately more readable and straightforward, which can help when making updates!

Do you have too many templatesets to choose from?

Not sure which ones you actually need? Not sure which ones are actually in use?

Now it’s easier than ever to figure out which templatesets you’re actually using — and clean up the ones you’re not. Reducing clutter in your menus will reduce confusion and mistakes so you can focus on making your pages look their best!

To find out which templatesets are in use — and which pages are using them, start on the Pages tab. In the sidebar menu, notice the Search Queries option and expand it to find the “Pages using a specific templateset” built-in query.

On this page, you’ll have the option to choose which templatesets you want to check. In this example, I’ve chosen the “Use this! New templateset 2018 October” templateset, because I want to see: is this even in use anymore now that we have more recent templatesets?

On the screen that follows, I can see that this templateset is in use by only three pages, so I can probably edit these pages to use a different templateset, then retire this templateset so it stops cluttering up my drop-down menu and confusing new hires.

Go through each of your templatesets, see if they’re still in use, and if not,  hide them so they won’t appear in your drop-down menus anymore!

To hide a templateset you’re not using anymore, go back to the Pages tab, and in the sidebar, expand the Appearance menu option to find Templatesets.

From there, click “Hide” on any templateset you’re not using anymore and it won’t show up in your dropdown menus. (Don’t worry, if you ever change your mind, you can always unhide a templateset!)

Hiding templatesets that you’re not using anymore can be really helpful, especially when onboarding new staff who might not have the same institutional knowledge as you or know all of the differences between the templatesets you’re using, or even which ones are still in use. That’s also a great reason to add a description to each of your templatesets!

Do you have too many reports in the reports tab? Having trouble finding just the ones you need? Do you regularly copy old reports and make one tiny change to make a new report?

If so, re-usable reports are for you!

Re-usable reports will pause before they run to ask you: which page (or mailing, or tag, or other type of thing) did you want to see these results for?

Let’s take a look at an example. Here I have a report called “Top 10 Pages with the Most Actions by Tag”, which will answer the question “Which pages had the most actions for a specific tag?”

Now I could create one report for every tag I wanted to see results for, but that would take a long time and I could easily end up with several reports! Worst of all, if I made a mistake in one of those reports, I’d have to fix them all.

Instead of doing that, if I leave my filter criteria option for tags blank like in the below screenshot, then the report will pause to ask me which tag I want to see results for.

Let’s take a closer look at just our filter criteria:

Note that this isn’t the same as leaving the filter criteria entirely blank, it’s just that we haven’t specified which tag we want to see results for, so the report will ask us when we run it.

In my example I’m using tags, but you could do the same with pages, mailings, or any other filter criteria you like!

You can create mailing templates by adding custom mailing fields to your mailing wrappers. These fields will display in a new Content section of the Compose screen along with the mailing Body field so that you can have multiple editable elements of the wrapper, while hiding the messy structural code out of sight — and safely out of editing range.

For example, you may have a wrapper like this:

<h1>{% include_tmpl custom_fields.headline %}</h1>
<img src="{{ custom_fields.image_url }}" width=300>
{% block content %}{% endblock content %}
<p>{{ custom_fields.signature }}<br/>
Your Organization</p>

Choose this wrapper for a draft and your Compose screen will look like this:

Switching wrappers will change what fields show up here; their display is governed by what is defined in the selected mailing wrapper.

Templates vs. Models

Mailing models are example mailings that are copied each time into a new, fully-customizable mailing. Everything — metadata, content, styling — copies over. Sometimes that’s super helpful! But sometimes you want to maintain the structure and style of a mailing without the content, or you want to control or simplify customization options. Templates are all about simplicity.

Example Wrapper: Template with Sidebar (Built In)

Your instance already has the custom mailing fields of sidebar_text, featured_image, link_url, signature and references.

The image and buttons will automatically link to the URL entered in the link_url field, and the call-out box will only appear if there are values for either the sidebar_text or the featured_image. The button is drawn via CSS so it’ll be visible whether or not the user has images enabled for their email client. And the image is automatically sized to be a max width of 260px.

Setup

One time: create custom fields

Mailing fields used in the wrapper are standard custom fields, so you can set a type, description, defaults, or make a field required. They should be created prior to including them; including a field unrecognized by the system will display the field in red with a warning that it needs to be created.

If you create an HTML type custom field, we’ll include the WYSIWYG in that section under content. You must use specific syntax when you include fields of this type, or of any type where you plan to use template tags or filters:{% include_tmpl custom_fields.NAME %}. Otherwise, {{ custom_fields.NAME }} is sufficient.

One time: Add custom fields to your mailing wrapper

The custom mailing fields section in the snippets menu on the Wrapper screen will insert your fields using the appropriate syntax for the field type. You’ll also see a list of custom mailing fields used in the wrapper under the template box. Hover over them to see the field type, display name and description.

If there’s a value in the mailing field…

You may only want to show an element if the staff member has specified something to go there. For example, a gray sidebar box doesn’t make sense without an image or button to go inside it — it would just be a gray rectangle! A simple if statement can show your element if a field is filled in:

{% if custom_fields.image_url %}
   <div style="align:right;background:gray;padding:10px;max-width:200px">
      <img src="{{ custom_fields.image_url }}" width="100%" />
   </div>
{% endif %}

Now the sidebar will show if there’s an image URL, but it won’t if that URL isn’t filled in.

Working with templated mailings

• Any custom mailing fields not used for the selected mailing wrapper will continue to be available in the Custom Mailing Fields section at the bottom of the Compose screen.
• On the Proof and Send screen, click on the blue Preview link next to the Content header to view a rendered version of your mailing combining all of the fields as previously.

At ClientCon in May, I ran a presentation called “10 Features Every Client Should Use,” intended to help clients get the most out of ActionKit. I wanted to highlight a handful of different features that every client would find useful and wanted it to be a good mix — some things quick and easy, others that would take a little more time to set up fully. Here’s a brief overview of those ten features.

Mailing Models

Mailing models are templates or starting points you can use to create new mailings — with your pre-set targeting and layout all set up for you already.

Page Models

Similar to mailing models, page models are templates or starting points for your pages and are especially useful for types of pages that you’ve customized heavily, like a video share page or a reportback page.

Two-factor authentication

You care about your members’ privacy, and they trust you to protect their data. Setting up two-factor authentication allows you to safeguard that information by adding an extra layer of security to your ActionKit staff accounts.

Staff announcements

Announcements allow you to remind staff of new policies, targeting, or workflows and stick to the top of every page in ActionKit for logged-in staff users. They’re especially useful for reminding staff of changes or things to keep in mind, and you can easily dismiss them.

Customize “Your Progress”

The “Your Progress” dashboard that appears at the top of the Home tab when logged into ActionKit can be customized with things like documentation, onboarding and training resources, a mailing calendar, or report results.

Custom Page Fields

Custom page fields allow you to make big and small changes to your pages without needing a lot of ongoing code changes. Most commonly this is used to change things like the text of submit buttons, but the sky’s the limit!

A/B Testing

A/B testing allows you to test different variations of a page to see which one gets more actions or donations. You can test changes to the layout and design, or test different versions of content to see which images or messaging are more effective.

Cloudfront

The faster your pages load, the more actions and donations you’ll get. You should be doing everything you can to make your pages load as quickly as possible, and using a tool like Cloudfront can make a big impact with just a small one-time setup.

Customize “Draft Dash”

The “Draft Dash” dashboard appears just above the Send button of your mailings and can be customized with just-in-time reminders, a checklist of things to make sure you’ve done before sending a mailing, and even automated checks for common targeting and tagging mistakes.

Suppress Spam Actions

ActionKit has built-in protection against spam bots, and it’s worth periodically checking your spam settings to make sure that everything’s configured just the way you want it.

To learn more about setting these up, check out the presentation 10 Features Every Client Should Use — and be sure to read the presenter’s notes. It’ll be like you were right there at ClientCon!

Multiple templatesets are the obvious way to handle multiple brands. A new templateset gives you total control of the look, feel, and behavior of your ActionKit pages or microsite. But each additional templateset means one more thing to maintain and upgrade, which can get cumbersome quickly.

A few simple bits of Django will reduce the number of templatesets you need to maintain.  Read on for details. Continue reading “Templateset Nonproliferation”

ActionKit has built-in protections against spam to ensure that actions on your pages come from actual people, not bots.

That’s important because you don’t want spambots on your list hurting your email reputation. Also, if you’re showing recent signers or their comments, you don’t want spam comments included with your legitimate signatures. 

There’s documentation with an excellent deep dive into the nuts and bolts of how everything works, but here’s a brief overview of the most important options.

Spam Check Settings

Superusers can configure a wide variety of spam settings on the bottom of the Configure ActionKit screen. By default, ActionKit will check for spam actions on Petition, Letter, and Signup pages, and can also check on Survey pages if you like.

The built-in defaults are meant to be a good level of protection without rejecting legitimate actions, but you can configure the settings in a way that works for you.  

Honeypot Check

This is the most effective option for catching spam.  Project Honeypot is a service that identifies probable spambots so that they don’t end up on your email list. ActionKit checks an action taker’s IP address against this list to determine the likelihood of an action being spam.

It’s enabled by default with a threshold of 20 — a good balance between not blocking legitimate actions and not letting too many spam actions through.

If you find that too many spam actions are getting through, you can try decreasing the threshold. Or if too many legitimate actions are getting blocked, you can raise the threshold.

Spam Check Log

ActionKit keeps a list of all of the actions that were caught by the filters you have in place as suspected spam actions.

You can view this list by going to the Pages tab, and in the Other menu in the sidebar, click Spam Check Log.

You can filter these actions by date and by which type of filter caught the action.

You should see mostly spam actions caught in the filter, but you might see some legitimate actions, too.

How can you tell if an action is legitimate? It’s mostly a judgment call — the automated filters aren’t perfect. It comes down to different patterns of behavior by spambots and real people.

What are some “tells” that make it more likely that someone is a spambot?

• If someone’s email address has their name in it, and that name is very different than the name they gave on their action. For example: Jane Doe, brenda.smith@example.com
• If someone’s state and zip code are very obviously in conflict
• Email addresses with a lot of random numbers or letters
• Lots of actions on an old page that’s not being promoted anymore

Spambots tend to appear in waves and have similar patterns, so it’s less likely that you’ll see just one or two spam actions — you’ll probably see a lot of similar actions all at once.

Typically, if an action comes from a member with an established action history, it’s usually legitimate. Sometimes, a first-time action taker might have their action marked as spam, and it’s up to you to decide whether it’s actually spam or not.

If you just see spam actions caught in the filter, great! If you see some legitimate actions caught in the filter, you can click Reverse on those actions so they aren’t marked as spam.  If you see lots of legitimate actions, you can adjust your filters.

Suppress Actions

By default, ActionKit does not suppress suspected spam actions caught by these filters — it only flags them for your review in the Spam Check Log.

If you want to automatically suppress suspected spam actions, enable Suppress Actions under Spam Check Settings on the Configure ActionKit page.

Don’t worry, if the filter marked a legitimate action as spam, you can always reverse it in the Spam Check Log or on that user’s Action History page.

Unsubscribe Users

By default, ActionKit does not unsubscribe suspected spambots caught by these filters from your lists — it only flags them for your review in the Spam Check Log.

If you want to automatically unsubscribe suspected spambots, enable Unsubscribe Users under Spam Check Settings on the Configure ActionKit page.

Don’t worry, if the filter unsubscribed a legitimate user for being a suspected spambot, you can always reverse it in the Spam Check Log or on that user’s Action History page.

Protect your reputation

Keeping your list spambot-free is important for your email reputation, and ActionKit makes it easy to stop spam actions with lots of options to configure to meet your needs. Be sure to check the Spam Check Log periodically to make sure that legitimate actions aren’t being caught and adjust your filters as needed. To your list health!