Skip to main content
When a customer is created or updated with a standard first name or middle name, Maestra automatically detects their gender and writes it to the customer profile. This saves you from collecting the field explicitly and keeps gender-based segmentation and personalization working even when only a name is available.

When automatic detection runs

Maestra fills in the gender field only in specific cases. The rules below decide whether the detected value is written.
1

Trigger

The customer is created or edited through an import or an operation. Manual edits to the customer profile do not trigger automatic gender detection.
2

No explicit value

Gender is filled in only if it isn’t explicitly provided in the same import or operation. If the incoming data includes a gender value that contradicts what the name reference would suggest, the incoming value wins.
3

Overwrite on new name

A previously stored gender may be overwritten if the customer’s new name appears on the standard list for a different gender.

How the detection works

Maestra matches the customer’s first name (and, where applicable, middle name) against a built-in reference list of standard names. Each entry on the list is associated with a gender. If the name matches an entry, the corresponding gender is written to the profile. For example, if a customer is imported with the first name “Alex” and no gender field, Maestra looks “Alex” up in the reference list and records the matching gender. If that same customer is later updated and their first name is changed to a name that the reference list ties to a different gender, the stored value can be overwritten on the next import or operation.
Detection runs on the name as it appears in the incoming data. Non-standard spellings, nicknames, or names that aren’t on the reference list won’t produce a match, and the gender field will be left empty.

Priority of data sources

When the same import or operation carries both a name and a gender value, the explicit gender value takes priority over anything the name reference would suggest. This protects cases where:
  • The customer has self-identified a gender that doesn’t match their name.
  • Your source system already stores a verified gender value.
  • You’re importing a corrected value to override an earlier auto-detected one.
In short: explicit data from the caller beats reference-based inference.

When the field stays empty

Automatic detection won’t fill the gender field if:
  • The customer is edited manually in the profile UI rather than through an import or operation.
  • The name on the incoming record isn’t on the reference list of standard names.
  • No first name or middle name is provided at all.
In any of those cases, the gender field keeps its previous value (or stays empty if it was never set).
If you rely on gender for segmentation or campaigns, audit how names arrive in your imports. Clean, standard first names give the best match rate; nicknames and initials usually won’t resolve.