GOTV

From Riders

Date: Fri, 11 Feb 2005 16:31:25 -0500
From: "Gregory Heller" <hellertech@rcn.com> Add to Address BookAdd to Address Book
To: riders-talk@npogroups.org
Subject: Re: RIDERS-TALK web-based voter file software experiences

The NY Democratic Senate Campaign Committee was running 4 installs Of
AdvoKit each with over 100k voters, and each install had between 7and
20
active users.

But advokit was also used by votercall and vote all your values with
over a million records and 10s of thousands of users. you should talk
to dan robinson about scaleabiltiy. right before the election they did
a ton of work optimizing the code with help from some leading php and
mysql developers from around the globe from what i understand.

So i would say that ist is very scaleable.

the folks at verified voting used advokit with some web-gis software to
do mapping of polesite problems,a nd i know that the CivicACtions folks
were talking about walklist mapping.

currently there is no report writer that is built into advokit so you
have to use the standard walk sheets, which are pretty good in terms of
providing info that you want and sortability. if you want anything
more
custom you ahve to build it.

sperez wrote:

>How well does AdvoKit scale up? Put another way, how many people have
>you had use it (either in terms of total users or users at one time or
>both) and how much data (voter records) have you had in it?
>
>Also, how well do the walk lists and mapping work? That is, do the
walk
>lists come up in walk list order, etc.?
>
>Thanks for the info, Steve
>
>
>----Original Message----
>From: Gregory Heller hellertech@rcn.com
>Sent: Tuesday, February 01, 2005 11:16 AM
>To: riders-talk@npogroups.org
>Subject: Re: RIDERS-TALK web-based voter file software experiences
>
>I think it is generally important to make the distinction between
Voter
>Data and Voter File Software. I have been working on political
>campaigns in NYC and NYS for 5 years or so now and used a variety of
>home grown databases for Voter Contact management (VCM) and also a
>variety of data sources (vendors like Voter Contacct Services and also
>getting data direct from boards of elections)
>
>In this passed election cycle i ran data for 5 state senate campaigns,
>and provided data for a few more. On 4 Campaigns we used AdvoKit
>http://www.advokit.net an open source web based VCM application
>developed by the folks at the eVolve Foundation
>http://www.evolvefoundation.org/ and supported by CivicActions
>http://www.civicactions.com we "brought our own data" that we
colelcted
>from various county boards of elections, enhanced with some of our own
>data and sent out for phone matching with ApT Data Services (who BTW
>does Online VCM as well)
>
>Advokit is a really amayzing application that is primarily designed to
>facilitate distributed (grassroots campaigning, you can read the
website
>
>for a full description) we used it for a more tradition top down
>campaigning. Cutting lists centrally printing them and having folks
>phone bank the lists or knock on the doors. We then had volunteers do
>the data entry back into the system.
>
>You can have multiple "operations" tracking of contacts, multiple
>questions etc... It is really a powerful system.
>
>Advokit is now being ported over to the Drupal/civicspace framework
from
>
>what i understnad, which is very exciting, as there is an active
project
>
>within the civic space community to add donor management and powerful
>crm and from the discussion that i have had with the folks involved,
>advokit will be seemlessly integrated.
>
>
>The best part about all of this is that these systems are open source.
>You find your hosting (i think that CivicActions is going to be
offering
>
>hosting packages) you bring your own data (buy it or acquire it
however
>you do) and then you are up and running with minimal recurring costs
as
>opposed to many VoterFile/Data vendors out there that charge data
>licensing fees and software licensing fees etc....
>
>I would highly encourage folks to look at advokit and consider using
>advokit. as advokit grows, and more peole use it, essentially the
cost
>of doing this kind of Voter Contact work will drop and smaller
>organizations or "poorer" organizations will have these powerful tools
>at their fingertips.
>
>-Gregory
>
>Mike Weissman wrote:
>
>>I'm wondering if anyone is familiar with, and could share their
>>opinions on, any of the vendors such as VAN, Huttleston, Leverage,
>>Prevail, Trimeros, Astro2000 and others who provide web interfaces
for
>>
>>managing voter file data. I've used (some of) these in electoral
>>campaign settings; I'm not sure if others here might have used them
in
>>
>>non-electoral campaign or other settings.
>>
>>Thanks,
>>
>>Mike Weissman

Thread on CRM-Dev on Voter File/CRM Integrations Issues

From Michael Haggerty - techsoldaten at yahoo dotcom

Have worked on a number of national projects
collecting voter file data from different state
parties / data providers, and we found the following
problems:

1) Depth and breadth of data varies widely
2) Lack of common terminology - Donated does not mean
the same thing in MA and AZ
3) Data lacks contextual basis when it hits the file -
no one really understands all fields except data
compiler

Conceptually, can a record in a voter file really be
considered as a contact in the CiviCRM model? While
any individual / organization could become a contact,
voter file records may not be at that level for the
reasons mentioned above. When you are getting a name,
an incomplete 32 character street address and a series
of GOTV codes that are not human readable, there is
probably an intermediate step necessary to handle data
complexities.

