Pages¶
What Is A Page?¶
Pages in ActionKit generally correspond to web pages, where your users can take an action. ActionKit doesn't offer content page types, only action pages. For most groups, it makes sense to maintain and host the home page of their website outside of ActionKit, linking from there to ActionKit Pages for advocacy, fundraising, events and other member engagement.
You direct users to your Pages to express support for your position, lobby decisionmakers, donate, sign up for events, and more. Pages capture data about those actions and your users.
Pages are also how users get subscribed to your mailing list so you can email them through ActionKit. By default, anyone who takes action is added to the mailing list you associate with the page. To maintain good email deliverability, your page should clearly indicate this, so users aren't surprised when they receive email from you.
You can customize just about everything about your page, from the appearance, to the user form fields, to user specific content. You can host your pages with us, using our mini-CMS to enter your page content, or you can host your page externally, using another CMS.
Pages are broken down into Types to give you quick access to features specific to the page's purpose.
What Are The Page Types?¶
ActionKit walks you through the process of creating Pages based on Type, streamlining the process and incorporating best practices. The Types are:
Petition – Petition Pages are generally used to petition an advocacy target on a specific issue or campaign. Users can add a personal comment but they cannot edit the statement. Petitions support one-click signing.
Letter - Letter Pages are similar to Petition Pages, but the user is encouraged to edit the letter you provide or write their own. Also, one-click signing is only available for petition pages. Letter pages are designed to encourage the user to customize the content, so you want the user to land on the screen with the content.
Call – Call Pages ask the user to call an advocacy target, generally to lobby them on an issue. These pages display the target phone number and ask the user to indicate whom they called and how it went.
Whipcount – Whipcount pages are a version of call pages that allow you to track the positions of a set of targets. A typical whipcount would target a small set of legislators who are either undecided on an issue, or hold key positions in the legislative process. Whipcount pages do not rely on a user's address to determine targets. The user sees the full list of targets, selects one to call, then sees a form with the target's phone number, instructions, and a contact form (unless the user is already recognized). The user calls and records the target's position on your issue. Once enough users have confirmed a target's response (based on your settings on the Whipcount Responses screen under User submitted), that target shows as confirmed so the next user can call a different target.
You can also use whipcount pages to generate thank and spank calls to targets.
Letter to the editor (LTE) – LTE Pages ask users to compose an original letter to the editor of a local, regional, or national newspaper. The user first selects a newspaper from a list, then composes a user, then submits. ActionKit emails the user's letter to the editor for the relevant paper using data from a third party database. A user can only submit once for any given paper from an LTE page.
Survey – Survey Pages provide one or more questions for your users. Use surveys to get input on a specific campaign or to track opinions about your organization over time or for anything where you want input. You can provide your users with selectable answers in any format or provide space for users to enter their own free form responses.
The results are available for download as a CSV by clicking the Download Actions link on the Reports Tab.
Event – Events are usually (but not always) used to organize off-line gatherings for advocacy, team-building, public education, etc. To create an event you first create an Event Campaign, which has multiple pages associated with it, including a page where hosts sign up and one where attendees sign up.
Donation – Donation Pages ask your users to contribute, order Products, or support Candidates (through bundled contributions) using a credit card, PayPal, or ACH direct debit.
To accept credit card donations, you must have a payment account set up with a merchant vendor we integrate with. You can accept recurring donations and donations in many currencies.
To accept PayPal donations, we need information about your PayPal Account.
To accept ACH direct debit, you need a merchant account with Braintree and you must sign up for their ACH beta program.
You can also manage donations through ActionKit.
Update Recurring Donation - From pages of this type, users with existing recurring donations can update the amount of their recurring donation or update their credit card number, bank information (for ACH direct debit donations), or billing address. The billing address is prefilled from the last saved billing address for this recurring profile, and changes to the billing address are only available for Braintree, Authorize.net and PayFlowPro accounts. Users cannot update the billing address for PayPal accounts.
The update page also includes a link to the cancel recurring donation page.
If you have more than one merchant account, your page will automatically use the correct one for the user's recurring profile.
The template for changing the layout or appearance of this page is Recurring update.
Cancel Recurring Donation – This Type allows users with an existing recurring donation commitment to log in and cancel the commitment. The user cannot request refunds for past payments from this page.
The template for changing the layout or appearance of this page is Recurring cancel.
Signup – Signup Pages are the most basic Type. You can use them to add users to a mailing list or associate them with a Tag.
Unsubscribe – Unsubscribe Pages allow your users to ask not to be sent future mailings. Once a user is unsubscribed you can't email them from ActionKit.
Users can also ask to be removed from particular mailing lists, however, your page must make it possible to unsubscribe from all mailing lists with one click. If they're following a link from an ActionKit mailing (e.g. they have an AKID), they must be recognized and cannot be asked to enter their email address.
When a recognized user lands on your unsubscribe page, they see a checkbox for each list they belong to, as long as your template set is based on the Original. All the boxes will be checked by default. The user can simply submit to unsubscribe entirely. If the user unchecks all the boxes and then submits, the same thing happens - the user is unsubscribed from all lists. Only if the user leaves some boxes checked do they remain subscribed to any mailing lists.
In your own templatesets and offsite pages, you must maintain this type of approach -- either pre-selecting all the lists or providing a prominent remove-from-all-lists option at the top of the screen. Although you may lose a couple users who would otherwise have checked only some of the lists, this is a minor price to pay for maintaining good deliverability. If a user thinks they unsubscribed entirely, but forgot to check a box and therefore receives an email, they may become angry and complain to their ISP, which is very damaging to your email reputation.
Account Tools – You can also create several account screens where your end users can manage their own profile, including the user update and password screens. You can only create one version of each screen.
Import Pages - This page type doesn't correspond to a user-facing web page. Import Pages are used to add users, actions, or user data to your database from a CSV file. Add these Pages from the Pages Tab or the Users Tab.
How Do Pages Work?¶
Neither you nor your users see most of this, but starting when a user lands on your ActionKit page, there are a lot of things that happen! Below we describe the process and call out some key information about the data we capture for each action.
Processing User Actions¶
Here's what the process looks like:
1 A user arrives on your page.
The user either followed a link or typed a URL into a browser's address bar. Usually the link was in a mailing you sent them but it could also have been forwarded by a friend or posted on Facebook or in a blog, etc.
2 ActionKit checks the URL for an ActionKit ID (or AKID) and action source.
Mailings from ActionKit generally include this information and you can add them to other links you create.
- If the link includes the AKID, ActionKit looks at your page to see what fields are required, then in the database to see if we have that information for the user. See required fields for more information.
- If we have the required information, the user sees a message like Not Bob? Click here. and doesn't have to enter any personal data. See recognized users for more information.
- If we're missing anything, the user is presented with a blank user form.
- If the link doesn't include the AKID, the user is presented with a blank user form.
3 Either way the user takes the suggested action (hopefully) and submits by clicking the button on the page (which will say something like Submit Donation or Send Letter).
4 ActionKit checks the information the user submitted.
- If required fields are still missing, the user sees an error message and must enter the information before the action will be processed. See Required Form Fields for more information.
- If the field is one we validate and the data is wrong (like a 6-digit zip code), the user sees an error and must correct the entry to submit.
5 Once the user successfully submits, a row is added to the core_action table. Content, like letter text, is saved. See Data Capture 101 for more information.
- If the link includes an action source (included in mailings by default), it's saved to core_action as well. If not the action is assigned the generic source, website.
6 ActionKit checks to see if the user entered an email address that is new to your database:
- If so, ActionKit creates a new user by adding a row to the core_user table.
- If the email is not new, that means the user was recognized from the link or entered an email address that was already in your database. Either way, ActionKit saves any new or changed information to the existing user record.
7 ActionKit checks to see if the user's subscription status or list membership has changed. By default, taking action on a page makes the user mailable and adds them to whatever mailing list you associate with the page, if they aren't already on it.
The user doesn't see any of this! After submitting, the user immediately lands at the URL you specified during page creation - usually a thank you page generated from content you entered on the Edit content screen.
8 If you enabled the tell-a-friend widget, the user sees a box for friends' email addresses. ActionKit will send them the TAF message and append the source code taf to links. (So if the friend follows the link, they start the process at the top).
9 Finally, ActionKit takes a look at the address data the user submitted and adds and corrects location-related information (for example, we add the user's Congressional District based on their zip and address info). See Geographic coding for more information.
Pages And Users¶
What Is A Recognized User?¶
ActionKit 'recognizes' users who follow a link in one of your mailings to one of your pages, unless you override this. ActionKit recognizes your existing users if the link to the page includes the user's identifier or AKID. ActionKit automatically adds the AKID to links in mailings (so the user lands on the page and sees their info). You can add the AKID to your own links, like on your website.
The goal is to get more of your users taking action by not requiring them to re-enter contact information if you already have it. Recognized users don't usually see a user form at all in ActionKit. Instead, the user will see a sentence saying "Not User_first_name? Click here". We use this approach instead of auto-filling any fields both to protect the privacy of your existing users and to make it easier for them to take action.
There are a few reasons a user might not be recognized, even if they came in with the standard AKID parameter:
User already took this action. By default most Pages are set to Recognize user once. This is to cover the scenario in which one of your users receives your mailing, takes action, then forwards their personalized link to a friend. The friend will click on the link and see a blank user form and (we hope) join your list as a new user.
Page type does not recognize users. Donation pages and event host pages always show the full user form to get the most current, accurate information from the user.
Need more user information. If your page requires a field (say, zip code) and a user arrives at the page with an
akid=
but has no zip code on file, they'll be shown a user form so we can get their zip. Sometimes, Pages require certain fields even if you didn't choose them from the required form fields list. For example, Call Pages targeting U.S. Senators and Representatives will require the user's state or zip.This particular page or link specifically disables user recognition. You can set one of your templates to disable user recognition with the code:
<input type="hidden" name="never_recognize" value="1">
And you can make sure a particular link doesn't trigger user recognition by adding the query string parameter
nr=1
. You can fully 'depersonalize' a link (and disable click tracking for it as well) by adding the parameterno_akid=1
to the link.Invalid akid=. Several things can make an AKID invalid: using a plain numeric AKID without the cryptographic 'hash' we use to prevent tampering, changing the user or mailing IDs in an AKID, or accidentally pasting in an AKID that was cut short by linebreaking.
Even if a user is not recognized, ActionKit will save any new or changed information to the correct user record for any email address that already exists in the database.
User Identifier¶
An AKID (or ActionKit ID) is the unique identifier used by ActionKit to represent a particular user. ActionKit automatically adds the AKID to links in bulk mailings (so the user lands on the page and sees their info).
Each user's AKID is displayed on their individual user record (the screen you see if you search for the user from the Users Tab and then click on the user email). It's displayed under the user's name and to the right of the user_id.
The AKID is also displayed in the URL on the Thanks screen that a user sees after taking an action. You'll usually see something like this: /thanks/testpetition1?action_id=126&akid=.2.HxiD3p&taf=1
. The part after akid=
and before &
is the AKID.
You can use the AKID for testing. For example, if you want to test your suggested ask formula for a Donation page, you might want to view the page as if you'd followed the link in a mailing. To do this, put the link at the end of your URL like this: /yourpagenamehere/?akid=yourAKIDhere
You can also use the AKID in confirmation emails. Let's say you want to thank users who take action on a Petition page, then ask them to contribute to the same campaign. And you want the Donation page to recognize the user. Just put this at the end of your link: /?akid={{ user.token }}
. Then be sure to test!
User Form Required Fields¶
The user must enter a value in any required fields before they can successfully submit on a page through the user form. If a required field is blank, the user will get an error message until they fill in a value. Email address is always a required field because a unique email address is required to create a new user in ActionKit.
In general, you set which fields are required for a given page in the Customize Fields section on the Edit Content screen.
Some Pages require specific data, whether or not you set the field as required yourself. For example, ActionKit must know what district a user lives in to display a phone number for a Call page that targets the U.S. House of Representatives. If the user has a zip code in the database, ActionKit automatically assigns the user to a congressional district and shows the correct target. Zip code is required because the action can't be submitted if the user doesn't have a value saved in the field already.
Aside from fields required by the page Type, you decide which fields are required. By default, when you create a new page, zip is selected as a required field. We recommend requiring zip code so you know the user's congressional district and state but you can unselect it if you wish.
Validation¶
ActionKit reviews the data the user submits in certain fields for obvious errors and shows the user an error message if they need to correct the data.
- Email - The email address entered must include "@", followed by at least one letter, followed by ".", then at least two more letters. The minimum address that is acceptable is
a@b.cd
. This rule applies to emails entered in the user form and in the tell-a-friend box.- Zip - Zip codes must be 5 characters and if you have a separate
plus4
field, 4 characters are required in that field. Validation is done only if the country is the United States.- Phone - If the country is United States or if it's unknown, the phone numbers must contain at least 10 characters. Formatting characters such as dashes and parentheses are acceptable such as in the number (555) 555-1212.
Geocoding¶
ActionKit looks at the zip or postal code and address information submitted and does a couple types of geo-coding.
Address And Zip Clean Up¶
ActionKit validates address information as follows:
- If a user enters a 9 digit zip code, the zip is saved in core_user.zip and the other 4 digits are saved to core_user.plus4.
- If a user enters their address and city and a zip code that doesn't match, ActionKit will overwrite the zip code with a corrected version and add a plus 4 if we can determine the correct information.
- If a user enters their zip, but not an address, city or state, ActionKit will assign a state and a city if possible to the user. Usually a zip plus 4 is required to determine the city.
- If a user enters a value in a postal code field, the value is saved to core_user.postal. If the user country='United States', the postal code is copied to the
core_user.zip
field, and if provided, the core_user.plus4 field. In any case, the postal code field value is left as entered.- If you or an end user enter 'US' or 'USA' or several similar values these will be normalized to 'United States'.
Note
ActionKit does not attempt to determine city or region from a postal code in another country.
Legislative Districts¶
ActionKit uses address information to figure out which state and federal legislative districts each user is in and saves the results to the core_location table. This information is used by Petition, Letter and Call pages to determine the appropriate target for any user action.
When a user lands on one of these page Types, ActionKit looks at the core_location
table (which is updated upon address change). If the relevant district field is empty, ActionKit will display an empty user form.
Here's more detail on how ActionKit makes the district assignment:
- US Senate - Based on state, or zip code if the user hasn't entered a state.
- US House - Based on zip code. Many zip codes are split between multiple congressional districts. In those cases we determine the user's zip+4 using their address and then map that to the congressional district. If the user hasn't entered an address and is in a zip with multiple districts, ActionKit guesses based on which district has more people in the zip.
- State Senate and House - Here zip codes are most often split between multiple districts. ActionKit will not guess at state districts because it'd be wrong so often. If a user tries to sign a Petition to state legislative targets, ActionKit will assign them to the right target if their zip isn't split or if we have their zip+4 already. Otherwise, ActionKit will ask for their full address.
Note
ActionKit only runs the processing for the legislative district assignments where the user country='United States'.
Physical Location¶
ActionKit uses city, zip or postal code to assign a loc_code, which is saved in the core_location table. A loc_code is not assigned if country is the only available information. This loc_code is used for radius targeting in targeting recipients.
ActionKit also assigns a latitude and longitude to US or international users for whom we have a zip, postal or city. This is saved in core_location also. Lat/long is used to find events near a user.
Additionally, ActionKit uses the location to assign the user a time zone, which is recorded in the timezone field.
Values in core_location are updated upon address change.
How do I add a Page?¶
From the Pages Tab, you can create a page from scratch or starting from a model.
To create a page from scratch, click Add Page, and select the Page Type from the dropdown. To create from a model, click Page From Model and then select the model. The latter only works if you already have a model for the page type you want to create.
You'll land on the Action basics screen.
At the top is a link to the History, which will list all changes made to this page.
There are four steps for creating a page of most types:
- Action basics - Create the page and set basics like the name, tags, and type-specific info like advocacy targets. This is all information required for action processing, regardless of where you're hosting the page.
- Edit content - Select a Templateset to define the page's appearance and customize the user form. Enter content, or if you indicate that you're hosting the page on your own servers, we'll put some filler in for the content.
- After-action info - Define everything that happens after the user submits (again, regardless of where the page is hosted) including the landing page, thank you email, tell-a-friend and social media sharing, and after-action notifications.
- View on site - Proof and test the page. If you selected the checkbox to host your own page, this step is called Preview/get HTML and you'll see a button to download the HTML.
Petition and Letter pages have an additional step for setting up automated signature delivery. Whipcount pages have one additional screen for whipcount results. For events, you must create an Event Campaign, then the steps above are used to create Host and Attendee Pages.
Managing Your Pages¶
There are several features designed to assist you with managing your pages:
Default Settings¶
You can customize your instance's header, change various defaults, enable advanced functionality and more from the CONFIG screen.
The page-related defaults include:
Page Settings
Languages¶
Default Language: Select from the drop down of languages you've set up in your instance. We will use the translations you set up for the corresponding language for every new page and assign that language to each new email wrapper. You will be able to change both.
If you leave this blank, ActionKit doesn't assign a language to new pages. Actiontakers on a page with no language are assigned English. New email wrappers are also designated as English.
If you've set up English as a language in your instance and modified field names or system messages, you must select English here to have your modified language associated with new pages by default.
Show Multilingual: Change this to False if you would like to hide the language and multilingual campaign selection boxes on the Action Basics screen for all page types in your instance.
Page Analytics¶
Analytics Tag Code: If you use an analytics system, such as Google Analytics, you can use this field to paste in a bit of code (e.g., a "Google Tag"). If provided, this code will be automatically included in the page wrapper.html template.
If you have customized your wrapper.html template, you need to add the following to the bottom of this template if you want ActionKit to automatically add this code block:
{{ analytics_tag_code|safe }}
If placed in the wrapper.html of your template sets, ActionKit will automatically populate this with the Analytics Tag Code you have set in the site configuration.
Pages¶
Defaults apply to all new pages.
Media Prefix: Allows you to use Cloudfront to serve static files more quickly. Read more in the section on Improving Page Load Speed.
Preload Context: When this is enabled, the "context"--the URL ActionKit uses to determine if a user should be recognized, to get Representative info on a call-Congress page, and so on--is loaded earlier in the page than it would be otherwise.
Recognize Users Default: Choose always, once or never.
Redirect All Links: When this is disabled (the default) ActionKit doesn't use the /go/ redirector for links to action pages. If you run into a problem with users' clicks not being tracked, enable this setting. Read more about links and tracking.
Sharing¶
Default Share Image: Save a Default share image and it will be used as the Facebook share image by default before other images on the page, if any. You can override this choice for any page in the Sharing section.
Uploader¶
Always Use Fast User Fields Option: You can have the fast upload option enabled by default for new import pages.
Uploader: Choose whether newly created Import pages should have "Subscribe to list" selected by default. If unchecked, newly created Import pages will be set to "Don't change subscriptions".
User Generated Emails¶
User-Generated Emails: Sets the "from address" to be used for TAF emails and immediate signature delivery. The user's email is used for the "reply to" but the from must be in your domain to ensure delivery.
Donation Settings
Payment Accounts¶
Helpful if you are importing legacy donations via the uploader. To accept donations in ActionKit you must have a payment account with a vendor we integrate with. To add an additional payment processor, you have to ask support, but if you'd like to add payment accounts for imports or for the ActBlue sync, you can add them here. Click here to learn more about payment accounts.
Donation Processing¶
Duplicate Window: You can change the time period during which ActionKit will reject a 2nd donation in the same amount from the same credit card as a duplicate. This is set at 5 minutes by default. You can disable duplicate detection by setting it to zero, although we don't recommend this since users will sometimes hit the submit button twice in a row.
Send IP Address: Irrelevant for Payflow Pro and Authorize.net since they always capture the IP address.
If you're using Braintree, you can send the IP address along with each one-time donation.
Warning
You must create the
customer_ip
custom field in the Braintree gateway prior to enabling the option or ALL donations will fail.
Admin Recurring Update¶
Braintree only.
Collect Card Code: If this is true, we will show the CVV on the form for updating recurring donations in the admin UI. If it's false, we won't.
This should correspond to the setting at your Braintree Gateway. If you require CVV at the gateway, you'll want to expose it on the form.
Donation Page Defaults¶
Defaults set here will be pre-selected for every new donation page created in your instance.
Allow International Addresses: If enabled, new pages will have the allow international addresses box checked. Country field is added to the user form and zip or postal shows based on the country selected by the user. Postal is not required. Note: If you use PayPal or Authorize.Net as your processor, you still need to disable their AVS verification or you will not be able to accept international addresses.
Minimum Amount: The number entered here is used for new donation pages and also new recurring donation update pages.
Payment Account: The account chosen here will be the default payment account for new donation pages.
Suggested Ask Formula: The suggested ask formula chosen here will be the default formula across your organization for new donation pages.
Recurring Retry¶
ONLY RELEVANT if Braintree is your merchant vendor. This is not applicable to ACH direct debit recurring donations, which are handled directly by ActionKit.
Each merchant vendor handles recurring donation processing slightly differently. This includes recurring donation retries. Find details about recurring donation processing and data capture.
When a user with an active recurring profile misses a payment, the merchant vendor will try again. When and how often varies by vendor and is often something you can customize for your account.
By default, Braintree accrues missed payments toward a recurring profile. This can lead to a nasty surprise for some of your most valuable donors if their payments fail for a few months and then succeed (for a total that includes the missed months). Alternately, you can change your settings in Braintree so all retries are completed before the 2nd payment comes due but this costs you money, as some of the later attempts would be successful.
ActionKit's Recurring Retry settings provide a workaround that allows you to establish a custom retry schedule without ever billing the user for more than their monthly commitment. Setting up Recurring Retry requires steps in ActionKit and in Braintree.
1. Configure Recurring Retry in ActionKit:¶
To enable this, click Edit on the CONFIG screen next to Recurring Retry, then click Enable Retries. Enter a max retry number and a retry interval. For example, you might pick 4 as the max retry with an interval of 10 days. ActionKit will prompt an attempt to bill the user's credit card for their monthly total 10 days after the initial failed payment, then 20 days, 30 days, and the last retry will be at 40 days.
If you set Cancel After Retries to True, we’ll cancel the profile at Braintree and set the status at ActionKit to canceled as well. If this is set to False, the profiles remain active unless you manually cancel them at Braintree or through the ActionKit API.
2. Configure Braintree Gateway:¶
We recommend setting the following Recurring Billing Options in the Braintree gateway:
- Automatically retry failed transactions: checked
- After a subscription is past due, retry the subscription after: 1 day
- If above retry fails, try again after: 1 day
- If above retries have failed: Leave the subscription past due
Having Braintree's automatic retries on allows the "leave subscription past due" behavior, which is what prevents accrued monthly billing from occurring. This does mean Braintree will attempt two retries, but with the above settings, they will complete before ActionKit retries begin (which have a minimum interval of four days).
If you've configured Braintree as described, no further attempts will be made after the max retries have been attempted. If the charge is processed at any point, no further attempts are made and there is no balance due.
ActionKit retries are recorded in the core_transaction table with a type of 'retry'. Each 'retry' row will have a status of 'success' or 'failure'.
Pages Dashboard¶
On the Pages Dashboard you can toggle between Recent Pages, Multilingual Campaigns, and Models.
The Recent Pages view displays the page type and action count for the page by default. You can change the action information displayed by editing the Page Mini-dash report.
Note
The counts on the dashboard are cached. You can double click on a count to update it but otherwise it updates every few minutes.
Select Browse All or Browse By Type buttons at the top of the Pages dashboard to see a full list of all pages or pages of a certain type, respectively.
Summary Data¶
The following information is displayed for each page on the dashboard: short name, title, page id, page type, action count and available actions. - name given at page creation for page url. In most cases, the action options are Edit, Copy, View, and Hide.
Browse All And Browse By Page Type¶
The Browse All button displays the full list of all pages. Alternatively, use the Browse by Type or use the search box and the built in filters to view a list of specific pages on this screen.
These screens displays the same Summary Data as the dashboard.
From these listings you can:
- Filter pages by type, tag, language and model status using the toolbar on the right.
- Search short names and titles and sort the list by specifying Order By and Descending or Ascending and clicking Search.
- Show hidden or disabled pages by clicking Show Hidden. Hide a page by clicking Hide.
- Create a new page by copying an existing page.
- Bulk edit pages to show/hide pages or add/remove tags from pages.
Advanced Search¶
Advanced Search provides considerably more options than browsing all.
To perform an advanced search:
When browsing all, click the Advanced Search button at the top of the results page; or click the Advanced Search button from the Pages tab.
The default is All records which will show you all the pages in your database. To limit this Add a Filter by selecting from the dropdown. You can set a sort order if you'd like. Then click Search.
Filter Options
The filter options are taken from those found in the Pages query builder. All filters include some common controls:
- Click on the × icon to remove a filter.
- Click and drag the ≡ to change the order in which the filters appear.
- To exclude rows based on a filter, click on the green Required button to toggle it to Excluded.
Many filters include variables that you can adjust. You'll see these as soon as you select the display.
For example, if you select the display type Number of Actions, you'll see a dropdown with All Actions selected by default. You can change this to:
- Completed Actions - only those with a "completed" status in core_action.
- Non-Spam Actions - only those not designed status="spam" in core_action; only relevant if you've enabled spam checks.
- Spam Actions - only those with a "spam" status in core_action, only relevant if you've enabled spam checks.
You'll also see options for restricting the time period of the actions (e.g. today, last year, custom range, etc.) and specifying the action count.
To see a list of the choices and the corresponding SQL for any of the available filters, view the Query Builder SQL Reference.
There are some filter options in the query builder that aren't here (e.g. SQL expressions and row limits). Also, blank fields are treated as empty values instead of as parameters.
Bulk Editing¶
For Pages, you can hide pages, show hidden pages, add and remove tags from pages in bulk.
Hiding a page disables it. If a user goes to the URL for a hidden page, they’ll see a “Sorry, the URL you tried to load doesn't exist” error. This is true for all hidden pages, whether they’re hidden individually or in bulk.
Be especially careful hiding unsubscribe pages. If the unsubscribe page is used in one of your mailing wrappers, your mailing may fail and in any case, the page won’t be reachable, leading to irritated users marking your mailing as spam and quite possibly cats and dogs living together.
To bulk edit:
1 From the Browse All screen (or from the Event List screen for events), click on the “Bulk Edit” link in the top left next to “Show Hidden”.
2 Choose the items that you want to apply the action to -- you can click to select specific items, or select all items visible on the screen.
3 Click the Save button, review the count of objects to be changed, and confirm.
You’ll then see a reportback with the number of changes actually made. This may differ from the preliminary count if, for example, an object you try to apply a tag to already has that tag.
Page Type Specific¶
One-click (Petition)¶
In the Options section, click if you'd like to Enable One-Click Signing. This turns on a shortcut for recognized users, who sign the petition simply by clicking the link in a mailing, without entering any information. These users are directed automatically to the thank you screen and their action is recorded in the core_action table.
One-click signing makes it easier for a user to take action, increasing action rates. But it's important to make it clear to users that they sign by clicking the link in the email.
Users who aren't recognized will see the standard petition page with the content you entered and a blank user form.
And the one-click link only works once - subsequent clicks on the link take the user to the petition page to submit an action, just as they would for pages without one-click enabled.
Warning
You cannot use one-click if you are hosting your own pages.
Signature Deliveries (Petition & Letter)¶
You have several options for delivering your signatures to your target(s). Petition and Letter pages have an additional step where you can configure automated delivery by email, fax (if you have an InterFax account), or via the Communicating With Congress integration for pages targeting the US House.
You also have two non-automated delivery options. You can use the bulk delivery system to send manually when you wish, or generate a PDF for in-person delivery.
Fallback Page (Call)¶
If you're targeting a state or federal legislator and a user who lives outside the district(s) lands on the call page they'll see a message saying 'This action isn't available where you live'.
Or, you can designate a fallback page to provide an alternative action for these users. For example, if your call page targets the two CA Senators, a user from NY could be directed to a related petition if you enter the petition URL here.
If you enter a fallback URL, be sure to test it. You can do so by entering a zip code that's outside the district of any of the targets you selected for your call page.
The fallback page isn't used if your target doesn't have a jurisdiction in ActionKit. This includes the US President and custom targets without a state or country jurisdiction assigned.
Whipcount Responses (Whipcount)¶
Whipcount page creation includes an extra step called Whipcount Responses. This is where you set the source you'll use to determine the targets' positions and some related settings.
First you pick a Result Source. The choices are:
- User submitted - If you select this option, all targets will show Unknown, call now! in the stance column until enough users submit the same response, according to the choices you make in the User Submitted section.
This option is selected by default when you create a new page because this is the standard approach to whipcount campaigns.
- User submitted with admin overrides - This option is the same as user submitted, except that you can set the position yourself, instead of using the data your users provide, for one or more targets. You do this in Whipcount Response Overrides.
A use case for this option is if you've got staff meeting with legislators and you want to override the stance submitted by users where it doesn't match what you've heard directly from the legislator.
- Admin configured - If you select this option, you should set overrides for every one of the page's targets. If you don't set an override for one or more targets, they'll show Unknown, call now! no matter how many calls are made.
This option is most useful if you want to create a thank and spank action.
User Submitted¶
Here you set two parameters that control which results are shown to users:
- Minimum calls - Minimum number of reported calls before results will be displayed. Avoids one user controlling all the results.
- Minimum response agreement - Percentage of calls that must agree before results will be displayed. Use to improve your confidence in the reported results.
Once the responses for a target meet these minimums, the target's row on your page changes color (red or green) and the stance column changes to Supportive or Opposed as appropriate.
This section is not shown if you choose Admin Configured.
Whipcount Response Overrides¶
When you want to set the stance for a target yourself, just select the target from the dropdown on the left then select the appropriate stance.
Select Edit all target responses at once. to see a screen where you can scroll through the full list of targets and set overrides instead of selecting each target one by one.
Once you set an override, the target's row on your page changes color (red or green) and the stance column changes to Supportive or Opposed as appropriate. Users can still call the target, but the responses they enter will never change the result for a target with a response override.
Whipcount Redirect URL (Whipcount)¶
You can easily ask your users to make multiple calls. The whipcount template in the Original Templateset has some special code that you can trigger by setting the Redirect URL on the After action screen to the Whipcount page's URL. If you do this, the user will see thank you text, followed by the list of results so they can select and call again. Edit the template to change the thank you text.
User Signature Template (LTE)¶
When your user submits an LTE, ActionKit appends their contact information and emails the letter to the newspaper chosen.
Using the default user signature template, the user information, or signature, looks like this:
First Last
Number Street
City, ST Zip
(XXX) XXX-XXXX
You can change the format by creating a new user signature template and selecting it from the drop down in the User signature section on the Action basics screen. You add a new template by clicking the :green: + or under Other on the Pages Tab.
The default user signature template looks like this:
{% if user.first_name %}{{ user.first_name }} {% endif %}
{{ user.last_name|default_if_none:'' }} {{ user.address1|default_if_none:'' }} {% if user.city %}{{ user.city }}, {% endif %}
{% if user.state %}{{ user.state }} {% endif %}
{{ user.zip|default_if_none:'' }} {{ user.phone|default_if_none:''|format_phone }}
Snippets can be used in signature templates. They are not clickable so you need to cut and paste the snippet into the template. Use snippets to include information like occupation in the signature by creating a custom user field for occupation
and adding the field to the user form in the LTE template. Then add {{ user.custom_fields.occupation }}
at the bottom of the signature template.
Take action using the email address you use to log in to the admin UI to view a sample letter as it will appear to the editor. This is particularly useful if you customize the signature. The email will start "This is a preview of the message that would be delivered" and include the content you entered in your letter. To submit an LTE to a paper yourself you must submit with a different email address.
Newspaper Types & Phone Numbers (LTE)¶
You can select which types of newspaper you'd like your campaign to target:
- National (papers with circulation greater than a million),
- Regional (circulation between one hundred thousand and a million), and/or
- Local (circulation less than a hundred thousand).
Make sure to check at least one paper type!
If a user submits a letter to a paper, then comes back to the same page to send another LTE, only the papers the user hasn't sent to will display.
Display Phone Numbers (LTE)¶
When enabled, this feature will display the phone numbers of the newspapers.
LTE User Form Fields (LTE)¶
Address and phone number are required for LTE pages. Most newspapers of any type will not consider letters without these. The Customize Fields section is still accessible on the Edit content screen because you can add additional fields.
Users who are following a link from a mailing will see a blank contact form unless we already have all this information in the database.
Canned Letters (LTE)¶
LTE Pages have an additional section on the Edit content screen where you can provide your users with pre-written letters to use as inspiration.
Papers which get obvious form LTE submissions are not likely to publish them so you may want to include obvious prompts in your canned letters, like [INCLUDE YOUR OWN EXPERIENCES WITH ISSUE X HERE]
. Alternately, canned letter paragraphs can be a series of prompts, like 'When I heard about Senator X's stance on the jobs bill, I... '
By default, we provide space for up to three canned letters, but you can add more.
Question Builder (Survey)¶
The Edit content screen for Survey Pages includes the standard introduction and thank you text boxes, and is also where you compose your survey questions.
In the top-right corner of each question area is a Sort handle, which you can drag to rearrange the order of the questions in a survey. There's also a checkbox here for deleting a question. Check the box and submit to complete the deletion.
Type your question in the Question Label box, just as you'd like it to appear on the page (including a ? if you want one to display).
Choose a type of user input field in the Question Type menu:
- Custom HTML
- Keyboard Entry
- Text
- Number
- Single Selection
- Select Menu
- Radio Buttons
- Multiple Selection
- Checkboxes
- Multi-Select List
- Upload
- File Upload
The selection of a "question type" determines which other fields are visible.
Structured Question Types¶
If you choose any question type other than Custom HTML, you will see these two options:
- Field name: Enter the name under which user responses will be saved in the core_actionfield table and displayed by the survey downloader. The name should only include letters, numbers, and underscores (no spaces or other characters).
- Required: If you check this checkbox, users will not be able to submit the survey without entering a value for the question.
There are some additional options which show up only for certain question types:
- Text: You can set the field width and height if you'd like to override the defaults set by the templateset you selected for this page. You can also enter text in the placeholder box to give user's additional guidance on what to enter.
- Number: You can set the field width and a range for accepted responses. If a user submits a number outside of the range they'll see an error message. This is not supported in all browsers.
- Single or multiple selection types: Use the Values box to enter choices for the user to select from. Enter one or more values, each on their own line. Optionally, you can use an equals sign to separate a code and a description, like "Y=Yes", to store the code value in the database while displaying the more descriptive text to the user. (You can also use an equals sign on a line by itself to create a blank item in a select menu.)
- File Upload: You can choose which types of files users can upload, and specify a directory name to use when the files are uploaded to your S3 bucket.
Custom HTML Fields¶
If you choose "Custom HTML", you will see a Question HTML box to enter the HTML markup that will be shown to the user and collect their response.
There are several requirements that must be met for the Question HTML or your page will not function correctly. See examples below.
- Response options must be written as HTML. You can provide the user with choices in a drop down menu or checkboxes, or you can create a text field where users can enter a free form response.
- Response options must specify the name you'd like to assign to each question. The name can only include letters, numbers, and _ (no spaces or other characters). You don't define the name first.
- Response options use the correct syntax when naming the input fields:
name="action_QUESTION_NAME_HERE"
.
Warning
If you are using a Custom HTML question, user responses will be permanently and silently lost unless your input fields include the question name with action_
in front of it (for example, name="action_QUESTION_NAME_HERE"
).
Please test your data capture by submitting a response, downloading the results at Reports > Download a survey, and checking for your response.
Advanced Examples¶
For examples of some cool things clients have done with surveys, including requiring certain questions to be completed, saving responses in a list format, or shuffling the order in which questions are displayed, see the examples in advanced templates.
HTML Examples¶
Here are two examples of questions, each shown first as a structured question type, and then using equivalent custom HTML:
Question label: "What was the first record album you bought yourself?"
Question type: Text / Field name: album / Field size: 50 spaces wide and 1 rows high
Custom HTML:
<input name="action_album" type="text" size="50">
Question label: "What's your favorite color?"
Question type: Select / Field name: color / Alternatives:
= red green purple
Custom HTML:
<select name="action_color"> <option></option> <option>red</option> <option>green</option> <option>purple</option> </select>
Minimum Amount (Donation)¶
Users will not be able to make a donation in an amount less than your minimum. Often this is set to an amount that just covers the transaction fee charged by your vendor.
Payment Accounts (Donation)¶
To accept donations in ActionKit you must have a payment account with a vendor we integrate with. You can accept credit cards through ActionKit donation pages with a traditional merchant vendor account with Braintree, Authorize.net, PayFlow Pro or PayPal. You can also accept PayPal payments where the user logs into their own PayPal account and pays with their preferred method with a standard PayPal account.
ActionKit records each donation and generates a request to the vendor, asking them to process the donation and deposit the funds in your bank account. We also provide an interface for prompting changes (like refunds), so these are captured in your ActionKit database as well.
PayPal (Donation)¶
Note
This section references PayPal's standard payment product, not PayPal's PayFlow Pro.
ActionKit's PayPal implementation offers support for both traditional CC processing (like that provided by Braintree, Auth.net and PayFlow Pro) as well as paying via PayPal accounts. Users set up their PayPal accounts to use whatever payment method they prefer (e.g. credit card, bank account). When users pay via PayPal accounts they are redirected to the PayPal site and then back to ActionKit after they approve the payment.
Read more about our PayPal integration.
Suggested Ask Formula (Donation)¶
You can customize the suggested donation amounts shown to a previous donor based on that user's giving history.
Recognized users will see a suggested donation and any larger amounts you enter on the Edit content screen. You define the formula used to set the suggested amount, basing it on the donor's highest previous gift, 2nd highest gift, average gift,most recent gift or total over a particular time period. Imported donations are included.
You can also insert the same ask amount in a mailing using the suggested ask Snippet in the mailer.
To read more about defining the formula used to set this amount, read Suggested Ask Rules.
Allow International Addresses (Donation)¶
If you wish to accept credit card donations from users with international addresses, you must:
1 Select the Allow international addresses checkbox.
2 Turn off AVS with your merchant vendor.
3 Modify your donation page template to include country.
International addresses will not be accepted unless you've completed all three steps.
Donations must still be in U.S. dollars unless you are set up to receive donations in other currencies as outlined below.
ActionKit still requires state and zip if the user selects the United States as their billing country. Neither postal nor region are required if the user selects any other country.
Users with JavaScript will see the correct fields when they switch countries. Users without JavaScript will see all four fields (region, state, zip and postal) all the time but if they fill out extra fields they will be ignored.
Accept ACH Payments (Donation)¶
If you use Braintree as your merchant vendor, you can accept transfers from U.S. bank accounts using ACH Direct Debit. Before you can process these payments, you will need to do some setup as described here.
Accept Foreign Currencies (Donation)¶
To accept donations in other currencies you need to use Braintree as your merchant vendor. You'll need to do some additional set up with Braintree for each currency you wish to accept. Then you can create Donation Pages, send mailings, generate reports, etc. using the currency. The set up is similar to using other languages; donation campaigns will generally need distinct Pages and mailings per currency. Details, including how to get started are at currencies.html.
Products (Donation)¶
ActionKit provides basic support for product sales and give aways. Products can be premiums, merchandise for sale, or something less tangible (for example, 'adopting' an endangered tiger).
Products are used with donation pages. If you have set up any products, you'll be able to select them in the More options section on the Action Basics screen when you create your page.
The default layout offers users options to select a product and to make an additional donation. You can change the layout, offer products with no option for an additional donation, or allow users to donate without selecting a product on a page with products by editing the donate.html template.
Our product system is not designed to function as a storefront. If you need shipping and tax calculations and fulfillment tracking, we recommend using an external storefront and integrating the data using our API.
Candidate Donations (Donation)¶
Use this option to create bundling pages for candidates. You need to add Candidates first before they'll be available for inclusion on a Donation page.
The end user fills in the amount they'd like to give to each candidate and there's an option to make a regular donation to your organization.
In the Original Templateset, employer and occupation are automatically required for Pages with candidates. PACs can easily copy the code to require these fields everywhere or you can use it to adapt your Templatesets for bundling for non-federal races with different rules.
Fraud Filters (Donation)¶
Fraudsters will sometimes use Donation Pages to test whether stolen credit cards are functional or not. These carding attempts can incur transaction and chargeback fees for your organization.
Clients who use PayFlow Pro, Authorize.net or Braintree as their payment gateway can set global- and per-page fraud limits.
The fraud scores are generated using the MaxMind minFraud service. We incur a small charge for each fraud score calculated, but do not pass that charge along to you.
MaxMind looks at a lot of factors: whether the user's IP address is that of a known fraudster, whether the country of the card issuer matches the user's current location, HTTP request headers that can help tell automated scripts from real users, and more.
The filters can reject some real donations although the benefit of avoiding fraud may outweigh any donations lost, especially if you're having a problem with fraud.
The filtering process logs details to the core_donationattemptlog table, where you can review exactly how many attempts were rejected and the details of the rejections.
By default, ActionKit blocks donations from IPs in 5 high risk countries: Brazil, Estonia, Ghana, Nigeria, and Vietnam. If any of those are high value for your organization, we can remove those countries on a per-client basis. Note that this comes with an increased risk of carding attempts, which can incur transaction and chargeback fees.
Read more if you want to enable fraud filters for your instance.
Donation User Form (Donation)¶
Unlike other page types, donation pages do not use the user form template. Instead the form is part of the donate template.
Donation pages always require the user to enter all of their contact information. By default they do not require the credit card CVV, if you use Authorize.net or Braintree, and you've changed your settings so this isn't required by your merchant vendor. It is required by default by both vendors, so if you remove it from your ActionKit form without changing your settings, donations will fail.
Note
Always test changes to your donation templates by making real donations through a donation page that uses the template with the changes. This is the only way to be sure relevant donation pages are still working.
Amount Options (Donation)¶
You can select an amount as the default, which means it will be pre-selected on your page.
If your page also uses a Suggested Ask formula, here's how these amounts and the Suggested Ask amount interact:
- For users who aren't recognized by ActionKit, the donation amounts entered here will be displayed. Read about which users will be recognized.
- For recognized users who have never given, the Suggested Ask amount is used in place of the lowest amount on your list. The amount under Make ask amount in the Suggested Ask Conditions section for the top row is used.
- For recognized users who have previously given, the Make ask amount column shows the lowest suggested donation that will be shown to all users with a total less than the amount in the first column for whichever criteria you select (e.g. Highest Donation); all larger donation amounts entered here will show as well.
For example, if your formula is based on the donor's Highest Previous Contribution (HPC) and the user has an HPC of $150 and the suggested ask is $175, the amounts shown on the page will be $175 and any donation amounts that are larger.
- There is an exception to this rule. If the donor would only see one or two donation amounts on the page because the Suggested Ask is higher than all but one donation amount, ActionKit will display all of your donation amounts (just as if the user wasn't recognized).
For example, if a user has an HPC of $1000, the Suggested ask amount is $500 in the default formula. If the largest donation amounts entered in this section are $500 and $1000, the user would only see two suggested amounts. Instead they will see all the amounts you enter in this section.
Recurring Donations (Donation)¶
A Recurring Donation is a commitment your user makes to give a donation automatically on a regular basis, like monthly. Through ActionKit you can accept recurring donations by credit card, US bank transfer (ACH Direct Debit), or from the user's PayPal account. You must sign up for recurring billing with your payment processor. Most payment processors consider recurring billing a distinct product from one-time payments. ACH Direct Debit recurring payments are handled directly by ActionKit, but you must sign up for the ACH beta program with Braintree.
By default, users are charged on the same day of the month each month by the merchant vendor. ActionKit will show the payments immediately or the next day, depending on which merchant vendor you use.
By editing your Donate template and depending on your merchant vendor, you may be able to adjust the billing date (e.g. to the 1st of each month) or change the frequency (e.g. to weekly or yearly). You can also edit your template to create a recurring only page.
Default Page (Unsubscribe)¶
One unsubscribe page will be used as your organization's default, which means it will be automatically included in email wrappers. You can link to a different unsubscribe page by editing the wrapper or you can change your default unsubscribe page. All wrappers must link to an unsubscribe page.
Just select Use In Mail Wrapper under Unsubscribe Options on the Action basics screen for the page you want as the default. This will replace whatever page was previously selected as your default unsubscribe page.
Data and Reports¶
Data Capture 101¶
Table Structure¶
Most tables include a field called "id", which is a unique identifier (e.g. id is a field in the core_user table that goes up by 1 each time a row is added). Other tables that include the same field reference it using part of the table name (e.g. user_id is a field in the core_action table that tells you to look in the core_user table under that id to find out who took a specific action).
Most tables include a created_at field that shows the timestamp in UTC when each id was added to the table. Many also include an updated_at field, which shows the last time information in this table was updated.
This table shows the relationships between key tables.
Users¶
A user is a unique email address. ActionKit doesn't have any concept of a person. It isn't possible to have a user with two email addresses or two users sharing an email address.
Anytime a new email address is entered on a page, a row with a unique id is added to the core_user table. A row is also added to the core_action table. The value in the created_user field is "1" if the email address is new to your database. The value in the core_action source field will be saved to the user's source field in the core_user table. See Action sources for more information.
User Info¶
Basic information about each user is saved to core_user, including email, name, address, and language.
Address info entered by the user is saved after address and zip clean up. If possible based on the address info entered, Legislative districts and physical location values are saved to the core_location table.
Phone numbers are saved in core_phone. You can include phone
and/or mobile_phone
as a field in your user form. ActionKit will automatically write the user entry to the core_phone table with phone type 'home' or 'mobile', respectively.
Any contact information submitted using an existing email address will be saved under the user id associated with that email address. New information overwrites existing information (for example, if an existing user enters a new address it will overwrite the old address), except:
- A contact field (such as, name, address, zip, etc.) with data is usually not overwritten with a blank.
- But a blank is saved over existing data for an address, if the user enters a new zip and a blank address. We save the blank because usually this means that the user has moved to a new zip code and the old address is bad.
New address data is saved in core_user. The old address is saved to core_useroriginal.
Users And Lists¶
When a user takes action, the user is added to the mailing list associated with the page if they are not already on it. The subscribed_user
field in the core_action table will equal 1 if the user is new to the list.
List membership is recorded in the core_subscription table. Only users who are subscribed to at least one list are in this table. Each user has one row for each list they are on, so if a user is on three lists, that user will have three rows in this table.
If a user is subscribed to at least one list, the value in subscription_status
in the core_user table is subscribed
. Only users with this status can be mailed through ActionKit. Other possible statuses are unsubscribed
and bounced
.
Every change in the user's list membership and subscription status is saved to the core_subscriptionhistory table. This table shows the type of change (e.g. subscribed by an action on a page, subscribed through the uploader, unsubscribed by marking a mailing as spam, unsubscribed by a staff user). Not all changes in a user's status and list membership are the result of an action on a page, but most are and these show the action_id
associated with the change. See Data capture details for more information.
Pages¶
Pages are created through the admin interface or the API. Basic information about each page is saved to the core_page table with the page type, name and title, creation and last update dates, as well as some basic settings like list_id
and whether the page is hidden. Page content is saved in the CMS tables.
Actions¶
An action is created when a user submits on a page, when you process an action using the API, and for each row you successfully import using the uploader.
For each action, a row is added to the core_action table with the user id, page id, timestamp, and action source . You can see a history of every action taken by every user in this table.
If a page does not allow Multiple responses and a user submits more than once, later actions override the first action instead of creating additional ones.
Action And User Fields¶
There are two field types you can use on any page to capture additional data:
- Action fields - Designed for uses like survey questions, where you may want to capture multiple responses per user. The field name, the user response and the
action_id
are saved to core_actionfield each time an associated action is saved. See Survey data capture for more information.
- Custom user fields - Designed for information you want to associate directly with a user, where you want the value to be overwritten with new entries (for example, occupation). The field name, the user response and the
user_id
are saved to core_userfield; the old response is overwritten every time the user submits a new response. See custom user fields for more information.
General Reports¶
Compare Pages¶
Select one or more pages and view this report to compare the following statistics for each:
- Total Actions
- Total Donations
- Avg. Gift
- Total People
- New Members
- Total Clicks
- Conversion Rate
Download Actions¶
You can download a CSV of all actions on any page using the Action downloader. By default the report includes the user_id, action timestamp and any actionfield values. You can append user information and limit the time period for the results returned.
Action Rates: Monthly Progress¶
View action rates to see actions by subscriber and in total per month.
Page Type Specific Data¶
Petition And Letter¶
Each time a user adds comments to a petition they are saved to a row in the core_actionfield table (associated with the user's action in the core_action table). The field is named comments
.
The letter the user submits, with or without edits, is saved to the same field.
You can see a list of the comments by running the Comments by Page report.
Call¶
When a user submits on a call page, a row in core_callaction_targeted will link the action to the target. If the user checks who they called, there'll also be a row in core_callaction_checked.
If a user fills in the user form and submits, but then doesn't submit on the call screen where we show the phone numbers and script, an action is still added to the core_action table, but the status is set to incomplete.
For your convenience there is a Call Page Dashboard report which displays the number of actions submitted on a call page by advocacy target.
Whipcount¶
Call results are captured in core_whipcountactioncalled. The table shows the target_id
, the action_id
and the response
recorded for the target's position. Joined to core_target for information on the target for each row and core_action for the user_id
of the person who made the call.
LTE¶
Use the LTE downloads report to download all the letters written for a particular page. Use the LTE basics report to see summary counts for a particular page, including # of letters, # of users, # by state, and # by newspaper.
Survey¶
As with other pages, every time a user submits on a survey page an action is created. The user's responses are associated with the action, not directly with the user. The id of the user's action on the survey page is the same as the parent_id
in the core_actionfield table. The name of each question is saved to core_actionfield.name
while responses are saved to core_actionfield.value
.
Users may submit more than one value for the same field. For example, when you are using checkboxes or a multiple select.
Users can also take action on a survey page more than once and each time the responses will be saved.
The question and the response are saved together as users take action. As a result, the names in the core_actionfield for a particular survey page will not include every question name until every question has been answered at least once. Questions to which no one has responded won't show up in the table, nor will they appear in a downloaded CSV of the survey results. If you submit a response with every question filled in, the download will include every possible field.
You can download survey responses using the action downloader, which will include a column for each question.
Donation¶
Donations in ActionKit are a type of action so all the standard action data like user_id, page_id, and action source are saved to the core_action table for each donation attempt.
Donations are more complicated than other action types though and a number of tables are involved. A row is also added to the core_order table with donation specific information including the amount. If the donation was processed through ActionKit (not imported) a row is added to core_transaction with information from the merchant vendor if the transaction failed. If the donation was imported, a placeholder row is added to the core_transaction table with the account field set to import.
A row is added to core_orderrecurring when a new recurring commitment is created.
Read about the information available in each table and how to view specific donation categories (failed attempts, product orders, recurring donations, etc.) under data capture details.
The following donation reports are built in:
Unsubscribe¶
The Unsubscribe Reasons report shows comments left by users in response to the question 'Why are you leaving?', if your page includes that. The results are stored in a custom action field associated with the unsubscribe action.
QA Your Page¶
This section contains the follow topics:
Testing Overview¶
As soon as you save a page in ActionKit it’s "live", meaning any user who ends up at the URL can see the page and take action. Of course, users generally don’t find a page unless you’ve shared it by sending an email or linking to it from your website or sharing it on Facebook or another public forum.
Always test a page before you share it with your users and again if you make changes.
You may want to do additional testing for specific cases.
If you’re using a new, untested templateset, your testing should be more extensive and involve multiple browsers. Read about templateset testing here.
For most page types, when you test your page, your actions are recorded just as your user’s actions are. You can confirm that the data you entered was recorded in the database.
Finally, you may want to check optional elements you’ve included like snippets and taf.
Snippets Testing¶
If you use Snippets on one of your content pages, you may want to view the page as a few different users.
For example, say you’re asking a small group of top members to take part in a whipcount calling campaign in advanced of an important vote. You want to with "Dear first_name" with a fallback to "Regional Leader" if the user doesn't have a first name in the database. You click to insert the first_name
Snippet in the Introduction text box and then delete the "Friend" default text, intending to replace it with "Regional Leader", but you get a call and forget to replace it. If one of your targeted users doesn’t have a first name in the database, they’ll just see "Dear" in the introduction.
In this case, you might want to check what the page will look like for a few of the regional leaders you’re emailing about the action.
You have several options for viewing as a recognized user.
TAF Testing¶
The tell-a-friend functionality is built into the templateset, so if you’re using a set that’s already been tested it’s usually sufficient to simply view and the proof TAF message for your page.
However, it never hurts to test this and viewing the actual TAF email is the best way to confirm that you included the correct action page URL.
Test this by:
1 Fill in an email address for an account you can check. This can be the address you just took action with.
2 Submit the tell-a-friend.
3 Go to the inbox for the email you just used and make sure you received the TAF and that the link you included takes you to the correct page and includes a referring akid and source. It will look something like this: http://docs.actionkit.com/?referring_akid=.1.qgzMpZ&source=taf
Data Capture Testing¶
As with TAF’s, the functionality that records an action and the associated data is built into ActionKit and generally can’t be "broken" by changes you make while creating a page. (Although this is one reason you need to test new templatesets).
Data capture testing is still a good idea and particularly important for survey and donation page types. We’ve outlined more information about how to check the data under the page type in Testing Protocol by page Type.
The query below is useful for confirming basic data capture for any page type:
SELECT cu.first_name, cu.last_name, cu.zip, ca.created_at as action_date, ca.source as action_source
FROM core_user cu
JOIN core_action ca on (ca.user_id=cu.id)
JOIN core_page cp on (cp.id=ca.page_id)
WHERE cp.name={page_name}
Viewing As A Recognized User¶
When you follow a link in Pages to view a page, you see what the page will look like for a user who isn’t recognized. Most often an existing user will follow a link in an email from you to reach your page and ActionKit will recognize the user.
For most basic testing, you don't need to view the page as a recognized user. But here too, when you've got a new templateset or you want to test something specific, you may want to see what a recognized user will see.
You have two options:
- You can create your draft email and send yourself proofs. Follow the link to the page in the proof to view the page as the user specified in the to line of the proof mailing.
Or
- Search for the user by name or email or other criteria from the Users tab. Click through to the user record. Copy the akid shown under the user name. Return to the URL of your page. At the end of the URL, after the final "/", append "?akid=" and paste the token. The URL will look like: "http://docs.actionkit.com/?akid=.1.qgzMpW". The page will show what this user will see if they follow a link to the mailing. You can repeat this for as many users as you’d like.
In either case, you should be careful submitting. ActionKit thinks you are the recognized user, so if you submit, an action will be recorded in the recognized user’s name and they’ll receive a Confirmation Email if you’ve set that up for the page.
If you want to view the Snippets on the thank you screen or a Confirmation Email for a user aside from yourself, it’s best to do that as another staff user.
Testing Protocol By Page Type¶
Signup Testing¶
Signup pages are the most basic.
1 View the page by clicking View for the page in the Dashboard or the Browse All listing, or by clicking View on site on the page edit screens.
2 Proof the page and check the appearance. Hit the back button and then select the appropriate step at the top of the screen to make changes.
3 Fill in your contact information and submit. If you’ve changed the required fields you can try submitting without information you expect to be required. You should see an error message like
Zip required
.4 View and proof the thank you page.
- If you entered a Redirect URL in your page, confirm that you land on the correct page.
- If you enabled tell-a-friend, proof the tell-a-friend subject and message. Send yourself a tell-a-friend to confirm the functionality.
- If you entered a goal, confirm that a thermometer is displayed and that the goal is correct. Results are cached briefly so it may be a few minutes before the action count on the thermometer increases.
5 Check your inbox for a Confirmation Email if you enabled this option. If you haven’t received one you should:
- check your spam folder,
- return to Confirmation Email set up and confirm that this options is enabled.
If this condition persists report a bug through the ActionKit support form.
6 Proof and test links in your Confirmation Email (if there are any).
Petition And Letter Testing¶
Petition and letter page testing has an additional step for signature delivery.
1 View the page by clicking View for the page in the Dashboard or the Browse All listing, or by clicking View on site on the page edit screens.
2 Proof the page and check the appearance. Hit the back button and then select the appropriate step at the top of the screen to make changes.
3 Fill in your contact information and submit. If you’ve changed the required fields you can try submitting without information you expect to be required. You should see an error message like
Zip required
.4 View and proof the thank you page.
- If you entered a Redirect URL for this page, confirm that you land on the correct page.
- If you enabled tell-a-friend, proof the tell-a-friend subject and message. Send yourself a tell-a-friend to confirm the functionality.
5 Check your email for a Confirmation Email if you enabled this option. Proof and check links (if there are any).
6 If you enabled a signature deliveries option on your page, and you took action using the email specified in the delivery section (the one you used to log in to the ActionKit admin) and that email is in the target's district, you'll receive an example email. The subject line of the email will contain the prefix "[Batch delivery proof]" or "[Fax delivery proof]". "This is true for immediate and batch delivery. Any conditional content, like a comment, will be taken from your action.
Call Testing¶
Be sure to submit as a user who lives in the district of your page target.
1 View the page by clicking View for the page in the Dashboard or the Browse All listing, or by clicking View on site on the page edit screens.
2 Proof the page and check the appearance. Hit the back button and then select the appropriate step at the top of the screen to make changes.
3 Fill in your contact information and submit. If you’ve changed the required fields you can try submitting without information you expect to be required. You should see an error message like
Zip required
.4 View and proof the script text. Confirm that your target is who you expect given the address information you just submitted.
5 By default call pages include a survey question where the user can tell you how it went. You can confirm that responses are being captured by submitting something in the field, then selecting Download Actions on the reports tab and entering the page short name.
6 View and proof the thank you page.
- If you entered a Redirect URL for this page, confirm that you land on the correct page.
- If you enabled tell-a-friend, proof the tell-a-friend subject and message. Send yourself a tell-a-friend to confirm the functionality.
7 Check your email for a Confirmation Email if you enabled this option. Proof and check links (if there are any).
8 If you enabled the Fallback page functionality, complete the steps above again, using a zip code that is not represented by the the targets you selected for this page. Make sure the fallback page is the one you expect.
For example, if your call page targets CA Senators, and you’ve selected a fallback page, take action using a Nevada zip code and you should see the fallback page instead of the script and call targets.
LTE Testing¶
When you test an LTE page, use your staff email address and a letter won't be sent to the newspaper.
1 View the page by clicking View for the page in the Dashboard or the Browse All listing, or by clicking View on site on the page edit screens.
2 Proof the page and check the appearance. Hit the back button and then select the appropriate step at the top of the screen to make changes.
3 View and proof the LTE screen including talking points, writing tips and canned letters, if you included any of these.
- Check that your display matches the settings selected in Action basics:
- Newspaper types - Make sure the papers shown match your selections among national, regional and local papers.
- Phone numbers - Confirm that the paper’s phone number shows if you selected this option.
- Select a paper, enter a subject and message, and submit. Remember that you’ll receive an error message and be unable to submit unless your message is at least 15 characters long.
4 Fill in your contact information and submit. Be sure to use the email address you used to log into ActionKit, if you’d like to see a proof of the final letter. Be sure to use a different address if you want to submit a letter yourself. LTE’s always require a full address and phone number.
5 If you’ve added any fields and made them required, or if you just want to check that requirements are working correctly, submit without complete information. You should see an error message like
Zip required
.6 View and proof the thank you page.
- If you entered a Redirect URL for this page, confirm that you land on the correct page.
- If you enabled tell-a-friend, proof the tell-a-friend subject and message. Send yourself a tell-a-friend to confirm the functionality.
7 Check your email for a Confirmation Email if you enabled this option. Proof and check links (if there are any).
8 If you took action using the same email address you used to log into the ActionKit admin, you should receive a test mailing. The email will start "This is a preview of the message that would be delivered..." and include the content you entered in your letter.
9 Confirm that the signature appears as you expect given the LTE signature template chosen for this page.
Survey Testing¶
Testing is particularly important for survey pages because you need to confirm not only that the action works and looks as you expect but that user responses are saved to the database for future reference. We will warn you if your advanced HTML survey question does not include user_
or action_
, the two field names that will prompt ActionKit to save a response, but still be careful!
1 View the page by clicking View for the page in the Dashboard or the Browse All listing, or by clicking View on site on the page edit screens.
2 Proof the page and check the appearance. Hit the back button and then select the appropriate step at the top of the screen to make changes.
3 Check the display and response options for your survey questions.
4 Select or enter responses as appropriate, fill in your contact information and submit. If you’ve changed the required fields you can try submitting without information you expect to be required. You should see an error message like
Zip required
.5 View and proof the thank you page.
- If you entered a Redirect URL for this page, confirm that you land on the correct page.
- If you enabled tell-a-friend, proof the tell-a-friend subject and message. Send yourself a message to test the tell-a-friend functionality.
6 Check your email for a Confirmation Email if you enabled this option. Proof and check links in the email (if there are any).
7 Confirm your responses were saved. To do this, go to the Reports tab, click Download a Survey and pick the survey from the dropdown.
If your responses were not saved, return to the Edit Content screen. Confirm that the field names under Question HTML start with action_
and that the HTML is correct.
Donation Testing¶
The only way to test a donation page is to submit an actual donation using a real credit card. Merchant vendors offer a sandbox where you can test with a fake credit card number, but there may be (and often are) differences between the sandbox code and the live code used to process your donations.
Important
Please note when testing or when processing multiple manual donations that we have built in a delay time between donations to protect the user from erroneously clicking the submit button on a slow donation form. The default is 5 minutes. You can change this and other organization-wide default settings from the CONFIG.
We outline below how to refund your test donation afterward.
If you’ve enabled a Suggested Ask Formula in for your donation page, we suggest running additional tests as a recognized user.
1 View the page by clicking View for the page in the Dashboard or the Browse All listing, or by clicking View on site on the page edit screens.
2 Proof the page and check the appearance. Hit the back button and then select the appropriate step at the top of the screen to make changes.
- Make sure the suggested donation amounts are what you expect.
- If monthly giving is enabled make sure you see both the monthly and one-time donation options.
- If this page is associated with a product, be sure the product is shown with the appropriate text and images.
3 Donation pages require users to enter complete address information regardless of the settings in the Action basics screen.
- If there is a shippable product on the page, shipping address is also required.
- If you’ve required additional information or you want to test the required field functionality, you can try submitting without information you expect to be required. You should see an error message like
Zip required
.4 Enter the required information and a valid credit card number then submit.
5 View and proof the thank you page.
- If you entered a Redirect URL for this page, confirm that you land on the correct page.
- If you enabled tell-a-friend, proof the tell-a-friend subject and message. Send yourself a tell-a-friend to confirm the functionality.
6 Check your email for a Confirmation Email if you enabled this option. Proof and check links (if there are any).
7 If you’d like to refund your test donation:
- Search for yourself using your name or email from the Users tab.
- Click on the User's Action History link near the bottom in the left column.
- Find the action row for the donation you just made and select Refund.
Unsubscribe Testing¶
If you have multiple mailing Lists, we suggest running additional tests as a recognized user.