-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Estimated pending rewards should reset monthly #15005
Comments
@jsecretan for review of above. |
Yep, all good by me, the vital part is highlighting the estimated amount on the way, because when we had left that out in early versions, users were very unhappy. Eager to see the design treatment of that. |
I should mention, there is some complexity here though. I do believe we'll be able to pretty closely estimate the payout, by knowing when the payment tokens were checked in (but cc: @tmancey to keep me honest). However, there are frequently amounts you earned in a month that will "rollover" to the next month, based on how the protocol works. It would be best if the design treatment had some way of dealing with this. |
@jsecretan We can infer the exact amount due from the payment balance endpoint for the previous month |
Great, thanks @tmancey |
ClarificationCurrent behavior: Let's say that a browser has "10 BAT estimated pending rewards this month". In reality, due to the protocol, the user will probably only receive 9 BAT in the upcoming payment date. 1 BAT will be rolled over to the next month's estimated pending rewards. How it should work with the new changesGiven the above example with:
Once the new month comes:
|
The NTP rewards widget should be updated to show the same information (including the "X BAT arriving in Y days" notice). |
Labelling as |
Verification completed with
Encountered and logged #16731 while testing this issue. Scenario 1 - not all tokens from June cashed in prior to Jul 1 (some token roll-over) - Production
June 30th
July 1st
During testing, the Ad grant date was changed from July 5 --> July 7 using Griffin.
Confirmed that July 7 showed the new UI, but July 8 did not.
Scenario 2 - all tokens from June cashed in prior to Jul 1 (no token roll-over) - Production
June 30th
July 1st
During testing, the Ad grant date was changed from July 5 --> July 7 using Griffin.
Confirmed that July 7 showed the new UI, but July 8 did not.
Scenario 3 - no tokens cashed in for June (clean profile) - ProductionCreated a profile today (July 1) and viewed some ads. July 1st
July 1st
Scenario 4 - Next payment date is not the 5thUsing Griffin, the next ad payment date can be changed to be something other than the 5th. Using staging variations server, confirmed that if the "Next payment date" is set to be something other than the standard 5th, the new UI message recognizes this and adjusts accordingly. TranslationsSpot checked to confirm translations. Used the following languages
Verification completed with
Scenario 1 - not all tokens from June cashed in prior to Jul 1 (some token roll-over) - Staging
June 30th
July 1st
Scenario 2 - all tokens from June cashed in prior to Jul 1 (no token roll-over) - Staging
June 30th
July 1st
Verification passed on
Set the system date to `31st July`, launch brave with clean profile and enable rewardsConfirmed Set the system date to `1st Aug` and relaunch braveConfirmed starting Aug 1st the new UI showed as expected on brave://rewards Confirmed starting Set the system date to `5th Aug` and relaunch braveConfirmed ads payout alert is shown as expected on brave://rewards Set the system date to `7th Aug` and relaunch braveConfirmed ads payout alert is shown as expected on brave://rewards Set the system date to `8th Aug` and relaunch braveConfirmed ads payout alert is NOT shown in brave://rewards on 8th Aug Set the system date to `9th Aug` and relaunch braveConfirmed ads payout alert is NOT shown in brave://rewards on 9th Aug no ads payout alert on July20th (clean profile) - ProductionCreated a profile today (July 20th) and viewed some ads.
Next payment date is not the 5thUsing Griffin, the next ad payment date can be changed to be something other than the 5th. Using staging variations server, confirmed that if the "Next payment date" is set to be something other than the standard 5th, the new UI message recognizes this and adjusts accordingly. Currently Ads panel is showing up the next payment date as 6th Aug or some other date on a clean install, restart browser is required to see the correct next payment date which is the expected behavior (next payment date is set to 8th in Griffin). Discussed with @tmancey ( encountered and closed #16858 (comment) |
"Arriving in x days" refers to the start of the payout process, and not necessarily when the user will receive their rewards. For some, it may be |
@jonathansampson that is correct |
Thank you for confirming, @tmancey. We should then expect to receive routine feedback from users who fall into the x + y days category, given the current wording. |
Description
Right now, the estimated pending rewards counter in brave://rewards captures the cumulative total and does not reset every single month. Currently, it only decrements when the BAT is paid out or claimed.
The design team would like the estimated ad earnings counter to appear as follows:
Monthly reset: Estimated pending rewards counter should show the estimated ad earnings for this calendar month only
Arrival notice: Since there is a delay between when the user receives their payout and the beginning of the calendar month (since payout day is on the 5th), then from the 1st to the 5th of the month, there should be a countdown that says "Your x BAT is on the way and will be here in n days" (not final text).
In the Ads module in brave://rewards, it should be redesigned and broken out by calendar month as so:
This will bring the behavior more in line with the upcoming Brave Rewards dropdown panel refresh, as well as the Brave Rewards NTP widget.
The text was updated successfully, but these errors were encountered: