Overview
Introduction#
The transactional data originating from the export service is formatted in a flat file structure, which means that for a CSV file each row has the same number of columns, some of which are generic and may change meaning depending of the type of data the row is describing.
The key to understanding the meaning of the data is the Campaign Type, which in each row determines what kind of data is output in each of the other columns.
This document is based around describing a standardised CSV format, as this strips away the customizations that are possible within each instance. This means that the naming of column headers have been standardised, as has the order of the output of any fields from constituent records. The standardcsv format described here is available for output by the export service, and may be appropriate for use when testing and developing as a way of limiting the number of factors affecting the output from the platform.
Constituent record fields
It should be noted that the standardcsv format only includes 'standard' constituent record fields presented in a fixed order, and which is limited to the tagged fields: Email Address, Title, First Name, Middle Name, Last Name, Address 1, Address 2, Address 3, City, Region, Postcode, Country, Phone Number
File structure#
Each row in the output file contains a number of items relating to particular aspects of a transaction.
Common Transactional Data Segments#
The first section of a row contains data columns that are common to all transaction types, such as which supporter the activity relates to, the date and time of the transaction, as well as reference names and identifiers for pages or objects in the account. A Campaign Type helps to determine how the Campaign Data Segments, which contains the data relating specifically to the transaction, should be interpreted.
Account ID#
All transactions are products of activities taking place within an account. The account may be represented in each row of data by an 'account identifier'. This identifies the subaccount the record belongs to. If your data warehouse is pulling from multiple Engaging Networks instances, this can be used to differentiate the origin of incoming data - for example, if your organization has multiple branches, each may have their own subaccount identifier. This can be of note particularly if supporter activity needs to be reconciled from multiple Engaging Networks accounts, as their supporter identifiers will be different.
Supporter#
The universal data available as part of transactional exports inlude the Engaging Networks supporter identifier, the email address of the supporter, as well as the created and modified dates for the record.
A unique supporter identifier in Engaging Networks is typically created based on a supporter's email address. The uniqueness of the record is determined by the account, so each subaccount will have different database identifiers for the same email address. When working with our APIs, a supporter can be referred to both by their email address and their database identifier. The export service provides details about when the supporter was created, and last updated. If 'last updated' is blank, this typically means that a supporter is new enough to only have made a single page submission.
Additional supporter details may be available if an appropriate export group has been selected.
Campaign Data Segments#
For each data row, the contents of this section will depend on the specific type of activity the row relates to. These columns typically have a header such as 'Campaign Data 1' to 'Campaign Data 30'
The 'campaign type' for a transaction is automatically generated by the software, and reflects the type of page where the transaction originated as well options selected when a supporter submitted the page. The data presented in the campaign data columns will vary according to the campaign type being used. A donation page, for example, may produce transactions that cover a multitude of different 'campaign type' descriptions, dependent on whether the donation processed was a single or recurring payment, whether the donation was made in the memory of someone, etc.
Default supporter segment#
Depending on the output settings, the rows may include data from the account's default supporter record (consitituent) fields. The supporter segment can be customised using an 'export group', which determines which fields you would like included in this output. Export groups can be created and managed in the Account Settings under Account Data Structure and Manage Field Export Groups.
Campaign Types#
Transactions for a number of different types of activities may be created by the software, this table attempts to provide an overview of the various modules and the types of transactions they might produce.
Advocacy | |
| PET | Advocacy Petition |
| ETT | Email-to-Target |
| CTT | Click-to-Talk |
| TWT | X-to-Target |
| SVY | Survey |
Fundraising (Netdonor) | |
| FCS | Fundraising Card Single |
| FCR | Fundraising Card Recurring |
| FBS | Fundraising Bank Single donation |
| FBR | Fundraising Bank Recurring |
| FRU | Fundraising Recurring Update |
| FUR | Fundraising Unmanaged Recurring |
| FOC | Fundraising One-Click |
| FCA | Fundraising Cash |
| FCH | Fundraising Check |
| RFD | Refund |
| FIM | Fundraising In Memoriam |
| ETM | E-Commerce Item |
| PTM | Premium Item |
Peer-to-Peer v2 (Amplify) | |
| AMR | Amplify Registration |
| ATA | Peer-to-Peer Attendee |
| ACC | Peer-to-Peer Cash or Check Offline Gift |
| ACS | Peer-to-Peer Credit Single |
| ATK | Peer-to-Peer Order |
| ACR | Peer-to-Peer Credit Recurring |
| ACF | Peer-to-Peer Fee Purchase |
| AMD | Peer-to-Peer Refund |
Peer-to-Peer v3 | |
| PSTE | Peer-to-Peer Site |
| PFRP | Peer-to-Peer Registration - Primary |
| PPAY | Peer-to-Peer Registration Payment |
| PACS | Peer-to-Peer Self Additional Donation |
| PACR | Peer-to-Peer Registration Additional Donation: Recurring |
| PFTC | Peer-to-Peer Team Create |
| PFTA | Peer-to-Peer Team Member Addition |
| PFTE | Peer-to-Peer Team Member Exit |
| PORG | Peer-to-Peer Organization |
| PFOC | Peer-to-Peer Organization Create |
| PFOA | Peer-to-Peer Organization Association |
| PFOE | Peer-to-Peer Organization Exit |
| TPPU | Team Peer-to-Peer Page Update |
| IPPU | Individual Peer-to-Peer Page Update |
| OPPU | Organization Peer-to-Peer Page Update |
| PFCS | Peer-to-Peer Credit Single |
| PFCR | Peer-to-Peer Credit Recurring |
| PFCH | Peer-to-Peer Fundraising - Check |
| PFCA | Peer-to-Peer Fundraising - Cash |
| PRFD | Peer-to-Peer Fundraising - Refund Single or Recurring |
| PFIM | Peer-to-Peer Fundraising - In Memoriam |
| PITM | Peer-to-Peer Fundraising - Incentive Item |
Events | |
| ETK | Event Ticket Summary |
| ETA | Event Ticket Attendee |
| ECS | Event Purchase - Card Single |
| EBS | Event Purchase - Bank Single |
| ECC | Event Purchase - Cash or Cheque |
| EFD | Event - Refund Single or Recurring |
List Management | |
| UNS | Unsubscribe |
| EMS | Email Subscribe |
| Management of individual lists submitted via these dedicated pagetypes, or indeed any other type of page created in the software are submitted as answers to 'questions'. These are output as individual transactions. | |
| QCB | Question CheckBox |
| CQS | Question with Confirmation |
| QMR | Question Multiple Response |
Membership | |
| MSP | Membership |
| MMR | Membership Member Association |
Messaging | |
| SBC | Messaging: SMS BroadCast |
| MBC | Messaging: Marketing BroadCast |
| EBC | Messaging: Email BroadCast |
Engaging Networks Dashboard | |
| MSC | Manual Supporter Create |
| MSU | Manual Supporter Update |
REST Services | |
| SSC | API Service Supporter Create |
| SSU | API Service Supporter Update |
Other page types | |
| HSU | HUB Supporter Update |
| DCF | Data Capture Form |
| ECF | E-Card Form |