Data types – questions vs form fields, transactional vs supporter

As you work with your account, you’ll come up against a few different types of data. Ultimately these all link back to your supporters in one way or another, but different data types are processed and recorded in the software in very different ways, so it’s good to develop an understanding of how they all work together.

This document will take you through the various data types you will meet. We’ll first talk about the distinction between supporter data and transactional data. Next we’ll look at how constituent data and transactional data relate to the account data structure and tagged fields. We’ll then look at questions, which are primarily treated as transactional data, but share some of the qualities of supporter data. Finally we’ll take an overview of the ways you can actually interact with data in the software.

Supporter data vs. transactional data

For the most part, data in your account can be classed as either supporter or transactional data.

Supporter data

Supporter data is basically a record of semi-permanent information associated with a particular individual, such as biographical information or contact details. It has the following essential characteristics:

• It is associated with the supporter themselves, rather than any specific activity by that supporter.
• A supporter data field only has one value for a particular constituent at any one time. For example, if an individual has an existing supporter record in your account, and they then fill in a form page and change their address field values, the previous values will be overwritten. We don’t retain transactional records of each amendment to supporter data, only the most recent value.

Transactional data

Transactional data is data used to process a particular activity, such as a donation, the signing of a petition, or a supporter’s response to a broadcast email. Transactional data further splits into two categories: unrecorded and recorded transactional data.

Unrecorded transactional data consists of data values used for processing only, and not logged permanently on our system. This would typically be something like the credit card details used to process a donation. The details need to exist in the software as transactional data in order to collect the information from the donor and pass it through to the payment gateway, but once the transaction is complete, the details disappear from the system.

Recorded transactional data actually stores certain details of activity that has taken place in the system. Coming back to the example of a donation, the recorded transaction data stored would be things like donation amount, the payment gateway used, and the success status of the transaction.

For recorded transactional data:

• The logged data is linked to a constituent by a unique numeric ID, but also to a particular page, broadcast or question.
• The data is permanently logged in the system – transactional data does not get overwritten by subsequent activity by the same constituent.

Data types and account data structure

The fields available for data collection in your account are determined by the setup of your account data structure. The fields defined in the account data structure are then available to be pulled in when building form pages. In this way, the values entered by supporters on form pages link back to a centralized data structure in your account.

Each field in the account data structure can either be tagged or not tagged. Tagged fields are those that are used for specific purposes in the software – examples are address fields or email address (which is used as a unique identifier). Only one tagged field of a particular type can exist in your default supporter record – for example if you already tagged a field as “Email Address”, you can’t use the same tag for another field. Untagged fields are simple data collection fields and your account data structure can contain any number of these. For more detailed information about tagged fields, click here.

The data collected on pages can be supporter data or transactional data. The default supporter record has to reflect this, so it’s therefore important to realize that:

• Some default record fields will generate supporter data. These include biographical fields such as “First Name”, and all fields marked as “Not Tagged”.
• Some default record fields generate transactional data. An example would be “Appeal Code”, which is inserted into a specific column in the transaction row corresponding to a supporter completing a particular form page.
• Some default record fields are not stored permanently in any form. This would include, for example, sensitive payment information such as “Credit Card Number”.

Question data

Questions are somewhat similar to supporter data in that question fields are pulled into form pages, and the most recent response usually represents the current state of affairs for that particular constituent. For example, opt-in questions record whether a constituent is currently opted in, based on that constituent’s most recent response.

There are, however, some important differences between questions and normal form fields:

• Questions are represented in exports as transactional data – this means that historical responses are not overwritten by newer data.
• Any number of questions can be added, without affecting the columns included in the default supporter record.
• Questions are created individually in the form block (see this page), whereas ordinary supporter data fields are defined by the account data structure.

Working with data

There are two main ways of directly viewing and interacting with specific data records:

1. Lookup supporter allows you to view and edit individual records.
2. You can export and import batches of data in csv or xlsx format.

Lookup and manage supporters

The lookup supporters page can be reached by navigating to Data & Reports > Lookup Supporter while logged into your account.

You’ll see a page that looks something like this:

You can search for particular supporters based on any visible constituent data field, as well as on registrations on particular pages.

Once you’ve brought up a particular supporter, you can view and edit supporter data fields in the right-hand panel.

In the left-hand panel, you can also pull up, create or edit individual transaction logs using the panels on the left-hand side.

You can find more information on working with Lookup Supporter here.

Exporting and importing data

It’s often more practical to work with your data in bulk.

You can export all, or a subset of your data by navigating to Data & Reports > Export.

The process of building a query and exporting data is fully explained here, but briefly, when you have built a list of data records and click the Export button, you will arrive at this pop-up:

• Selecting User Data will export supporter data – the file will contain one row per supporter, with a column for each field in your default supporter record, and will not include any questions or transactional information.
• Hybrid Data is identical to User Data, except that the software will append columns containing summary transaction data and question, based on the specific questions and transactions referenced in your query.
• Transactional Data will export rows based on transactions referenced in your query. Your file will contain one row per instance of activity. Supporter data fields are optionally appended on each row.

It’s also straightforward for you to import supporter data via the dashboard, under Data & Reports > Import. The process of importing supporter data is explained here.

Finally, we also have an import/export API which allows you to programmatically push and pull data from our servers over a secure connection. This offers much of the import and export functionality available in the dashboard. In addition, the import API allows you to import historic transactional data. Click here for an overview of the API.