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

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:

User clicks on banner 2009_Jimmy - utm_source = 2009_Jimmy
User lands on the donate landing page - utm_source = 2009_Jimmy.donate
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

&utm_source=2009_JimmyAppeal1&utm_medium=appeal&utm_campaign=fundraiser2009

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

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

http://wikimediafoundation.org/wiki/Donate/Now/en?utm_source=2008_nometer_1_collapsed&utm_medium=sitenotice&utm_campaign=fundraiser2008

and could doctor any of the paramaters.

Paths

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

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