Legacy Consent and Duplicate Contacts Before a Day-One Welcome
Northline Apparel is migrating 2.4 million legacy contacts to SAP Emarsys six weeks before its autumn campaign. The export contains 1.1 million contacts with an email opt-in flag, but 300,000 of those flags have no consent timestamp or source. Another 180,000 rows are probable duplicates: emails differ only by case or trailing spaces, and 42,000 contacts appear under two legacy IDs with different last-order dates. About 90,000 records lack a country value, which the welcome program uses to select language and legal footer. The business wants to import everything, suppress nobody, and launch a welcome email to all opt-ins on day one. The current sender domain is authenticated only for the old ESP. The CRM team can provide a source-system ID and last engagement date for every row. Legal has asked for a defensible consent position, and the campaign team wants to avoid duplicates receiving two welcomes.
1. What contact-data decisions should you make before the first production import, and why?
Read the worked answer
Treat the first import as a controlled data product, not a file load. First define the contact key: keep the CRM source-system ID as a stable external key and use normalized email (trimmed, lowercased) only as the matching attribute, because email changes and duplicates exist. Create explicit fields for consent status, consent source, consent timestamp, and suppression reason rather than relying on a single opt-in flag. Map country with a documented default and a quarantine value for missing data, so language and legal footer logic never silently picks the wrong jurisdiction. Run a full import into a test account, reconcile row counts and field-level null rates against the export, and check a sample of known contacts. Do not activate welcome automation until the test import proves that opt-in counts, country distribution, and duplicate resolution match expectations. This sequence protects deliverability and consent defensibility while giving the campaign team a launch date they can trust.
2. How would you handle the 300,000 opt-ins without timestamp or source, and the 180,000 likely duplicates?
Read the worked answer
Separate the two problems. For the 300,000 unverified opt-ins, do not treat the flag as marketable consent. Import them with a consent status such as "unverified" and exclude them from the day-one welcome. Run a re-permission campaign only where legal approves the basis, or suppress them from marketing until they re-opt in. Preserve the original flag in an audit field so the decision is explainable. For duplicates, normalize email, group by normalized email plus source ID, and define survivorship rules: retain the most recent verified consent, the most complete country and engagement data, and the highest last-order date, while keeping the alternate legacy ID as an alias. Ambiguous cases-same email but conflicting consent-should be quarantined, not merged automatically. Load the resolved set, then run a duplicate report after import. This prevents two welcomes to one person and prevents an unverified record from inheriting another record's consent.
3. What launch gates would you set before the day-one welcome?
Read the worked answer
Use gates that are measurable and owned. Data gate: production contact count reconciles to the resolved import file, duplicate rate is below an agreed threshold, and consent counts by status match the legal extract. Content gate: seed tests for every country/language variant, correct footer and unsubscribe link, and rendering checks in major clients. Deliverability gate: sender domain shows SPF, DKIM, and DMARC alignment; bounce and complaint handling is configured; the sending IP plan matches expected volume. Automation gate: welcome entry excludes unverified and suppressed contacts, frequency cap prevents overlap with other programs, and a test contact receives exactly one welcome. Operational gate: a named approver signs off, a rollback/suppression list exists, and the first two hours of sends are monitored before full volume. If any gate fails, delay the welcome rather than importing unverified consent. The reasoning is that a day-one launch is a volume event; errors become reputation and legal problems at scale.