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.
Description
Description
Details
Details
Customize query in gerrit
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T112923 [EPIC] Banner history post launch | |||
| Resolved | AndyRussG | T112022 Associate banner history ID with contribution_tracking ID | |||
| Resolved | Ejegg | T118349 Determine what was breaking GlobalCollect in paymentswiki 3730cff20 |
Event Timeline
Comment Actions
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?
Comment Actions
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%.
Comment Actions
Here's a beta cluster banner with a wee script that does this:
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. :)
Comment Actions
Change 238820 had a related patch set uploaded (by AndyRussG):
bannerHistoryLogger.sendLog: use the promise from logEvent
Comment Actions
Change 238820 merged by Ejegg:
bannerHistoryLogger.sendLog: use the promise from logEvent
Comment Actions
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.
Comment Actions
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... :)
Comment Actions
Change 244109 had a related patch set uploaded (by AndyRussG):
WIP Add banner history log ID processor
Comment Actions
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!!
Comment Actions
Change 246425 had a related patch set uploaded (by AndyRussG):
WIP add banner_history module
Comment Actions
Change 246425 merged by Ejegg:
Add banner_history module to consume BH log id associations
Comment Actions
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.
Comment Actions
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!