I'm thinking the solution is less technical and more
methodological. There seems to be a need for a data
warehousing feature to accomodate things like this on
a large scale, and some well identified import
processes for dealing with voter files for typical
campaigns. When I say typical campaigns, I mean ones
which deal with at most a single state's voter file.

Would love to see a project like the following:

1) Build data definition tables for voter files from
all 50 states. Know what data is provided and what it
means in that voter file.

2) Collects common data import rules that account for
irregularities in data. For instance - when Oklahoma
puts an entire address in single field, there should
be some common, peer reviewed rules for breaking down
the data.

3) Common methods for manipulating voter file
information as part of data import process - typical
campaigns have very select data acquisition needs.
Would like to be able to import based on geography and
categorize as part of import process.

There are just some preliminary thoughts. I'm thinking
that, in some cases, data is not necessarily bound for
a contact table or even CS. The potential here is for
something a little bigger, for CS as a data
warehousing platform.

From David Geihufe

It strikes me that CiviCRM already provides a
methodology solution to the issue of using voter files
= Domain.

If I am an organization that is going to start with
voter file data, I import it into Domain A of CiviCRM.

I use extended fields, whatever, to get all the data
in there in a standardish format (this is not an issue
that CiviCRM needs to support). I can put millions of
records in Domain A, but since Domain A doesn't drive
my email, events, or other core business processes, I
don't take that much of a performance hit (is this
true?).

Then I match my domain A record set with Domain B,
which is my "regular" CRM repository, I am basically
grabbing information from Domain A and appending it to
records in Doman B.

I can also run analysis on Domain A to decide which
ones are going to become part of my CRM effort (send
bulk main, put on call lists, etc.).

From Dan Robinson

Interesting comments. Since I became involved in this stuff I see that
it is about three different related processes -

1) Data aquisition, cleansing and enhancement - this is a dirty job -
but someone has to do it. You talk about a national file - that is the
strategy pursured by the RNC, DNC and the large national voter file vendors.

2) Data analysis and targetting - each campaign has different
requirments and a different strategy. This is where you take the data
from 1) and decide what it means to a campaign

3) Transactional - Once you know what you want to do you have to do it -
get the data into the field and contact voters.

Each of these three steps requires a different set of highly specialized
tools - my general conclusion is that trying to build and uber-tool is a
mistake. Better to work on an uber-process that employs best of breed
tools in each of the three processes. Needless to say that the data
flow is not one way.

There are big differences between how CRM (constituent and customer
relationship management) and VRM (voter relationship management) work.
While there are a lot of similarities there are significant
dissimilarities as well. VRM is a much more dynamic data environment
with a constantly changing set of data, significant requirements to get
data in/out of the system quickly and repeatedly all in the context of
very compressed timelines.

Our immediate goal is to get AdvoKit in shape to well handle the
transactional stuff.

From Andrew Hoppin - andrew at civicspacelabs dot org

David, I like your proposed approach a lot. That is in fact essentially
what we did for the Clark campaign in the end, but it was haphazard and
painful. If we design it right-- so that it is easy and intuitive for an
application with a GUI to be written for an administrator to choose what
type of syching to do when-- then it would work well. Synching and
de-dup'ing tools would be really important, and there is some nuance also in
determining which data "wins" in this process. It would be important, for
example, for an administrator through an application that leverages the
CivicCRM API to be able to easily and intuitively say "I want to synch all
records that have been modified in Domain B with the analogous record in
domain A every night at midnight, and I want the address field in Domain B
to overwrite the address field in Domain A if they're different." You'd
want to synch for a number of reasons; for example, 1) data on voting
history from A you'll want to get into B in order to know more about the
people on your fundraising prospect list (which is likely domain B); 2)
profile data like mailing address captured in Domain B (from relatively
fresh sources like signups on the website and volunteer inquries and
Meetups) is likely more up to date and accurate than data in Domain A, but
you're likely to create lists for mass mailings from Domain A, so you want
that data updated in A with the data from B; 3) Similarly, the voter file
you purchase at the beginning of a campaign won't reflect newly registered
voters, so you'll want to add people that aren't in A but are in B to A;
there is a lot of nuance in figuring out who is who though-- is John Smith
at 21 Main St. in Boston in Domain A the same as John Smith at 100 Broadway
in Boston in Domain B if there is no John Smith at 100 Broadway already in
Domain A? Is this one person who moved? Or is it a different, newly
registered voter? There is no consistent right answer to these synching and
deduping questions, so what we should endeavor to achieve is to enable the
people actually working with the particular data sets in question a lot of
flexibility. I realize that a lot of these issues are more relevant to the
application side than the data model side, but it is really important to
think about "updated" and "date of last update" flags for records in both
Domain A and Domain B, and also the ability to easily archive and back-up
data any that is being overwritten through a synching and/or de-duping
process from the other database, lest an ignorant/inexperienced/exhausted
data administrator do something stupid and want to recover it, which they
inevitably will in the context of a campaign cycle.