Jump to content

Fundraising Tracking

From Wikitech

Analytics play a large role in the annual fundraiser and we utilize a very simple and light weight system to capture how a user moves through their workflow.

Central Notice

All banners created within the Central Notice system are manually coded with the following Google Analytics compatible identifiers

  • utm_source - ex. 2009_Jimmy, variant1, variant2
  • utm_medium - ex. sitenotice,sidebar, nytimes
  • utm_campaign - ex. 20101214JA022

A good example of this is Notice37. If you look at the template definition you will see a section of code that looks like the following

 var url = '{{int:Centralnotice-2009 Notice1-donate-url}}&utm_medium=sitenotice&utm_campaign=fundraiser2009&utm_source={{{notice}}}';
  • ⧼Centralnotice-2009 Notice1-donate-url⧽ - is a internal shared resource link the points to our landing page
  • &utm_medium=sitenotice&utm_campaign=fundraiser2009 - are two of the Google Analytics tags mentioned ealier
  • &utm_source={{{notice}}} - is a secondary substitution allowing for an arbitrary amount of equally waited landing pages

Landing Pages

Tracking pipeline
Tracking Tags

Once a user clicks on this banner they are taken to the landing page configured under the notice variable. Each landing page is coded with the following js script

This code has important actions. One is to pull the name of the landing page and affix it to the utm_source. The second is to affix a payment method once a user clicks on either paypal or credit card.

For example:

  1. User clicks on banner 2009_Jimmy - utm_source = 2009_Jimmy
  2. User lands on the donate landing page - utm_source = 2009_Jimmy.donate
  3. User selects paypal as the payment method - utm_source = 2009_Jimmy.donate.pp

Within each step were simply affixing our tracking identifiers. If a user gets to the landing page but then chooses to browse another page like five facts then we automatically lose the name the banner that they arrived with.

Multi Step Tracking

During the 2009/10 fundraiser we made use of variable landing & appeal page tracking by first coding the banners as stated above but changing the utm_medium variable on any appeal page. Effectively we modified the url to be


once a user loaded an appeal page.

Contribution Tracking Database Table

If a user continues within the payment pipeline and either clicks on paypal or credit card for their donation then we make an entry for the session in the civicrm_contribution_tracking table within the civicrm database on db9. The contribution tracking table has the following possible variables.

  • id - Unique Contribution Tracking ID
  • contribution_id - Civicrm contribution id that is only populated once we've had a conversion. This column is set to null when the corresponding contribution entry is deleted from the contribution table.
  • referrer - what url they came from
  • utm_source - banner + landing page + payment method. UTM Source. This is the original text but is separately broken out into banner etc. We aspire to drop this field if we can be sure the data in it is clean enough to always capture in sub-fields.
  • utm_medium - sitenotice
  • utm_campaign - date of creation + 2 character appeal code + 3-digit index ex. 20101214JA022 (Date,JA for Jimmy Appeal 022 for the 22nd of that type)
  • language - what language wiki they came from
  • country - Country the donor accessed the form from
  • tracking_date - time of transaction ex. 20090817221920
  • amount - Donation amount
  • currency - Donation currency
  • usd_amount - Donation amount in USD
  • is_recurring - Is recurring donation
  • utm_key
  • gateway - Gateway, e.g paypal_ec,adyen
  • appeal - JimmyQuote - the appeal is the text to the left of the input boxes (on desktop-size screens)
  • payments_form_variant - a 'variant' typically determines the appearance of the payment form. For example, a variant can change something about the input boxes or their labels
  • banner
  • landing_page
  • payment_method_id
  • payment_submethod_id
  • os - Data pending - see pending T182039. Operating System
  • os_version - Data pending - see pending T182039. Operating System
  • browser - Data pending - see pending T182039. Browser
  • browser_version - Data pending - see pending T182039. Browser version
  • recurring_choice_id - Denotes whether a recurring donation was the result of upsell or an organic recurring transaction
  • device_type_id - The device the banner was served to (e.g Desktop or Mobile)
  • banner_size_id - Large or small banner
  • is_test_variant - Test, rather than a control group
  • banner_variant - The name of the tested variant (if not control)
  • is_pay_fee - Did the user select to pay the processing fee
  • mailing_identifier - External mailing identifier


PayPal transactions are recorded in payment instrument bit of the utm_source as 'pp'.

If a user clicks on PayPal then their data is first posted to the ContributionTracking extension and recorded. At this point we do not yet have a contribution id to insert as the transaction is not yet complete.

Within the PayPal donation a contribution_tracking_id: XXXX variable is inserted by our code and it becomes part of the the transaction. If the donation is successfully completed then the PayPal IPN service will eventually message our listener which will place the contribution onto the processing queue. Upon successful verification we insert the contribution into CiviCRM and receive back a contribution id. We insert this contribution id into the contribution_tracking table by lining up with the tracking id present in the record.

Recurring Payments using PayPal

Recurring payments using PayPal are recorded in the payment instrument bit of the utm_source as 'rpp'.

The flow is exactly the same for PayPal up until the user sees the 'Thank You' page. PayPal then sends messages about the transaction to an IPN listener configured for recurring payments. PayPal will send the listener messages about a subscriber signing up for recurring payments, a successful payment, a failed payment and a subscriber cancelling their recurring payments.

Currently, we are only queueing messages we receive for recurring payments in ActiveMQ. We will eventually be integrating the data with CiviCRM.

Credit Card

Recurring payments using PayPal are recorded in the payment instrument bit of the utm_source as 'cc'.

If a user makes it to our donation gateway then their session is recorded upon first page load. We insert an entry into the contribution tracking database and retain that id as a hidden form field across all trxn's within the session. Subsequent page loads will not retrieve a new tracking id for the same user workflow. If a successful donation is made then the contribution is pushed onto our processing queue and will later be picked up by queue2civicrm for processing. Just as with PayPal our queue software will match up the entry in the contribution_tracking database by matching the tracking id present in the record.

Viewing Stats

Results of tracking can be viewed on foundation wiki and are grouped by date. Every banner entry has to be white listed in wmf-deployment/wmf-config/CommonSettings.php as it is not uncommon for noise to enter the system.

Missing Data

Tampering with data

It is very important to know that data can go missing in the system. Since tracking is unencrypted we are susceptible to any user tampering by either url editing or POST rewriting. By this i mean that anyone who click on a banner will see a url that looks similar to


and could doctor any of the paramaters.


Another way we lose data is if someone clicks on the banner and after seeing the landing page clicks on anything but donate by cc or paypal. After reading about Wikimedia they decide to click the donate link and pick a payment type. At this point the utm_source would look like '.landing1.pp' notice that it's lacking the first section of our tracking that would typically have the banner name.

During the 2009/10 fundraiser we were able to track 92% of transaction that received an id. 1% had absolutely no data for utm_source while 7% had only '.Support ' which was likely due to fraud.

Future Planning


OWA will be used in conjunction with the above described system.