SAP Emarsys Customer Engagement Implementation
This domain tests whether you can stand up a working Emarsys account end to end: account and user structure, the contact data model and consent, sending infrastructure and deliverability, segmentation and Automation Center programs, integrations such as Web Extend and order/product feeds, and a controlled go-live. Items are scenario-shaped; you are usually asked what to configure first, or why a program will not fire.
Foundations: account, users, environments
- Agree the business-unit/brand structure and data separation at kickoff; it drives field design, segment scope and reporting.
- Create named users with least-privilege roles. API traffic uses dedicated API users with IP restrictions, never a personal login.
- Keep test activity out of the production contact database; use a separate sandbox account where one is provisioned.
Contact data model and consent
- Design contact fields before importing: name, type (text, number, date, selection) and consumer. Treat the type as fixed at creation - a wrong type usually means a new field and re-import, not an edit.
- Standardise identifiers (email as primary, plus an external ID) so imports match and update existing contacts instead of duplicating them.
- Model opt-in explicitly: source, timestamp and double opt-in where required. Opt-out is a status change, not a deletion; deleting destroys suppression history and risks re-contacting people who refused.
Sending infrastructure
- Authenticate a custom sending domain (SPF, DKIM, DMARC) and a link/click domain (CNAME) before the first campaign, and warm new sending IPs with engaged segments first.
- Put reply-to, bounce handling and unsubscribe settings in the sender profile so every campaign inherits them.
Automation, segmentation, integrations
- In Automation Center, choose the entry point matching the trigger (date, segment, behaviour, contact, API), add waits and decision nodes, test with a seed list, then activate.
- Segments combine field, behavioural and transactional conditions; do not assume instant refresh.
- The Web Extend tag, product catalogue feed and order data feed feed Predict and recommendations; without enough history, scores are unreliable.
Worked example
A retailer wants a birthday email with recommendations. (1) Create a date-type field birthday and import values - a date trigger reads a date field, so the field must exist first. (2) Build the email with a first-name token and a recommendation block, and test rendering. (3) Create a Date-trigger program on birthday, add a time-of-day wait, then a decision checking opt-in and email validity before the send node. (4) Add exit criteria so a purchase before send removes the contact. (5) Activate and verify with an internal seed list. Activating before the field is populated yields an empty program.
Traps that cost marks
- Launching a program before its entry-point filter matches anyone, then blaming the email.
- Creating fields after import and re-keying data.
- Bulk sending from an unauthenticated or cold domain.
- Expecting a newly activated program to fire retroactively for contacts already matching the entry criteria.
- Testing with real customers instead of seeds.