Release Email Archive: 2013


Hey ActionKitties! Here's what you'll see tomorrow morning in your instance:


We've made some changes to improve mail speed particularly for mailings that use a landing page. Several more related changes will be in the next release.

Also for this release:

  • We no longer add quotes automatically to new from lines -- these are no longer required to display from lines correctly.
  • We've added a weekly cache option to query library reports.
  • We made it possible to edit custom fields for a mailing that's already been sent.

And we fixed a few bugs: * All mailer targeting options should carry over to the individual mailing report. Target groups and merge file selections weren't displayed. * Custom mail fields will now implement the always show option if you've selected this.


We've also done some work to optimize reports, particularly those that use last run.

We've exposed three more categories in the query builder: mailings, targets and media.

And we've added a safeguard against running very large reports. You'll get an error message if you try to download a report that exceeds 500MB. Usually that means there's a mistake in your SQL, but let us know if this limit stops you from doing something.

Finally, a couple bug fixes here as well: * We fixed the action_rates report so the donation totals are correct, even if you have one or more pages of the recurring donation type (which was deprecated some time ago). * We fixed a problem that caused the amount in the Donation query builder to always revert to the default.


If you use Braintree as your merchant provider, we've added some options. These only apply to pages using CSE. You can now include the following with requests to Braintree -- please note that some set up is required first in the Braintree gateway for several of these:

  • Email: This will be transferred automatically.
  • IP address: There's a new instance-wide configuration option, available at Under Donations Send IP Address is set to False by default. NOTE: You must create the 'customer_ip' custom field in the Braintree gateway prior to enabling the option or ALL donations will fail.
  • Custom fields: Inputs on braintree donation pages prefixed with braintree_ will be submitted as custom fields. Again, the donation will error and fail if a custom field is submitted that has not first been created in the gateway.
  • Device data: We've made changes to allow you to take advantage of Braintree's new fraud protection tools, beyond MaxMind. Most groups will not need this, but if you are encountering problems with fraud that you aren't able to reduce using MaxMind, you may be interested in this option. We're looking for a client to test this. If you're interested let us know. You'll need to make some changes to your account settings and your donation templates and we're happy to help you figure that out.

For all of the above, because of how donations and recurring donations are structured, the data is attached to the transaction for a single sale, but to the customer for a recurring donation.


  • More manual updates including a new section on the merchant vendors we accept.
  • We cleaned up some terms in the admin UI for consistency.
  • Custom fields where the names can't be edited once created are now greyed out so it's hopefully clearer visually. This includes custom page, user and mail fields.
  • We fixed a problem with the unicode in our default translations.


Lots of improvements this release to various features. As usual, you'll see these tomorrow morning in your instance:

Reports: We added query builder options for events and languages.

Optimization: We did some more work on speeding up slow reports (and more is coming in the next release). We also changed the way we handle after action emails to insulate page load speeds from any mailer slowdowns.


  • Mergefiles: Mergefiles now upload to Amazon's S3 service, to allow handling much larger Mergefiles. The uploader will use HTML5 or Flash to handle the upload. In either case, we still recommend compressing your files with Zip or GZip compression.
  • From lines: You can now hide and unhide from lines.
  • Bug fixes: We fixed a bug related to recurring mailings and added more logging.

We also fixed a problem with the mailer targeting display for long page or mailing names. For example, if you've selected a page with a long name, the x is now visible is you want to remove it (although it overlaps the text). Also, you can click the Actions/Mailings/whatever box, then hit "Backspace" twice for each thing you want to delete.

For customers on SendGrid, we're correctly logging spam complaints that were not initially successfully delivered via the Event API.

Finally, if your email wrapper has errors in the HTML that stop ActionKit from generating a text version, we'll just use the HTML version instead of showing an error to users.

Template Tags

  • require_opt_in: ActionKit let you disable the automatic list subscription on actions with the confusingly named 'opt_in' parameter. Now 'require_opt_in' is a synonym. As always, you use it in a hidden input tag: <input name="require_opt_in" value="1">

New Django filters: Ethan at PCCC very helpfully contributed two new Django templating filters; you might find these particularly useful if you do API integrations using custom fields:

  • |load_datetime: parse a date/time from a string using Python's datetime.datetime.strptime method, documented at . For example, this code would output "Tuesday, January 1st":
    {{ '2013-01-01'|load_datetime:"%Y-%m-%d"|date:"l, F jS" }}
  • |load_json: load data from a JSON string such as a custom page field. For example, this template code will output "testval" if your page has a custom field named "settings" with the value '{"testkey": "testval"}':
    {% with page.custom_fields.settings|load_json as settings %} {{ settings.testkey }} {% endwith %}

Duplicate names: We added validation checks for most objects (like targets, languages, tags, template sets, etc.) so you'll see a descriptive error if you try to use a name that's already in use by a hidden object.

Imported recurring donation profiles: We modified the sync with merchant vendor accounts so we'll capture ongoing payments even if you mistakenly imported duplicate recurring profiles. In the future we'll make it harder to import duplicates.

Manual: General updates including a detailed write up on one-time donation processing and data capture, available here:


Hey ActionKitties! We've got a big change to the appearance of the mailer targeting screen coming out in this release. Hope you all like it as much as we do! Also a number of other improvements and bug fixes.

Mailer: New Targeting Screen Interface

