Page MenuHomePhabricator

Associate banner history ID with contribution_tracking ID
Closed, ResolvedPublic2 Story Points

Description

We should add a field to the contribution_tracking table (write a migration in the ContributionTracking extension) to hold the banner history ID. The ID will be passed through donatewiki when applicable. DonationInterface on paymentswiki will record that ID as part of storing the contribution_tracking row.

Details

Related Gerrit Patches:
wikimedia/fundraising/crm : masterAdd banner_history module to consume BH log id associations
mediawiki/extensions/DonationInterface : masterAdd banner history log ID processor
mediawiki/extensions/CentralNotice : masterbannerHistoryLogger.sendLog: use the promise from logEvent

Event Timeline

AndyRussG raised the priority of this task from to Needs Triage.
AndyRussG updated the task description. (Show Details)
AndyRussG moved this task to Backlog on the Fundraising Sprint Snoop (Dogg|Lion) board.
AndyRussG added a subscriber: AndyRussG.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 9 2015, 10:50 PM
AndyRussG triaged this task as High priority.Sep 9 2015, 10:51 PM
awight renamed this task from Implement in banners sending history, passing the banner history ID along and storing it. to Associate banner history ID with contribution ID.Sep 10 2015, 11:35 PM
awight updated the task description. (Show Details)
awight set Security to None.
awight edited a custom field.
awight added a project: Fundraising-Backlog.
awight added a subscriber: awight.
Ejegg added a subscriber: Ejegg.Sep 10 2015, 11:49 PM

Do we need to tie a specific banner history to a specific contribution? The original plan was a standalone table that just got an entry for each banner history that led to a donation. If we want amounts, maybe add another column and fuzz the totals?

Note that we have to send the banner history data back whenever a donation is made, i.e. anyone who donates is suddenly sampled at 100%.

Here's a beta cluster banner with a wee script that does this:

http://meta.wikimedia.beta.wmflabs.org/wiki/Special:CentralNoticeBanners/edit/CN_banner_history_test_banner

It looks like this is the best we can do for browsers that don't support sendBeacon, given current limitations in EventLogging on that count.

Test it out like this:

http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page?country=AQ

Here's a patch by @Ejegg to improve EL for this:

https://gerrit.wikimedia.org/r/#/c/238623/

Also TODO: make bannerHistoryLogger actually use the EL promise. :)

Change 238820 had a related patch set uploaded (by AndyRussG):
bannerHistoryLogger.sendLog: use the promise from logEvent

https://gerrit.wikimedia.org/r/238820

Change 238820 merged by Ejegg:
bannerHistoryLogger.sendLog: use the promise from logEvent

https://gerrit.wikimedia.org/r/238820

Confirmed on my local setup that the 200 ms delay (same as in the test banner on the beta cluster) is enough to get the log request through.

atgo added a subscriber: atgo.

Following the merging of these patches, the workaround for users without sendBeacon is now on the beta cluster. Also updated the beta cluster banner history banner. We can now smoke test the reception of events from different platforms... :)

Change 244109 had a related patch set uploaded (by AndyRussG):
WIP Add banner history log ID processor

https://gerrit.wikimedia.org/r/244109

The sendBeaconlessness workaround works, or at least smoke tested once, on beta labs, with waitLogNoSendBeacon set to 200 ms, on the following platforms:

  • IE10 (Win7)
  • IE11 (Win7)
  • Native Android browser
  • Mobile Safari (iPhone 5 emulator)
  • Safari 9 (OSX11)

I think we're good to deploy this part!!

Pcoombe added a subscriber: Pcoombe.Oct 8 2015, 2:14 PM

Change 246425 had a related patch set uploaded (by AndyRussG):
WIP add banner_history module

https://gerrit.wikimedia.org/r/246425

awight renamed this task from Associate banner history ID with contribution ID to Associate banner history ID with contribution_tracking ID.Oct 27 2015, 5:14 PM
awight added subscribers: ellery, DStrine.

Change 244109 merged by jenkins-bot:
Add banner history log ID processor

https://gerrit.wikimedia.org/r/244109

Change 246425 merged by Ejegg:
Add banner_history module to consume BH log id associations

https://gerrit.wikimedia.org/r/246425

It's really close! Things left to do:

  • Choose a cron period.
  • Set the job time limit to be something like (period - 15 seconds)
  • Create a Jenkins job, basing it on one of the other queue consumer jobs.
  • Run once to debug, examine the console output and verify that data actually went to the right places.
  • Set to run on a schedule.

The DI patch that handles banner history has been deployed, and the Jenkins job to run the Banner History queue consumer is up and running! (Thanks a ton, @Ejegg!!)

Associations of banner history log IDs and contribution tracking IDs appear to be accruing normally in the table in the database. I successfully correlated a record in the contribution_tracking table with a banner history log received via EventLogging!

AndyRussG closed this task as Resolved.Nov 25 2015, 3:14 AM
mmodell removed a subscriber: awight.Jun 22 2017, 9:52 PM