Developing with Stewardship in Mind
More often than not, developers don't get the chance to fully implement stewardship functionality because it's too vague of a requirement from the organization - our favorite example "Tell me how our email is doing?" is really open-ended and complex.
At TrueGivers, it took us 5 years to compile the research, technologies, and implementation details to support this initiative, so we know how difficult a task this is.
We're Here to Help Developers
Rather than charge thousands of dollars to guide organizations, applications, and developers on some consulting journey without end, we've developed some practical implementations. We break everything down into manageable parts to help everyone understand the scope and process it takes to make this successful - regardless of the size of organization and the complexity of the application.
Implementation
Metadata
This is critical in understanding what data is available, where it resides, and how it's populated and consumed. There are varying levels of metadata management, but for a quick start, we start with this:
| Entity | Attribute | Storage | Standards | Compliance | Policy | Process | Usage |
|---|---|---|---|---|---|---|---|
| Donor | First Name | database.donors.first_name
constantcontact.contact.first_name |
Trimmed, Propercased | Personally Identifiable Information (PII) | Privacy Policy - What we collect | Not validate, may be parsed from Full Name source | Marketing, Screening, Change of Address, CRM |
Standards, Compliance, and Policies
Some people would argue that not all of this is the responsibility of developers, but we think it is important for developers to know what's involved.
Standards
This is definitely a developer responsibility. From simple data hygiene, formatting, and normalization to validation and verification. Each entity/attribute should have it's own set of rules and processes defined. We put this at the forefront of everything we do. The most common and obvious ones are contact data, but things like professional title, company name, etc. should also be included. It's always better to identify the entity/attribute early on because once your database is growing, it may be too difficult an undertaking to fix.
Compliance
The mechanics behind compliance vary by the source, but they are generally centered around sensitivity and security of data. Most of the time some simple alerts or audits of what entity/attribute is being used that has a related compliance is sufficient. Sometimes other measures need to be put in place, like an email filter that provides outbound scanning of emails at the time of send to ensure opted out email addresses are rejected or a rule that specifies a recipient can only ever receive two emails in a 30 day period.
Coverage
This one is easy - right? This is something we hear all the time - "All you need to do is provide a count of all of our email addresses, how can that be so hard?" Well, without the other pieces in place, this question is not just a count of email address where it's not blank. What about opted out, bounced, role-based, and invalid syntax? Simply put, there needs to be support from the data developer who initially builds the underlying storage mechanism to identify and implement the right model to support all the answers to that very easy question.
Quality
This is about providing a quality stewardship experience and enabling stewards to take control of this process. Sure, making sure we are putting syntactically correct email addresses into the system is very important, but what about the quality of those email addresses? How do we measure this? For example, is [email protected] a better email address than [email protected]?
Usage
Usage tracking usage enables an organization to measure the potential impact of quality as it relates to downstream actions. Sending a single donor 40 messages a month because they have 3 email addresses on file can help reduce complaints and improve the donor experience.
Transparency
Transparency is key to the process, but definitely not one developers typically are involved in. In this role, developers should be mindful of tracking all interactions with end user's data so that if they want to view a timeline of their interactions, see all of the campaigns they've been selected for and why, or see all of the personal details an organization has collected about them - they should!