Amazon actually just sends us one field for name (and only stores one on their side). We've been putting everything up to the first space in the first name field, and the rest in the last name. This is on the theory that we usually use the first name alone for email greetings and want that to look natural. It's also tough for a computer to tell the difference between a first name / last name like "Miguel De Icaza" and a first/middle/last like "Elliott James Eggleston".

Thanks @Ejegg, that explanation makes sense. I had hoped Amazon sent first
and last name data separately, but I can see how it would be hard to come
up with a good rule to distinguish middle initials from last names with
more than one word. I appreciate you looking into it!

@MBeat33 ping to make sure you saw this - the Amazon middle initial issue
won't change.

Could we modify the Civi import so that if there is only a single initial after the first name (or a single initial plus a period), it would import as ‘public, john q’? Might that change still allow ones like ‘de beattie, michael’ to import correctly?

@awight, Amazon gives us little for search parameters at their portal. If we need to locate a transaction in Civi it's basically a name search, as donors don't have a transaction ID to provide us. We may know the donors first and last names, but if the transaction reaches Civi as 'P Beattie, Michael' we typically need to contact the donor to ask their middle initial in order to confirm that we've located the correct transaction. Civi doesn't seem to allow a wildcard search for '* beattie, michael' or '*. beattie, michael'. I am trying to remove the extra time going back and forth with donors this step adds to confirming or refunding donations.

@awight why the uptick on priority?

@atgo: I'm losing it. I swear I responded yesterday, but the gist was that I increased priority to normal cos this is impacting the donor services workflow.

@MBeat33: Civi does have a wildcard search, it's horrendously slow and confusing, but for your example, you could type "%beattie". It takes a few minutes. FYI, there's another thing we can do if this is too painful--we can add a fulltext search index. That would mean pretty much instantaneous results for any kind of name search you want to run.

@awight thank you, I tested the % wildcard on some Amazon donor records and though slow it seems to find them often enough. If altering the name import function to account for middle initials would affect the first name greetings in TY emails then I think we can get by with the wildcard. I will update the DS documentation so payment processor agents know to use the wildcard for elusive donors. Thank you for looking into this.

Two PHP libs that attempt to solve this:
https://github.com/joshfraser/PHP-Name-Parser
https://github.com/jasonpriem/HumanNameParser.php

@CCogdill_WMF and @MeganHernandez_WMF
We touched on this briefly today, and tech would like to know what you think about the following: when we're dealing with processors with mangled name data such as Amazon, we have an accurate full name, but can't give a decent first or last name. How about, we use the full name for these cases?

We could find a way to export names into silverpop so your template doesn't have to know any of this

The new Amazon Seller Central portal allows for searching by email address, so we won't be solely reliant on Civi to locate disputed transactions.

@awight this isn't a scientific assumption, but my experience of reviewing Amazon name data is that the first name is generally sensible, but the last name is off. Even if someone has a two word first name (let's say John Paul), I don't think it's wildly problematic to call that person "John". Because we mostly only use first names in email, I don't see the need to put work into improving the parser for this purpose.

@CCogdill_WMF
Good point--Amazon is currently only for the US, where first-name salutation is kosher.

When we do expand the places we're offering Amazon, however, we might want to revisit this. JFYI, the workaround I'm suggesting isn't in our parser, it would be something we do in the Silverpop export job and in the Thank-you job. Meaning that we're fine taking names in exactly as we do, and we can always fix the outbound jobs at a later date.

@awight sure, let's remember this as Amazon expands. I'm thinking about
Japan specifically...