We have a scenario where we send an email to a donor with a contact ID & hash in the url - the current behaviour is

1. if they fill in the donation form using the same email as the link was sent to then the donation is matched to the contact
2. if they use a different email a new contact is created (or if there is an existing record for the different email they might be matched there). An activity is created to link the 2

In the latter case most of the donations come from the same person using an alternative email. A small portion come from cases where a different person has filled in the form using the link - these people can be seen at https://civicrm.wikimedia.org/civicrm/referrals

In most cases the person fills in the form with the same first name and last name so we could code-match the contacts. There are a couple of considerations.

1. security - in theory someone could fill in the form with their email & someone else's link. We might then send them an email that has some data from the original donor. This scenario is really no different when done using code that when DR dedupes the donor as they are currently doing. Mitigating factors are that we do not send much PI by email and they would need to have the link. I think other sites might address this by sending an email notifying the original email address (although that might be mostly when the user gets a login)

2. which email do we then use? We have one email that the donor has clearly responded to and one that they have entered. It seems somewhat common for donors to enter unchecked emails when they donate, suggesting that we might not want to stop using the one we have been emailing. On the other hand it would be surprising to a user to receive a receipt to an email that differs to the one they entered.

We do have some fields we can use to denote email type that go beyond just 'is_primary' - ie

• is_billing
• is_bulkmail
• location_type_id

However we need to think about these in the context of Acoustic - does it impact our exports if we start to use one or more of the above fields differently.

Another Acoustic gotcha is that we normally put emails on the suppression list if they are the non-preferred email - this is something we would ideally do a deep dive into at some point this year.

A final point is that if we are doing in code what DR is doing manually anyway then none of the considerations above are made better or worse by us doing that & we could maybe separate the 'automate what happens' and 'what should happen'