Thanks for creating this @Cstone !

From DR's side, we need to ensure two things on the audience side:

• Annual donors are excluded
• Any donors who only gave once (ie unintended recurring) are excluded.

I think @SHust and @AMJohnson may have more notes which they can add here for visibility, although I know the plan is to work on this the week of 5th to start deploying on 12th.

Hi Team - bringing this into our current sprint. CC @NNgu-WMF for ensuring audience team has viz on this year's copy. Thanks for raising this in today's standup @krobinson. And thanks @Cstone for making these phabs.

I just filed an exclusion phab https://phabricator.wikimedia.org/T413907 and added the relevant info into this Asana task

Thanks @SHust - Please let's also ensure annual recurring donors are excluded from this send, as they get the receipt upon the donation processing each year.

@krobinson, the annual recurring donors have been mentioned in this suppress request phab: https://phabricator.wikimedia.org/T413907

@Eileenmcnaughton - Adding the notes here for your visibility:

Goals:
Test to 1K donors on Monday (Eileen's time zone)
If there are no issues, start the deployment ideally on Monday, to ensure all emails go out by Thursday.

Wishlist:

1. Would it be possible to let us know the estimated volume this week, as we need to plan for team capacity?
2. Send rate per hour, and the estimated duration information would be great, so we can share it with the team.
3. Would it be possible to have a search kit similar to the one shared on Slack last year, so that we can track progress?

Please let us know if anything else is needed
Thanks in advance, team!

@SHust It will be just over a million contacts in total: 1068559.
Note that this doesn't differentiate between annual and monthly donations (this is a bit complex when we consider that recurring donations can be converted from monthly to annual). This is just any donor with more than one recurring donation in the year. Should be close, but there might be some donors with two annual donations and other edge cases.

1 row in set (1 min 56.764 sec)

SELECT COUNT(*) AS contact_count
FROM (
SELECT c.id
FROM civicrm_contact c
INNER JOIN civicrm_contribution cont
  ON c.id = cont.contact_id
  AND cont.contribution_status_id = 1
  AND cont.contribution_recur_id IS NOT NULL
  AND cont.receive_date BETWEEN '20250101100000' AND '20260101095959'
GROUP BY c.id
HAVING COUNT(cont.id) >= 2
) t;

Thanks, @Lars - This is a great estimated volume to prep for team capacity.

1. Thanks @Lars - note that we're not currently updating any from monthly to annual yet, but yes, any one-time or annual recurring gifts should also be included in the summary for recurring donors, as well as endowment gifts.

We would ideally exclude those donors who are solely OTG or annual. I'm not sure there was complexity with those who gave multiple annual donations in the past, but annual was brand new so I guess there weren't many (if any). It sounds like it's too late to address this for this year without delaying the send, so it's fine. But for next year let's aim to exclude those who are exclusively annual (even those with multiple gifts), as annual donors get the receipt in the moment and it just adds unnecessary bulk and bandwidth to my team responding to those who have already received their receipts.

Given this, have we checked that the dynamic of the receipt is very clearly differentiating between annual and monthly?

2. Did the test go out @Eileenmcnaughton ? If so, we didn't see any tickets, so assume it's all good!

When will they start deploying?

@krobinson Just for clarity, the note about including annual / monthly donors above was with respect to the estimate of how many receipts would be sent, not specifically about the actual sending process where I hope we handle that distinction.

And I don't think we need to worry about this for 2025 receipts (as I don't think we switched any donations from monthly to annual, except maybe some tests via donor portal), but we will need to consider the case where someone has upgraded from annual to monthly or vice versa for next year. Our current query (EOYEmail::MakeJob) only checks that contribution_recur.frequency_unit is not annual, but the frequency_unit could have changed during the year. If someone had a monthly donation and switched it to annual in November, we would miss those ten monthly donations.

These are being sent out now! They're going out slightly slower than last year's but should be done within a week.