The proliferation of targeting options had made this screen pretty unwieldy and many of you had provided feedback about changes you'd like, including making it easier to skip options that never apply to your group.

Taking all that into account we came up with a new design. The functionality is all the same, but we've:

  • Moved the Limits and Ordering section to the top. This will tie into some features related to tests coming out in a future release. And you don't have to scroll down for these settings even if you select a lot of targeting options.
  • Include and exclude options are all hidden under two buttons to start. Click on either button to see the targeting categories. If you click on some of the options, like Donors, multiple related targeting boxes display.
  • At the bottom, if they're relevant, you'll see the options to target constituents of your page's advocacy targets, target user ids in a merge file, or target legislative directors for a bulk signature delivery. You won't see these options if you haven't made the appropriate choices on the Compose screen. For example, if you didn't select a merge file, you won't see the option to target based on merge files.

Reports: New query builder categories

We've added categories for actions and pages. These two have some overlap.

The pages category allows you to recreate the Compare Pages report so you can more easily add other fields you care about or eliminate fields you don't.

The actions report builder allows you to look at action totals and rates by a range of criteria and see details about particular actions.

Also, a feature you may have noticed but that we hadn't documented yet: If you want to create a report with the builder that makes use of parameters (where the person running the report is prompted to provide an input), you can do that for any of the filter fields with a text box. For example, if you want to create a report showing action counts with a given source on a given page, select the source and page options and leave the text boxes blank. To run the report staffers will need to enter the source and page name or id.

Manual: Updated sections and ActionKitties sign up link

Users has been rewritten and updated. Mailings, reports and WMD all have new information and we've added a lot more entries to the index.

Also, at the top of the Release Email Archive, we've added the link your staff can use to be added to our client email list (so they receive release emails and other important notifications).

Bug fixes and performance improvements

  • The tags for |actiontaken: and |tagged: now work on pages in addition to mailings.
  • Event search will now recognize a city and state without the comma, like berkeley ca.
  • We fixed some permissions problems that were allowing staff users to see screens they shouldn't.
  • We limited the number of sent mailings displayed by default on the individual user's mailing history screen. This will help with load times. You can click a link at the bottom of the 100 records to see the full history.


Hey ActionKitties! New features coming out tomorrow morning:

Query builder: Donations and products report types are out in beta!

You'll see this looks very similar to the users report builder. Create a new query report and select the Query Type to get started. Your display selections define the columns to be included in the report. Your filter selections limit the rows to those matching your criteria.

Donations are complicated! We've simplified things a bit in the query builder so you can get the number you want without having to fully understand the data structure. For example, you don't need to know how the core_order and core_transaction tables relate to get a count of one-time donations broken down by final disposition: successful, failed or reversed.

However, it's still helpful to have a basic understanding of how donation processing works and the terms we've used:

A new donation is processed through one of your donation pages or imported through an import page using the uploader. Either way, an action is created as well as an order. If this is a new recurring donation, a recurring order is also created. Product orders are considered a type of donation, even if the product doesn't cost anything (and that's how you might end up with a $0 order).

When the donation is submitted to your merchant vendor a transaction is created. Imported donations don't have transactions. Future payments toward a recurring commitment (or profile) create new transactions, but not new orders or recurring orders.

A few terms you'll see in the query builder: Order - Any donation or product order attempt. Transaction - An exchange with your merchant vendor. Usually processing the order (which might be successful or not) but there also transactions for creating or canceling a recurring profile. Payment - Money went into your account! Any successful donation or product order for more than $0. A recurring donation will have many associated payments. Imports are included as payments. Recurring profile - Each new recurring donation commitment gets a new recurring profile ID. One donor may have multiple profiles. Changing the amount or credit card information for a profile does not generally create a new profile. We're working on a plain English write up with more detail on processing and on the options in the query builder.

Also, we're looking for feedback! Something confusing? Missing? Broken? Please let us know right away.

Uploader: ActionKit's new upload system is finally ready to come out of beta! That means that we're making good on our promise to remove the older upload system. You shouldn't notice any differences in upload behavior (the new uploader has been the default since its launch in 2011), but please let us know if you have questions.

API users: If you're using the old start_import() API call please switch to calling start_upload() as soon as you can. For now, they'll switch to going through a wrapper around start_upload() but six months from now we'll be removing support entirely. Please open a ticket if you have questions about how to make this transition. You can read up on start_import() here:

Manual: We've indexed most manual sections and the reports section has been updated.

Events: We've added more fallbacks for event locations that can't be found. Also, you can use "place" instead of zip or city in your event search forms and the functionality will remain the same.

