[GSoC 2015] - Strategic Fundraising and Campaigning

[niko_systopia]

Hello everyone,

My name is Niko Bochan. I am a Computer Science student from the
University of Bonn, Germany.

This is the first time for me to participate in Google Summer of Code
and I am very excited to do so.

For this years Google Summer of Code I would like to work on the
'Strategic Fundraising and Campaigning' project, which focuses on
extending the functionality of CiviContribute with hierarchical
campaigns, more detailed metrics, reports and statistics in order to
enhance the capabilities of CiviCRM for strategic fundraising and
campaigning. You can find the complete project description here:
http://wiki.civicrm.org/confluence/display/CRM/Google+Summer+of+Code+-+2015#GoogleSummerofCode-2015-StrategicFundraisingandCampaigning

I am currently working at SYSTOPIA, a consulting agency based in Germany
that specialises in CiviCRM implementation and customization. Over the
last year I have gained experience with CiviCRM and its ecosystem while
helping to develop, test and maintain
extensions such as the SEPA Direct Debit Module
(https://github.com/Project60/org.project60.sepa), "Little BIC
extension" (https://github.com/Project60/org.project60.bic) and an
extensive donation receipt extension, which will be publicly available
later this year.

Furthermore I helped locating and resolving a few bugs in the CiviCRM
core, like issue CRM-15852/CRM-14114 and CRM-14739. Therefore I am quite
confident that I have the required skills and experience needed for this
project.

However there are a few questions that I would like to get some feedback on:

- Should these changes be integrated directly into the CiviCRM core or
rather be implemented as a (CMS-independent) CiviCRM-extension?
- Which requirements does the international community impose on a
project like this?

Answers and indeas regarding the second question are especially
important to me, because while working on the aforementioned extensions,
it quickly became clear that the workflow and requirements in Germany
sometimes drastically differ from other countries. This could also be
the case for Fundraising and Campaigning.

Thank you and regards

[Erik Hommel]

Hi Niko,
great that you are willing to get started with this!! It could be useful to check the CiviRules extension as well, which is being developed with fundraising perspective.
Check http://redmine.civicoop.org/projects/civirules/wiki

[JoeMurray]

See http://wiki.civicrm.org/confluence/pages/diffpages.action?pageId=128253954&originalId=236158984 for a bit of feedback.

One small point about 'creating a field or a function to (manually or automatically) add campaign codes that enable a (semi-) automatic matching of contributions and campaigns':
- There are some ways of doing this already with the linkages from contributions to contribution pages to campaigns.
- When using a contribution page for more things than just one campaign, it might also be useful to link from an email from CiviMail that uses a unique code per contact to the resulting contribution. This is likely being undertaken by another project that is focussing more on testing of response rates.
- Is this related to CiviSEPA's attempt to categorize incoming EFT's? For North America, the batch data entry forms are the most convenient way to enter transactions that did not come through payment processors.

[petednz]

I am not sure how related this is but thought I would add this here in case it helps any ideas. We have a client that uses 3 x contribution custom fields for better tracking of donations by adding components to the urls that are put in a civimailing. For example, their three fields (with example options) are

FUND NAME eg Election Donation, International Projects, Campaign Manager
APPEAL NAME eg Campaign leaflets, Magazine, Conference
CAMPAIGN NAME 2014 election, 2005 election, 2008 election

hence a link to a mailing might include

civicrm/contribute/transact?&reset=1&id=30&{contact.checksum}&cid={contact.contact_id}&FUNDNAME=optionX&APPEALNAME=optionY&CAMPAIGNNAME=optionZ

[jaapjansma]

What you might want to include is to use campaign or sort of for donor journeys and activism journeys. It would be very help full if we had an entity in civicrm which has a donor journey structure and donor journey activities e.g. the second ask in a donor journey. So that activities and contributions could be linked to that specifc step in a donor journey. So that the reporting on effectiveness of a donor journey point could be measured.
Ilja from Amnesty and Steinar from MAF Norway could tell you more about this.

[JoeMurray]

Another term for donor journeys (which I think of more as analytical devices during design http://en.wikipedia.org/wiki/User_journey) is Drip campaigns. See http://en.wikipedia.org/wiki/Drip_marketing.

[ilja]

Hi all,

I might not completly understand what is the goal, but I might be a little skeptical.

My general feeling is that they should not focus on reporting and metrics in civiCRM, to do that you have much better applications (I myself integrate RapidMiner, data analytics software, and QlikView, data visualisation software with civiCRM. I know MAF Norways integrates with Tableau). My feeling is that you should not try to build the one big system able to to everything, but combine specialisted software - where each software used its core competences. You can't build that good reporting, visualisation, analytics tools with the same ritme as those specialist software do. Concerning metrics most fundraiser (at least the good one specialist in what they are doing) use their on metric definition depending on their needs.

It might be more usefull to work on easy usable (for non-developers) connectors between civiCRM on one side and Qlik/Tableau/RapidMiner on the other side.

Greetings,
Ilja

[Fabian_SYSTOPIA]

Hi everyone,

@Ilja: I agree with you that the main focus should not be on complex reporting and metrics as specialized software can do that much better.

However, especially for smaller organisations that don't have ressources for a separate DataMining App or those who don't have a good fundraising specialist (which are still very sparse in Germany...) some out of the box reporting can make sense. Also most of the German commercial competitor products have those and they prove to be quite a selling point.

IMHO a campaign hierarchy and the additional fields & functions make a lot of sense in any case: Both those organisations who use an external DataMining Software and those who don't can decide if they want to use the additional information for analytics. In addition they would enable some much needed/wanted functions for planning campaigns and subsequent actions in CiviCRM.


@Joe:

- Is this related to CiviSEPA's attempt to categorize incoming EFT's?

CiviSEPA enables direct debits to be performed within the SEPA-area. Matching incoming EFT's created with CiviSEPA is no problem as they have a unique mandate ID stored within CiviCRM. There is also CiviBanking which enables you to match all kind of incoming EFT's with customized recognition patterns. However, both of the would not be directly linked to the functions discussed here.

[niko_systopia]

Hello everyone,

First of all thank you for your feedback. It really helps me to get a better view of
which expectations and current approaches exist for this project. I agree that this is quite a
sophisticated proposal and therefore i have planned to focus primarily on
implementing the basic structures, such as a campaign hierarchy, all needed fields
and user interface modifications. Metrics, reports and statistics are a second
priority goal that could be implemented rather general, maybe by making
the data accessible via API/BAO and/or by providing a few example reports.

My progress so far:
 - set up civi-buildkit
 - added my name to the GSoC candidate list (https://github.com/civicrm-gsoc/gsoc_candidate/pull/19)
 - checked the possible ways to communicate with my mentor Björn. We can arrange
   weekly meetings because we are located in the same city and furthermore are in contact via
   email and skype.
 - worked out an approximate timeline for this project:
   - Pre-Coding planning-stage:
     - clarify whether to implement it directly into the core or as a seperate extension
     - identify which CiviCRM-components are affected and need to be modified
     - identify user interface requirements
   - Stage 1 (week 1-4):
     - setting up development environment (mostly done already)
     - review of best approaches, best practices and code guidelines
     - work out a first proof-of-concept
     - re-evaluation of current approach if necessary
   - Stage 2 (week 5-8):
     - setting up the final basic structure (classes, hook implementation, UI, needed files)
     - testing functionality (campaign hierarchy, custom fields, functions)
     - performing mid-term evaluation
     - extending basic structure according to needs
   - Stage 3 (week 9-12):
     - user interface modification/integration (campaign view and campaign management)
     - performing ui tests (usability and functional tests)
     - implementation of basic functionality of metrics, reports and statistics

From now on I will keep posting my progress here.

Thanks and regards
Niko

[xavier]

THanks for the update

[emilyf]

Hey Niko

Now that we have entered the official coding section of the project, we are looking for daily updates from the student detailing the following:

- What you are working on today
- What issues / roadblocks you are trying to overcome
- Any other questions you have where we can help (you can also ask these on stack exchange)

Please keep us updated as to your progress! How are things going?

[niko_systopia]

Hello everyone,

This is a brief update on what's going on at the moment:

We have decided to implement the project as an extension. I will try
to keep everything compatible with the CiviCRM core to
ease a possible future merge.
 
Last week we had the first 'kick-off scrum meeting' with my mentor Björn.
Together we tried to figure out which components of the campaign extension need
to be worked on first and came to the following conclusion:

- We need a more detailed page for each campaign. This page should contain
  all already available information, such as campaign start and end dates, description and goals,
  and extended information like key performance indicators (KPI) and expenses.
 
- We need a few helper classes that contain all relevant methods to work with a
  hierarchical campaign tree structure. This is what i am currently working on.
 
- After that I will begin implementing a the APIs for KPI and campaign expenses and
  connect them with the campaign page.
 
From now on I will try to update you at least once daily.

So far there are no major problems. Angularjs and the custom directives for CiviCRM can be quite tricky to use, though 

Niko

[niko_systopia]

Last week i have been working on:
 - the campaign dashboard page, especially an improved 'breadcrumb'-navigation
 - enabled the parent_id select box for campaigns
 - added a 'view'-button to the existing campaign dashboard page via hook_civicrm_links
   and made it so that the page is opened in a new window instead loaded via ajax
 - there is now a "CampaignTree"-class that provides a few helper methods

 What I try to focus on this week:
 - The campaign tree visualization using d3js
 - A few generic KPI calculation methods and visualization elements (d3?)
 
 I will let you know more tomorrow.

[niko_systopia]

- more work on visualization elements

[niko_systopia]

Yesterday i extended the tree view directive a bit more and did more work on kpi calculation. The most difficult task here is writing solid sql statements for them. Today i plan on finishing these tasks.