All types of eActions share the following common set of requirements:
- Common fields: name (Given, Family and Mother's family name in Spanish countries), address (email or street), country, post code, permission, personal message, anonymity. Labels for fields should allow formatting and links (mainly for permission statement and link to privacy policy)
- Address validation (email/street)
- Rich media (optional): Contributing non-text content like photos, videos and audio
- Signatory total (optional): the actual number of signatures the petition has. If off-site petitions are also used, it includes the count from these in the total.
- Progress indicator (optional but best practice): a visualisation of the percentage of signatures achieved vs. a pre-set goal. Sometimes the progress indicator is not desired until a minimum number of signatures is achieved. The actual number of signatures is usually displayed around/over the progress indicator.
- API (optional): methods that enables 'widgets' to be developed that are hosted on remote sites and store submissions centrally. This also requires that 'widgets' can retrive information for a progress indicator and petition counts as well as expire.
- Syndicated (optional): basic information about the petition (title, demand, overview, URL). The URL will have tracking information so that participants that have taken the action via a feed-based url will be known.
- Bulk signatures (optional): For off-site and offline petition signature collection, the reporting of the totals where individual entries are unfeasible (for one of many good reasons). In addition to signature counts, the collection date, source/event name, location and organiser (name and contact details) need to be recorded so that signatures are traceable. Where the source is online but off-site, it needs to verified if new counts are totals (and thus replace old count with updates date-time) or just new numbers. This should also allow the use of automatic updates from online but offsite sources.
- Import: import of individual signatures collected offsite. Data fields and validation must be the same as for online submissions. Import source/event name, date-time, and person (name and contact details) are also recorded (and associated with each record) for traceability. Any invalid imports are recorded as bulk signatures. Duplicates (address or name-address) are discarded.
- Export: export signatures to file
- Tracking: storage of tracking codes and information with each petition signature. Tracking codes cover source, medium, searchterms, version. Other tracking information covers Off-site Referrer URL, Landing URL, Pre-Action Page URL, Action Page URL, IP address, Browser User Agent, Browser Language code. Tracking should start on the first page anywhere on the site, not just an action page.
- Metadata: petition title, overview, language, start date, end date, relevance (e.g. geographic, language), topics/tags, organiser (e.g. organisation, coalition, person), etc.
- Completion page: A configurable page or URL to the signatory should arrive at after successfully signing a petition. This can be static-HTML, a secondary action/ask or dynamic content/form
- Completion message: A configurable message (e.g. HTML/text email) that is sent to the petition signatory on successfully signing a petition. This is usually used to ask the recipient to help promote the petition by telling others in their network
