Normalize email at capture so [email protected], [email protected], and [email protected] all resolve to the same person, before they become three records
Email is the cookbook's most common deterministic identifier and the most subtly inconsistent. The customer who signs up as [email protected] on the website, [email protected] at the checkout, and [email protected] on the discount form looks like three different people to a stack that compares the raw strings. Each form does its own light cleanup (some lowercase, some trim, some do nothing), and the contradictions land in the warehouse as three customer records with overlapping contact data, three audience memberships, and three quarters of spend attributed to three different lifecycles.
The fix is to normalize email at the moment of capture, with one set of rules applied at every surface that takes an email. The rules are not exotic. Lowercase the whole address. Strip plus-aliasing (the +coupons tag in Gmail-style addresses). Strip dots inside the local part for providers that ignore them (Gmail). Normalize common typo domains (gmial.com → gmail.com). What is exotic is the discipline of applying them everywhere rather than in three places that drift.
This recipe builds normalization at every email-capture surface, with the canonical normalized form written to the identity graph and the raw form preserved as provenance, so a record reconciliation knows which capture event produced which edge.
A reduction in duplicate customer records driven by email-formatting differences, measured as the dedup rate against the historical baseline of records-per-real-person. The metric is the email-record deduplication rate: the percentage of new email captures that match an existing customer record at the normalized level rather than creating a new one, against a baseline measured before normalization was applied. The value shows up in the contact log (one customer receiving one campaign instead of three near-duplicates), in the warehouse (one record per person instead of a fractional, contradictory set), and in the activation layer (audiences that reflect the actual unique audience rather than an inflated count).
The second outcome is the operational visibility of the duplicate problem itself: surfacing the rate at which captures collide with existing records, which is the leading indicator the team needs to know whether the recipe is doing the work.
A normalization function that every email-capture path calls before writing the email to the customer record. Composable stacks suit this because the function is a shared utility the surfaces import; packaged stacks may have the normalization inside each tool and the consistency question is whether each tool's normalization matches. The capability that decides whether the recipe holds is the at-capture coverage: a normalization library that runs on three of four capture surfaces and not the fourth produces the same duplication problem the recipe was built to solve, only on the slice the team did not cover. The audit step that confirms every surface uses the same normalization is the unglamorous discipline.
Compare the tools on Martech Stack Builder
Data engineering owns the normalization pipeline, the graph write that records the normalized edge plus the raw provenance, and the rule maintenance as provider behavior changes. Marketing ops owns the inventory of email-capture surfaces and the verification that each surface uses the shared normalization rather than its own. Legal advises on the disclosure question for the provider-specific rules: stripping `+aliasing` is generally uncontroversial, but normalizing email is processing personal data, and the disclosure that the stack does this is part of the GDPR-strict picture rather than a separate question. The recipe ships in weeks because the normalization library is straightforward, but the slip is the surface inventory: a stack with email captures in fourteen places (forms, integrations, vendor exports landing back) takes longer to instrument than one with three.
Work in this order. The surface inventory matters more than the rule set.
Anonymous-to-known stitching covers steps 1 to 4, identifier graph write step 5, and signal quality monitoring step 6.
The first failure is the surface that does not normalize. A new form, a third-party integration that lands emails back into the warehouse, a vendor export that arrives in mixed case: any of these can re-introduce the duplication the recipe was built to prevent, and the duplication compounds because the new captures look like new customers. The surface inventory is the discipline, not the rule set.
The second is over-normalization. Stripping all dots and plus-aliasing works for Gmail because Gmail explicitly ignores them; doing the same to a custom email provider that does treat them as distinct produces false merges of two genuinely different customers. The rule set has to be provider-aware, and the safest default is to apply aggressive normalization only to providers known to ignore the variants, and conservative normalization elsewhere.
The third is the consent reconciliation at merge. Two records merged on normalized email may have different consent states, and the question of which state survives the merge is a real policy question. The safer rule is the stricter consent (a record that opted out is treated as opted out; a record that consented to marketing only on one capture is treated as marketing-only). Documenting the reconciliation rule before the first merge happens is what keeps the recipe defensible rather than retroactively explainable.
Did this recipe match your situation?Anonymous response. Sign up to leave a longer note tied to your account.
Resolve individual visitors to the account they belong to, so the buying committee shows up as one account rather than scattered anonymous leads
Connect the same person across phone, laptop, and tablet using signals you can stand behind, with an honest fallback when you cannot
Run identity resolution behind one service rather than each downstream system maintaining its own join logic, so a single resolution rule survives the next stack change