Recurring mailings: You can hide recurring mailing drafts now. Because of the way recurring mailings work (to make changes to one you've committed you need to stop and copy it), you can end up with multiple unused recurring drafts. Now you can hide these.

Delivery jobs: We're currently working on improving the PDF generation and delivery systems. We have a small change coming out now. The download all links will no longer show on the list of delivery jobs for any jobs that don't have PDF or CSV selected as download options.


Hey ActionKitties! We've got a some back end improvements coming out in this release as well as a couple visible changes:

  • Page snippets: Target related snippets are not just for call pages! The snippets menu has changed to reflect this.
  • Delivery jobs: We're working on improving the signature delivery system. The change you'll see this release is a new "Download links" screen, where you can view the page your targets will see if you send them the link in a delivery mailing, cut and paste the URL to send to them directly, and download CSVs and PDFs yourself for any target.

After you create a delivery job, you'll see a new link to "download files for specific targets." Or, return to the list of delivery jobs where you'll see "Download links" in the Actions section.

A couple things to note:

  • If you don't see any targets on the download links screen, that means you either don't have targets associated with the page, or you don't have any signatures for the targets.
  • If you don't see columns for PDF or CSV, return to the PDF details step of delivery job creation and make sure you've selected those options for this job.
  • Delivery snippet: We added snippets to put page numbers in PDF headers/footers.
  • IP_addresses: We made a change in how we capture ip addresses to ensure that a trailing comma isn't recorded for future actions.
  • REST API: We added a default ordering for all resources and allowed for ordering for mailings by send date.
  • Manual clean up: We cleaned up some broken links from last release and made some corrections and updates.


Hey ActionKitties! Lots of exciting stuff coming to your instance tomorrow morning.

Query Builder (BETA): If you were at ClientCon2013 you saw the preview. Now available for testing!

NOTE: This is in beta. We know you will find problems and errors in the interface and in the queries. Feedback please.

Here's how it works. You can create queries without writing SQL by using ActionKit's point-and-click query builder interface. To use the query builder, when you create a query report, change the "Query Type" field from "Write Your Own SQL" to "Users Report". Other report types coming in future releases. You'll see two new fields, titled "Displays" and "Filters", which you can use to define your report. As you make selections in those two areas, the query builder generates the corresponding SQL.

The Display defines the columns that will show when you run the report. You'll see that some of the selections allow you to further define the display options. For example, if you select "Lifetime Action Count" you can select the types of actions to be included in the count from All Actions, Completed Actions (only those with a status in core_action of "completed"), Completed Non-import (status completed and not an action on an Import page), Completed Significant Actions (status completed and not an action on an Import, Unsubscribe, or Recurring Donation Management page), or Completed Petition Actions (completed action on a Petition Page).

The filter column limits the number of rows that are returned. By default, a row is returned for every user. You can limit this by various criteria. For example, select "Is Subscribed to Main List" to see only users who are currently mailable and subscribed to list_id=1.

You can arbitrarily limit the number of rows returned by selecting "Limit to the first [100] rows" under "SQL Features". You can also join filter criteria using OR or AND by selecting "Any of these criteria" or "All of these criteria" under " SQL Features" and then dragging the relevant filters in to the box.

By default the filters will require that the results you select are included, but you can click on the green "Required" to reverse this so the query will only find those who don't meet the criteria.

Please note: Turning on the query builder or changing the query builder type will erase any SQL query you may have entered so far, and when you are using the query builder, you can not edit your SQL directly. However, you can use the query builder to begin defining a query, and then switch back to "Write Your Own SQL" to make further changes to the query before saving it.

Read more about it in the manual at


  • Selection boxes for including and excluding by mailing: A number of people have asked if we could reinstate the old targeting selection box, where you could select from a drop down of recent mailings. In order to also maintain the option for easily selecting older mailings, we added a 2nd box. Select from a list of recent mailings in the top box. Start typing the id or subject to find older mailings in the 2nd box. All selections, from both boxes, will appear in the top box after you save your targeting (so if you return to the targeting screen you'll see the full list in one place).

  • Debug links for Superusers: We've added links to the bottom of the individual mailings report to two screens that may be useful if you encounter a problem or want to see when a mailing set was last rebuilt. Only staff users who are super users will see these. The first link is to see what happened if a send failed, and the other is a history of set rebuilds.

  • Faster sends! We made a change to speed up mailing set builds that include or exclude mailings, actions, library reports, and raw sql queries. Builds are up to 3 times faster for those targeting criteria.

  • Caching results of reports in the query library for mailing targeting: As you know, you can save query reports and make them available for targeting in the mailer.

    Currently, every time you rebuild the target set for a mailing, any query reports used in the targeting are re-run. Most of the time, for most groups, this works great. However, if you have a very long-running query, this can slow things down quite a bit.

    With this release, we've added an option to the query report to cache the report results. When you create or edit a query report with the "mailer" tag, you'll see a new option above the Schedule and Emailing section called "Refresh". By default, "every time" is selected so the default behavior is exactly the same as what happens now. If you have a slow query and you don't want to wait on rebuilds, you can change this to "hourly" or "daily". These options tell ActionKit to cache the results for an hour or a day the first time the report is run. The report is only run again if the cache is empty when the target set for the mailer is rebuilt.

    If you set the report to refresh hourly or daily, you'll see a note next to the query in the Targeting Section on the Proof and Send screen. The note says "Query cached. Rebuilds hourly." (or daily).

    At any point, you can manually clear the cache using the link under the Refresh selections on the query report editing screen.

This also release includes some changes to help you avoid accidentally double-hitting users while running mailing tests.

First, we've made some changes to help catch any remaining cases where you might invalidate a test sample by changing the targeting of other mailings in the same test set (for example, where you have three test mailings of the same size each going to a random sample of users, mailing b excludes a, mailing c excludes b and a). It's still safest to rebuild and send the mailings in order, starting with mailing a. We try to catch it and warn you if you accidentally rebuild and send mailing b; rebuilding c or b out of order will either force a rebuild or all three mailings or display rebuild before send messages.

Second, we've added an option on the mailer targeting screen to "Mirror excludes of sent mailings". This box is checked by default to ensure that if a sent mailing excluded your draft, your draft will also exclude the sent mailing. That's a best practice for avoiding mailing overlap, and usually, you should leave the box checked. You can see which mailings have been excluded in the Excludes section of the "Proof and Send" screen. If there's a special situation where you want to double-hit those mailings' targets, uncheck the box.

Excludes are only added when you edit your query or rebuild your mailing set; it's normal if mailings don't show up in your targeting as soon as they're sent.


We added some real search functionality! It's not google, but the following are now available:

  • Matching on multiple words (e.g. action field)
  • Matching terms with a dash or underscore (e.g. one-click)
  • Basic logic (e.g. find "donation" but not recurring by entering "donation - recurring")

The results are weighted, so if your search terms are in a title, that will come at or toward the top of the list.

You need to select separately if you want to search the API reference.

Also, we've reworked the templates section in the developer guide. Let us know what you think.

Organization wide settings

We've exposed a few organizational settings. These are available to all super users, who will see a new link to "settings" near the version at the bottom of the screen. This brings you to

For now, the available settings are mostly other vendor accounts or display options.

You can change the time window ActionKit will use to check for duplicate donations. By default, ActionKit will return an error if a user submits a second donation within five minutes. If you reset this to 0, duplicate detection is disabled and users will be charged if they accidentally hit the submit button more than once.

In future we'll add other organizational settings to this list (possibly default donation account or minimum amount as well as language settings).

Misc and bug fixes

  • We updated the descriptions in the core_subscriptionchangetype table to include unsubscribe_import and changed one of the Unsubscribe Admin descriptions to the more accurate Unsubscribe by Feedback Loop (Clicked Spam).
  • We made it possible to find pages with multiple tags in the REST API. For ex. will search for pages with both tags.
  • The canonical_url tag will return the SSL URL for donation pages.
  • We made a change to how the uploader processes uploads - you shouldn't notice any changes but it should be more reliable.
  • We made a change that allows TEMPLATE in the value of a query string in a redirected URL. This means you can do things like include a source value and append a dynamic mailing ID in the URL for tracking.
  • The report tool will wait to send an emailed report until the HTML has fully rendered, even if you request it more than once or while the report is still running, where the report shows a breakdown by page or mailings.
  • When a user asked to change his/her email address to that of another user, and clicked the link to confirm in the email message, we were returning an error. This is now fixed.
  • Allowing multiple responses for call pages led to two actions per call in the database. That's fixed.
  • Previewing delivery emails no longer errors.


Just a few things for you this week. As usual, these will be in your instance tomorrow morning.

We added a write up on statistical significance to the Compare Mailings report. There's a table and definitions of terms to help you determine whether the performance difference between two mailings is statistically significant. This is currently only available for this report, not for the break down by subject line on the individual mailing report. Layout improvements for the Compare Mailings report coming soon. Let us know if this is helpful and if you have questions!

We've added a table called zip_proximity that displays all zip code pairs within 50 mi of each other. There's an index on (zip, distance). The data looks likes this:

zip nearby same_state distance 00501 00501 1 0.0 00501 00544 1 0.2 00501 06401 0 36.5 00501 06403 0 43.0 00501 06404 0 38.9

You can use this to do things like find users near a campaign's events: select,, distance from events_event e join zip_proximity zp on ( = join core_user u on zp.nearby = where campaign_id = 1 and distance < 10;

This gives you another tool to use to work with zips based on proximity.

You can also use the existing report tag, {{ users_near_location }} , that allows you to find users in a certain radius from a zip code, city and state, or city and country.

Survey download options changed so one option includes name, address, district and phone.

Bug fixes:

We improved the Compare Pages report so it shouldn't time out if you select a donation page with many thousands of donations.

If you had a merge file with a column for zip, previous ActionKit would match on that column, even if you had another column first that was supposed to be used for the match. Now the mailer will match on the first column even if zip is a later column in the file.

We fixed some problems with the new widget for selecting mailings for mailer targeting. The current mailing will no longer show on the list and you should be able to find an option again after you select it then deselect it.


Hey ActionKitties! It was really great to see so many of you in June. This whopper of a release includes recurring mailings in beta (as previewed by Randall Farmer at ClientCon13). Plus a lot of other cool stuff. As always, you won't see these changes in your instance until tomorrow morning.

RECURRING MAILINGS (BETA): Recurring mailings are now available. Please note that this feature is in beta. We've tested, but this is complicated functionality and there will still be bugs. We hope you'll test it! You don't need to sign up as a beta-tester; just start using it. If you do, for now it's a good idea to do some extra checking -- do your counts look right, did the correct number of mailings get sent today, etc. Also, let us know where the set up is confusing or unclear.

Here's the overview of recurring mailings from the manual:

Recurring mailing series send the same content out on a schedule, often daily, weekly, or monthly.

In ActionKit, you'll use them to:

  • send mail when something is coming up, like if the credit card for a user's recurring donation is about to expire or an event they've signed up for is happening soon
  • send mail after something happens, like if a user joined the list in the past week
  • send other automated, always-identical messages, like weekly surveys to random users

Recurring mailing series in ActionKit replace 'triggers' in other systems. So, instead of setting up a trigger to email new subscribers 14 days after they sign up, in ActionKit you'd set up a recurring mailing targeted to people who signed up 14 days ago. You have to shift your thinking slightly to use recurring mailings if you're used to triggers, but you can generally do the same things with both.

Remember, recurring mailings uses the same HTML for every send. So, you can't use a recurring mailing for a newsletter, or any other email that's regularly scheduled but has content specially written for each time it's sent.

Creating and writing content for a recurring draft is just like for a normal draft; the differences are mostly in targeting, sending, and maintaining the mailings once they're launched.

Read more at including a description of the new reports we've added to help analyze performance for your recurring series' and some of the new sample queries you'll see in the query library (e.g. recurring donors whose credit card recently failed).


  • On the select recipients screen, we've changed targeting by Mailings and Actions to use "Auto-complete". The lookups are id, name, title and tag for pages; id, subject and tag for mailings. Name, title and subject are searched with wildcards, id and tags are searched from the beginning of the string. Mailings are no longer limited to those created in the last 60 days.
  • We changed how the checkbox for "Target members who are constituents of your landing page's targets" interacts with other targeting selections in the mailer. If you check this box and also make selections in another targeting box, we'll AND the choices together just as we do when you combine other categories. Previously the page target's constituents would be combined with some categories using AND and some categories using OR. Now, for example, if you check target constituents and also enter CA in the State targeting box, we'll only include users in California who live in the districts of targets on your page.
  • We made user.location available for creating snippets from core_location data in mailings. Address information is in the core_user table, but some other geographic info like county is in the core_location table. For example, to include the user county in a mailing insert: {{ user.location.us_county }}.
  • We also fixed a couple bugs, including one with the "s" if plural snippet.

SECURE SQL CONNECTION: You can now create an encrypted connection to the client database. Here's the recipe for the standard mysql command line client:

mysql --ssl-cipher="DHE-RSA-AES256-SHA" --u [username] --p [password] -h ak_yourgroupname

Depending on your client or API interface, you may need to provide additional configuration options.

MANUAL UPDATES: We've got another big documentation update in this release, including:

  • Database Table Directory: We've updated this and improved the formatting. Recurring mailings related tables coming soon!
  • Report reference: We've added a section that shows all of the built-in reports included with your instance, including our sample query library reports for use in the mailer. The reference shows our SQL. New queries in this release are not yet documented but will be for the next release. The reference is available at
  • Search improvement: We've fixed a bug that kept search terms from being highlighted in the results. The search functionality still has serious limitations -- we're working on improving this and providing more indexing so it's easier to find what you need.


  • You can now copy target groups. On the pages tab, click legislative or custom next to Targets to see your list of available groups. There's a copy button for each to the right.
  • We've added a new page displaying all the download links for the individual targets of a delivery job. You can use this to see what the targets will see if they follow the link you mail to them. You can also resend them the link or give it to them over the phone as needed.

When you create or edit a delivery job, go to step 2 "Check Preview PDF". At the bottom of the screen, after your preview loads, you'll see a link to "download links for specific targets."


  • ActionKit had a bug where recurring payments that failed ended up with an incorrect status of "completed" in core_transaction. This has been corrected and from now on recurring payments that fail will have the status "failed" in core_transaction."

OTHER * We fixed some problems caused by hiding parts of an event campaign. * We added messages asking you to confirm when hiding or copying more objects (e.g. from lines in the mailer). * We fixed a problem where non-ascii characters would sometimes break CSV downloads.


Once again, we've got a big release for you. Be sure to read the first bullet under mailings if you test mailings.

These changes will be live in your instance tomorrow morning.

Mailings: We've made some changes to improve performance and avoid some problems related to specific targeting, plus made a couple small improvements.

  • If you change the targeting for a draft mailing that is included or excluded by another draft, you'll have to rebuild the dependent draft before you can send it. For example, let's say I am sending an alert (A) to super actives. I've also set up a draft (B) that I'll send later in the day to the rest of my list so it excludes my super actives mailing. I realize I forgot to include recent donors in my super actives, so I change the targeting for mailing A and send it. Now when I go to "current drafts" on the mailings tab, I'll see a message "query needs rebuild before send" for mailing B. I can click the link to "rebuild now" or rebuild from the "Proof and Send" screen.

This is not true if the dependent draft is scheduled. If you change the targeting for a draft that is included or excluded by a scheduled mailing, the scheduled mailing will always automatically rebuild at send.

The latter change may affect random tests that you schedule instead of sending manually. Remember that the recipients matching your targeting selections are saved at the time you create your mailing (or when you force a rebuild). For tests you need to build your mailing targeting sets in order (first A, which targets X random users, then B, which excludes A, then C, which excludes A & B, etc.). Then, if A, B, and C are all scheduled to go out together first thing tomorrow, and you go back and change the targeting for A, you'll need to rebuild the targeting sets for B & C manually. Otherwise you risk double-hitting users and invalidating your test results.

In an upcoming release, we'll be adding a write-up on our recommended approach to A/B testing. We'll also be adding a checkbox to allow you to exclude anyone who received or will receive a mailing that's already sent or sending that day.

  • More info on target set build time and status. The dashboard, target page and the summary page now display how long we think it will take to build your mailing target set (based solely on the previous run), and the SavedQuery status displays more prominently on the Proof and Send screen.
  • Custom mailings fields will be retained when you copy a mailing and they can now be removed from a particular mailing.
  • New snippet. If you've created a petition and enabled one-click, but you want to disable one-click in a particular mailing (without disabling user recognition and tracking), simply append nosig=1 to your URL.

Bulk uploader: You can import by user_id and akid in addition to email address.

Bug fixes: Accidentally targeting an event with no future actions will return a count of 0 instead of failing. We modified the way that merge files handle combining city and state to get unique locations. We fixed a bug finding language specific signup pages for Event campaigns and one that stopped users from updating their zip for US events using an international form. We also changed the link in the user record for event hosts to go to the "act as host" screen for the event and save some more detail under the action record, like role and status.


Two releases this week. We've got a bunch of performance improvements in today for mailings, reports and imports.


  • Multiple responses default: When you create a petition or letter page the new default is to not allow multiple responses. Each user can only sign once and if they try to sign again, their later entry will overwrite the earlier one.
  • Merge files: Previously we always matched on the first column in the merge file for mailings. But city, state is a special case because some city names are not unique (e.g. Springfield), so if city and state are the first two columns in your merge file we'll automatically use both to make sure we get the correct value for each user.
  • Limit by state for events in the mailer: As mentioned in the last release, we made a change so the withevents snippet can be used to display only events in the user's same state. This release we added a checkbox on the recipient selection screen so you can easily limit mailer targeting in the same way.
  • Unsubscribe codes: We added change_id=8 to the reports that show a total count of unsubscribed users. Change_id=8 in the core_subscriptionhistory table means the user was unsubscribed through the bulk uploader on the users tab.
  • Couple bug fixes:
  • Advanced searches for events: Searching for public events now returns public events, not private ones (oops).
  • Reports scheduled to send hourly would fail if you selected CSV as the format. This is no longer the case.


For this release we've made some changes to improve performance including mailing speed for particular types of targeting. We've also got a variety of improvements to existing features and some bug fixes. As usual, the changes will be in your instance tomorrow morning. Enjoy!

Whipcount page improvements. When you copy a whipcount page, the targeting choices and positions will be retained. Also, by default, there's a column that shows the number of calls reported for each target. The column now displays regardless of the result source -- whether you're setting the position for the target or basing it on user reports. Finally, there's a new option to see all the targets as a list so it's easier to set the responses if your group includes a lot of targets.

Displaying only events in the user's state. When you use the attendee recruitment snippet in the mailer, ActionKit shows the user the closest event (or events if you change the limit in the snippet), regardless of what state the event is in. If you want to force ActionKit to show only events in the same state as the user, you can use one of two new parameters that work with the "withevents" tag -- state and user_state_only.

For example,

{% withevents with user as nearby_user 'eventcreatetemplate' as campaign 30 as radius 1 as limit user.state as state %}


{% withevents with user as nearby_user 'eventcreatetemplate' as campaign 30 as radius 1 as limit 1 as user_state_only %}

Both do the same thing.

Please note -- we will not send to users who don't have a nearby in-state event but these users will be included in your mailing count which may be a little high as a result. For example, if you have a user who lives in Nevada near the border with California, and the only event within 30 miles of that user is in California, the user will not receive an email but will be in the mailing count. This will be fixed in the next release.

One-click petitions and proofs. If you have a petition with one-click enabled and your mailing users a link to the page, previously you couldn't test the link from a proof without submitting a signature in the name of the user in the proof. Now you can click on the link and confirm that you've linked to the right page.

LTE improvement. If a user submits to a particular newspaper, then comes back to send another LTE, only the papers to whom the user has not sent a letter will show on the list.

REST API. Save_or_create will work for classes that don't have create or update.

Bug fixes

  • On the home tab, if you click through from recently opened to a mailing you just sent, you'll now be directed to the individual mailing report.
  • We fixed a problem with the appearance of the "display all" screens if you had a long list of tags.
  • ActionKit will not automatically save your work on pages when you hit the back button. (Usually you'll see a prompt to save your changes or lose them).
  • We fixed several reports with unsubscribe counts to include users who marked your email as spam. This is recorded as change_id 6 in the core_subscriptionhistory table. We also recently added change_id 8 for users who were unsubbed using the bulk uploader. That will be added to these same reports in an upcoming release. The affected reports are: unsub_users, unsub_users_weekly and unsub_users_main.
  • We fixed a problem that had prevented merge files from working with delivery mailings.


This week we've got some important changes to petition/letter delivery that you should review if you use either immediate or bulk delivery and also a change to donation pages that only applies if you use Braintree or Please ask through support if you aren't sure about how either of these apply to you.

We've also got some smaller changes and bug fixes noted at the bottom.

Letter and petition delivery: We've made some changes that affect both our immediate and bulk delivery systems.

  • We removed the limit of 30 emails every 24 hours for state legislators. However, we still suggest using bulk delivery and/or notifying your target when you expect to deliver more than this in one day to a given target. The limit is still in place for custom targets. You can ask us to lift the limit through the support form (for example if the target is an agency and has asked for public comment at a published email address). However, read the disclaimer.
  • We changed the rules for when we overwrite changes you've made to the contact information for a target. When you create a delivery job, you'll see a link to change the address we use for delivery. It brings you to this screen where you can find your target and click to update the email address and name for the target.

You can enter a new email address for a state legislator, add or update the email for a custom target (someone you've added), or update the email for the legislative director for a federal legislator.

For state and federal Senators and House Reps we will only overwrite the information you enter if our vendor provides a new email address. Your updates will not be overwritten with a blank email or with the same email the vendor provided previously.

Please note -- when you click to update a federal legislator (a U.S. Senator or House Rep) you'll see the name of the Legislative Director, not of the legislator. This is the person bulk deliveries go to. There are no immediate email deliveries for federal legislators. If you update the email and/or name here, future bulk deliveries to the federal legislator will go to the person and address you enter instead of the Legislative Director provided by our vendor.

WARNING: Your advocacy target can mark your signature deliveries as spam and this can do serious damage to your email reputation and hurt your delivery rates. This is especially true if the target escalates their complaint with a given ISP. This isn't something we can't control. In our experience it's more likely to happen if you're emailing someone at a personal email address or if they are inundated with messages. You need to balance the advocacy value of your delivery against your ability to get messages to your users in future. We advise caution and recommend moving to the bulk delivery system and/or notifying your target if you get a lot of actions for one target. We're considering a more automated system that would combine bulk and immediate delivery but for now this is something you need to manage manually.

Donation pages no longer require CVV: This change is only relevant if you use Braintree or and it will not change how your existing pages function, unless you have already changed your settings with your merchant vendor so they don't require CVV. Currently we require it and then Braintree and Authorize require it by default, so even if you shut it off with them we still required it.

Rate limiting for mailings: Usually we send your emails as fast as we can once you hit send! However, there may be times when you'd like the emails to trickle out. The classic use for this feature is to send call alerts slowly enough to avoid all of your users getting a busy signal at once. It may also be useful if you are sending users to a partner with limited network or server resources. We've added a new rate per second option on the targeting screen for mailings. Usually you should ignore this! But if you do want to slow down the rate at which we send a message, enter a number here. The low end is 2 mails/second and the high end is 300/second.

More options for the autocomplete for the reports showing performance by page or by mailing. We're working on ways to make this more intuitive visually but for now we've just added all the options. You can select from among recent pages or mailings in the top box. You can search for older mailings in the second box. The report will show results for mailings from both boxes. Alternatively, if you want to use the drag-to-select option for selecting mailings over a time period, you can click the link to show the plain multi-select box.

We'll return an error if you try to send an email with a subject that only includes spaces.

You can now delete query and dashboard reports using the RST API.

We added a template tag for custom_fields_list that will always return custom fields as a list.

Both and will return the donation total for confirmation and after action emails.


Hey ActionKitties! A few new things for you this week:

  • Search for users by actions taken on the advanced user search screen.
  • New template tag that tells Django to treat any returned value as a list. For example, if you've got multiple values entered for a custom field, this tag forces Django to return the value(s) as a list. The tag is "force_list". E.g. if you have a custom user field for people's academic degrees:
{% for degree in user.customfield.degrees|force_list %}
{% endfor %}
  • A couple improvements to the REST API:
  • Fix PUT and POST to userfield resources directly in the REST API
  • Fix POSTing application/www-x-urlencoded to the generic action processor via the REST API
  • And a little improvement in the AK javascript that will keep the view from jumping to the top whenever there's an error. Instead we scroll errors into view if they were offscreen.


Hey ActionKitties! This week we've added some advanced options for page set up that give you the ability to decide when most pages will recognize a user and how many separate actions a user can take. Plus a bunch of smaller improvements and bug fixes (so scroll down if the first long section isn't relevant for you).

User recognition and multiple responses for pages: This release adds two options that allow you to control when ActionKit pages will recognize your users and what happens when a user takes action on the same page more than once.

Your existing pages have all retained the previous settings (although you can change them now if you'd like).

You'll see these new settings in the "More Option" section for most new pages you create:

"Recognize user" allows you to control what happens when a User arrives on an ActionKit page with a hashed token (?akid=xxx-yyy-zzzzzz). The default option "once", will recognize a user until they submit the page and take action. This is a default because most of the time the first user who follows a link like this and submits on the page is the user associated with the AKID. Other users who follow the same link are generally friends who have received a message from the original user telling them about the action, so you don't want the page to recognize them -- both because the page would think the friends are still the original user and because you want to capture correct contact information for any friends.

You can change this to "Always" or "Never." You might use "Never" if you want to do something like make sure that everyone taking action on a page enters a correct phone number, whether or not you already have one in the file. "Always" has fewer obvious uses, but we've included it in case there are times when you want everyone who follows a link to be counted as the user identified in the link.

"Allow multiple actions" lets you control what happens when a User submits on the same Page more than once. If true, ActionKit will save multiple actions for the same page for the same user. If false, ActionKit will update the original action (replacing all its custom fields). SOURCE, DATE?

This relates to the recognize user setting because ActionKit will determine whether the same user is submitting on a page either because the user was recognized and submitted or because the user entered an email that matches the email of a previous submittal. For example, if you set a survey page to "Always" recognize a user and to NOT allow multiple responses, that means that every user who submits following a link from a particular mailing will have an action recorded under the AKID from the mailing and only the final response will be saved to your database.

A few page types do not include these options. Unsubscribe pages must always recognize the user in order to comply with our requirements for best practices for email delivery. Donation-related pages and event creation pages require the user to enter their information, even if the user is recognized, so we don't show these options for those page types either.

By default, when you create new pages of any type, "once" and "Allow multiple responses" will be selected. Previously Petition, Whipcount, and Call pages recognized the user one but only allowed one response. As noted above, behavior will not change for your existing pages, but new pages of these types will allow multiple responses.

If you set a limit for a mailing, "random" is pre-selected as the sort order. You can change it if you aren't doing a test, but most often the limit function is used for testing where you want the recipients to be selected at random.

For mailings, if you select a merge file on the compose screen, you'll see a new option at the bottom of the recipient selection screen to target only users in the merge file.

Reports for Compare Mailings and Compare Pages have better options for selecting the objects to compare. These now use the multi-select widget so you can start typing the page name, page type or ID or the mailing ID, subject or tag and select from those that match.

Events display in descending order by when they were created (unless you specify a different order).

The targeting summary for mailings now includes an id for pages and campaigns so you can identify which was selected even if many share the same name.

Also, we fixed a couple tricky bugs that you all helped us identify:

  • Users who a staff user unsubscribed from the individual user record in the admin could be accidentally resubscribed if they were included in an import through the bulk uploader. Users who unsubscribed themselves or who staff unsubscribed through the importer were not affected.
  • A merge file that ended in .txt, even if the content was tab- or comma- separated, would get stuck uploading but won't now.
  • The fallback page wouldn't show correctly for a user who outside of the district of one of the targets on a call page, where the page had both a general target (like President) and a geo-coded target (like a Senator).


In the last week we've been doing some tune ups on the back end, including adding indexes to some tables, writing additional tests and improving validation and some error messages that you or your users might see.

We've also got some more visible changes:

  • Advocacy targets can be included in petition and letter pages. If you're asking users to sign a petition to their House Reps, you can include the Representative name using {{ context.targets.title_full }}. Of course, this only works if the user is recognized and we have enough information to determine the user's district (zip code for this example) so you may want to include a default if you're using this in the page content. For example: {{ context.targets.title_full|default:"Your Representative" }}. If you're using this on the thanks page, you don't need a default (since the user will have just submitted). We'll be updating the list of snippets in a future release and adding documentation on how to use this if you're hosting your own pages.
  • Country field will only be updated for a user from a hidden field value if the user also changes their address or zip. If a recognized international user submits on a page that isn't set up for international actions, this change will maintain their existing country entry, even if the page includes the hidden field setting country to "United States" that is in our default template set for pages that aren't internationalized. If the user enters a zip or a street address on a page like this their country is changed to "United States".
  • Mailings sets: After 30 days, mailings sets that have been saved to your database will be deleted unless the mailing was stopped or died. The id of every user who was sent a mailing is saved to the core_usermailing table which is never deleted so you won't lose mail history (but you will have fewer tables displayed if you view your table list through your SQL connection).
  • Reports: We added a note to the top of the built-in donation reports that don't include recurring donations to make this clearer, most importantly the Fundraising Campaigns dashboard report. Also we added the code for users who were added through the API so these users will be included in the List Growth dashboard.


This week we've got a manual overhaul, a cool new mailer feature in beta, and our usual bug fixes and new features:

  • Merge files for mailings (beta): We're looking for testers! With this new feature, you can include user-specific information not directly available in ActionKit in your mailings using merge files. For example, you may want to use highly localized goals based on users' cities: "We need 5 more volunteers in Oklahoma City today!" Or include the name of the local newspaper based on zip code.

    Start by uploading a CSV or TSV where the first column is the field you'd like to match on. For example, include an id column to match on user_id or email to match on user email. There are a bunch of other fields you can match on including city, state, zip and country. Then make a column for the value(s) you'd like to insert. For example, you might have a file with a column for zip and a column for newspaper. Use snippets to insert the relevant content for each user in your mailing.

    This feature is still in beta so let us know if you're trying it out and be sure to view plenty of proofs. We've already got a few improvements in mind (like some changes to make the workflow clearer when you use this option). Read more at

  • Manual upgrade: In addition to a new color scheme, we've added more links in the admin UI and new content throughout, plus we've rewritten the pages section of the campaigner's guide. You'll find more information on action processing and data capture, user recognition, snippets and custom content, a new section on testing your pages and more. The old pages section is still available (so you can replace any bookmarks you have over time). Your questions informed what we added so please keep them coming!

  • Limits on immediate email delivery to advocacy targets for petition and letter pages: The immediate email delivery option in ActionKit sends an email to advocacy targets for whom we have an email address every time a user submits on a page. We've added a limit of 30 emails every 24 hours because sending a high volume of emails to one address in a short time can have serious negative affects on your overall email reputation and deliverability. There will be cases where an exception is appropriate (for example when an agency requests public input to a designated email address). For now you'll need to request an override through the support form. Once you've hit the daily limit you'll receive an email. At that point you can set up a bulk e-delivery or, where you know you're going to hit the limit, you may want to plan on sending a daily bulk e-delivery instead.

  • User specific mailing proofs: You'll see a new option on both the compose and proof and send screens to "see proofs for specific users." Select one or more staff members to receive proofs, or enter an email address, then select this link and enter a list of user_ids to receive proofs for specific users. This allows you to view mailings as they will appear to users meeting specific criteria. For example, if you want to see how your suggested ask will appear to donors with a large average gift, you can enter the user_ids of 5 users you know meet that criteria. We still recommend viewing and testing random proofs as well because you may encounter a problem that you aren't specifically looking for.

  • Report improvements: Some of the reports that come standard with ActionKit were missing the "wawd_standard" tag which we corrected. Also the events dashboard now includes attendance information as reported by the host.

  • Validation: We added validation for after action notification emails (so we'll let you know when you set them up if you've got a problem like a broken Django template). We also added a check that the fallback page entered for a call page (if you use one) is a URL. And we stopped an action_id in a URL from overriding a user_id in the URL path.