🎯 SFMC Interview Prep — Master Roadmap (Zero → Hero)

For: Akash Kumar Panda — SFMC Email Developer @ GAP Inc. (4+ yrs), Certified MC Email Specialist Goal: Walk into the LTM interview proficient in every SFMC topic — fundamentals, dev, architecture, cross-channel, the modern platform, and your own projects.

One naming note before you start. The product this course teaches in depth — Email Studio, Journey Builder, Automation Studio, Content Builder, AMPscript/SSJS — is now branded Marketing Cloud Engagement (lineage: ExactTarget → "Marketing Cloud" → Marketing Cloud Engagement). Salesforce also now sells newer core-platform / Data Cloud-native editions — Marketing Cloud Growth, Marketing Cloud Advanced, and (2025) Engagement Plus — which use Flow instead of Journey Builder and segments instead of SQL. If LTM's interviewer says "Engagement" they mean the classic product you know; if they say "Growth/Advanced" they mean the new stack. Module 17 makes you fluent in the difference so you never sound out of date.

Currency: content verified accurate to current Salesforce Marketing Cloud, 2026. Salesforce rebrands fast (Datorama → Marketing Cloud Intelligence → Marketing Intelligence; Interaction Studio → Marketing Cloud Personalization; Genie/CDP → Data Cloud / Data 360). Modules 17 and 18 hold the moving numbers and names so they only have to be corrected in one place.

---

How this course is organized

Each numbered file is a module. Read them in order the first time. After that, jump around. Every module has the same shape:

1. Concept — what it is, why it exists, where it fits.
2. Deep dive — the detail an interviewer probes for.
3. Code / Hands-on — real snippets you can run in your own BU.
4. Interview angles — the exact questions you'll be asked + model answers.
5. Gotchas — the "senior developer" knowledge that separates you from a 2-year dev.

🔑 = a must-know that interviewers use to separate juniors from seniors. 🧪 = go do this hands-on in your GAP sandbox (or a free SFMC trial) before the interview.

---

The full module map

Modules 01–15 are the core curriculum (read in order). Modules 16–17 are the cross-channel + modern-platform stretch. Modules 18–21 are fast-revision reference assets — cheat sheet, limits, function reference, glossary — built for the last 48 hours. Modules 22–23 are rehearsal and career framing.

---

Pick your track first

Before you plan, decide which track LTM's JD points at — then prioritize accordingly. (Do the Module 15 JD→module worksheet once you have the real job description.)

• Email-Developer track (your core strength): 01–15, with extra reps on 04, 05, 06, 10. This is the bulk of the course and where you already shine.
• Cross-Channel / Architecture stretch track: add 16 (Mobile/cross-channel) and 17 (Data Cloud, editions, Intelligence, Personalization) early and heavily. This is what separates "maintenance-mode email dev" from "can grow into architecture" — your stated goal.

Either way, treat 18–21 as reference (look-up, don't read cover-to-cover) and finish with 22 (mock interviews) + 23 (cert narrative).

Suggested study plan

If you have ~10 days:

If you have ~3 days: Day 1 = 01, 04, 05 (ref: 19). Day 2 = 06, 08, 10, plus 16/17 skim. Day 3 = 14 self-quiz → one Module 22 mock → 20 + 21 scan → 15.

Last 48 hours, regardless of track: live in the reference assets — 20 (Cheat Sheet), 21 (Glossary), 19 (Function Reference), 18 (Limits) — and run at least one timed Module 22 mock end-to-end.

---

The 13 questions you MUST be able to answer cold

If you can nail these, you're 80% there. (Full answers live in Module 14; rehearse them as spoken answers in Module 22; one-liner versions are on the Module 20 cheat sheet.)

1. Walk me through the SFMC Contact model — Contact, Subscriber, Subscriber Key, Contact Key. Senior "why": there are two systems of record — the Email Studio Subscriber (keyed by Subscriber Key, lives on the All Subscribers list, drives email-channel status) and the Contact Builder Contact (Contact Key, cross-channel). Keep them in sync via the same key; a Contact can exist without a Subscriber record and vice versa.
2. List vs Data Extension — when each, and why DEs win? Relational/multi-key modeling, custom schema + data types, AMPscript/SQL access, no practical list ceiling, far better performance, Journey/Automation integration. Lists are essentially legacy except publication lists used for unsubscribe scoping — and All Subscribers still underpins subscriber status even when you send from DEs.
3. Data Extension taxonomy — keep the axes separate (an interviewer will pull this thread): (1) structural type — Standard, Filtered, Random; (2) sendability — Sendable vs non-Sendable (a property, enabled by the Subscriber/Send Relationship — see #10); (3) scope/sharing — Shared DEs (require Enterprise 2.0 / multi-BU) and Synchronized DEs (SYNC_EXT, fed by Marketing Cloud Connect from CRM, and read-only — you copy into a Standard sendable DE before sending). These are independent properties, not mutually exclusive "types": one DE can be Standard and Sendable and Shared at once.
4. AMPscript vs SSJS — when each? AMPscript for inline content personalization and most send-time logic (faster, simpler); SSJS for control flow, try/catch error handling, API/WSProxy calls, and complex data manipulation. Gotcha: SSJS runs in a different context — AMPscript vars don't transparently cross over; bridge with Variable.SetValue/GetValue or Platform.Function.TreatAsContent.
5. Explain Lookup, LookupRows, LookupOrderedRows — and what each returns: Lookup() → a single value (first match); LookupRows() → an unordered rowset; LookupOrderedRows() → an ordered, row-capped set (explicit count + sort spec like 'Date DESC'). All cap at 2,000 rows. On zero matches you get an empty rowset / RowCount=0 — not an error.
6. How does Journey Builder differ from Automation Studio? JB = customer-state orchestration: real-time/triggered, wait-until, decision splits. Automation = scheduled/file-triggered batch ETL. They're complementary and often chained — Automation preps the DE, Journey orchestrates the experience.
7. Walk me through how an email actually sends — DE → inbox. Don't stop at "DE to send"; reach the deliverability layer: Sender Profile / Delivery Profile resolution, send classification, throttling/IP warmup, the SAP authenticated domain, and bounce processing (hard vs soft vs block; auto-unsubscribe after repeated hard bounces via RMM).
8. What are SPF, DKIM, DMARC and how do they relate to SAP (Sender Authentication Package)? SAP = paid add-on: dedicated IP + private/branded sending domain + Reply Mail Management (RMM) + the DKIM signing domain SFMC sets up. SFMC publishes SPF and signs DKIM on the authenticated domain; DMARC alignment is the customer's responsibility via their own DNS.
9. How do you make an email render correctly in Outlook? MSO conditional comments (<!--[if mso]>), VML for buttons/backgrounds, ghost tables — plus the Word-engine quirks: no max-width, no background-image without VML, margin/padding inconsistencies; why hybrid/"spongy" coding beats pure media queries for Outlook; dark-mode color-inversion handling.
10. Explain Sendable vs non-Sendable DE and the Subscriber Relationship. A DE becomes sendable when a field is mapped as the Subscriber Relationship to _subscriberkey. Be ready to draw it: SubscriberKey field → "Subscriber Key (Relates On)".
11. How do you deduplicate in a SQL Query Activity? ROW_NUMBER() OVER (PARTITION BY <key> ORDER BY <date> DESC) then WHERE rn = 1. Senior depth: the deterministic ORDER BY breaks ties (vs nondeterministic GROUP BY/MIN-MAX), and on large DEs consider a primary-key-on-target overwrite strategy for performance.
12. Explain the Gmail/Yahoo 2024 bulk-sender requirements and how you implement them in SFMC. (Enforced Feb 2024, tightened since.) For bulk senders (>5,000/day to Gmail): DMARC at minimum p=none with SPF/DKIM alignment; RFC 8058 one-click unsubscribe (List-Unsubscribe + List-Unsubscribe-Post: List-Unsubscribe=One-Click); honor unsubscribes within 2 days; keep the Postmaster-reported spam complaint rate < 0.3%. In SFMC: authenticated SAP domain, configure the List-Unsubscribe header, and use a proper subscription/unsub center. This is the most likely fresh 2026 deliverability question — don't get caught flat.
13. Tell me about a complex SFMC problem you solved. (Your DE Lookup / VAWP stories — Module 15; rehearse as STAR in Module 22.)

---

Interview-day checklist

• [ ] Can draw the Contact model on a whiteboard from memory — including the two systems of record (Subscriber/All Subscribers vs Contact Builder Contact).
• [ ] Can draw a sendable DE: SubscriberKey field mapped as the Subscriber Relationship to _subscriberkey.
• [ ] Can write a LookupRows + Rows/Row/Field loop without notes and state what Lookup() vs LookupRows() vs LookupOrderedRows() each return (single value / unordered set / ordered+capped), the 2,000-row cap, and that zero matches → empty rowset, RowCount=0 (not an error).
• [ ] Can write a dedup SQL with ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ... DESC) + WHERE rn = 1, and explain why the ORDER BY must be deterministic.
• [ ] Can sketch a WSProxy retrieve skeleton (var api = new Script.Util.WSProxy(); api.retrieve('DataExtensionObject[Name]', cols, filter)) and loop pages with ContinueRequest until MoreDataAvailable is false.
• [ ] Can explain your DE Lookup WSProxy project in STAR format in 90 seconds (Module 15; rehearse in Module 22).
• [ ] Can state the Gmail/Yahoo 2024 bulk-sender rules and the List-Unsubscribe / List-Unsubscribe-Post: List-Unsubscribe=One-Click (RFC 8058) headers.
• [ ] Know the difference between Triggered Send, Journey email, and User-Initiated send, and how a Send Classification ties a Sender Profile (From) to a Delivery Profile (IP/SAP domain, headers) — and Commercial vs Transactional.
• [ ] Can name at least one cross-channel point: how you'd add SMS to a journey and the consent/STOP-keyword difference vs email (Module 16).
• [ ] Can say one sentence on Marketing Cloud Growth/Advanced + Data Cloud vs the classic Engagement you know (Module 17) — so you never read as out of date.
• [ ] Scanned the Module 20 cheat sheet and Module 21 glossary within the last 24 hours.
• [ ] Ran at least one timed Module 22 mock interview out loud and self-scored.
• [ ] Have 3 questions ready to ask THEM (see Module 15).

---

Now go to 01_Architecture_and_Data_Model.md. Let's begin.

Cramming? Jump straight to 20_Cheat_Sheet_OnePager.md, 21_Glossary.md, and a mock in 22_Mock_Interview_Scripts.md.

Module 01 — SFMC Architecture & Data Model

This is the single most-probed area in senior SFMC interviews. If you only master one module, master this. 🔑

---

1. What SFMC is and where it fits

Salesforce Marketing Cloud (SFMC) is a B2C digital marketing platform for cross-channel campaign execution: Email, SMS, Push, WhatsApp, Ads, Web, and journey orchestration. It was originally ExactTarget (acquired by Salesforce in 2013), which is why so much of the underlying API/object model still says "ExactTarget."

🔑 Naming / rebrand (say this so you sound current): Salesforce rebranded the core sending suite to Marketing Cloud Engagement (MCE). "SFMC" and "Marketing Cloud Engagement / MCE" refer to the same product — interviewers at LTM may use either name; mirror whichever they use. The broader Marketing Cloud umbrella now also includes Marketing Cloud Growth / Advanced (newer SKUs built natively on the core Salesforce/Data Cloud platform), but the classic ExactTarget-lineage product you've worked on at GAP is Engagement. If asked "have you used the new Marketing Cloud?", clarify which one they mean — Engagement (the one you know cold) vs Growth (core-platform-native).

Key distinction interviewers want: - Marketing Cloud (SFMC) = B2C, high-volume, Subscriber-centric, separate platform/data model from core Salesforce CRM. - Marketing Cloud Account Engagement (Pardot) = B2B, built on the Salesforce CRM platform, Lead/Contact-centric. - Sales/Service Cloud = the core CRM (Accounts, Contacts, Leads, Opportunities, Cases).

SFMC is not built on the core Salesforce platform — it does not use Apex, SOQL, or standard CRM objects natively. It has its own data model, its own SQL, its own scripting languages (AMPscript, SSJS), and its own APIs (REST + SOAP). Integration to core CRM happens through Marketing Cloud Connect (covered in Module 09).

---

2. The "Studios" and "Builders" — the product map

Interviewers love asking "what tools have you used?" Know what each does:

Studios (channel execution): - Email Studio — design, send, track email. Subscribers, lists, A/B testing, triggered sends. - Mobile Studio — MobileConnect (SMS), MobilePush (in-app/push), GroupConnect (WhatsApp/LINE). - Social Studio — RETIRED (end-of-life November 18, 2024). No longer part of the platform. Mention it only to show you know the product history — social listening/publishing is no longer a native SFMC capability, and Salesforce did not ship a like-for-like replacement. Saying "being retired" in 2026 signals stale knowledge; say "retired in late 2024." - Advertising Studio — audience activation to Google/Meta etc. - Web Studio / CloudPages — landing pages, microsites, forms, code resources.

Builders (cross-channel infrastructure): - Content Builder — central repository for emails, templates, content blocks, images. - Journey Builder — multi-step, multi-channel customer journeys. - Automation Studio — scheduled/triggered batch workflows (SQL, imports, file transfers, scripts). - Contact Builder — the contact data model: data extensions, attribute groups, data designer. - Analytics Builder — reports, Discover (custom reporting), Web/Email analytics. - Einstein — the AI layer. Know enough to be dangerous on each: - Einstein Send Time Optimization (STO) — analyzes each contact's last ~90 days of engagement (opens/clicks across send hours) and picks the individual's best send hour within a window you define. In Journey Builder you drop an Einstein STO activity before the send; it staggers each contact's send to their optimal hour. (Plays directly to your open-time countdown timer work — STO decides when the email lands, your timer logic handles what time it shows when opened.) - Einstein Engagement Scoring — buckets every subscriber on two axes (engagement and reach/deliverability) into personas: Loyalists, Window Shoppers, Selective Subscribers, Dormant, plus predicted likelihood-to-open / click / unsubscribe. Useful for suppression and re-engagement segmentation. - Einstein Content Selection — at open time, picks the best content block/asset per contact from a pool (rules + ML). - Einstein Copy Insights — analyzes historical subject-line language to suggest/score subject lines. - ⚠️ Senior caveat to volunteer: all of these are engagement-trained, so Apple Mail Privacy Protection (MPP) inflates opens and degrades open-based models — lean on click/conversion signals where you can (see §7).

Platform / Setup: - Setup menu — users, roles, BUs, security, sender authentication, installed packages, data retention. This is also where the Sender Authentication Package (SAP), API integrations / Installed Packages, and Contact Deletion configuration live (see §11–§13).

🧪 In your GAP org, click into each and note which BU you're in. Interviewers ask "how is your org structured?"

---

3. Account hierarchy: Tenant, Enterprise, Business Units 🔑

Enterprise (top-level account, a.k.a. "Enterprise 2.0")
│
├── Parent / Top-level Business Unit
│     ├── Child Business Unit (e.g., Brand: Gap)
│     ├── Child Business Unit (e.g., Brand: Old Navy)
│     ├── Child Business Unit (e.g., Brand: Banana Republic)
│     └── Child Business Unit (e.g., Brand: Athleta)

🔍 Line by line: - Enterprise (top-level account, a.k.a. "Enterprise 2.0") — the very top of the account: the whole contract/tenant. "Enterprise 2.0" is the modern hierarchy that allows parent→child asset sharing; everything else hangs underneath this. - │ — a connector line; it just shows that the next level branches down from the Enterprise. No SFMC meaning of its own. - ├── Parent / Top-level Business Unit — the governance BU directly under the Enterprise. Shared DEs, templates, and enterprise suppression lists usually live here so children can reference them. - │ ├── Child Business Unit (e.g., Brand: Gap) — a child BU for one brand. A BU is the unit of data segregation, brand sender identity, and user access — so each brand (Gap) gets its own. - │ ├── Child Business Unit (e.g., Brand: Old Navy) — another brand's BU, isolated from Gap's. The same physical person can exist in both with separate subscriber records and separate unsubscribe scope. - │ ├── Child Business Unit (e.g., Brand: Banana Republic) — a third brand BU; reinforces the one-BU-per-brand pattern a multi-brand retailer uses. - │ └── Child Business Unit (e.g., Brand: Athleta) — the last child (the └── corner just marks the final branch). All four children share the parent's assets but keep their own sending reputation/IP/From-identity.

• A Business Unit (BU) is a logical partition of an Enterprise account. It controls data segregation, brand separation, user access, and sender identity. GAP, with multiple brands, almost certainly uses BUs per brand/market.
• Enterprise 2.0 is the modern hierarchy that allows sharing of content, data extensions, and other assets from a parent BU down to children. (Legacy "Enterprise" / "On Your Behalf" hierarchies exist but new orgs are Enterprise 2.0.)
• Each BU has its own Subscribers? No — read carefully below. Subscribers are managed at a specific level depending on the send relationship.

Tenant / stack / instance (integration vocabulary) 🔑

• A Tenant is your account's slice of the multi-tenant Marketing Cloud infrastructure. Each tenant lives on a stack/instance (e.g., s7, s10, s50) — when an interviewer asks "what stack are you on?" they mean this.
• Critically, API endpoints are tenant-specific. Modern REST/SOAP/auth URLs embed your tenant subdomain, e.g. https://MC<tenant-subdomain>.rest.marketingcloudapis.com and ...soap.marketingcloudapis.com, with auth at ...auth.marketingcloudapis.com. The legacy generic endpoints (e.g., the old exacttargetapis.com / s<n>.exacttarget.com hosts) have been retired — always use the tenant-specific endpoint from your Installed Package. Naming this correctly signals real integration experience.

What is shared vs siloed across BUs:

Why BUs matter for an interview at a multi-brand retailer (like GAP, or LTM): - You isolate Gap subscribers from Old Navy subscribers, but a person can exist in both. - All Subscribers list is shared at the Enterprise level (the master subscriber roster), but sends and unsubscribes can be scoped (publication lists / list-level vs all-subscriber-level unsubscribes).

BU sharing edge cases under Enterprise 2.0 (senior depth): - A Shared DE is referenced, not copied — a change in the parent reflects immediately in every child BU that references it. Children read it; they don't get their own copy. (Same model for shared content/templates.) - But sends and tracking happen in the child BU's context — the send job, the data views, and the engagement attribution belong to the BU that sent it, even when the audience came from a shared parent DE. - Sender reputation, sending IP/domain, From-name/From-address, and unsubscribe scope remain per-BU. Two brands sharing the same audience DE still build independent reputation and brand identity.

🔑 Cross-brand person scenario (verbalize this — it lands well at a multi-brand retailer):

"Take a shopper who buys at both Gap and Old Navy. It's the same physical person, and at the enterprise level we can resolve them to a single Contact Key. But each brand sends from its own BU, so they're separately suppressible per BU: if they unsubscribe from Gap, that's a BU-level unsub and Old Navy is untouched. Architecturally I'd choose BU-level subscription management precisely so a brand opt-out doesn't cascade across the whole portfolio — only a master / All-Subscribers unsub should suppress every brand. The privacy trade-off: a true 'delete me everywhere' (GDPR/CCPA) request must be handled as a Contact Delete or a global unsub, not a single-brand opt-out."

🔑 Unsubscribe scope question (very common): A subscriber can unsubscribe at three levels: 1. List-level / Publication list — unsub from one type of email (e.g., "Promotions") but keep others. 2. Business Unit level — unsub from one BU/brand only. 3. All Subscribers (master) / Enterprise / global — unsub from everything across the account.

This is governed by subscription management and which list the unsubscribe is processed against.

---

4. The Contact Model — THE core concept 🔑🔑

This is where most candidates get tripped up. Learn the vocabulary precisely.

Contact vs Subscriber

• Contact — a person in Contact Builder / the Contact model. The "single view" of an individual across ALL channels (email, SMS, push). Identified by Contact Key.
• Subscriber — a person specifically in the email (Email Studio) context — someone who can receive email. Identified by Subscriber Key.

A Subscriber is essentially a Contact in the email channel. Historically (ExactTarget era), "Subscriber" came first; "Contact" was added later as the cross-channel super-set. In practice the keys are usually the same value.

Contact Key vs Subscriber Key 🔑

• Subscriber Key — the unique identifier for a subscriber in Email Studio. It is the deduplication key for email. Best practice: use a stable business ID (Customer ID / Loyalty ID), NOT the email address, because email addresses change and a person may have multiple.
• Contact Key — the unique identifier in the Contact model (cross-channel). Usually mapped to the same value as Subscriber Key.

Why not use email as the Subscriber Key? (classic interview Q) - One person can have multiple email addresses → duplicates. - Email can change → you'd lose history/tracking continuity. - Using a Customer/Loyalty ID lets you keep one subscriber record with a changeable email attribute.

🔑🔑 Why the Subscriber Key choice is architecturally load-bearing (go deeper than "emails change"): The key is the join/dedup spine that ties together: the All Subscribers roster, every sendable DE, the data views (the SubscriberKey column in _Sent/_Open/_Click/etc.), Journey Builder contact entry, and the Contact model linkage. A wrong or unstable key: - Fractures tracking attribution — if the key changes, historical opens/clicks no longer line up to the person. - Inflates contact count = inflates cost — email-as-key multiplies records when an address changes or a person has several addresses, and every extra record counts toward your contracted contact allocation (see All Contacts below).

The realistic enterprise migration scenario (be ready to talk through it): a legacy org that used email-as-key decides to move to a stable Customer/Loyalty ID. This is painful because the key is effectively immutable — you can't just edit it in place. It requires a formal, Salesforce-assisted Subscriber/Contact Key migration that re-associates historical engagement to the new keys and can involve downtime. The lesson for a greenfield build: pick a stable, system-owned business ID as the key on day one.

Subscriber ID

• An internal system-generated numeric ID SFMC assigns to the subscriber record. You don't set or send to it directly — you use Subscriber Key — but it surfaces in data views and is used internally as the record's primary key.

🔑 Reconciling the identifiers (frequent senior question)

Candidates blur these four. Keep them straight:

The one rule that prevents most pain: Subscriber Key and Contact Key should be the SAME value. When they diverge, email identity and cross-channel identity stop lining up — the classic cause of duplicate contacts (and therefore inflated, billable contact count).

All Subscribers list (Email Studio)

• The master list of every subscriber in a BU (technically the All Subscribers list spans send relationships). Every subscriber who has ever been sent to / imported exists here with a status: Active, Bounced, Held, Unsubscribed.
• Status precedence: Unsubscribed and Bounced/Held will suppress sends regardless of the source list (full suppression order in §9).

🔑🔑 All Contacts (Contact model) vs All Subscribers — and the billing truth

• All Subscribers is the email-channel roster (Email Studio). All Contacts (Contact Builder → Contacts) is the cross-channel roster — the full Contact-model population including people who have no email channel at all (SMS-only, push-only, contacts created via CloudPages/API/mobile).
• Therefore: every Subscriber is a Contact, but not every Contact is a Subscriber. A Contact can exist with no sendable email channel and still occupy a slot in All Contacts.

💰 The billing fact that is a near-guaranteed senior question at a large retailer: CONTACT COUNT is the contracted/billable metric in SFMC. Your contract licenses a number of contacts, and every contact across all BUs counts toward that allocation — including bounced/undeliverable contacts and contacts with no sendable channel. Going over drives overage charges. This is why data hygiene, suppression discipline, and contact deletion matter financially — not just for deliverability.

🔑 "How would you reduce SFMC cost?" (strong answer that ties the whole model together):

"Cost is driven by contact count, so I'd attack the count: purge old hard-bounced and long-dormant records, delete dead loyalty IDs and test/orphan contacts (those created via every channel — CloudPages, API, mobile — that never became real subscribers), and avoid email-as-key, which multiplies records whenever an address changes. I'd schedule Contact Deletion for confirmed-removable records and keep suppression lists lean. Net effect: a smaller billable population, better deliverability, and cleaner attribution."

Orphaned-contact problem: contacts created via mobile, CloudPages, or API that never become subscribers still count against billing. Audit for these — they're invisible in Email Studio (no subscriber record) but very much present (and billable) in All Contacts.

---

5. Data storage: Lists vs Data Extensions 🔑

Lists (legacy)

• Flat, simple subscriber lists. Limited attributes (Profile + Preference attributes only, account-wide schema).
• Tied tightly to subscriber/all-subscribers model.
• Slow at scale, rigid schema, hard to relate. Largely legacy.

Data Extensions (DE) — the modern, preferred storage 🔑

• A relational table in SFMC. You define your own columns (fields), data types, primary keys, nullability.
• Can hold subscriber data or any reference data (products, stores, offers, barcodes…).
• Far more scalable and flexible than lists. This is what you should default to.

Why DEs over Lists (interview answer):

"Lists use a fixed, account-wide attribute schema and don't scale or relate well. Data Extensions are custom relational tables — I control the schema, set primary keys for dedup, can relate them in the data model, query them with SQL, and they handle high volume far better. At GAP everything ran on Data Extensions."

Types of Data Extensions 🔑🔑 (extremely common question)

Frame the taxonomy correctly — this precision is a senior differentiator. There are really only two true STORAGE types: Standard and Sendable. Everything else — Shared, Filtered, Synchronized — is a creation/sharing variant (a modifier) on top of those, and Salesforce Data Extension is a Marketing Cloud Connect-specific case. Don't recite them as six co-equal "types"; group them.

True storage types:

Variants / modifiers (a Standard or Sendable DE created a particular way):

⚠️ Don't conflate Synchronized DE vs Salesforce Data Extension (a common mix-up): - Synchronized DE = continuous read-only mirror of a CRM object (via Synchronized Data Sources), prefixed, non-sendable. - Salesforce Data Extension = a staging DE auto-built by MC Connect for a Salesforce Data Event journey entry.

🔧 Correction — Filtered DEs do NOT auto-refresh:

A Filtered DE is static by default. After creation it reflects a point in time and only updates when you manually refresh it or run a refresh via Automation Studio / REST API / SSJS. For a truly current segment, schedule the refresh in an Automation — or, as most senior developers do, use a SQL Query Activity instead (more control, joins, aggregation). See the Filtered DE vs SQL trade-off below.

🧪 Synchronized DE → sendable DE pattern (verbalize the SDE workflow):

"CRM Contacts sync in as a read-only Synchronized DE Contact_Salesforce (prefixed, non-sendable). I run a SQL Query Activity selecting the opted-in records into a sendable DE Audience_CRM_OptIn, mapping ContactID → SubscriberKey, then send to that. You never send to the SDE directly — it's a mirror."

🔑 Filtered DE vs SQL Query Activity (senior trade-off — know when each is right)

When is a Filtered DE still fine? A genuinely one-off, single-DE, simple-criteria segment a marketer can self-serve. When is SQL mandatory? Any join across DEs, any aggregation/dedup, or any segment that must stay current — which is most real work. As a senior developer, lead with SQL.

Sendable DE & Send Relationship 🔑

When you make a DE sendable, you map: - "Send Relationship" field in the DE (e.g., SubscriberKey or EmailAddress) → to → Subscriber Key (or Subscriber's email). - This tells SFMC which column identifies the person, so it can dedup against All Subscribers, apply unsubscribes, and write tracking back.

Interview trap: "If a DE isn't sendable, can you send to it?" → No. You must mark it sendable and define the send relationship. A reference/lookup DE (e.g., your barcode table) stays non-sendable; you lookup into it from an email sent to a sendable audience DE.

🧪 Sendable DE creation — verbalize this end-to-end (rehearse it):

"I create a DE Audience_Promo_2026 with SubscriberKey (Text, Primary Key), EmailAddress (Email), FirstName (Text), LoyaltyTier (Text). I mark it Sendable and set the Send Relationship: the DE field SubscriberKey Relates To the Subscriber Key, and I designate EmailAddress as the Email field. Now I can send to it — at send time SFMC dedups on Subscriber Key against All Subscribers, applies unsubscribes/suppressions, and writes tracking keyed by SubscriberKey into the data views."

DE field properties to know

• Primary Key — enforces uniqueness; required for UpsertDE matching and for dedup on import.
• Nullable — whether the field allows nulls.
• Data types (canonical — be precise about limits, interviewers probe this):

⚠️ Number-vs-Decimal import gotcha (trips people up constantly): you cannot import 19.99 into a Number field — it silently rejects/fails because Number is integer-only. Monetary and fractional fields must be Decimal (e.g., Price as Decimal(6,2)). Set this up front.

• Default value.
• Retention policy (per DE) — three modes, explained in depth in §13.

🧪 The sendable-audience + non-sendable-reference pattern (your StyleCash/barcode work)

You send to a sendable audience DE and look up into non-sendable reference DEs at render time. This is the exact pattern behind your barcode and offer work — show the code.

Single-row lookup (barcode by Subscriber Key — non-sendable reference DE):

%%[
  VAR @barcode
  SET @barcode = Lookup('StyleCash_Barcodes', 'BarcodeValue', 'SubscriberKey', _subscriberkey)
  IF NOT EMPTY(@barcode) THEN
]%%
  <img src="https://barcode.cdn/%%=v(@barcode)=%%.png" alt="Your StyleCash barcode">
%%[ ENDIF ]%%

🔍 Line by line: - %%[ — opens an AMPscript block. Everything between %%[ and ]%% is server-side logic that runs at send/render time; the recipient never sees it, only its output. - VAR @barcode — declares a variable named @barcode. AMPscript variables always start with @; declaring before use is good practice and avoids surprises. - SET @barcode = Lookup('StyleCash_Barcodes', 'BarcodeValue', 'SubscriberKey', _subscriberkey) — Lookup reads a single value from a DE. Arguments in order: the DE name (StyleCash_Barcodes), the column to return (BarcodeValue), then a field/value pair to match on (SubscriberKey = _subscriberkey). _subscriberkey is a built-in that holds the current recipient's Subscriber Key, so this fetches this person's barcode. On no match it returns an empty string (not an error). - IF NOT EMPTY(@barcode) THEN — guards the output: only render if a barcode was actually found. EMPTY() is true for null/empty; NOT EMPTY means "we got a value." Without this guard you could emit a broken image tag. - ]%% — closes the AMPscript block; what follows is literal HTML output. - <img src="https://barcode.cdn/%%=v(@barcode)=%%.png" alt="Your StyleCash barcode"> — the rendered HTML. %%=v(@barcode)=%% is inline-output syntax: v() prints a variable's value into the HTML, so the image URL ends in the looked-up barcode value. - %%[ ENDIF ]%% — closes the IF. Every IF ... THEN must have a matching ENDIF or the email won't compile.

Multi-row lookup (1:Many — show depth beyond a single Lookup; mirrors a Data Designer 1:M relationship):

%%[
  VAR @rows, @count, @i, @row, @offer
  SET @rows = LookupRows('Offers', 'SubscriberKey', _subscriberkey)
  SET @count = RowCount(@rows)
  FOR @i = 1 TO @count DO
    SET @row = Row(@rows, @i)
    SET @offer = Field(@row, 'OfferText')
]%%
  %%=v(@offer)=%%<br>
%%[ NEXT @i ]%%

🔍 Line by line: - %%[ — opens the AMPscript block (server-side logic, runs at render time). - VAR @rows, @count, @i, @row, @offer — declares all five variables up front: @rows (the result set), @count (how many rows), @i (loop counter), @row (the current row), @offer (the value pulled from that row). - SET @rows = LookupRows('Offers', 'SubscriberKey', _subscriberkey) — LookupRows returns every matching row (a rowset), not a single value. It pulls all rows in the Offers DE where SubscriberKey equals the current recipient — i.e., all of this person's offers (1:Many). - SET @count = RowCount(@rows) — RowCount returns how many rows came back. If nobody matched, this is 0 and the loop below simply never runs (no error). - FOR @i = 1 TO @count DO — starts a loop from row 1 through the last row. AMPscript rowsets are 1-indexed (they start at 1, not 0). - SET @row = Row(@rows, @i) — Row grabs the single row at position @i from the rowset so we can read its fields. - SET @offer = Field(@row, 'OfferText') — Field reads one column (OfferText) out of the current row into @offer. - ]%% — closes the AMPscript block; the next line is HTML emitted once per loop pass. - %%=v(@offer)=%%<br> — prints the current offer text followed by an HTML line break, so each offer appears on its own line. - %%[ NEXT @i ]%% — marks the end of the loop body and advances @i to the next row. The FOR repeats until @i exceeds @count. (FOR always pairs with NEXT.)

Why this matters in the model: the audience DE is sendable (it's who gets the email and where tracking is keyed); the reference DEs (StyleCash_Barcodes, Offers) stay non-sendable (they're what to render). You never send to the reference DE — you Lookup/LookupRows into it. (Developers usually prefer AMPscript Lookups over Data Designer traversal for send-time personalization because of the control they give — see §6.)

---

6. Contact Builder & the Data Model (Data Designer)

• Contact Builder is where you define the relationships between data extensions — the "Data Designer."
• Attribute Groups — logical groupings of related attributes/DEs around the Contact (e.g., "Loyalty," "Purchases," "Demographics"), linked back to the contact universe.
• Data Relationships — 1:1 or 1:Many links between DEs, joined on keys.

🔑 The Population concept (commonly missed)

• A Population is the foundational DE that defines the universe of contacts in the data model — the master set of people, linked together by Contact Key. Attribute Groups attach off the Population. Think of it as "the table that says who exists," with everything else (loyalty, purchases, demographics) hanging off it via relationships.
• You can designate a Population in Data Designer; Attribute Groups then relate to it on Contact Key so Journey Builder and personalization can traverse from a contact to their related attributes.

🔑 Cardinality matters for Journey Builder data binding (senior nuance)

• 1:1 relationships bind cleanly — one related row per contact, so a journey/personalization can reference an attribute directly.
• 1:Many relationships are where people get burned: a contact has multiple related rows (e.g., many orders), and the journey can't magically "pick one." You either bind to a specific cardinality or pre-flatten the data (one row per contact via a SQL Query Activity) before entry. Mis-modeling 1:M as 1:1 produces wrong or empty personalization.

Why this matters: Journey Builder and some personalization can pull related attributes via these relationships. But for email-send personalization, developers most often use direct AMPscript Lookups / LookupRows instead (more control over which row(s) to pull, ordering, and fallbacks — see the §5 examples). Know both, and be able to say when you'd use Data Designer traversal (journey decision splits on related attributes) vs AMPscript (render-time content control, 1:M loops).

---

7. Data Views 🔑 (system tables for tracking)

SFMC exposes hidden system data views you can query with SQL (in a Query Activity). They start with _ and are NOT visible in the DE list but are queryable:

🔑 What data views are (and how to query them) — say this precisely

• They are read-only system views, queryable only via a SQL Query Activity in Automation Studio. You cannot open them in the DE UI, and you cannot retrieve them directly via REST.

Simplest possible data-view query (a single view, no join — useful to see the shape of _Subscribers before you build anything fancier):

SELECT SubscriberKey, EmailAddress, Status
FROM _Subscribers
WHERE Status = 'Active'

🔍 Line by line: - SELECT SubscriberKey, EmailAddress, Status — return three columns from the view: the identity key, the email, and the subscriber's status. - FROM _Subscribers — read from the _Subscribers data view (the master per-BU subscriber roster with status). The leading underscore marks it a system view; it's invisible in the DE list but queryable here. - WHERE Status = 'Active' — keep only rows whose status is Active, i.e., exclude Held, Bounced, and Unsubscribed. Status is a string, so the literal is quoted. This is the canonical "give me currently-mailable subscribers" filter. - The SQL is a subset of T-SQL (SQL Server flavor): SELECT only — no DDL, no INSERT/UPDATE/DELETE inside the query, functions like DATEADD/GETDATE/DATEDIFF/CASE/JOIN work, but it is not the full T-SQL surface. A Query Activity has roughly a 30-minute timeout, and the result set is written by INSERT into a target DE (the activity's "Target DE" with Append/Overwrite/Update behavior).

🔑🔑 Retention: data views vs broader engagement data (get the numbers right — the vague "~6 months" is a credibility risk)

State two separate, current policies: 1. Data views retain engagement events for about 6 months (~180 days) — this is the figure that matters for the SQL you run against _Open/_Click/etc. 2. The broader engagement-data policy (data behind Email Studio Tracking and Analytics Builder reports) was extended to 730 days (2 years), effective June 16, 2025 (Salesforce first announced a 180-day cut for May 15, 2025, then revised it upward to 730 days).

⚠️ Don't say "about 6 months" loosely. Say: "Data views hold roughly 180 days; the broader engagement reporting data is now retained 730 days as of June 2025 — and they're different policies." Some accounts/events can also have shorter effective retention (historically certain _Open configurations were much shorter). Because data views purge, persist long-term engagement to a permanent DE via a scheduled Automation (Query Activity → DE). This is the canonical "how do you keep historical engagement?" answer.

⚠️ Apple Mail Privacy Protection (MPP) — current deliverability nuance that distorts _Open

Since iOS 15 / MPP (2021), Apple Mail pre-fetches images, generating machine "opens" for Apple Mail users whether or not they actually opened. So: - _Open (which includes both unique and repeat opens) is inflated and unreliable for true engagement. - Open-based segmentation is broken — lean on clicks and conversions, not opens. - This directly hits your A/B testing methodology (use CTR / conversion as the decision metric, not open rate) and any "sent but never opened" suppression logic — that segment now mixes genuine non-openers with MPP users whose opens were stripped, so treat it as unreliable and validate with clicks.

Example — last 90 days openers (basic):

SELECT s.SubscriberKey, o.EventDate
FROM _Sent s
JOIN _Open o ON s.SubscriberKey = o.SubscriberKey AND s.JobID = o.JobID
WHERE o.EventDate > DATEADD(day, -90, GETDATE())

🔍 Line by line: - SELECT s.SubscriberKey, o.EventDate — choose the columns to return: the person's Subscriber Key (from the _Sent view, aliased s) and the open timestamp (from _Open, aliased o). - FROM _Sent s — read from the _Sent system data view, giving it the short alias s. _Sent has one row per send event. Data views are queryable only in a SQL Query Activity in Automation Studio. - JOIN _Open o ON s.SubscriberKey = o.SubscriberKey AND s.JobID = o.JobID — an inner join to _Open (alias o), keeping only rows where the same person (SubscriberKey) opened the same send (JobID). Joining on both columns ties an open to its specific send job, not just any send to that person. - WHERE o.EventDate > DATEADD(day, -90, GETDATE()) — filter to opens within the last 90 days. GETDATE() is "now" (server time); DATEADD(day, -90, ...) subtracts 90 days; keeping rows newer than that gives the trailing-90-day window. Because it's an inner join, only people who actually opened survive — these are your recent openers.

Example — "sent but NEVER opened in last 90 days" (correct LEFT JOIN / anti-join):

SELECT s.SubscriberKey, s.JobID, s.EventDate AS SentDate
FROM _Sent s
LEFT JOIN _Open o
  ON s.SubscriberKey = o.SubscriberKey
 AND s.JobID = o.JobID
WHERE s.EventDate > DATEADD(day, -90, GETDATE())
  AND o.SubscriberKey IS NULL

🔍 Line by line: - SELECT s.SubscriberKey, s.JobID, s.EventDate AS SentDate — return the person, the send job, and the send date. AS SentDate renames EventDate in the output so it's clearly the sent date (since we're not pulling an open date here). - FROM _Sent s — start from the _Sent data view (alias s): every send event is a candidate. - LEFT JOIN _Open o — a left join keeps all _Sent rows even when there's no matching open. (An inner JOIN would drop the non-openers — the exact people we want.) - ON s.SubscriberKey = o.SubscriberKey — match opens to sends by the same person… - AND s.JobID = o.JobID — …and the same send job, so an open only "counts" against the send it belongs to. - WHERE s.EventDate > DATEADD(day, -90, GETDATE()) — restrict to sends in the last 90 days (same date math as before). - AND o.SubscriberKey IS NULL — the anti-join condition: keep only rows where the left join found no open (the _Open columns came back NULL). That isolates "sent, but never opened." Filtering on a left-joined column being NULL is the standard way to express "exists in A but not in B."

A plain JOIN can't return non-openers — you need a LEFT JOIN ... WHERE o.SubscriberKey IS NULL anti-join to capture people with a Sent but no matching Open. Caveat to say aloud: Apple MPP inflates _Open, so this "never opened" set is unreliable as a true-engagement signal.

Example — persist 180-day engagement to a permanent DE (scheduled Automation): run a Query Activity like the above on a schedule with the Target DE set to your long-term Engagement_History DE (Append), so you keep history past the data-view purge.

---

8. How the pieces connect (mental model to draw)

        CONTACT (Contact Key)  ← cross-channel single view
              │
   ┌──────────┼───────────┐
 EMAIL       SMS         PUSH
 (Subscriber Key)
              │
   Sendable Data Extension (audience)
        │  send relationship → Subscriber Key
        │
   [SEND]  → All Subscribers (status check / suppression)
        │
   Tracking writes back → _Sent / _Open / _Click / _Bounce (data views)

🔍 Line by line: - CONTACT (Contact Key) ← cross-channel single view — the top of the model: one person across all channels, identified by Contact Key. This is the Contact Builder identity that ties email, SMS, and push together. - EMAIL SMS PUSH — the three channels that branch off the one Contact. The same person can be reachable on any/all of them. - (Subscriber Key) — sits under EMAIL: in the email channel the person is a Subscriber, identified by Subscriber Key (best practice: the same value as the Contact Key). - Sendable Data Extension (audience) — the table you actually send to. It must be marked sendable and contain the audience rows for a campaign. - │ send relationship → Subscriber Key — the mapping that makes a DE sendable: one DE field is designated the Send Relationship, pointing to the Subscriber Key so SFMC knows who each row is. - [SEND] → All Subscribers (status check / suppression) — at send time SFMC checks each key against the All Subscribers roster, applying status (Held/Bounced/Unsubscribed) and suppressions before mailing. Status always overrides list membership. - Tracking writes back → _Sent / _Open / _Click / _Bounce (data views) — after the send, engagement events are recorded into the read-only data views, keyed by Subscriber Key, where you can later query them with SQL.

And personalization at send time:

Email content → AMPscript Lookup → Standard (reference) DEs
                                    (barcodes, offers, store info)

🔍 Line by line: - Email content → AMPscript Lookup → Standard (reference) DEs — the render-time personalization path: as the email builds, AMPscript Lookup/LookupRows calls reach into non-sendable Standard DEs to pull per-recipient content. The audience DE says who gets the email; these reference DEs supply what to show. - (barcodes, offers, store info) — typical reference data you look up but never send to directly (e.g., a barcode table, an offers table, store locations). They stay non-sendable on purpose.

---

9. Send-time identity resolution & suppression hierarchy 🔑🔑

When you send to a sendable DE, SFMC doesn't just blast every row. It runs an ordered resolution/suppression pipeline. Knowing the exact order is a strong differentiator and expands the "status overrides list membership" point:

1. Dedup on Subscriber Key against All Subscribers (the audience is collapsed to unique keys; one person = one send even if listed twice).
2. Master / global (All Subscribers) unsubscribe — suppresses across the whole BU/account scope.
3. Business-Unit-level unsubscribe — suppresses for that brand/BU.
4. Publication-list unsubscribe — suppresses for that topic/list.
5. Suppression list(s) applied at send — keys/emails on a never-send list are dropped.
6. Exclusion script (AMPscript evaluated at send time) — dynamic per-send suppression.
7. Status checks — Held / Bounced (and Unsubscribed status) — undeliverable/suppressed statuses are removed.

The takeaway line: "Status and unsubscribes always win over list membership — being in my audience DE is necessary but not sufficient; the send pipeline can still drop you at any of these stages."

Publication List vs Suppression List vs Exclusion Script (don't conflate these)

Senior framing: "A publication unsub is the subscriber's stated preference and changes their list status; a suppression list is an operational never-send I control without touching their status; an exclusion script is dynamic, per-send logic. They behave differently against All Subscribers, which matters for compliance reporting."

---

10. Sender Profile, Delivery Profile & Send Classification 🔑

These were only a table cell before — senders must explain them:

• Sender Profile — defines the From name and From address (and reply behavior) for a send. "Who it's from."
• Delivery Profile — defines the IP/send-from infrastructure: the sending IP pool, the header/envelope (SAP) domain, and footer/physical-address settings. "How/where it goes out from."
• Send Classification — the policy wrapper that combines a CAN-SPAM/Commercial vs Transactional type + a Sender Profile + a Delivery Profile. You pick a Send Classification when you send.

🔑 Commercial vs Transactional (and where it's legitimate vs abused): - A Commercial classification enforces CAN-SPAM: the unsubscribe link and physical mailing address footer are required, and unsubscribes are honored. - A Transactional classification can bypass the unsubscribe/CAN-SPAM footer — appropriate for genuinely transactional mail (order confirmations, password resets, shipping notices) the recipient can't opt out of. - ⚠️ Abuse warning to voice: marking promotional mail as Transactional to dodge unsubscribes is a compliance violation and a deliverability risk. Transactional classification is for true transactional content only. This ties directly to the unsubscribe-scope discussion in §3.

---

11. Deliverability & authentication architecture 🔑🔑 (your exact role)

A senior email developer will be grilled here. Know the stack cold.

• SAP — Sender Authentication Package — the Salesforce add-on that gives a BU a dedicated/private sending domain, dedicated IP(s), authenticated link wrapping, and a branded Reply Mail Management. It's what moves you off shared infrastructure onto your own reputation.
• Private / dedicated domain — your own authenticated From-domain (and link domain), so reputation is yours, not a shared pool's.

Authentication trio (be able to define each): - SPF (Sender Policy Framework) — DNS TXT record listing which servers/IPs are allowed to send for your domain (envelope/Return-Path check). - DKIM (DomainKeys Identified Mail) — a cryptographic signature in the header; the receiver verifies it against your published public key (proves the message wasn't altered and came from you). - DMARC (Domain-based Message Authentication, Reporting & Conformance) — a policy built on SPF + DKIM alignment, telling receivers what to do on failure (p=none monitor → p=quarantine → p=reject) and where to send aggregate reports.

🔑 Gmail / Yahoo bulk-sender requirements (effective Feb 2024) — for senders >5,000/day: - SPF + DKIM + DMARC all required; DMARC at minimum p=none. - RFC 8058 one-click List-Unsubscribe (List-Unsubscribe + List-Unsubscribe-Post headers), and you must honor unsubscribes within ~2 days. - Keep the spam complaint rate under 0.3% (Google's threshold; aim well below). - Valid PTR / forward-confirmed reverse DNS (FCrDNS) and TLS for transport. - Monitor with Google Postmaster Tools (and Yahoo's complaint feedback).

🧪 Talking point (verbalize):

"For our >5k/day domains we run a full SAP with SPF + DKIM signing on a private domain, DMARC at p=none moving toward quarantine, an RFC 8058 one-click List-Unsubscribe header we honor within 2 days, and we watch Google Postmaster Tools to keep the spam complaint rate under 0.3%."

---

12. Contact Deletion & data governance (GDPR/CCPA) 🔑

A data-governance line at a large retailer almost always reaches Contact Deletion.

• How: Contact Builder → Contacts → Delete (UI), or via API / Automation for bulk. You delete by Contact Key.
• Suppression period: after a delete request, SFMC applies a suppression period defaulting to 2 days (configurable 0–30 days in Contacts Configuration). During it, that Contact ID cannot be re-uploaded and the contact receives nothing. Set it to 0 to queue deletion immediately.
• Scope of the delete: it removes the contact across All Contacts + all sendable DEs + the Email Studio subscriber record + channel records (MobileConnect/MobilePush, etc.) — a true cross-platform erasure.
• Priority: contact deletion is deprioritized behind sends, imports, and queries — it runs when the platform has capacity, so it is not instant even at suppression 0.
• Irreversible & billing: the delete is hard (no recovery) and frees a slot against your contracted contact count (ties back to §4 billing).
• GDPR/CCPA "right to be forgotten": this is the mechanism for an erasure request — distinct from an unsubscribe (which keeps the record).

🧪 Governance example (verbalize):

"For a GDPR erasure request I submit the Contact Key to Contact Delete in Contact Builder; with the suppression period set to 0 it queues immediately, removing the contact across All Contacts, all sendable DEs, the Email Studio subscriber record, and Mobile records — and it frees a slot against our contracted contact count. I tell stakeholders it's queued (deprioritized behind sends) and irreversible."

---

13. Data Retention Policy on a DE — mechanics 🔑

The per-DE retention setting (different from the §7 engagement/data-view retention) has three modes:

1. Delete records (keep the DE) — purge rows on/after a date or on a rolling period (N days/weeks/months/years), leaving the empty DE in place.
2. Delete all records and the DE — purge rows and remove the DE itself at the date/period.
3. Delete the entire DE — drop the DE (structure included).

Plus key behaviors: - "Reset on import" (a.k.a. reset the retention clock on import) — if ON, each import restarts the rolling window; if OFF, rows age out on their own schedule regardless of imports. - Period units — day / week / month / year, or a fixed date. - Hard deletes — retention deletions are unrecoverable. There is no undo/recycle bin. - Does NOT apply to data views — those are platform-governed (§7: ~180 days for data views, 730 days for broader engagement data). Don't confuse DE retention with engagement-data retention — a classic point of confusion.

⚠️ Interplay with active journeys/sends (senior edge case): if a DE's retention deletes rows while a contact is mid-journey or while a triggered send references the row, you can get errors or dropped personalization. Coordinate retention windows with journey duration — never set aggressive retention on a DE that feeds an active automation or journey.

🧪 Concrete scenario (verbalize):

"On a daily triggered-send staging DE I set retention to 'Delete records' on a 7-day rolling period with reset-on-import OFF, so stale rows self-purge. On a reference DE (store locations) I set NO retention — deletion is unrecoverable and the data is permanent reference."

---

14. Import & API ingestion — how data gets in 🔑

Given you built a WSProxy DE Lookup tool, an interviewer will expect you to articulate UI import vs SOAP vs REST and the trade-offs.

UI / file-based: - Import Activity — load a file into a DE or List (run ad hoc or in Automation Studio). Key options: - Add Only (insert new, skip existing), Add and Update / Update (upsert on PK), Overwrite (truncate then load), Update only. - Requires a Primary Key for proper upsert/dedup. - List Detective — scans imports for bad/role/blocklisted addresses and quarantines them, protecting deliverability. - SFTP / Enhanced FTP — the file-transfer landing zone (Safehouse / Enhanced FTP) that File Transfer + Import activities pick up in automations.

API / programmatic: - SOAP — Create on DataExtensionObject (insert rows), Update, Retrieve (read, 2,500 rows per call, paginated via ContinueRequest / RequestID), Delete. Strong for metadata, folders (DataFolder), and CRUD on DE rows. - REST — token-based (OAuth); async insert endpoints for high-volume row inserts (/data/v1/async/dataextensions/...), plus upsert endpoints. Better for high-throughput row ingestion and modern integrations. - WSProxy (SSJS) — an in-platform SSJS wrapper over the SOAP API that avoids manual token/endpoint handling and is faster for bulk metadata/Retrieve operations — exactly your DE Lookup tool (WSProxy + DataFolder for recursive folder paths).

🔑 When to use which (senior framing — say this):

"WSProxy runs in-platform over SOAP objects — great for Retrieve and CRUD on DEs and folders (it's how my DE Lookup tool walks DataFolder recursively for full paths, no token juggling). REST is token-based with async inserts — I reach for it for high-volume row inserts and external integrations. SOAP Retrieve caps at 2,500 rows per call, so for large reads I page with ContinueRequest using the RequestID. UI Import is for file-based, marketer-run loads. I pick based on volume, whether it's metadata vs rows, and in-platform vs external."

---

15. Roles, permissions & platform governance 🔑

The module previously said roles are "assigned per BU" without the model. Fill it in:

• Standard roles ship out of the box: Administrator, Content Creator, Analyst / Viewer, Channel Manager (Email/Mobile), Data Manager, etc. (Exact set varies by edition.)
• Custom roles — granular permission sets you compose when standard roles don't fit (least-privilege).
• BU-scoped assignment — a user is granted a role per Business Unit: someone can be Admin in the Old Navy BU but read-only in Gap. Access is the intersection of user × BU × role.
• Enterprise vs BU admin — an Enterprise (top-level) Administrator manages the whole account: creates BUs, manages cross-BU users, sharing, SAP/sender authentication, and account-wide settings. A BU admin is scoped to their BU only.

Integration access (belongs here too): - Installed Packages / API Integration — you create an Installed Package to get API credentials. Two integration types: - Server-to-Server — client-credentials OAuth, no user context — for backend/automation (your WSProxy/REST jobs, ETL). - Web App — authorization-code OAuth with a redirect — for apps that act on behalf of a logged-in user. - Scope each package to the minimum permissions and BUs needed.

---

16. Interview angles (with model answers)

Q: "Explain the difference between a Contact and a Subscriber."

"A Contact is the cross-channel single view of a person in the Contact model, keyed by Contact Key. A Subscriber is that person specifically in the email channel, keyed by Subscriber Key. In most orgs the keys map to the same stable business ID. Subscriber is the older Email-Studio concept; Contact was layered on for multi-channel."

Q: "Why use Subscriber Key instead of email address?"

(See §4 — multiple emails, email changes, dedup, history continuity; and the load-bearing-key / migration depth there.)

Q: "What's a sendable vs non-sendable DE?"

"Sendable means I've defined a send relationship mapping a field to Subscriber Key, so I can send email directly to that DE and SFMC can dedup, suppress unsubs, and write tracking. Non-sendable DEs are reference tables — like my barcode or offer tables — that I look up into from the email, but never send to directly."

Q: "How are Business Units used at a multi-brand company?"

(See §3 — isolate brand data/identity, shared-but-referenced parent assets, the cross-brand person scenario, and per-BU sender profiles/reputation; sender vs delivery profile detail in §10.)

Q: "Where does tracking data live and how long?"

"In system data views — _Sent, _Open, _Click, _Bounce, etc. — queryable only via a SQL Query Activity in Automation Studio. Data views retain ~180 days; the broader engagement reporting data (Email Studio Tracking / Analytics Builder) is now retained 730 days as of June 2025 — two different policies. For anything longer-lived I run a scheduled Automation (Query Activity → permanent DE) to persist it, and I weight clicks/conversions over opens because Apple MPP inflates _Open."

Q: "Is the Subscriber/Contact Key case-sensitive?" (trap question)

"No — it's case-INSENSITIVE. ABC123 and abc123 resolve to the same record. That's exactly why SFMC rejects a raw 15-character Salesforce ID with a CaseSensitiveSalesforceID error and forces conversion to the 18-character case-safe ID before it can be stored as a key. And the key is the identity/dedup value — you don't 'edit' it in place; re-pointing keys is a formal, Salesforce-assisted migration, so I treat it as effectively immutable in normal ops."

Q: "What drives SFMC cost, and how would you reduce it?"

"Contact count is the contracted/billable metric — every contact across all BUs counts, including bounced and channel-less contacts. To reduce it I purge hard bounces and long-dormant records, delete dead/test/orphan contacts via Contact Deletion, keep suppression lists lean, and avoid email-as-key (which multiplies records). Smaller billable population, better deliverability, cleaner attribution."

Q: "How do you handle a GDPR 'right to be forgotten' request?"

"Contact Delete by Contact Key in Contact Builder (or API for bulk), suppression period at 0 to queue immediately. It removes the contact across All Contacts, sendable DEs, the Email Studio subscriber record, and Mobile records, is irreversible, frees a billable slot, and is deprioritized behind sends — so it's not instant. That's distinct from an unsubscribe, which keeps the record."

Q: "A >5,000/day domain — what's your deliverability/authentication setup?"

"Full SAP with a private domain, SPF + DKIM signing, DMARC (p=none → moving to quarantine), RFC 8058 one-click List-Unsubscribe honored within ~2 days, valid PTR/FCrDNS + TLS, and Google Postmaster monitoring to keep the spam complaint rate under 0.3% — i.e., the Gmail/Yahoo 2024 bulk-sender bar."

Q: "Filtered DE or SQL Query — when each?"

"Filtered DE for a one-off, single-source, simple-criteria segment a marketer can self-serve — but it's static until refreshed, so it's not live. SQL Query Activity is my default for anything relational, recurring, or with logic: it joins, aggregates, dedups, and re-runs fresh each schedule."

Q: "WSProxy vs REST vs SOAP — when do you reach for each?"

"WSProxy (in-platform SSJS over SOAP) for Retrieve and CRUD on DEs/folders — it's how my DE Lookup tool walks DataFolder recursively, no token handling. REST for high-volume async row inserts and external integrations. Raw SOAP when I need objects WSProxy doesn't wrap cleanly, paging large reads with ContinueRequest/RequestID past the 2,500-row Retrieve cap. UI Import for marketer-run file loads."

Q: "What's the difference between a Synchronized DE and a 'Salesforce Data Extension'?"

"A Synchronized DE is a continuous read-only mirror of a CRM object via Synchronized Data Sources — prefixed, non-sendable; I build a sendable DE off it with SQL. A Salesforce Data Extension is the staging DE Marketing Cloud Connect auto-creates for a Salesforce Data Event journey entry. Different things that people conflate."

---

17. Gotchas (senior-level knowledge)

• All Subscribers status overrides list membership. Someone Unsubscribed at the master level won't get sent to even if they're in your audience DE. (Full suppression order in §9.)
• Primary Key ≠ required for sendable — but without a PK you can't UpsertDE cleanly and imports won't dedup.
• Filtered DEs are STATIC by default — NOT auto-maintained. After creation they reflect a point in time and only update when you manually refresh them or refresh via Automation Studio / REST / SSJS. For a truly current segment, schedule the refresh — or use a SQL Query Activity (most seniors' default: joins, aggregation, control).
• Synchronized DEs are read-only and not sendable directly — you build a sendable DE off them via SQL. (Don't confuse with a Salesforce Data Extension, the MC-Connect staging DE for Salesforce Data Event journeys.)
• Shared DEs require Enterprise 2.0 and proper sharing config; child BUs reference, not copy — but sends/tracking happen in the child BU's context, and reputation/IP/unsub scope stay per-BU.
• Data view retention (~180 days; broader engagement data 730 days since June 2025) means you can't query "all-time opens" — you must persist to a permanent DE on a schedule.
• 🔧 Subscriber Key / Contact Key are CASE-INSENSITIVE — ABC123 and abc123 resolve to the same subscriber. (Corollary: never store a raw 15-character Salesforce ID as a key — SFMC requires the case-safe 18-character ID; a 15-digit ID throws a CaseSensitiveSalesforceID validation error.) The key is the dedup/identity value — you can't simply edit it in place to re-point history; reconciling keys across systems is a formal Subscriber/Contact Key migration (Salesforce-assisted, can involve downtime), so treat it as effectively immutable in normal operations.
• Number is integer-only — importing 19.99 into a Number field fails; use Decimal for any fractional/monetary value.
• Contact count = billing. Every contact across all BUs (including bounced/channel-less/orphaned) counts toward the contracted allocation — hygiene and deletion are cost levers, not just deliverability.
• Apple MPP inflates _Open — open-based "engaged/not engaged" segmentation is unreliable since 2021; lean on clicks/conversions.
• DE retention deletes are HARD (no recovery) and don't apply to data views; coordinate retention windows with active journey/triggered-send durations or you'll break personalization mid-flight.
• Transactional Send Classification can bypass the unsubscribe footer — legitimate only for true transactional mail; using it for promo content is a CAN-SPAM violation and deliverability risk.

---

Quick self-check (answer out loud)

1. Name the two true DE storage types and the three variants/modifiers, with one use case each.
2. Draw the Contact model with all four identifiers (Subscriber ID/Key, Contact ID/Key).
3. What are the 3 levels at which a subscriber can unsubscribe, and how do Publication List / Suppression List / Exclusion Script differ?
4. Which data view join finds people who were sent but never opened — and why is that segment unreliable now?
5. Why is a barcode lookup table non-sendable?
6. Is the Subscriber Key case-sensitive? What error appears if you import a 15-digit Salesforce ID?
7. What is SFMC's billing metric, and name three ways to reduce it.
8. Walk the send-time suppression order (dedup → … → Held/Bounced).
9. Name the Gmail/Yahoo 2024 requirements for a >5k/day sender.
10. WSProxy vs REST vs SOAP — when each? What's SOAP Retrieve's per-call row cap?
11. The three DE retention modes, and how DE retention differs from engagement-data retention.
12. What is a Population in Data Designer, and why does 1:1 vs 1:M cardinality matter for Journey Builder?

➡️ Next: 02_Email_Studio_and_Content_Builder.md

Module 02 — Email Studio & Content Builder

Your daily workspace. Interviewers expect you to be fluent here. We cover the send pipeline, classifications/profiles, the preference-center layer, A/B testing, triggered/transactional sends, the tracking data model & retention, deliverability & authentication (SPF/DKIM/DMARC, SAP, Gmail/Yahoo 2024 rules), Einstein, and Content Builder.

---

1. Email Studio overview

Email Studio is where you build, configure, send, and track email. Core areas:

• Email (Content) — classic email editor. Classic Email content creation is deprecated/retired — Content Builder is the current and only supported content-authoring tool in Engagement. Legacy emails may still exist in this app, but every new build goes through Content Builder. If you describe classic Email as a current build path in an interview, you'll sound dated.
• Subscribers — Lists, Groups, All Subscribers, Data Extensions, Send Classifications, Profile/Preference attributes, Suppression lists.
• Interactions — Triggered Sends, User-Initiated Sends, Send definitions.
• A/B Testing.
• Tracking — per-send and aggregate reporting.
• Admin — Send Classifications, Sender/Delivery Profiles, Reply Mail Management, Header & Footer Rules, account settings.

---

2. The anatomy of a send 🔑

Every email send is composed of:

1. Email content (from Content Builder).
2. Audience — a Sendable Data Extension, list, or group (+ filters).
3. Exclusions / Suppressions — exclusion scripts (AMPscript) and suppression lists.
4. Send Classification — bundles the CAN-SPAM classification, Sender Profile, and Delivery Profile.
5. Send schedule — immediate or scheduled.

Send Classification 🔑

Defines the legal type of the message and ties together identity + delivery settings. - Commercial — marketing/promotional. Must honor CAN-SPAM (include unsubscribe + physical address). Respects unsubscribes. - Transactional — operational (order confirmations, password resets, receipts). Can bypass unsubscribe because it's not promotional — but you must use it correctly/legally. Sent typically via Triggered Sends or Transactional Messaging API.

A Send Classification = Sender Profile + Delivery Profile + CAN-SPAM classification.

Governance & legal nuance on Transactional classification (senior depth)

• A transactional classification suppresses the unsubscribe requirement, but CAN-SPAM still requires a valid physical mailing address in a transactional message. Only the unsubscribe is relaxed, not the address.
• Don't abuse it. A message is legally transactional only if its primary purpose is a transaction or relationship (receipt, shipping notice, password reset). Dressing a promo up as transactional to skip the unsubscribe is a CAN-SPAM violation and a deliverability/reputation risk — mailbox providers and Salesforce's compliance team police this. At GAP scale, abusing it can poison a whole IP/domain's reputation.
• There is also a "Commercial — unsubscribe honored but link suppressed" style exception used for things like account-required commercial mail; in practice you keep the unsub mechanism active and just control footer rendering. The cleaner mental model for interviews: Commercial = unsub mandatory; Transactional = unsub optional, physical address still mandatory, and the content must genuinely be transactional.
• Send Classification is also a prerequisite for Triggered Send Definitions — every TSD must reference a send classification.

Sender Profile 🔑

• Defines the From Name, the From Address, AND the Reply-To address / custom reply-mail routing behavior (used together with Reply Mail Management). It answers WHO the email is from and where replies go.
• From values (and Reply-To) can be set dynamically via AMPscript — e.g., route replies to a store-specific or region-specific mailbox, or set the From name per brand-market.
• e.g., Gap <news@gap.com>, Reply-To customerservice@gap.com.
• "Use custom reply mail management address" + the Reply-To here is what enables auto-reply handling, unsubscribe-by-reply, and OOO/bounce routing — it is not just a cosmetic From-line.

Delivery Profile 🔑

• Defines the sending IP address / IP pool and whether to include the account-default Header & Footer or none (the two options are typically Account Default vs None).
• Important precision: the footer content itself — the physical mailing address + unsubscribe link — is not authored inside the Delivery Profile. It is configured via Header & Footer Rules at the account/BU admin level (and the unsub link / physical address can also flow from the Profile Center / Subscription Center config). The footer is associated with the delivery profile, not written in it.
• If the Delivery Profile uses 'None', the sender must manually add an unsubscribe link + physical mailing address in the email content to stay CAN-SPAM compliant. This is a classic gotcha: a developer picks "None" to suppress the boilerplate footer, then ships a non-compliant commercial email.

Interview line: "A Send Classification packages a Sender Profile (who it's from and where replies go — From Name, From Address, Reply-To), a Delivery Profile (the sending IP/IP pool and whether to attach the account-default header/footer or none), and the CAN-SPAM classification (commercial vs transactional). The footer text comes from Header & Footer Rules at the admin level, not from the delivery profile itself. Transactional classification can suppress the unsubscribe requirement but still needs a physical address."

---

2b. Header & Footer Rules, Profile/Subscription Center & Publication Lists 🔑 (the preference layer — classic senior question)

This is the layer that actually generates the CAN-SPAM footer and powers preference-based unsubscribes. Most candidates skip it; interviewers love it.

Header & Footer Rules

• Set at the account/BU admin level. This is where the account-default footer (physical mailing address + unsubscribe link, plus optional VAWP link) is authored.
• The Delivery Profile only chooses whether to attach the default (Account Default) or not (None). The content lives here.

Profile Center vs Subscription Center

• Profile Center — the page where a subscriber updates their profile attributes (name, preferences, etc.). Reached via %%profile_center_url%%.
• Subscription Center — the page where a subscriber manages which Publication Lists they're opted into, and where the global unsubscribe lives. Reached via %%subscription_center_url%%. The default %%unsub_center_url%% / %%unsubscribe%% link routes here.
• Together these are the Preference Center. They can be customized as CloudPages for branded, granular preference management ("email me about Sale, not about Loyalty").

Three distinct kinds of opt-out — know the difference cold 🔑

1. List unsubscribe — opts the subscriber out of one specific List only. They still receive sends to other lists/DEs. (Legacy list model.)
2. All Subscribers (global / master) unsubscribe — opts the subscriber out of all commercial mail at the BU level. This is the hard "remove me" — sets subscriber status to Unsubscribed in All Subscribers.
3. Publication List opt-down — a marketer-managed channel. The subscriber opts out of a category (e.g., "Promotions") via the Subscription Center while staying subscribed to others (e.g., "Order updates"). This is how you offer "fewer emails" instead of "no emails," which protects your list size and reduces complaints.

Mapping to the One-Click List-Unsubscribe header (RFC 8058): the List-Unsubscribe / one-click header that Gmail & Yahoo now require maps to your global/master unsubscribe (or a configured publication-list opt-out). When a recipient hits the mailbox-provider "unsubscribe" button, SFMC must honor it — see the deliverability section. This is why your Subscription Center config and your List-Unsubscribe settings have to agree.

Interview line: "There are three opt-out scopes — a List unsubscribe (one list), an All Subscribers unsubscribe (global, sets status Unsubscribed BU-wide), and a Publication List opt-down (marketer-managed category, the 'send me fewer, not none' option managed in the Subscription Center). The CAN-SPAM footer comes from Header & Footer Rules, and the mailbox-provider one-click List-Unsubscribe header maps to the global/publication opt-out."

---

3. Send types 🔑 (know the differences cold)

The three ways to fire a "triggered/transactional" send (senior distinction) 🔑

1. Classic Triggered Send (SOAP TriggeredSend object) — the original. You reference a Triggered Send Definition (TSD). Supports throttling rules (e.g., cap at 10k/hr) and priority.
2. messageDefinitionSends REST endpoint — REST wrapper that also sends against a Triggered Send Definition. Same underlying TSD model, modern transport.
3. Transactional Messaging API (TMA) — POST /messaging/v1/email/messages/{messageKey}. The modern, true-1:1 path. Does NOT throttle — it queues and sends as fast as possible (highest throughput / SLA). Supports email, SMS, and push, returns per-message status callbacks (async webhook), and lets you query message status synchronously. Rate-limit behavior: REST returns HTTP 429 (respect Retry-After); the SOAP API returns 500 for performance-based throttling. Use TMA for order confirmations / password resets at scale.

Interview soundbite: "Classic Triggered Sends support throttling and priority; the Transactional Messaging API does not throttle — it queues and sends ASAP, supports email/SMS/push, and gives per-message status callbacks. So if I need to rate-limit (e.g., protect a downstream system or warm an IP) I use classic triggered with a throttle rule; if I need raw 1:1 throughput with delivery SLA I use TMA."

Transactional Messaging API request (REST):

POST /messaging/v1/email/messages/0e8a1c3f-... HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json

{
  "definitionKey": "order_confirmation_tx",
  "recipient": {
    "contactKey": "cust_8842193",
    "to": "shopper@example.com",
    "attributes": {
      "FirstName": "Ava",
      "OrderNumber": "GAP-771204",
      "OrderTotal": "$148.00"
    }
  }
}

🔍 Line by line: - POST /messaging/v1/email/messages/0e8a1c3f-... HTTP/1.1 — the Transactional Messaging API endpoint. The GUID after messages/ is the messageKey of a pre-created transactional send definition; you're telling SFMC "send this defined message." TMA is the modern, true-1:1 path that does not throttle. - Authorization: Bearer <token> — the OAuth 2.0 access token from your installed package (/v2/token). Every SFMC REST call needs this bearer token; it expires (~20 min) so production tooling refreshes it. - Content-Type: application/json — tells SFMC the body is JSON (not form data or XML). - (blank line) — the HTTP spec requires one blank line separating headers from the body. - "definitionKey": "order_confirmation_tx" — the external key of the transactional send definition (the email + sender/delivery profile bundle). This is what to send; the URL's messageKey is the routing target. - "recipient": { — opens the single recipient object. TMA is 1:1, so one recipient per call. - "contactKey": "cust_8842193" — the Contact Key / Subscriber Key, the platform's stable identity for this person. Use a durable business ID (here a customer number), not the email, so identity survives address changes. - "to": "shopper@example.com" — the destination email address for this send. - "attributes": { — opens the personalization payload — the values that fill %%FirstName%%, %%OrderNumber%%, etc. in the email at render time. - "FirstName": "Ava" — personalization value; renders wherever the email references FirstName. - "OrderNumber": "GAP-771204" — the order reference for an order-confirmation email; this is exactly the kind of transactional value you log to a SendLog so you can prove what each customer received. - "OrderTotal": "$148.00" — the order total; pre-formatted as a string here so the email doesn't have to do currency formatting in AMPscript. - 429 → back off using the Retry-After header; 200/202 → accepted, then watch the async status callback for Sent / Bounced / NotSent.

Contrast — classic SOAP TriggeredSend payload (conceptually):

<TriggeredSend>
  <TriggeredSendDefinition><CustomerKey>order_confirmation</CustomerKey></TriggeredSendDefinition>
  <Subscribers>
    <EmailAddress>shopper@example.com</EmailAddress>
    <SubscriberKey>cust_8842193</SubscriberKey>
    <Attributes><Name>OrderNumber</Name><Value>GAP-771204</Value></Attributes>
  </Subscribers>
</TriggeredSend>

🔍 Line by line: - <TriggeredSend> — the SOAP object you Create to fire a classic triggered send. This is the older path; it obeys the throttle/priority rules on the referenced TSD. - <TriggeredSendDefinition> — opens a reference to the Triggered Send Definition (TSD) — the pre-built bundle of email + sendable DE + send classification that this fire runs against. - <CustomerKey>order_confirmation</CustomerKey> — the external key of that TSD. CustomerKey is SOAP's name for the external/customer key you set when creating the definition. - </TriggeredSendDefinition> — closes the definition reference. - <Subscribers> — opens the recipient. Classic triggered send sends to one (or a small batch of) subscriber(s) per call. - <EmailAddress>shopper@example.com</EmailAddress> — the recipient's email address. - <SubscriberKey>cust_8842193</SubscriberKey> — the stable Subscriber Key (same identity concept as contactKey in REST). - <Attributes><Name>OrderNumber</Name><Value>GAP-771204</Value></Attributes> — one personalization name/value pair passed into the send; SOAP uses verbose <Name>/<Value> element pairs where REST uses a flat JSON object. Add one <Attributes> block per field. - </Subscribers> — closes the recipient block. - </TriggeredSend> — closes the object.

The SOAP path obeys the TSD's throttle/priority; the TMA path does not throttle.

Data-model & audit angle (how each is logged / debugged) 🔑

• User-Initiated Sends create a Job — visible in _Job, with per-subscriber rows in _Sent, _Open, _Click, etc. (the data-model section below). Easy to audit because there's one JobID.
• Triggered Sends log per trigger — each fire is its own send against the TSD; debug with a SendLog DE and the error/bounce events.
• Transactional Messaging API gives synchronous + callback status per message (best for real-time idempotency/retry). Retries should be idempotent — guard with the OrderNumber/contactKey so a retry doesn't double-send.

Triggered Send Definition (TSD) lifecycle & limits 🔑

• You create the TSD (links email + audience/sendable DE + send classification), then start/activate it, then fire it via API.
• A TSD must be in Active/Started status to accept triggers. If it is Paused, incoming triggers are queued, not dropped — when you restart, the queue flushes. (Triggers sent while the definition is Inactive/never-started are rejected.)
• Content-change refresh behavior (key gotcha): a TSD caches a snapshot of the email content. If you edit the email after the TSD is started, the change is not picked up automatically — you must pause and refresh (re-publish) the TSD (effectively a new version) for the new content to go out. This bites teams who "fix a typo" in a live welcome email and see nothing change.
• Key concepts: Send Throttling, Priority, Suppression, and the started-status requirement above.

---

4. A/B Testing 🔑 (you have direct experience — articulate it well)

SFMC's native A/B test lets you test exactly ONE variable per test. The supported native variables are: - Subject Line - Preheader - From Name - Email / Content (two email versions) - Send Date/Time (a fully supported, first-class option — not a fringe one)

Mechanics: 1. Define Test A and Test B. 2. Set the test split % (e.g., 10% of audience → 5% A, 5% B). 3. Choose the winner criterion — and this is a precision point interviewers probe: the native Email Studio A/B tool only supports highest Unique Open Rate or highest Unique Click Rate (CTR). Click-to-open / CTOR is NOT a selectable native winner criterion. If you need CTOR-based or conversion-based winner logic, you must run a manual/SQL split (see below). Also note: ties resolve in favor of Version A. 4. Set a test duration / wait period before picking the winner. 5. The winning version sends to the remaining 90% automatically (or you can choose to send the winner manually after review).

Your resume: "Delivered A/B testing frameworks improving CTR 12–15% and conversions 7%." Be ready to explain: - What you tested (subject lines, hero content, CTA, offer framing). - How you measured (open rate for subject tests, click rate for content tests via the native winner, CTOR/conversions via downstream tracking when you hand-rolled the split). - Why you sometimes hand-rolled it (native can't pick a CTOR or conversion winner; small lists pick noise).

Statistical rigor — the senior "why" 🔑

• Minimum detectable effect (MDE) & power: a 10% test split on a small list yields underpowered results — the test arms are too small to detect a real difference, so the "winner" is often noise. Bigger lists or a bigger split (or fewer, bolder variants) buy you power.
• Don't peek / don't stop early. Calling a winner the moment one version pulls ahead inflates false positives ("the peeking problem"). Let the wait period run; pre-commit to the duration.
• Apple MPP breaks Open-Rate winners. MPP pre-fetches the open pixel so opens are inflated/unreliable (see Tracking). So for the native tool, prefer the Click Rate winner over the Open Rate winner, or hand-roll a conversion-based split. This is exactly why your framework optimizing on CTR (+12–15%) rather than opens is defensible — say that out loud.

Manual A/B via SQL (full control, common at scale):

SELECT *, ROW_NUMBER() OVER (ORDER BY SubscriberKey) % 2 AS Bucket
FROM Lvl_Audience
-- Bucket 0 → Version A DE, Bucket 1 → Version B DE

🔍 Line by line: - SELECT *, — pulls every column from the source audience so the resulting DE is still a complete, sendable audience; we just add one extra column. - ROW_NUMBER() OVER (ORDER BY SubscriberKey) — assigns each row a sequential number 1, 2, 3… The OVER (ORDER BY SubscriberKey) is the window that tells SQL the ordering used to number the rows. Ordering by SubscriberKey makes the assignment deterministic — re-run it and the same person lands in the same bucket. - % 2 AS Bucket — the modulo operator returns the remainder when divided by 2, so odd row numbers → 1, even → 0. This is the classic 50/50 split into two buckets. Use % 3 for a 3-way, % 4 for quarters. - FROM Lvl_Audience — the source audience DE (a GAP naming-convention DE; Lvl_ is a layered/leveled staging prefix). - -- Bucket 0 → Version A DE, Bucket 1 → Version B DE — a comment reminding you to route each bucket to its own sendable DE (filter WHERE Bucket = 0 into the A DE, Bucket = 1 into the B DE), then send each version. This is the manual equivalent of the native A/B split, but you control the criterion and can pick a CTOR/conversion winner.

🧪 More robust split — stable hashed buckets that survive list growth. ROW_NUMBER() re-numbers everyone when the audience changes (a new row in the middle shifts everyone after it). For a split that keeps a given person in the same arm across sends, hash the key instead:

SELECT *,
  ABS(CHECKSUM(SubscriberKey)) % 100 AS HashBucket,            -- 0–99 stable per key
  CASE WHEN ABS(CHECKSUM(SubscriberKey)) % 100 < 50
       THEN 'A' ELSE 'B' END        AS Arm                      -- 50/50, deterministic
FROM Lvl_Audience;

🔍 Line by line: - SELECT *, — keep all audience columns, then append the split columns. - ABS(CHECKSUM(SubscriberKey)) % 100 AS HashBucket — CHECKSUM() hashes the SubscriberKey to an integer; ABS() strips the sign (CHECKSUM can return negatives, which would break the modulo); % 100 maps it into 0–99. Because it hashes the key itself (not the row position), the same person always hashes to the same bucket even as the list grows — no drift between sends. - CASE WHEN ... % 100 < 50 THEN 'A' ELSE 'B' END AS Arm — turns the 0–99 bucket into a labeled arm: buckets 0–49 → 'A', 50–99 → 'B' (a clean 50/50). To make a 10% holdout, use < 10 for the holdout and route the rest normally. - FROM Lvl_Audience; — the source audience DE. Filter on Arm to build each version's sendable DE.

Hand-rolled CTOR / conversion winner (since native can't): When you must pick the winner on CTOR or a downstream conversion (native only does Open/Click), split the holdout, send both arms, measure after a window, then route the winner to the remaining 90% via a control flag and an Automation:

/* 1. After the test window, score each arm from the tracking data views */
SELECT
  j.EmailName,
  COUNT(DISTINCT o.SubscriberKey)                                   AS UniqueOpens,
  COUNT(DISTINCT c.SubscriberKey)                                   AS UniqueClicks,
  CAST(COUNT(DISTINCT c.SubscriberKey) AS FLOAT)
     / NULLIF(COUNT(DISTINCT o.SubscriberKey),0)                    AS CTOR
FROM _Job j
LEFT JOIN _Open  o ON o.JobID = j.JobID
LEFT JOIN _Click c ON c.JobID = j.JobID
WHERE j.JobID IN (<jobA>, <jobB>)
GROUP BY j.EmailName;

/* 2. Write the winning creative key to a control DE the 90% send reads */
/*    UPDATE OfferControl SET WinningCreative = 'B' WHERE CampaignID = '<cid>'  */

🔍 Line by line: - /* 1. After the test window... */ — a block comment; SFMC SQL uses /* */ for multi-line and -- for single-line comments. Reminds you to score after the wait period, not the moment one arm leads (the peeking problem). - SELECT — begins the scoring query that produces one row per email/arm with its metrics. - j.EmailName, — the email's name from the _Job view, so each arm is human-readable in the output. - COUNT(DISTINCT o.SubscriberKey) AS UniqueOpens — counts distinct openers (one per person no matter how many times they opened) → unique opens. DISTINCT is what makes it unique rather than total. - COUNT(DISTINCT c.SubscriberKey) AS UniqueClicks — same idea for clicks: distinct clickers = unique clicks. - CAST(COUNT(DISTINCT c.SubscriberKey) AS FLOAT) — counts unique clickers and casts to FLOAT so the division below yields a decimal, not integer truncation (without the cast, 5/10 would be 0). - / NULLIF(COUNT(DISTINCT o.SubscriberKey),0) AS CTOR — divides unique clicks by unique opens to get CTOR. NULLIF(...,0) turns a zero denominator into NULL so you get a null instead of a divide-by-zero error (a key SQL safety habit). - FROM _Job j — the send-job metadata data view, aliased j. This is the anchor table (one row per job). - LEFT JOIN _Open o ON o.JobID = j.JobID — joins open events for that job. LEFT JOIN keeps the job row even if there are zero opens. - LEFT JOIN _Click c ON c.JobID = j.JobID — joins click events for that job, again as a LEFT JOIN. - WHERE j.JobID IN (<jobA>, <jobB>) — limits scoring to the two test jobs (arm A and arm B). Replace the placeholders with the real JobIDs from the test send. - GROUP BY j.EmailName; — collapses to one row per email so the aggregate COUNTs are per-arm. Any non-aggregated column in SELECT must appear here. - /* 2. ... UPDATE OfferControl SET WinningCreative = 'B' ... */ — commented because SQL Query activities are SELECT-only — you can't run UPDATE directly. In practice you write the winner to the control DE via a target-DE Update action or a Script activity; this comment documents the intent (stamp 'B' as the winner for this campaign so the 90% send reads it).

The 90% send then resolves the winning creative per-subscriber at render time via a Lookup against OfferControl (same control-DE pattern as the double-build in Section 11). For a true conversion winner, join your downstream Sales/Service Cloud or Web Analytics conversion data instead of _Click.

---

5. Exclusions & Suppressions 🔑

Three mechanisms, know all three (and when to reach for each):

• Suppression List — suppresses by EMAIL ADDRESS (not SubscriberKey). Attached at send time. Records on a suppression list have no subscriber status and don't count toward your All Subscribers total. Good for global "do not contact," legal suppressions, competitor domains. Precision point: don't conflate this with exclusion-by-SubscriberKey — a suppression list is email-keyed, and a suppressed person is simply invisible to the count, whereas an excluded/unsubscribed subscriber remains active and counted.
• Exclusion Script — an AMPscript boolean expression evaluated per subscriber at send time; when it returns TRUE, the subscriber is EXCLUDED. Can key off SubscriberKey, attributes, or anything resolvable at send. The subscriber stays active and counted; they're just skipped this send.
• SQL pre-filter — you filter the audience when you build the sendable DE (in an Automation query). Most performant at scale.

Correct exclusion script as actually entered in the send UI — the UI expects a single boolean expression that excludes when TRUE:

%%[ IF EMPTY(emailaddr) OR AttributeValue("DoNotMail") == "True" THEN ]%% true %%[ ENDIF ]%%

🔍 Line by line: - %%[ ... ]%% — the AMPscript code block delimiters. Anything between %%[ and ]%% is logic that runs but produces no visible output; output happens outside the block (here the literal word true). - IF EMPTY(emailaddr) — EMPTY() returns true when a value is null or blank; emailaddr is the built-in send-context attribute for the recipient's email. So this drops anyone with no email address. - OR AttributeValue("DoNotMail") == "True" — OR means either condition triggers exclusion. AttributeValue("DoNotMail") reads the send-context attribute/column named DoNotMail; == "True" compares it (as a string) to the flag value. So this also drops anyone explicitly flagged do-not-mail. - THEN ]%% true %%[ ENDIF ]%% — when the IF is true, AMPscript exits the code block and outputs the literal text true, then re-enters a block to close with ENDIF. The send UI excludes the subscriber whenever the script's rendered output is true — so you deliberately emit true for the people you want to drop. - Key gotcha restated: you write the boolean for who to exclude, not who to keep. If you accidentally invert it, you exclude your whole audience and mail nobody.

(If the resolved output is true, the subscriber is excluded. So you write the condition for who to drop, not who to keep — a very common mix-up.)

🧪 Richer exclusion script (GAP retail): drop null emails, do-not-mail flags, and a competitor/employee domain in one expression. Useful when you can't bake the rule into the sendable DE:

%%[
  SET @email  = AttributeValue("emailaddr")
  SET @domain = Substring(@email, IndexOf(@email,"@") + 1, Length(@email))
  SET @dnm    = AttributeValue("DoNotMail")
  IF EMPTY(@email)
     OR @dnm == "True"
     OR @domain == "competitor.com"
     OR IndexOf(@email,"@") == 0 THEN
]%%true%%[ ENDIF ]%%

🔍 Line by line: - %%[ — open the AMPscript block. - SET @email = AttributeValue("emailaddr") — read the recipient's email into a variable @email so we can reuse and parse it. SET assigns; @-prefixed names are AMPscript variables. - SET @domain = Substring(@email, IndexOf(@email,"@") + 1, Length(@email)) — extract the domain part. IndexOf(@email,"@") finds the position of @; + 1 starts just after it; Substring(value, start, length) slices from there to the end (Length(@email) as an over-long length safely grabs the rest). Result for ava@gap.com is gap.com. - SET @dnm = AttributeValue("DoNotMail") — read the do-not-mail flag column into @dnm. - IF EMPTY(@email) — exclude if there's no address at all. - OR @dnm == "True" — or if explicitly flagged do-not-mail. - OR @domain == "competitor.com" — or if the address is on a competitor (or internal/test) domain you never want to mail. Swap in real domains. - OR IndexOf(@email,"@") == 0 THEN — IndexOf returns 0 when the substring isn't found, so this catches malformed addresses with no @ at all. THEN ends the condition. - ]%%true%%[ ENDIF ]%% — emit literal true (exclude this subscriber) when any condition matched, then close the IF. As before, rendered true = excluded.

Same logic, but pre-filtered in SQL at audience-build time (more performant):

SELECT *
FROM Lvl_AllShoppers
WHERE EmailAddress IS NOT NULL
  AND EmailAddress <> ''
  AND (DoNotMail IS NULL OR DoNotMail <> 'True')
-- Result DE becomes the sendable audience; no per-subscriber exclusion script needed.

🔍 Line by line: - SELECT * — pull all columns so the result DE remains a complete, sendable audience. - FROM Lvl_AllShoppers — the source audience DE (the full shopper population before filtering). - WHERE EmailAddress IS NOT NULL — keep only rows that have an email. IS NOT NULL is the SQL way to test for a present value (you can't use <> NULL). - AND EmailAddress <> '' — also drop empty-string emails. A column can be non-null yet blank (''), so you need both this and the IS NOT NULL check to be safe. - AND (DoNotMail IS NULL OR DoNotMail <> 'True') — keep rows where the do-not-mail flag is either unset (IS NULL) or not 'True'. The parentheses group the OR so it's evaluated as one condition; without them the precedence would be wrong. This is the SQL equivalent of the exclusion script's DoNotMail == "True" drop, but done once at build time instead of per-subscriber at send time — far cheaper at GAP scale. - -- Result DE becomes the sendable audience... — comment: because the filtering already happened here, the resulting DE is clean and you don't need an exclusion script on the send.

Order of operations at send time 🔑

When the send executes, SFMC applies all the do-not-send layers together, roughly: 1. Subscriber status — Unsubscribed, Held, and Bounced records are skipped (status section under Tracking). 2. Suppression lists attached to the send (email-address match). 3. Exclusion script — evaluated per subscriber. 4. Suppress Duplicates (if enabled) — collapses repeat email addresses in the audience. The union of all of these is removed; the remainder receives the email.

Performance: exclusion script vs SQL pre-filter 🔑

• An exclusion script runs per subscriber at send time, so on a multi-million-row GAP blast it adds send-time overhead and can slow the send.
• A SQL pre-filter does the work once at audience-build time — far cheaper at scale.
• When to use each: Suppression list for global do-not-contact / legal; Exclusion script for dynamic per-send logic you can't bake into the DE (e.g., a value that changes by send context); SQL pre-filter for everything you can resolve at build time — especially large sends.

Be precise in interview: Suppression list = static, email-keyed, uncounted; Exclusion script = dynamic per-subscriber boolean that EXCLUDES when true (and costs send-time CPU); SQL pre-filter = cheapest at scale, do it at audience build.

---

6. View As Web Page (VAWP) 🔑 — you list VAWP debugging on your resume!

• VAWP = the browser-viewable version of an email ("Having trouble viewing? Click here"). The native link is emitted via the %%view_email_url%% personalization string (and the account-default footer can include it).
• It's a CloudPage-rendered version of the email content.

Native VAWP vs a custom CloudPage "web version" — get this right 🔑

• Native VAWP (%%view_email_url%%) actually passes the job / subscriber / batch context through to the rendered CloudPage. So most send-time personalization resolves correctly in the native web version. The blanket claim "VAWP renders outside the send context so everything is null" is overstated — for the native link it usually works.
• A custom web version is one you build yourself via CloudPagesURL() pointing at your own CloudPage. That is where the null-context problem bites, because you are responsible for passing identifiers in the URL and re-hydrating the subscriber.

When VAWP personalization actually comes back null

1. You built a custom web version via CloudPagesURL() without passing identifiers (no subscriber key / job id).
2. The link or its query string is stripped or shared (forwarded to a friend, security scanner rewrites it, the qs gets dropped).
3. You rely on profile attributes that aren't present in the web context (a value that only existed in the send-time sendable DE row).

Re-hydration pattern (custom web version): pass an identifier, then Lookup to rebuild context.

%%[
  SET @sk    = RequestParameter("sk")                         /* or AttributeValue("_subscriberkey") for native */
  SET @row   = LookupRows("Lvl_Audience","SubscriberKey", @sk)
  IF RowCount(@row) > 0 THEN
    SET @first = Field(Row(@row,1), "FirstName")
  ELSE
    SET @first = "there"                                       /* null guard / fallback */
  ENDIF
]%%
Hi %%=v(@first)=%%, ...

🔍 Line by line: - %%[ — open the AMPscript code block. - SET @sk = RequestParameter("sk") — read the sk value from the page's query string (...?sk=...). RequestParameter() works on CloudPages to pull URL params. The comment notes that on a native VAWP you'd instead read AttributeValue("_subscriberkey") because native VAWP carries the send context. - SET @row = LookupRows("Lvl_Audience","SubscriberKey", @sk) — LookupRows(DE, fieldName, value) returns all rows from Lvl_Audience where SubscriberKey equals @sk. This re-fetches the subscriber's data to rebuild the context that the web version lost. - IF RowCount(@row) > 0 THEN — RowCount() returns how many rows came back; > 0 means we found the subscriber. Always check this before reading fields, or a missing row throws an error. - SET @first = Field(Row(@row,1), "FirstName") — Row(@row,1) grabs the first returned row (AMPscript rowsets are 1-indexed, not 0); Field(row, "FirstName") pulls the FirstName column from it. So @first is now the looked-up first name. - ELSE — runs when no row matched (unknown/bad sk). - SET @first = "there" — the fallback / null guard so the greeting reads "Hi there," instead of "Hi ," when the lookup fails. Always provide a default. - ENDIF — closes the IF. - ]%% — close the code block. - Hi %%=v(@first)=%%, ... — outputs the variable into the page. %%=v(@var)=%% is the AMPscript inline-output syntax for a variable's value.

Security consideration (senior point) 🔑

Don't expose PII in a guessable web URL. ?sk=cust_8842193 is enumerable — someone can iterate keys and pull up other people's personalized pages. Use an encrypted/obfuscated SubscriberKey or a one-time token (e.g., EncryptSymmetric / a GUID column you look up), and validate it server-side before rendering.

How you fix VAWP issues (great STAR material):

"The native VAWP link passes job/subscriber/batch context, so most personalization resolves there. Nulls show up mainly with custom web versions built via CloudPagesURL() without identifiers, or when the query string is stripped/shared. I guard with null checks and a fallback, re-establish context by reading URL params and Lookup-ing against the audience DE, and I never put a raw SubscriberKey in the URL — I pass an encrypted token so the page isn't enumerable."

---

7. Tracking & Reporting

Per-send tracking shows: Sent, Delivered, Bounces (hard/soft), Opens (unique/total), Clicks (unique/total), CTR, CTOR, Unsubscribes, Complaints, Forwards, Conversions.

Key metric definitions (be precise): - Open Rate = Unique Opens / Delivered. (Note: opens rely on a tracking pixel — undercounts with image blocking; Apple Mail Privacy Protection inflates/obscures.) - CTR (Click-Through Rate) = Unique Clicks / Delivered. - CTOR (Click-to-Open Rate) = Unique Clicks / Unique Opens — measures content effectiveness given it was opened. - Bounce Rate = Bounces / Sent. Hard bounce = permanent (bad address); Soft bounce = temporary (full mailbox, server down). - Delivery Rate = Delivered / Sent.

⚠️ State your denominator explicitly. SFMC's native tracking surfaces multiple click measures. The Tracking dashboard's "Click-through rate" is typically Unique Clicks / Delivered, but the _Click data view lets you compute total clicks too, and some views/practitioners use total clicks / delivered. Interviewers test whether you know unique vs total and delivered vs sent — so always say which you mean rather than reciting "CTR" bare.

🔑 Why opens are unreliable (beyond MPP): - Apple Mail Privacy Protection (MPP) pre-fetches the tracking pixel → opens look ~100%, with no real signal about who actually read it. - Bot / security-scanner pre-fetch opens — corporate link-rewriters and spam filters fetch the pixel (and even click links) before the human ever sees the email, manufacturing phantom opens/clicks. - Image caching / proxies further distort the count. - Conclusion: lean on clicks and (best) conversions, not opens, for optimization and A/B winners. This is exactly why your CTR-led A/B framework is the right call — say it.

🔑 Tie metrics to deliverability: a high complaint rate and low engagement degrade your IP/domain reputation, which pushes you toward spam/Promotions and lowers inbox placement — so "delivered" silently drops. Metrics aren't just reporting; they feed back into whether your next send even reaches the inbox.

Subscriber statuses 🔑 (and how bounces escalate)

Four statuses you must be able to name: - Active — receivable, no issues. - Bounced — has one or more bounces but not yet deactivated. - Held — temporarily un-mailable after repeated soft/technical bounces (SFMC retries soft bounces, then holds). A Held address is skipped at send; it can recover. - Unsubscribed — opted out (List, All Subscribers, or via reply/one-click). - (Undeliverable) — effectively dead after hard bounces.

Recovery: if a Held/Bounced subscriber later opens or clicks, SFMC can reset them to Active. RMM (Section 8) feeds bounce processing back into these statuses.

Bounce types (deeper than hard/soft) 🔑

• Hard bounce — permanent (invalid/non-existent address or domain).
• Soft bounce — temporary (full mailbox, server down, message too large). SFMC retries soft bounces over a window; repeated soft bounces escalate the subscriber toward Held.
• Block bounce — the receiving server blocked the message (content/reputation/blocklist). A deliverability signal, not a bad address — investigate IP/domain reputation.
• Technical bounce — DNS / connection / protocol failure on the receiving side. The flow: bounce events are processed (via RMM) → counted in _Bounce → repeated failures escalate status (Bounced → Held → Undeliverable) → engagement can reset to Active.

Conversion tracking — how SFMC actually captures it 🔑

The metrics list shows "Conversions," but you must articulate how they're attributed (interviewers ask this): - Impression/Conversion tracking pixels placed on the confirmation/thank-you page tied back to the send. - Web & Mobile Analytics (Marketing Cloud) — SFMC's own tagging that ties on-site behavior/purchase to the email. - UTM parameters → Google Analytics / GA4 — the most common real-world path: stamp utm_source/medium/campaign on email links and read conversions in GA. - Downstream Sales/Service Cloud — for B2B / CRM-connected orgs, the conversion is an Opportunity/Order back in core Salesforce, joined by ContactKey. At GAP, the practical attribution path is usually UTM-tagged links → web analytics / order data, then joined back to the send in a reporting DE.

Send/email size & rendering limits (operational) 🔑

• Gmail clips at ~102 KB — anything past that is hidden behind "[Message clipped] View entire message," which can cut off your footer/unsubscribe and tracking pixel. AMPscript-heavy emails are dangerous here because the rendered HTML (post-personalization) is what counts, not your source. Keep rendered size lean.
• Dark mode — design for color inversion (transparent PNGs, dark-mode-safe logos), not just the MPP open-rate issue.

---

7b. The tracking DATA MODEL & Data Views 🔑 (query it, don't just read the UI)

Senior candidates are expected to pull tracking via SQL against Data Views, not just stare at the dashboard. Data Views are system DEs you SELECT from in a Query Activity (you can't write to them, and they live in the shared / parent context).

Retention: Data Views retain about 6 months (180 days) of tracking. If you need history beyond that, export to your own DE / data warehouse on a schedule.

SQL — compute a real open rate from the data model (illustrating the join):

SELECT
  s.SubscriberKey,
  s.EventDate,
  CASE WHEN o.SubscriberKey IS NULL THEN 0 ELSE 1 END AS Opened
FROM _Sent s
LEFT JOIN _Open o
       ON s.SubscriberKey = o.SubscriberKey
      AND s.JobID         = o.JobID
      AND o.IsUnique      = 'true'   -- count unique opens only
WHERE s.JobID = 1234567;
-- NOTE: _Open includes Apple MPP and bot/scanner opens. There is no perfect
-- server-side flag for MPP, so engagement-quality work leans on _Click, not _Open.

🔍 Line by line: - SELECT — begins the query that returns one row per sent subscriber with an opened/not-opened flag. - s.SubscriberKey, — the subscriber's key from the _Sent view (aliased s). - s.EventDate, — when the send event happened for that subscriber. - CASE WHEN o.SubscriberKey IS NULL THEN 0 ELSE 1 END AS Opened — a CASE expression that outputs 0 if there was no matching open row (the LEFT JOIN produced nulls) and 1 if there was. This converts "did a matching open exist?" into a tidy 0/1 flag you can AVG() to get an open rate. - FROM _Sent s — the _Sent data view is the base: one row per subscriber per send. Anchoring on _Sent (not _Open) is what lets you count non-openers too. - LEFT JOIN _Open o — attach open events. LEFT JOIN keeps every sent row even when there's no open, which is exactly how you measure who didn't open. - ON s.SubscriberKey = o.SubscriberKey — match opens to the same person… - AND s.JobID = o.JobID — …and the same send job, so you don't credit an open from a different campaign. - AND o.IsUnique = 'true' — only count unique opens (one per person), not every repeat open. IsUnique is the data-view flag that distinguishes unique from total. - WHERE s.JobID = 1234567; — scope to one specific send job. Replace with the JobID you're analyzing. - -- NOTE: ... — the caveat: _Open is polluted by Apple MPP and bot/scanner pre-fetches with no reliable server-side MPP flag, so for real engagement quality you lean on _Click.

SendLog DE — your debugging black box for triggered/transactional sends 🔑 Triggered/transactional sends are hard to debug after the fact (no single JobID to eyeball). The pattern is a SendLog DE: a DE named _SendLog that SFMC auto-writes to during sends when configured, plus your own AMPscript writes for resolved values. Log JobID, SubscriberKey, the resolved offer/personalization value, and a timestamp at send time, so a failed/blank personalization can be diagnosed post-send.

-- Create a SendLog DE (key fields). SFMC recognizes a DE named "_SendLog".
-- Columns (example): JobID, ListID, BatchID, SubID, TriggeredSendID,
--                    SubscriberKey, OfferResolved, LogDate

🔍 Line by line: - -- Create a SendLog DE (key fields)... — a comment block (not runnable SQL); it documents the schema of the logging DE you create manually in the UI. - -- SFMC recognizes a DE named "_SendLog" — naming the DE exactly _SendLog lets SFMC's built-in Send Logging feature auto-populate the standard columns during sends; you can add your own columns on top. - -- Columns (example): JobID, ListID, BatchID, SubID, TriggeredSendID, — the system fields SFMC fills automatically: JobID/ListID/BatchID/SubID identify the exact send and recipient slice; TriggeredSendID ties a triggered fire back to its TSD (critical because triggered sends have no batch report). - -- SubscriberKey, OfferResolved, LogDate — SubscriberKey is the person; OfferResolved and LogDate are your custom columns where you stamp the resolved personalization value and a timestamp so you can prove what rendered.

%%[
  /* inside the email body, at SEND/render time */
  SET @sk     = AttributeValue("_subscriberkey")
  SET @job    = AttributeValue("jobid")
  SET @offer  = Lookup("OfferControl","OfferPct","CampaignID", @cid)

  InsertData("_SendLog",
    "JobID", @job,
    "SubscriberKey", @sk,
    "OfferResolved", @offer,
    "LogDate", Now())
]%%

🔍 Line by line: - %%[ — open the AMPscript block. Placing this in the email body means it runs at per-subscriber render time, which is exactly when the offer resolves — so the log captures the real value each person got. - /* inside the email body, at SEND/render time */ — an AMPscript comment noting the timing; this would not work as intended in a commit-time context. - SET @sk = AttributeValue("_subscriberkey") — capture the system subscriber key into @sk. _subscriberkey is a built-in send-context attribute. - SET @job = AttributeValue("jobid") — capture the send's JobID into @job so the log row can be tied back to the exact send. - SET @offer = Lookup("OfferControl","OfferPct","CampaignID", @cid) — Lookup(DE, returnField, matchField, matchValue) fetches the single OfferPct value from OfferControl where CampaignID = @cid. This is the same render-time lookup the double-build pattern uses; logging it lets you later confirm whether the offer resolved or came back blank. - InsertData("_SendLog", ...) — InsertData(DE, field1, value1, field2, value2, ...) writes a new row into _SendLog with the name/value pairs that follow. (InsertData doesn't return anything; use Lookup/UpsertData when you need to read or upsert.) - "JobID", @job, — write the captured JobID into the JobID column. - "SubscriberKey", @sk, — write the subscriber key. - "OfferResolved", @offer, — write what the offer actually resolved to — the whole point of the log. - "LogDate", Now()) — Now() returns the current server datetime; stamps when this row was written. ) closes InsertData. - ]%% — close the AMPscript block. Now if a customer reports a blank offer, you SELECT * FROM _SendLog WHERE SubscriberKey = '...' and see exactly what resolved (or didn't) for that person on that job — invaluable for triggered/transactional sends where there's no batch report to read.

Send Email automation audience SQL — engagement-suppressed, dedup'd, multi-brand 🧪 A realistic GAP-style query that builds the sendable DE an Automation Send Email activity points at: opted-in, not globally unsubscribed, recently engaged, one row per person, scoped to a brand.

SELECT
    sub.SubscriberKey,
    sub.EmailAddress,
    sub.FirstName,
    sub.BrandPref
FROM   Lvl_AllShoppers          sub
LEFT JOIN _Unsubscribe          u   ON sub.SubscriberKey = u.SubscriberKey
WHERE  sub.BrandPref     = 'GAP'                       -- scope to one brand-market
  AND  sub.EmailAddress IS NOT NULL
  AND  sub.OptInStatus   = 'Y'
  AND  u.SubscriberKey  IS NULL                        -- anti-join: drop global unsubs
  AND  EXISTS (                                        -- engaged in last 90 days
        SELECT 1 FROM _Open o
        WHERE  o.SubscriberKey = sub.SubscriberKey
          AND  o.EventDate >= DATEADD(DAY, -90, GETDATE())
       )
  AND  sub.SubscriberKey IN (                          -- de-dup to ONE row per key
        SELECT SubscriberKey FROM Lvl_AllShoppers GROUP BY SubscriberKey
       );
-- Target DE: Send_GAP_Today  |  Action: Overwrite  → point the Send Email activity here

🔍 Line by line: - SELECT sub.SubscriberKey, sub.EmailAddress, sub.FirstName, sub.BrandPref — the columns the sendable DE needs: identity, the address, a personalization field, and the brand tag. Keep it lean — the send only needs sendable + personalization fields. - FROM Lvl_AllShoppers sub — the master shopper DE, aliased sub. - LEFT JOIN _Unsubscribe u ON sub.SubscriberKey = u.SubscriberKey — attach the unsubscribe data view. A LEFT JOIN keeps everyone and leaves u's columns null for people who never unsubscribed — which sets up the anti-join below. - WHERE sub.BrandPref = 'GAP' — scope to a single brand-market. In a multi-brand org (GAP / Old Navy / Banana Republic) this prevents cross-brand mailing. - AND sub.EmailAddress IS NOT NULL — only mailable rows. - AND sub.OptInStatus = 'Y' — only opted-in subscribers (permission). - AND u.SubscriberKey IS NULL — the anti-join: keep only rows where the unsubscribe table had no match (its key came back null), i.e., people who have not globally unsubscribed. This is the standard SQL way to "exclude everyone in table B." - AND EXISTS ( SELECT 1 FROM _Open o WHERE o.SubscriberKey = sub.SubscriberKey AND o.EventDate >= DATEADD(DAY, -90, GETDATE()) ) — an engagement filter: EXISTS returns true if the subscriber has at least one open in the last 90 days. DATEADD(DAY, -90, GETDATE()) is "90 days ago"; SELECT 1 is a convention meaning "we only care that a row exists, not its contents." Suppressing unengaged contacts protects the complaint rate the Gmail/Yahoo rules cap. - AND sub.SubscriberKey IN ( SELECT SubscriberKey FROM Lvl_AllShoppers GROUP BY SubscriberKey ) — a simple de-dup guard ensuring one row per key (a fuller dedup would use ROW_NUMBER() to pick a specific surviving row; the send itself also has a Suppress Duplicates option as a backstop). - -- Target DE: Send_GAP_Today | Action: Overwrite — comment: write the result into the sendable DE with Overwrite (full daily rebuild), then aim the Send Email activity at Send_GAP_Today.

---

7c. Data retention windows 🔑 (concrete numbers interviewers test)

Three different retention concepts — don't conflate them: 1. Data Views (tracking via SQL) retain ~6 months (180 days). 2. Engagement data via Email Studio Tracking + Analytics Builder reports retains 730 days (2 years) as of June 16, 2025 (raised from the previous 180 days). After 730 days, engagement data is no longer accessible via Tracking/reports — export it if you need longer. 3. Data Extension data retention is a per-DE setting you configure (delete records / delete the DE / delete all on a schedule, e.g., individual records older than N days). This is separate from the platform engagement-retention policy above and applies to your DEs.

Interview soundbite: "Data Views give me ~180 days of tracking via SQL; the broader engagement reporting policy is 730 days as of June 2025; and DE-level retention is whatever I configure per data extension. Three different clocks — I export tracking to a warehouse for anything I need beyond those windows."

---

8. Reply Mail Management (RMM)

• Handles automatic replies / bounces / out-of-office / unsubscribe-by-reply.
• Routes replies, processes bounces back into subscriber status, can auto-unsubscribe on "remove" replies.
• Part of the Sender Authentication Package (SAP) — gives you a branded reply address on your authenticated domain (see Deliverability).

---

8b. Deliverability & Authentication 🔑🔑 (the weakest area for most candidates — own it)

This is core senior content. Email reaching the inbox is a function of authentication + reputation, not just content.

Authentication: SPF, DKIM, DMARC

• SPF (Sender Policy Framework) — a DNS TXT record listing which servers/IPs are authorized to send for your domain. Validates the envelope/return-path sender.
• DKIM (DomainKeys Identified Mail) — a cryptographic signature in the header; the receiver verifies it against a public key in your DNS. Proves the message wasn't tampered with and is genuinely from your domain.
• DMARC — a policy (p=none | quarantine | reject) published in DNS that tells receivers what to do when SPF/DKIM fail alignment, and where to send aggregate reports. Alignment means the visible From domain matches the SPF/DKIM-authenticated domain. p=none is the minimum for bulk sending; quarantine/reject are stronger anti-spoofing.
• Reply-To / From domain alignment matters: for DMARC to pass, the From domain (and ideally Reply-To) should align with the authenticated sending domain — which is why the Sender Profile's Reply-To and your authenticated domain need to agree.

Sender Authentication Package (SAP) — SFMC's deliverability bundle 🔑

SAP is the Marketing Cloud add-on that sets up authenticated, branded sending. It includes: - Authenticated/Private Sending Domain (your domain, SPF + DKIM configured for SFMC) and a custom domain for CloudPages. - Dedicated IP address for the account. - Branded link & image wrapping — tracked links/images use your domain instead of generic *.mc...exacttarget.com, which lifts trust and reputation. - Account branding for View-as-Web-Page. - Reply Mail Management with a branded reply address.

Without SAP you send on shared IPs/domains and generic wrapped links — fine for low volume, weak for a brand at GAP scale.

Dedicated vs Shared IP (trade-offs)

• Shared IP — you share reputation with other SFMC customers. Good for low/spiky volume (the pool's steady traffic keeps the IP "warm"); bad because a noisy neighbor can dent your placement.
• Dedicated IP — your reputation alone. Recommended above roughly 250k emails/month and for consistent senders. But a dedicated IP must be warmed, and low/irregular volume on a dedicated IP looks suspicious (no established pattern).
• IP reputation vs domain reputation: mailbox providers track both. Domain reputation increasingly dominates (it follows you even if you change IPs), so protect the From/DKIM domain, not just the IP.

IP warming

• A new dedicated IP has no reputation — blasting full volume day one gets you throttled/blocked. Warm it: start small (most engaged subscribers first), ramp volume over ~4–6 weeks, growing daily volume gradually so providers build trust. Engaged openers/clickers early = better reputation faster.
• Seed lists — addresses across major providers (Gmail, Yahoo, Outlook) you send to in order to monitor inbox vs spam placement and rendering before/while ramping.

Gmail & Yahoo 2024 bulk-sender requirements 🔑 (near-certain 2024–2026 interview question)

For senders of >5,000 messages/day to Gmail (and Yahoo's equivalent): 1. SPF + DKIM both configured, aligned, and DMARC published with p=none minimum on the From domain. 2. One-click List-Unsubscribe header per RFC 8058 (and RFC 2369) — and you must honor it within ~2 days. 3. Spam complaint rate kept under 0.3%, with <0.1% as the safe target. 4. Valid PTR / forward-confirmed reverse DNS (FCrDNS) on the sending IP, and TLS for transport.

Scenario Q&A — "GAP sends >5,000/day to Gmail. What must be true?"

"SPF and DKIM both set up and DMARC-aligned with at least p=none; an RFC 8058 one-click List-Unsubscribe header that we honor within ~2 days; spam complaints under 0.3% (we target <0.1%); valid reverse DNS/PTR on the sending IP; and TLS. In SFMC I'd lean on the Sender Authentication Package (authenticated domain, DKIM, dedicated IP, branded links) and make sure the List-Unsubscribe / Subscription Center settings honor the one-click header. Then I'd watch the _Complaint data view and seed-list placement to keep us under the complaint threshold."

---

8c. Send-flow internals, throttling & send mechanics 🔑

• Commit time vs send time (the most important rendering nuance):
• Commit-time AMPscript runs once per send job when SFMC builds/compiles the send. Anything that must vary per subscriber must NOT be commit-time or every recipient gets the same value.
• Send/render time AMPscript runs per subscriber as each message is generated. Lookups, personalization, and last-second control-DE flips belong here. This is the reason the double-build offer-flip (Section 11) works — the Lookup must resolve at per-subscriber render, not commit.
• Send Throttling / send windows — account- or send-level setting to cap throughput (e.g., only send during business hours, or no more than X/hour) to protect downstream systems or warm an IP. (Classic Triggered Sends support throttle rules; the Transactional Messaging API does not throttle — Section 3.)
• Batch sizing — large user-initiated sends are processed in batches; relevant when reasoning about send duration and in-flight content edits.
• Suppress Duplicates — collapses repeated email addresses in the audience so one person isn't mailed twice in a send.
• Send Logging — enabling a _SendLog DE (Section 7b) captures per-message send-time data for debugging — essential for triggered/transactional where there's no batch report.
• Multi-BU / Enterprise 2.0 sending — in Enterprise 2.0 you can share content/data and send across business units; _EnterpriseAttribute and _BusinessUnitUnsubscribes data views exist to support cross-BU attributes and unsubscribe scoping. Unsubscribes can be scoped per-BU or honored enterprise-wide depending on config.

---

8d. Einstein features (modern interviews touch these) 🔑

• Einstein Send Time Optimization (STO) — picks the per-subscriber optimal send time within a window based on each contact's historical engagement, instead of one blast time. Great for global/retail audiences across time zones.
• Einstein Engagement Scoring — scores each subscriber's likelihood to open / click / unsubscribe / bounce, producing personas (e.g., "Loyalists," "Window Shoppers," "Dormant"). Use it to target or suppress.
• Einstein Content Selection / Testing — AI chooses the best content asset per subscriber from a pool at open/render time (real-time selection), beyond rules-based dynamic content.
• Einstein Copy Insights — analyzes subject-line/copy language and predicts engagement to guide subject-line writing.

  Tie-in: STO + Engagement Scoring would let you send GAP promos when each shopper is most likely to engage and suppress likely-to-churn/complain contacts — directly protecting the complaint rate the Gmail/Yahoo rules cap.

---

9. Content Builder 🔑

The central content repository (replaced classic Content). Stores emails, templates, content blocks, and images/documents — shareable across the BU.

Email creation methods

1. Template-based email — a layout (<table> structure with editable regions/data-type="slot") + dropped content blocks. Most maintainable.
2. HTML email (paste HTML) — paste full HTML; max control. What email developers usually do for pixel-perfect builds.
3. Text-only.

Content block types

• Free Form / HTML block — raw HTML + AMPscript.
• Text block.
• Image block.
• Button block.
• Dynamic Content block — rules-based content variation (e.g., show different hero by region/gender) without code.
• A/B / Einstein content.
• Reference content / Content Block by Name/ID — reusable blocks (your modular headers/footers/legal!).

Templates & Slots

• A template defines structure with slots (data-type="slot" data-key="...">) and blocks (data-type="block">).
• Locked regions vs editable regions control what marketers can change.

Your resume: "modular, reusable templates and components (headers, footers, promos, legal blocks)." This maps directly to Content Blocks referenced via ContentBlockByName/ById/ByKey + template slots. Be ready to explain how reuse reduced build time 30% (single source of truth → update once, propagate everywhere; fewer QA defects).

AMPscript in Content Builder

• AMPscript runs inside HTML/Free-form blocks and in referenced content blocks.
• %%=ContentBlockByName("path\to\block")=%% injects a reusable block at render → your modular architecture.

🧪 Brand-aware modular footer — pick the legal/footer block by brand at render time. This is the multi-brand version of your "modular legal blocks" resume point: one email, the right brand's footer injected per subscriber.

%%[
  SET @brand = AttributeValue("BrandPref")
  IF EMPTY(@brand) THEN SET @brand = "GAP" ENDIF
]%%
%%=ContentBlockByName(Concat("Shared content\Footers\Footer_", @brand))=%%

🔍 Line by line: - %%[ — open the AMPscript block. - SET @brand = AttributeValue("BrandPref") — read the subscriber's brand preference column into @brand (e.g., GAP, OldNavy, BananaRepublic). - IF EMPTY(@brand) THEN SET @brand = "GAP" ENDIF — fallback to a default brand so a missing value never produces a broken/blank footer path. - ]%% — close the block. - %%=ContentBlockByName(Concat("Shared content\Footers\Footer_", @brand))=%% — Concat() joins the fixed folder path with the brand to build a path like Shared content\Footers\Footer_GAP; ContentBlockByName(path) then fetches and injects that block at render time. Prefer ByName/ByKey over ById — IDs differ per BU, so an ID reference breaks when content is copied across business units. Sourcing from Shared content makes the footer reusable BU-wide (single source of truth → your 30% build-time reduction).

AMPscript vs SSJS vs GTL — three languages, when to use which 🔑

• AMPscript — the default for inline personalization in email/CloudPage content. Compact, fast for lookups/conditionals. Your bread and butter.
• SSJS (Server-Side JavaScript) — for procedural logic, loops over rowsets, WSProxy/API calls, JSON handling (your DE Lookup tool uses WSProxy in SSJS). Heavier than AMPscript; use it where AMPscript gets awkward. You can bridge values with Platform.Function.TreatAsContent / Variable.GetValue / Variable.SetValue.
• GTL (Guide Template Language) — Handlebars-style ({{ }}) templating, primarily for triggered/transactional templates and Mobile/JB content. Lighter-weight token replacement; good for transactional message definitions.
• Rule of thumb: personalization → AMPscript; complex data/API logic → SSJS; transactional/mobile templating → GTL.

Personalization-string hierarchy & how AttributeValue resolves 🔑 (explains "blank in VAWP" bugs)

There are three ways to drop a value, and they are not equivalent: - %%FieldName%% — the classic substitution string; resolves the attribute/column by name. - %%=v(@var)=%% — outputs the value of an AMPscript variable you SET. - %%=AttributeValue("FieldName")=%% — the function form; resolves a send-context attribute by name (safer in expressions / when the name has spaces).

Resolution order — where does AttributeValue('FirstName') get its value? AttributeValue() resolves against the send context, and the source depends on how you sent: 1. Sending to a sendable Data Extension with a FirstName column → resolves from the DE row. 2. Sending to a List where FirstName is a profile attribute → resolves from the profile attribute. 3. Generally: sendable-DE column > profile attribute > (plain) attribute for the same name.

Worked example — same email, two audiences, different source:

Hi %%=AttributeValue("FirstName")=%%,

🔍 Line by line: - Hi — literal text that renders as-is. - %%=AttributeValue("FirstName")=%% — the function form of personalization. %%= ... =%% is the AMPscript inline-output wrapper; AttributeValue("FirstName") resolves the send-context attribute named FirstName. Where it resolves from depends on the send (sendable-DE column vs profile attribute) — that's the whole lesson of this section. - , — literal comma after the name.

• Audience (a): a sendable DE with a populated FirstName column → renders "Hi Ava,".
• Audience (b): a List where FirstName is a profile attribute that's empty for this subscriber → renders "Hi ," (blank). This is exactly why a value can be fine in one send and blank in another (or in VAWP) — the source changed even though the field name didn't. Always know which context feeds your personalization, and add a fallback:

%%[ SET @fn = AttributeValue("FirstName")
    IF EMPTY(@fn) THEN SET @fn = "there" ENDIF ]%%
Hi %%=v(@fn)=%%,

🔍 Line by line: - %%[ SET @fn = AttributeValue("FirstName") — open a code block and read the resolved FirstName into a variable @fn once, so we can test and reuse it. - IF EMPTY(@fn) THEN SET @fn = "there" ENDIF ]%% — if @fn came back null/blank (EMPTY()), overwrite it with the fallback "there"; ENDIF closes the test; ]%% closes the block. This is the null-guard pattern that prevents "Hi ,". - Hi %%=v(@fn)=%%, — output the guarded variable. %%=v(@var)=%% is the inline syntax for a variable's value, so this safely renders "Hi Ava," or "Hi there,".

When do content blocks render? 🔑

• ContentBlockByName / ContentBlockById / ContentBlockByKey resolve at SEND / render time, per subscriber.
• Practical consequence: a last-minute edit to a referenced content block propagates to an in-flight scheduled send only if that subscriber's message hasn't committed yet. Once committed/rendered, it's locked in. (This is the same commit-vs-send-time idea from Section 8c, and it underpins the double-build flip in Section 11.)

Content Builder governance & operational nuances 🔑

• Shared content folders vs local — content in Shared Content is visible across BUs (Enterprise 2.0); local content is BU-scoped. Choose deliberately for reuse vs isolation.
• Enterprise 2.0 cross-BU sharing — you can share content/blocks across business units, but see the portability gotcha below.
• Size limits — content blocks cap around ~200 KB, and remember Gmail clips at ~102 KB rendered (Section 7) — modular blocks help keep individual pieces small.
• Content Detective — built-in spam-word / spam-likelihood checker that flags content likely to trip filters.
• Litmus / Email on Acid preview integration — for cross-client rendering checks beyond the native preview.
• Approvals & locking — content approval workflows and locked regions in templates control what marketers can edit.
• ContentBlockById is fragile across BUs — IDs differ per BU, so a block referenced by ID breaks when copied to another BU. Prefer ByName or ByKey for portability (also in Gotchas, Section 13).

---

10. Mosaic / modular layout (your resume word)

"Mosaic-based layouts" = modular grid layouts assembled from reusable content modules (rows/columns of swappable blocks). The interview value: consistency across brand-markets, faster builds, easier localization. Tie it to your 30% build-time reduction.

---

11. Double-build pattern (your resume — explain it!)

"Designed double-build campaign patterns (e.g., parallel 20% vs 25% offers) enabling stakeholders to finalize offer just before send."

Explain it as: Build two complete, send-ready versions in parallel (or one email with AMPscript-switchable offer driven by a flag/DE value), so the business can flip the offer at the last minute without a rebuild. The elegant version:

%%[
  /* Per-subscriber RENDER-time lookup — see render-timing note below */
  SET @offer = Lookup("OfferControl","OfferPct","CampaignID", @cid)
  IF EMPTY(@offer) THEN SET @offer = "20" ENDIF   /* fallback if control row missing */
]%%
... Save an extra %%=v(@offer)=%%% today! ...

🔍 Line by line: - %%[ — open the AMPscript block inside the email body so it runs at per-subscriber render time — the key to a last-second flip working. - /* Per-subscriber RENDER-time lookup ... */ — comment flagging that this must run at render, not commit. - SET @offer = Lookup("OfferControl","OfferPct","CampaignID", @cid) — Lookup(DE, returnField, matchField, matchValue) reads the single OfferPct value from the OfferControl control DE where CampaignID equals @cid (the current campaign id, set earlier in the send). One control row holds the live offer (e.g., 20 or 25); flipping that one value changes what every recipient sees. - IF EMPTY(@offer) THEN SET @offer = "20" ENDIF — the fallback default. If the control row is missing or blank (EMPTY()), default to 20 so you never ship a blank offer. This is the safety net the render-timing note insists on. - ]%% — close the code block. - ... Save an extra %%=v(@offer)=%%% today! ... — outputs the resolved offer into the copy. %%=v(@offer)=%% prints the variable; the extra literal % right after it is the percent sign the customer reads (so it renders "Save an extra 25% today!").

Flip one value in a control DE → both the 20% and 25% creative resolve correctly at send. Flexibility + speed + zero rebuild risk.

🧪 Two-flag double-build: switch BOTH the percent AND the hero image from one control row. Stakeholders often flip the offer and the creative together. One render-time lookup, two outputs:

%%[
  SET @rows = LookupRows("OfferControl","CampaignID", @cid)   /* render-time, per subscriber */
  IF RowCount(@rows) > 0 THEN
    SET @row   = Row(@rows, 1)
    SET @offer = Field(@row, "OfferPct")
    SET @hero  = Field(@row, "HeroImageUrl")
  ENDIF
  IF EMPTY(@offer) THEN SET @offer = "20" ENDIF
  IF EMPTY(@hero)  THEN SET @hero  = "https://img.gap.com/default-hero.jpg" ENDIF
]%%
<img src="%%=v(@hero)=%%" alt="Save %%=v(@offer)=%%%"/>

🔍 Line by line: - %%[ — open the block in the email body (render time). - SET @rows = LookupRows("OfferControl","CampaignID", @cid) — LookupRows(DE, field, value) returns all matching rows (a rowset) rather than a single field, so one lookup can yield multiple columns. Match on the campaign id @cid. - IF RowCount(@rows) > 0 THEN — proceed only if a control row exists; guards against errors when reading fields off an empty rowset. - SET @row = Row(@rows, 1) — grab the first row (rowsets are 1-indexed) into @row. - SET @offer = Field(@row, "OfferPct") — pull the OfferPct column from that row. - SET @hero = Field(@row, "HeroImageUrl") — pull the hero-image URL column from the same row. Now one lookup drove two dynamic values. - ENDIF — close the row-exists check. - IF EMPTY(@offer) THEN SET @offer = "20" ENDIF — fallback for the percent if the row was missing/blank. - IF EMPTY(@hero) THEN SET @hero = "https://img.gap.com/default-hero.jpg" ENDIF — fallback hero image so the email never renders a broken <img>. - ]%% — close the block. - <img src="%%=v(@hero)=%%" alt="Save %%=v(@offer)=%%%"/> — render the chosen hero image; the alt text reuses the offer percent (note the doubled trailing % again gives a literal percent sign). Flip one control row → both image and offer change for the whole send.

🔑 Render-timing correction (the detail that makes this actually work): for a true last-second flip, the Lookup against OfferControl must resolve at per-subscriber RENDER time, NOT in a commit-time block. Commit-time AMPscript runs once when the job is built, so if the flip happens there, every recipient is frozen to whatever the control DE said at commit, and a later change won't take effect. Keeping the Lookup in the email body (per-subscriber render) means stakeholders can flip the control row right up until each message renders. Always include the fallback default above so a missing/empty control row doesn't ship a blank offer. (See Section 8c commit-vs-send-time and Section 9 content-block render timing.)

---

12. Interview angles

Q: "Walk me through setting up and sending a campaign."

Build content in Content Builder (template + blocks) → define/refresh the sendable audience DE (often via Automation SQL) → apply exclusion script/suppression list → choose Send Classification (sender + delivery profile) → preview & test send (multiple clients) → schedule/send → monitor tracking.

Q: "Triggered vs User-Initiated send?"

User-initiated = batch, marketer/automation triggered, creates one Job (audit via _Job/_Sent). Triggered = real-time, fired by an API event against a started Triggered Send Definition; logs per-trigger (debug via _SendLog); used for transactional/behavioral 1:1.

Q: "Classic Triggered Send vs the Transactional Messaging API?"

Both do real-time 1:1, but classic Triggered Sends support throttling and priority (rate-limit, e.g., 10k/hr), while the Transactional Messaging API does NOT throttle — it queues and sends ASAP, supports email/SMS/push, and returns per-message async status callbacks. Rate-limit signaling: REST returns 429 (respect Retry-After), SOAP returns 500. TMA for true transactional at scale; classic when I need to rate-limit.

Q: "How does SFMC handle CAN-SPAM compliance on a send?"

The Commercial send classification enforces unsubscribe honoring, and the CAN-SPAM footer (physical address + unsubscribe link) is generated by Header & Footer Rules at the admin level — the Delivery Profile only chooses whether to attach that default footer or use 'None.' If a delivery profile uses 'None,' I must add the unsub link + physical address manually. Transactional classification can omit the unsub but still needs a physical address, and it must legitimately be transactional.

Q: "Native A/B winner — which metrics can you pick?"

Only highest Unique Open Rate or highest Unique Click Rate. CTOR is not a native winner option — for CTOR or conversion-based winners I hand-roll a split in SQL and route the winner to the holdout via a control DE. Ties go to Version A. Because Apple MPP inflates opens, I prefer the Click Rate winner natively.

Q: "List unsubscribe vs All Subscribers unsubscribe vs Publication List opt-down?"

List unsub = one list only; All Subscribers unsub = global BU-wide opt-out (status Unsubscribed); Publication List opt-down = marketer-managed category opt-out in the Subscription Center ("fewer, not none"). The mailbox-provider one-click List-Unsubscribe header maps to the global/publication opt-out.

Q: "We send >5,000/day to Gmail — what's required?"

SPF + DKIM aligned, DMARC p=none minimum, RFC 8058 one-click List-Unsubscribe honored within ~2 days, spam complaints <0.3% (target <0.1%), valid PTR/reverse DNS, TLS. In SFMC: Sender Authentication Package + correct List-Unsubscribe/Subscription Center config, and watch _Complaint.

Q: "Dedicated vs shared IP, and how do you warm one?"

Shared = pooled reputation, good for low/spiky volume; dedicated = your own reputation, recommended above ~250k/month and for consistent senders. A new dedicated IP has no reputation, so I warm it over ~4–6 weeks, starting with the most engaged subscribers and ramping volume gradually, using seed lists to watch inbox placement. Domain reputation matters as much as IP.

Q: "How would you debug a triggered send that delivered with a blank offer?"

A _SendLog DE that captures JobID, SubscriberKey, and the resolved offer value at send/render time. I SELECT the subscriber's row to see exactly what resolved (or didn't). Root cause is usually a commit-time vs render-time mistake or a missing control-DE row with no fallback.

Q: "How are conversions tracked?"

Conversion/impression pixels, Marketing Cloud Web & Mobile Analytics, or — most commonly — UTM-tagged links into GA/GA4, then joined back to the send in a reporting DE; CRM-connected orgs attribute via Sales/Service Cloud.

Q: "Why might a personalized value be blank in View As Web Page but fine in the inbox?"

(VAWP / send context answer — Section 6: native VAWP carries context; nulls come from custom CloudPage web versions without identifiers, stripped query strings, or attributes absent from the web context. Note also the personalization-source hierarchy in Section 9 — sendable-DE column vs profile attribute.)

---

13. Gotchas

• Test sends don't always replicate AMPscript that depends on the sendable DE context — use Preview-and-test with a real DE row, or Send Preview against the audience.
• CTOR vs CTR confusion — interviewers test this. CTOR = unique clicks / unique opens; CTR = unique clicks / delivered. State your denominator.
• Open rate is unreliable post-Apple MPP — and also inflated by bot/security-scanner pre-fetch opens. Optimize on clicks/conversions.
• A/B winner can be statistically meaningless on small lists — a 10% split underpowers it; don't peek/stop early.
• Native A/B can only pick an Open-Rate or Click-Rate winner — not CTOR; ties go to Version A. Hand-roll CTOR/conversion winners in SQL.
• Content blocks referenced by ID break if you copy across BUs (IDs differ) — prefer ByName/ByKey for portability.
• Delivery Profile 'None' means no auto footer — you must add the unsub link + physical address yourself or you're not CAN-SPAM compliant. The footer lives in Header & Footer Rules, not the delivery profile.
• Suppression lists are EMAIL-keyed and uncounted — don't confuse with SubscriberKey-based exclusion; suppressed records have no status and aren't in All Subscribers.
• Triggered Send Definitions cache content — edit the email and the live TSD won't pick it up until you pause + refresh it. Paused TSDs queue triggers, not drop them.
• Commit-time vs render-time — a per-subscriber Lookup (offer flip, content block) must run at render time, not in a commit-time block, or everyone gets the same value frozen at commit.
• Transactional Messaging API does not throttle — don't promise rate-limiting on TMA; use classic Triggered Sends with a throttle rule for that. REST 429 vs SOAP 500 on rate limits.
• Gmail clips at ~102 KB rendered — AMPscript-heavy emails can blow past it after personalization and lose the footer/pixel; keep rendered size lean.
• Don't put a raw SubscriberKey in a web-version URL — it's enumerable; use an encrypted token.
• Don't abuse the Transactional classification for marketing — CAN-SPAM violation + reputation risk; a transactional message still needs a physical address.

➡️ Next: 03_Email_Development_HTML_CSS.md

Module 03 — Email Development (HTML / CSS)

This is your craft. An email-developer interview WILL go deep here. Email HTML is "1999 HTML" — tables, inline CSS, and client quirks. Master the why, not just the how.

---

1. Why email HTML is different from web HTML 🔑

Email clients are NOT browsers. They strip <head> in some clients, ignore external CSS, ignore <style> in many clients, don't support flexbox/grid reliably, and many run ancient rendering engines (classic Outlook desktop uses Microsoft Word's rendering engine — mso). So:

• Layout = nested <table>s, not divs/flex/grid.
• Styling = inline CSS (style="...") for reliability; <style> in head as progressive enhancement.
• Widths in pixels on tables/cells; avoid percentages where Outlook breaks.
• No JavaScript (stripped for security; AMP/interactive are special cases).
• Everything must degrade gracefully.

⚠️ 2026 Outlook caveat (say this in interview). The "Outlook = Word engine" rule is true only for CLASSIC desktop Outlook (2007–2019/2021 and classic Microsoft 365 desktop). The New Outlook for Windows (codename Monarch, GA-rolling since 2023/2024) is built on WebView2 and renders with a modern Blink/Edge web engine — far better CSS support, but new quirks (it strips/ignores most VML and forces its own dark-mode inversion). Outlook.com (webmail) has used a Blink-based engine for years. Microsoft originally signaled an end-of-support date around October 2026 for the classic Word-engine client, then extended classic support through at least 2029, with an opt-out phase starting April 2026 (New Outlook becomes default but you can revert). Bottom line for an interview: the Word-engine era is finally winding down, but classic Outlook still has a long tail you must code for today.

🔑 The SFMC layer (don't forget this is an SFMC interview). Everything below is generic email HTML — but in SFMC the HTML lives inside Content Builder (modern) or legacy Email Studio templates, and is sprinkled with AMPscript (%%[ ... ]%% logic blocks and inline %%=Function()=%% / %%fieldName%%) for send-time personalization. Two facts that surprise people: AMPscript only executes inside HTML or Code Snippet content blocks (not in the WYSIWYG/text blocks), and Content Builder does NOT auto-inline your <style> CSS — you either hand-inline, run an inliner (Premailer/juice/MJML) before pasting, or accept that embedded CSS is progressive enhancement only. See Section 12 for the full SFMC platform mapping.

---

2. The bulletproof email skeleton 🔑

<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml"
      xmlns:v="urn:schemas-microsoft-com:vml"
      xmlns:o="urn:schemas-microsoft-com:office:office">
<head>
  <meta charset="utf-8">                                         <!-- load-bearing: encoding -->
  <meta name="viewport" content="width=device-width, initial-scale=1"> <!-- load-bearing: mobile -->
  <meta name="x-apple-disable-message-reformatting">            <!-- load-bearing: stop iOS auto-resize -->
  <meta name="color-scheme" content="light dark">              <!-- load-bearing: dark-mode opt-in -->
  <meta name="supported-color-schemes" content="light dark">   <!-- load-bearing: dark-mode opt-in -->
  <!-- <meta http-equiv="X-UA-Compatible" content="IE=edge"> legacy IE directive, no effect in modern email clients — harmless, optional, NOT essential -->
  <title></title>
  <!--[if mso]>
  <noscript>
    <xml>
      <o:OfficeDocumentSettings>
        <o:PixelsPerInch>96</o:PixelsPerInch>     <!-- load-bearing for classic Outlook: forces 96 DPI -->
      </o:OfficeDocumentSettings>
    </xml>
  </noscript>
  <![endif]-->
  <style>
    /* Progressive enhancement: media queries, hover, dark mode */
    @media only screen and (max-width:600px){
      .container{width:100% !important;}
      .stack{display:block !important; width:100% !important;}
    }
  </style>
</head>
<body style="margin:0;padding:0;background:#f4f4f4;">
  <!-- Preheader (hidden inbox preview text) — standardized recipe, matches Section 7 -->
  <div style="display:none;font-size:1px;line-height:1px;max-height:0;max-width:0;
              opacity:0;overflow:hidden;mso-hide:all;color:#f4f4f4;">
    Your preview text here
    &zwnj;&nbsp;&zwnj;&nbsp;&zwnj;&nbsp;&zwnj;&nbsp;&zwnj;&nbsp;&zwnj;&nbsp; <!-- spacer: stop body text leaking into preview -->
  </div>

  <!-- Outer wrapper table -->
  <table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0" style="background:#f4f4f4;">
    <tr>
      <td align="center">
        <!-- Container -->
        <table role="presentation" class="container" width="600" cellpadding="0" cellspacing="0" border="0" style="width:600px;max-width:600px;">
          <tr>
            <td style="padding:20px; font-family:Arial,Helvetica,sans-serif; font-size:16px; line-height:24px; color:#333333;">
              Hello world
            </td>
          </tr>
        </table>
      </td>
    </tr>
  </table>
</body>
</html>

🔍 Line by line: - <!DOCTYPE html> — declares standard HTML5 mode so clients that do render in a browser-like engine use predictable, modern parsing rather than legacy "quirks mode." - <html lang="en" xmlns="http://www.w3.org/1999/xhtml" ...> — opens the document. lang="en" tells screen readers which language to pronounce (accessibility); the xmlns:v and xmlns:o namespace declarations register the VML (v:) and Office (o:) tag families so classic Outlook's Word engine understands the <v:roundrect>/<o:OfficeDocumentSettings> tags you'll use later. Without them, those Outlook-only tags are ignored. - <head> — opens the metadata/style region. Note many clients strip or ignore parts of <head>, which is exactly why critical styling is also inlined. - <meta charset="utf-8"> — sets the character encoding to UTF-8 so accented letters, em-dashes, ™ symbols and emoji render instead of turning into garbled "mojibake." - <meta name="viewport" content="width=device-width, initial-scale=1"> — tells mobile clients to use the device's real width at 1:1 zoom, so your responsive layout scales correctly instead of being shown as a zoomed-out desktop page. - <meta name="x-apple-disable-message-reformatting"> — stops iOS/Apple Mail from auto-resizing (re-flowing) your font sizes and layout; without it Apple Mail may bump up your text. - <meta name="color-scheme" content="light dark"> — declares the email supports both light and dark rendering, opting into native dark-mode handling on supporting clients (Apple/iOS Mail). - <meta name="supported-color-schemes" content="light dark"> — the companion declaration; together they signal "I've designed for dark mode, don't aggressively force-invert me" to Class-2 clients. - <!-- <meta http-equiv="X-UA-Compatible" ...> --> — commented-out legacy Internet Explorer document-mode directive; it has no meaningful effect in modern email clients, so it's left as an optional, non-essential note (cargo-cult — see the load-bearing list below). - <title></title> — the document title; usually left empty in email because clients don't show it, but a valid HTML document expects the tag. - <!--[if mso]> — opens an MSO conditional comment: everything until <![endif]--> is read only by classic, Word-engine Outlook and ignored (treated as a comment) by every other client. - <noscript> — wraps the XML so non-Outlook engines that somehow see it don't try to execute/parse it; a defensive wrapper Microsoft's own boilerplate uses. - <xml> / <o:OfficeDocumentSettings> — Office-namespace settings block recognized only by Word-engine Outlook. - <o:PixelsPerInch>96</o:PixelsPerInch> — forces classic Outlook to treat the display as 96 DPI so images sized in pixels aren't blown up ~25% and blurred on high-DPI Windows (125%+ scaling). Load-bearing for classic Outlook only. - </o:OfficeDocumentSettings></xml></noscript> — closes the Office settings, XML, and noscript wrappers. - <![endif]--> — closes the MSO conditional comment. - <style> — opens embedded CSS. Remember: this is progressive enhancement only — Content Builder won't inline it and Gmail-class clients may strip it, so media queries / hover / dark mode live here while layout-critical styles get inlined. - @media only screen and (max-width:600px){ ... } — a media query: the rules inside apply only when the screen is 600px wide or narrower (i.e. phones). - .container{width:100% !important;} — on mobile, force the 600px container to fill the screen width; !important beats the inline width:600px set on the element. - .stack{display:block !important; width:100% !important;} — makes elements tagged .stack drop from side-by-side to full-width stacked on mobile. - <body style="margin:0;padding:0;background:#f4f4f4;"> — zeroes the default body margin/padding (clients add their own) and paints the page background grey. Body styling is inlined because body-level <style> is unreliable. - <div style="display:none;...mso-hide:all;color:#f4f4f4;"> — the hidden preheader wrapper (full breakdown in §7): display:none + tiny font + opacity:0 + overflow:hidden keep it out of the visible email while the inbox preview generator can still read the text; mso-hide:all hides it from classic Outlook; color:#f4f4f4 matches the background so any leak is invisible. - Your preview text here — the actual inbox-preview snippet the recipient sees next to the subject line. - ‌ ‌ ... — zero-width-non-joiner + non-breaking-space pairs acting as an invisible spacer; they push the real body copy out of the preview window so it doesn't bleed in after your crafted snippet. - </div> — closes the preheader. - <table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0" ...> — the outer wrapper table that spans the full inbox width and paints the background. role="presentation" tells screen readers it's layout, not data; cellpadding/cellspacing/border="0" strip the default table gaps/borders that would otherwise wreck the design (and that classic Outlook adds by default). - <tr><td align="center"> — a single row/cell; align="center" horizontally centers the inner container table (the reliable centering technique because Outlook ignores margin:0 auto). - <table role="presentation" class="container" width="600" ... style="width:600px;max-width:600px;"> — the 600px content container (the classic safe email width). width="600" is the HTML attribute Outlook obeys; the inline width/max-width cover the modern clients; the .container class is the hook the media query targets to go full-width on mobile. - <tr><td style="padding:20px; font-family:Arial,Helvetica,sans-serif; font-size:16px; line-height:24px; color:#333333;"> — the content cell. Padding gives breathing room; the font/size/line-height/color are inlined on the cell because Outlook drops body-level fonts, so every text cell must restate them. The Arial,Helvetica,sans-serif stack is web-safe everywhere. - Hello world — placeholder content. - </td></tr></table> (inner) — closes the container. - </td></tr></table> (outer) — closes the wrapper. - </body></html> — closes the document.

Memorize these reflexively: - role="presentation" on layout tables (accessibility — tells screen readers it's a layout table, not a data table, so they don't announce "table, N rows, N columns"). - cellpadding="0" cellspacing="0" border="0" on every layout table. - Inline font styles on every text cell (Outlook drops body-level fonts). - 600px is the classic safe container width.

Which head items are genuinely load-bearing (a senior dev knows the difference between essential and cargo-cult): - ✅ charset — without it, special characters/emoji break. - ✅ viewport — without it, mobile clients don't scale correctly. - ✅ x-apple-disable-message-reformatting — stops iOS Mail auto-resizing your font sizes. - ✅ color-scheme / supported-color-schemes metas — opt your email into native dark-mode handling on supporting clients (Apple/iOS Mail). - ✅ <o:OfficeDocumentSettings><o:PixelsPerInch>96</o:PixelsPerInch> — fixes classic-Outlook DPI image blow-up (see §3). - ⚠️ X-UA-Compatible: IE=edge — legacy Internet-Explorer document-mode directive with no meaningful effect in current email clients. Keep it out of habit if you like, but don't teach it as required; it's cargo-cult in 2026.

---

3. Outlook: the eternal nemesis 🔑🔑

Classic Outlook (2007–2019/2021, desktop Windows, classic M365) uses Word's engine → no background-image on divs, no max-width, no padding on some elements, gaps between tables, DPI scaling issues.

🔑 The bifurcation (essential for a 2026 interview). There is no longer one "Outlook." Know all three rendering realities: | Client | Engine | CSS support | VML | Dark mode | |---|---|---|---|---| | Classic Outlook for Windows (2007–2021, classic M365) | Word (mso) | terrible | ✅ honors VML | no forced inversion (largely leaves colors alone) | | New Outlook for Windows (Monarch, WebView2) | Blink (web) | good | ❌ ignores/strips VML | forces its own inversion | | Outlook.com (webmail) | Blink (web) | good | ❌ no VML | forces inversion, uses [data-ogsc] hooks | | Outlook for Mac | WebKit-ish | good | ❌ no VML | inversion-ish | | Outlook iOS/Android | web-ish | decent | ❌ no VML | varies |

The practical consequence: your VML buttons/backgrounds only fire in classic Outlook. In New Outlook / Outlook.com, the [if mso] branch is skipped and the [if !mso] (anchor/CSS) branch renders — so that branch must itself be fully Outlook-safe, not just "good enough for Gmail." Don't put a VML button in the mso branch and assume all Outlooks are covered; the modern Outlooks fall through to the live HTML.

MSO conditional comments — and the "why" of version gating

Target Outlook specifically:

<!--[if mso]>
   ...Outlook-only HTML (downlevel-HIDDEN: hidden from everything except Outlook)...
<![endif]-->

<!--[if !mso]><!-->
   ...everything-except-Outlook HTML (downlevel-REVEALED)...
<!--<![endif]-->

🔍 Line by line: - <!--[if mso]> — opens a downlevel-hidden conditional. Because the opening <!-- makes it a real HTML comment, only clients that understand the [if mso] test (classic Word-engine Outlook) "open up" and render what's inside; every other client sees a plain comment and skips it. - ...Outlook-only HTML... — content that should appear only in classic Outlook (e.g. ghost tables, VML). - <![endif]--> — closes the downlevel-hidden conditional and the surrounding comment. - <!--[if !mso]><!--> — opens a downlevel-revealed conditional. The trailing <!--> deliberately closes the comment for non-Outlook clients, so they render the following content; classic Outlook evaluates !mso as false and keeps the content hidden. - ...everything-except-Outlook HTML... — content for all the modern/web clients (and the modern web-engine Outlooks, which fall through here). - <!--<![endif]--> — closes the downlevel-revealed block; the leading <!-- re-opens a comment for non-Outlook clients so the closing marker itself isn't shown, and <![endif]--> ends the conditional for Outlook.

Two syntaxes, two behaviors (senior detail): - Downlevel-hidden — <!--[if mso]> ... <![endif]-->. The content is inside a real comment, so only clients that understand the conditional (classic Outlook/Word) reveal it; everything else treats it as a comment and ignores it. - Downlevel-revealed — <!--[if !mso]><!--> ... <!--<![endif]-->. The extra <!--> / <!-- markers close the comment for non-Outlook clients so they render the content, while classic Outlook (which sees !mso = false) keeps it hidden.

Version gating (gte mso 9, lte mso 16). The mso version numbers map to Office releases: mso 9 = Office 2000-era VML baseline, mso 12 = 2007, mso 14 = 2010, mso 15 = 2013, mso 16 = 2016+. You gate VML on [if gte mso 9] ("greater-than-or-equal to mso 9") because VML support entered around the 2000/9 build, so this targets all VML-capable Word-engine Outlooks. You'd use [if lte mso 16] ("less-than-or-equal") when you want a fix for classic builds only and want to exclude the modern web-engine client (which doesn't match mso at all). The plain [if mso] (no version) targets any Word-engine Outlook.

<!--[if gte mso 9]> VML button / background — fires in ALL classic Word-engine Outlooks <![endif]-->
<!--[if lte mso 16]> tweak limited to classic builds, excludes New Outlook web engine <![endif]-->

🔍 Line by line: - <!--[if gte mso 9]> ... <![endif]--> — gte = "greater-than-or-equal." This fires in any Word-engine Outlook reporting mso version ≥ 9 (Office 2000 and up), which is the baseline where VML support arrived — so it correctly targets every VML-capable classic Outlook. Use this guard around VML buttons and backgrounds. - <!--[if lte mso 16]> ... <![endif]--> — lte = "less-than-or-equal." This matches classic builds at mso 16 (Office 2016) and below. The New Outlook / Outlook.com web engine doesn't report an mso version at all, so it never matches — making this the way to scope a fix to classic Outlook only and deliberately exclude the modern web-engine clients.

Ghost tables (centering / fixed width in Outlook)

Outlook ignores max-width/margin:auto, so wrap fluid layouts in an MSO-only fixed table:

<!--[if mso]>
<table role="presentation" width="600" align="center"><tr><td>
<![endif]-->
   <div style="max-width:600px;margin:0 auto;"> ...fluid content... </div>
<!--[if mso]>
</td></tr></table>
<![endif]-->

🔍 Line by line: - <!--[if mso]> — opens an Outlook-only conditional, so the fixed-width table that follows exists only for classic Outlook. - <table role="presentation" width="600" align="center"><tr><td> — the ghost table: a 600px-wide, center-aligned table that pins Outlook to a fixed width (Outlook ignores max-width) and centers it (Outlook ignores margin:auto). role="presentation" keeps it out of the screen-reader data-table announcements. It opens a <tr><td> to hold the real content. - <![endif]--> — closes the Outlook-only conditional; the ghost table's opening tags are now in place for Outlook only. - <div style="max-width:600px;margin:0 auto;"> ...fluid content... </div> — the live, fluid layout every other client sees: max-width:600px caps it on desktop, margin:0 auto centers it. Outlook ignored both of these, which is exactly why the ghost table wraps it. - <!--[if mso]> — re-opens an Outlook-only conditional to emit the ghost table's closing tags. - </td></tr></table> — closes the ghost cell/row/table for Outlook, balancing the opening tags above. The closing tags live in their own conditional so non-Outlook clients (which never saw the opening table) don't choke on stray </table> tags. - <![endif]--> — closes the final Outlook-only conditional.

<!--[if mso]>
<v:roundrect xmlns:v="urn:schemas-microsoft-com:vml" xmlns:w="urn:schemas-microsoft-com:office:word"
  href="https://example.com" style="height:44px;v-text-anchor:middle;width:200px;"
  arcsize="10%" strokecolor="#1a73e8" fillcolor="#1a73e8">
  <w:anchorlock/>
  <center style="color:#ffffff;font-family:Arial,sans-serif;font-size:16px;font-weight:bold;">Shop Now</center>
</v:roundrect>
<![endif]-->
<!--[if !mso]><!-->
<a href="https://example.com"
   style="background:#1a73e8;border-radius:4px;color:#ffffff;display:inline-block;
          font-family:Arial,sans-serif;font-size:16px;font-weight:bold;
          line-height:44px;text-align:center;text-decoration:none;width:200px;mso-hide:all;">
   Shop Now
</a>
<!--<![endif]-->

🔍 Line by line: - <!--[if mso]> — Outlook-only conditional; the VML button below renders only in classic Outlook. - <v:roundrect xmlns:v="..." xmlns:w="..." href="https://example.com" style="height:44px;v-text-anchor:middle;width:200px;" arcsize="10%" strokecolor="#1a73e8" fillcolor="#1a73e8"> — a VML rounded-rectangle shape standing in for an HTML button. xmlns:v/xmlns:w re-declare the VML and Word namespaces locally (belt-and-suspenders). href makes the whole shape clickable. The inline height/width size it (VML ignores CSS padding). v-text-anchor:middle vertically centers the label. arcsize="10%" rounds the corners (percentage of the shorter side, not pixels). strokecolor is the border color; fillcolor is the button fill — here both your brand blue. - <w:anchorlock/> — locks the text so the user can't select/edit it and Outlook won't reflow it, stabilizing the click target. - <center style="color:#ffffff;font-family:Arial,sans-serif;font-size:16px;font-weight:bold;">Shop Now</center> — the visible button label; styled white/bold inside the blue shape. <center> is used because it's the most reliable way to center text inside a VML shape in Word. - </v:roundrect> — closes the VML button. - <![endif]--> — closes the Outlook-only branch. - <!--[if !mso]><!--> — opens the everything-except-Outlook branch (including New Outlook / Outlook.com, which strip VML and land here). - <a href="https://example.com" style="background:#1a73e8;border-radius:4px;color:#ffffff;display:inline-block; font-family:Arial,sans-serif;font-size:16px;font-weight:bold; line-height:44px;text-align:center;text-decoration:none;width:200px;mso-hide:all;"> — the real HTML/CSS button. display:inline-block lets it take a width and padding-like sizing; line-height:44px gives it height and vertically centers a single line of text; border-radius rounds it with real CSS; text-decoration:none removes the default link underline; width:200px matches the VML width. mso-hide:all belt-and-suspenders hides this anchor from classic Outlook in case any Outlook build leaks past the conditional, so you never get a doubled button. - Shop Now — the link text/label. - </a> — closes the anchor button. - <!--<![endif]--> — closes the non-Outlook branch.

Why each VML attribute exists (senior "why"): - arcsize="10%" — VML corner radius is a percentage relative to the SHORTER side of the shape (not pixels). On a 44px-tall button, 10% ≈ 4.4px radius. To match an 8px CSS border-radius you compute 8 / (height/2) roughly — corner rounding is proportional, so tall vs. short buttons need different percentages to look identical to the CSS side. - v-text-anchor:middle — vertically centers the label inside the roundrect (Word has no vertical-align you can trust here). - <w:anchorlock/> — locks the text so the user can't accidentally select/edit it and so Outlook doesn't reflow it; it also stabilizes the click target. - Explicit width/height in px — VML buttons ignore CSS padding, so unlike the CSS anchor (which you can pad), the roundrect must be sized with explicit dimensions. Size it to fit the longest label. - ⚠️ New Outlook / Outlook.com fall-through: because they strip VML, they render the [if !mso] anchor instead. That anchor uses display:inline-block + line-height for height — make sure it's robust, because for the modern Outlooks it's the only button they'll see.

Background images in Outlook (VML) — complete for BOTH worlds

Classic Outlook ignores CSS background-image; you need the VML half and the live-CSS half (with a color fallback) for everything else:

<!-- Classic Outlook (Word engine): VML background -->
<!--[if gte mso 9]>
<v:rect xmlns:v="urn:schemas-microsoft-com:vml" fill="true" stroke="false" style="width:600px;height:300px;">
  <v:fill type="frame" src="https://cdn.example.com/hero.jpg" color="#000000" />
  <v:textbox inset="0,0,0,0">
<![endif]-->
   <!-- Everyone else: real CSS background-image WITH a background-color fallback -->
   <div style="background:#000000 url('https://cdn.example.com/hero.jpg') no-repeat center / cover;
               width:600px;max-width:600px;height:300px;">
     <table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
       <tr><td style="padding:40px;font-family:Arial,sans-serif;color:#ffffff;">
         ...overlay text/content...
       </td></tr>
     </table>
   </div>
<!--[if gte mso 9]>
  </v:textbox>
</v:rect>
<![endif]-->

🔍 Line by line: - <!-- Classic Outlook (Word engine): VML background --> — a plain HTML comment labeling the Outlook-only half. - <!--[if gte mso 9]> — Outlook-only conditional (VML baseline, mso ≥ 9); the VML background renders only in classic Outlook. - <v:rect xmlns:v="..." fill="true" stroke="false" style="width:600px;height:300px;"> — a VML rectangle that will be filled with the background image. fill="true" enables the fill; stroke="false" removes any border; the inline width/height set the fixed box size (Outlook needs explicit dimensions). - <v:fill type="frame" src="https://cdn.example.com/hero.jpg" color="#000000" /> — paints the image into the rectangle. type="frame" scales the image to cover the box; src is the absolute image URL (relative URLs don't resolve in email); color="#000000" is the fallback color shown if the image is blocked or fails. - <v:textbox inset="0,0,0,0"> — a VML text container layered on top of the background so overlay content sits over the image; inset="0,0,0,0" removes default internal padding so your own padding controls spacing. - <![endif]--> — closes the Outlook-only opening half. - <!-- Everyone else: real CSS background-image WITH a background-color fallback --> — comment labeling the live-HTML half all other clients render. - <div style="background:#000000 url('https://cdn.example.com/hero.jpg') no-repeat center / cover; width:600px;max-width:600px;height:300px;"> — the real CSS background. The background shorthand sets the fallback color first (#000000), then the image, no-repeat, position center, and / cover to scale it to fill. Fixed width/height (and max-width) size the hero. If the image fails, the black color shows so overlay text stays readable. - <table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0"> — a layout table inside the div to position the overlay content reliably (tables behave more predictably than div padding across clients). - <tr><td style="padding:40px;font-family:Arial,sans-serif;color:#ffffff;"> — the overlay content cell: padding insets the text from the edges, white text reads over the dark hero, inline font for Outlook safety. - ...overlay text/content... — placeholder for the headline/CTA layered on the image. - </td></tr></table></div> — closes the overlay table and the CSS-background div. - <!--[if gte mso 9]> — re-opens the Outlook-only conditional to emit the VML closing tags. - </v:textbox></v:rect> — closes the VML textbox and rectangle, balancing the opening VML tags. - <![endif]--> — closes the final Outlook-only conditional.

The color="#000000" on <v:fill> and the #000000 in the CSS background shorthand are the fallback colors if the image is blocked or fails — never leave white-on-white text when the hero doesn't load.

Retina images (the principle made concrete)

Serve a 2× source asset and size it down with explicit width/height attributes and matching inline style. The browser/client downsamples for crispness on high-DPI screens:

<!-- Source file hero@2x.png is 1200x600; rendered at 600x300 -->
<img src="https://cdn.example.com/hero@2x.png" width="600" height="300"
     style="width:600px;height:300px;display:block;border:0;" alt="Spring sale hero">

🔍 Line by line: - <!-- Source file hero@2x.png is 1200x600; rendered at 600x300 --> — comment noting the asset is double resolution (1200×600) but displayed at half size (600×300); that downscaling is what makes it look crisp on Retina/high-DPI screens. - <img src="https://cdn.example.com/hero@2x.png" width="600" height="300" ...> — the image tag using an absolute CDN URL. The width/height HTML attributes (600×300) are what classic Outlook honors and what reserves layout space before the image loads; they also tell the client to downsample the 1200×600 source. - style="width:600px;height:300px;display:block;border:0;" — the inline CSS twin of those dimensions for modern clients; display:block removes the small gap Outlook/clients add under inline images; border:0 strips the blue link border some clients draw around linked images. - alt="Spring sale hero" — accessible name and image-blocked fallback text; describes the hero for screen readers and for recipients with images off.

"Too-tall image" fix (the 1728px height clip — see also Gotcha #3)

Classic Outlook's Word engine clips a single image taller than ~1728px from the bottom. Slice a long hero into stacked <img> rows so no individual image exceeds the limit (this also keeps file sizes and 102KB clipping under control):

<table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0">
  <tr><td><img src="hero-slice-1.jpg" width="600" height="800" style="display:block;border:0;" alt=""></td></tr>
  <tr><td><img src="hero-slice-2.jpg" width="600" height="800" style="display:block;border:0;" alt=""></td></tr>
  <tr><td><img src="hero-slice-3.jpg" width="600" height="700" style="display:block;border:0;" alt="Full-bleed campaign hero"></td></tr>
</table>

🔍 Line by line: - <table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0"> — a 600px layout table to stack the image slices with zero gaps between them; role="presentation" marks it as layout, and the zeroed cellpadding/spacing/border ensure the slices butt together seamlessly so the seams are invisible. - <tr><td><img src="hero-slice-1.jpg" width="600" height="800" style="display:block;border:0;" alt=""></td></tr> — the first slice (600×800). display:block removes the under-image gap that would otherwise create visible white lines between slices; border:0 strips link borders; alt="" is intentionally empty because this is a decorative fragment of a larger image — an empty alt makes screen readers skip it instead of announcing the filename. - <tr><td><img src="hero-slice-2.jpg" width="600" height="800" ... alt=""></td></tr> — the middle slice, same treatment and empty alt. - <tr><td><img src="hero-slice-3.jpg" width="600" height="700" ... alt="Full-bleed campaign hero"></td></tr> — the final slice. Only the last slice carries a meaningful alt, so the screen reader announces the hero once as a single concept rather than three times — keeping the height of each slice under the ~1728px Word-engine clip limit while presenting the artwork as one coherent image. - </table> — closes the stacked-slice table.

Consolidated: vertical spacing in Outlook (the canonical patterns) 🔑

Classic Outlook collapses/expands vertical space unpredictably. Treat spacing with spacer rows and explicit line-height, never margins:

<!-- Spacer ROW: a fixed-height gap that Outlook respects -->
<tr>
  <td height="24" style="font-size:0;line-height:0;mso-line-height-rule:exactly;">&nbsp;</td>
</tr>

<!-- Text CELL: pin the line-height so Outlook doesn't pad lines -->
<td style="font-family:Arial,sans-serif;font-size:16px;line-height:24px;
           mso-line-height-rule:exactly;color:#333333;">
  Body copy with predictable leading.
</td>

🔍 Line by line: - <!-- Spacer ROW: a fixed-height gap that Outlook respects --> — comment introducing the spacer-row technique used instead of CSS margins (which Word ignores). - <tr> — opens a dedicated table row whose only job is to create vertical space. - <td height="24" style="font-size:0;line-height:0;mso-line-height-rule:exactly;">&nbsp;</td> — the spacer cell. height="24" sets a fixed 24px gap that Outlook honors; font-size:0;line-height:0 collapse any text height so the cell's height comes only from the height attribute; mso-line-height-rule:exactly forces Word to use that exact zero line-height instead of padding it;   gives the cell content so it actually paints (empty cells can collapse to nothing). - </tr> — closes the spacer row. - <!-- Text CELL: pin the line-height so Outlook doesn't pad lines --> — comment introducing the text-cell pattern. - <td style="font-family:Arial,sans-serif;font-size:16px;line-height:24px; mso-line-height-rule:exactly;color:#333333;"> — a body-text cell with inlined font/size/color (Outlook drops body-level fonts). line-height:24px sets the leading and mso-line-height-rule:exactly forces Word to honor it exactly rather than its default "at least" rule that adds extra space and bloats your layout. - Body copy with predictable leading. — the visible text. - </td> — closes the text cell.

Why each piece: - mso-line-height-rule:exactly — by default Word uses "at least" line spacing and adds leading; exactly forces your stated line-height so text and spacers don't bloat. - font-size:0; line-height:0; on a spacer cell — collapses the   so the cell's height comes only from the height attribute, not from a stray text line. -   in the spacer — gives the cell content so Outlook actually paints the height (empty cells can collapse).

Other classic-Outlook fixes

• mso-padding-alt / spacer cells/rows instead of CSS margins (Word ignores margins on many elements).
• <o:PixelsPerInch>96</o:PixelsPerInch> (in the skeleton) fixes DPI image blow-up. Why: classic Outlook scales images by the Windows display DPI — at 120 DPI (125% scaling) a 600px image renders ~25% too large and blurry. Forcing 96 DPI makes 1px = 1px again. Caveat: this only affects the classic Word-engine client, and only when you set explicit width/height in px on the image.
• Outlook adds a gap under images: set display:block and border:0 on every <img>.
• Outlook ignores max-width on images/elements → always set explicit pixel width/height attributes and inline width (see Gotcha #3).

⭐ Bonus snippet: Outlook-safe horizontal divider (no <hr>)

The HTML <hr> tag renders inconsistently (and ignores your styling) in classic Outlook. The bulletproof divider is a 1px-tall colored table row — it's just a thin filled cell:

<table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td height="1" style="font-size:0;line-height:0;background:#dddddd;">&nbsp;</td>
  </tr>
</table>

🔍 Line by line: - <table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0"> — a 600px layout table so the rule spans the container width; role="presentation" marks it as layout; the zeroed cellpadding/spacing/border prevent stray gaps or default borders that would thicken the line. - <tr> — one row holding the rule. - <td height="1" style="font-size:0;line-height:0;background:#dddddd;">&nbsp;</td> — the rule itself: height="1" makes it 1px tall; background:#dddddd is the line color (a light grey); font-size:0;line-height:0 collapse the   so the cell height stays exactly 1px instead of being inflated by a text line;   gives the cell content so Outlook actually paints the 1px (empty cells can collapse to nothing). - </td></tr></table> — closes the cell, row, and table.

⭐ Bonus snippet: bulletproof full-width image (fluid, retina-ready, accessible)

For a retail hero that must fill the container on every screen — full width on desktop, fluid on mobile — use this single image pattern:

<img src="https://cdn.example.com/summer-hero@2x.jpg"
     width="600" alt="Summer styles up to 50% off"
     style="width:100%;max-width:600px;height:auto;display:block;border:0;">

🔍 Line by line: - <img src="https://cdn.example.com/summer-hero@2x.jpg" — the hero image from an absolute CDN URL (relative URLs don't resolve in the inbox); the @2x asset is double-resolution for crisp Retina rendering. - width="600" — the HTML width attribute classic Outlook honors and that reserves space before load; Outlook ignores the CSS max-width, so this fixed attribute pins it to 600px there. - alt="Summer styles up to 50% off" — meaningful accessible name and images-off fallback; describes the offer, not the filename. - style="width:100%;max-width:600px;height:auto;display:block;border:0;" — modern clients use this: width:100% lets it shrink fluidly on narrow screens, max-width:600px caps it on desktop, height:auto keeps the aspect ratio as it scales, display:block kills the under-image gap, border:0 strips any link border.

---

4. Responsive email approaches 🔑

Three strategies — know all three:

(a) Fluid / Spongy

Use % widths + max-width so layout flexes naturally. Minimal media queries. Resilient where media queries are stripped (older Gmail app, etc.).

(b) Responsive (media-query based)

Fixed desktop layout; @media (max-width:600px) overrides to stack/resize on mobile.

@media only screen and (max-width:600px){
  .col{display:block !important; width:100% !important;}
  .h1{font-size:24px !important;}
  .pad{padding:16px !important;}
}

🔍 Line by line: - @media only screen and (max-width:600px){ — a media query that activates only on screens 600px wide or narrower (phones). only screen excludes print/legacy contexts. Everything inside applies only on mobile. - .col{display:block !important; width:100% !important;} — turns side-by-side desktop columns (tagged .col) into full-width stacked blocks on mobile. !important overrides the inline width/display set on the element (inline styles otherwise win over <style> rules). - .h1{font-size:24px !important;} — shrinks an oversized desktop headline to a mobile-appropriate 24px. - .pad{padding:16px !important;} — tightens padding on small screens so content isn't crammed against the edges or wasting space. - } — closes the media query block. - Remember: this lives in <head><style> and Gmail-class clients / Outlook may strip it, so the non-mobile (inline) layout must already be acceptable on its own.

⚠️ Gmail (some app contexts) and Outlook strip <style>/media queries → must degrade gracefully.

(c) Hybrid / Fluid-Hybrid (most robust at scale)

Combine fluid widths + max-width + MSO ghost tables + inline-block columns that wrap naturally — works even when media queries are ignored. This is the pro approach for global, high-volume programs (like GAP/retail).

Column stacking via inline-block (hybrid):

<div style="font-size:0;text-align:center;">
  <!--[if mso]><table role="presentation" width="600" align="center"><tr><td width="300" valign="top"><![endif]-->
  <div style="width:100%;max-width:300px;display:inline-block;vertical-align:top;font-size:16px;">...col 1...</div>
  <!--[if mso]></td><td width="300" valign="top"><![endif]-->
  <div style="width:100%;max-width:300px;display:inline-block;vertical-align:top;font-size:16px;">...col 2...</div>
  <!--[if mso]></td></tr></table><![endif]-->
</div>

🔍 Line by line: - <div style="font-size:0;text-align:center;"> — the parent wrapper. font-size:0 collapses the whitespace between the inline-block children (the newline/space in your HTML otherwise renders as a real space that pushes columns to wrap early); text-align:center centers the inline-block columns (the reliable cross-client centering trick when margin:auto fails). - <!--[if mso]><table role="presentation" width="600" align="center"><tr><td width="300" valign="top"><![endif]--> — Outlook-only ghost table opening: a 600px centered table with a 300px first cell. Outlook can't reflow inline-blocks, so this scaffolds a fixed two-up layout just for classic Outlook. valign="top" top-aligns the column content. - <div style="width:100%;max-width:300px;display:inline-block;vertical-align:top;font-size:16px;">...col 1...</div> — column 1 (live HTML for everyone else). width:100%;max-width:300px makes it fluid up to 300px so two columns stack automatically on narrow screens with no media query; display:inline-block puts columns side by side; vertical-align:top aligns their tops; font-size:16px resets the readable text size the parent's font-size:0 had zeroed. - <!--[if mso]></td><td width="300" valign="top"><![endif]--> — Outlook-only: closes the first ghost cell and opens the second 300px ghost cell, mirroring the live columns. - <div style="width:100%;max-width:300px;display:inline-block;vertical-align:top;font-size:16px;">...col 2...</div> — column 2, identical treatment to column 1. - <!--[if mso]></td></tr></table><![endif]--> — Outlook-only: closes the second ghost cell, row, and table. - </div> — closes the parent wrapper.

The three mechanics that make this work (be ready to explain each): 1. font-size:0 on the PARENT — inline-block elements have whitespace (the newline/space in your HTML between the two <div>s) rendered as a real space character. That phantom space adds up and pushes your second column to wrap one line early. Setting font-size:0 on the parent collapses that inter-element whitespace to nothing. You then reset font-size (e.g. 16px) on each child so the actual text is readable. 2. width:100%; max-width:300px — each column is fluid up to 300px. On a narrow screen, two 300px columns can't both fit, so they reflow/stack automatically with NO media query. That's the whole point of hybrid: it degrades by reflowing, not by relying on @media that Outlook/old Gmail strip. 3. text-align:center + display:inline-block — this is also the canonical centering technique when margin:0 auto doesn't work (Outlook). Centering the inline-blocks via the parent's text-align is reliable everywhere.

Ghost columns mirror the live divs. The [if mso] <table>/<td width="300"> cells are the invisible-to-everyone-else scaffold that pins classic Outlook to a fixed two-up layout (Outlook can't reflow inline-blocks). The live <div>s and the ghost <td>s describe the same two columns to two different engines — keep their widths in sync.

---

5. Dark mode 🔑 (increasingly asked)

Clients recolor emails in dark mode. Problems: black logos disappearing, washed-out text, inverted backgrounds, low contrast.

🔑 The single most important concept: there are THREE classes of dark-mode behavior

Don't say "I use prefers-color-scheme for dark mode" — that's only true for some clients. The senior answer is the taxonomy:

The trap to avoid: a reader who thinks the @media query "turns on dark mode in Outlook" is wrong — Outlook.com / New Outlook ignore prefers-color-scheme and force their own inversion. For those you must use the original-style hooks Outlook injects, OR design palettes that look acceptable when inverted.

The [data-og*] hooks explained. When Outlook's forced inversion changes an element, it stamps that element with a data attribute recording the original value, which you can then target: - [data-ogsc] = original style color (inline style="color:..." got inverted) - [data-ogsb] = original style background-color - [data-ogac] = original attribute color (HTML color= attribute) - [data-ogab] = original attribute background

Techniques

<!-- In <head>: opt into native dark-mode handling (Class 2 clients) -->
<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">

🔍 Line by line: - <!-- In <head>: opt into native dark-mode handling (Class 2 clients) --> — comment noting these metas belong in <head> and matter to Class-2 (Apple/iOS Mail) clients. - <meta name="color-scheme" content="light dark"> — declares the email is designed for both light and dark; supporting clients then apply your prefers-color-scheme rules rather than blindly force-inverting. - <meta name="supported-color-schemes" content="light dark"> — the companion declaration (some clients look for this specific name); together they tell Apple/iOS Mail "I support dark mode, hand me control instead of auto-inverting."

Same element, both worlds (this is the example to show an interviewer):

/* Class 2 — Apple Mail / iOS Mail honor this */
@media (prefers-color-scheme: dark){
  .card        { background:#1a1a1a !important; }
  .card-text   { color:#ffffff !important; }
  .dark-logo   { display:block !important; max-height:none !important; }
  .light-logo  { display:none !important; }
}

/* Class 3 — Outlook.com / New Outlook forced inversion: re-assert via the hooks */
[data-ogsc] .card-text { color:#ffffff !important; }
[data-ogsb] .card      { background:#1a1a1a !important; }

🔍 Line by line: - @media (prefers-color-scheme: dark){ — fires only when the client honors the OS dark-mode signal (Class-2: Apple Mail, iOS/macOS Mail). The block inside re-styles elements for dark backgrounds. - .card { background:#1a1a1a !important; } — repaints the card's background near-black for dark mode; !important beats the inline light background. - .card-text { color:#ffffff !important; } — switches the card text to white so it reads on the dark card. - .dark-logo { display:block !important; max-height:none !important; } — shows the light-on-dark logo variant in dark mode (it was hidden in light mode); max-height:none undoes the collapse trick used to hide it. - .light-logo { display:none !important; } — hides the dark-on-light logo variant in dark mode, so only the appropriate logo shows. - } — closes the Class-2 media query. - [data-ogsc] .card-text { color:#ffffff !important; } — a Class-3 (forced-inversion) hook. Outlook.com / New Outlook ignore the media query but stamp inverted elements with data-ogsc ("original style color"); this selector re-asserts white text under that forced-inversion context. No @media — it's a plain attribute selector Outlook's injected attribute matches. - [data-ogsb] .card { background:#1a1a1a !important; } — the same idea for background: data-ogsb ("original style background") lets you re-assert the dark card background when Outlook force-inverts it.

<!-- Logo swap pattern referenced above -->
<img class="light-logo" src="logo-dark-on-light.png"  width="160" alt="GAP" style="display:block;border:0;">
<img class="dark-logo"  src="logo-light-on-dark.png"  width="160" alt="GAP"
     style="display:none;max-height:0;border:0;mso-hide:all;">

🔍 Line by line: - <!-- Logo swap pattern referenced above --> — comment tying this markup to the .dark-logo/.light-logo rules above. - <img class="light-logo" src="logo-dark-on-light.png" width="160" alt="GAP" style="display:block;border:0;"> — the default (light-mode) logo: a dark logo that reads on a light background. It's display:block (visible) by default; class="light-logo" is the hook the dark-mode media query uses to hide it; both logos share alt="GAP" so only one accessible name is announced regardless of which is shown. - <img class="dark-logo" src="logo-light-on-dark.png" width="160" alt="GAP" style="display:none;max-height:0;border:0;mso-hide:all;"> — the dark-mode logo: a light logo for dark backgrounds. It starts hidden via display:none and max-height:0 (belt-and-suspenders, since some clients ignore display:none on images); the dark-mode rule flips it visible. mso-hide:all keeps it hidden in classic Outlook, which has no real dark mode, so Outlook only ever shows the default logo.

⭐ Bonus snippet: protect a dark logo with a white "halo" cell (survives forced inversion)

Wrap a transparent dark-on-transparent logo in a cell with an explicit light background so Class-3 forced-inversion clients recolor the cell, not the logo behind it — stopping a black logo from vanishing into a black background:

<td align="center" bgcolor="#ffffff"
    style="background-color:#ffffff;padding:16px;border-radius:8px;">
  <img src="https://cdn.example.com/gap-logo.png" width="160" alt="GAP"
       style="display:block;border:0;">
</td>

🔍 Line by line: - <td align="center" bgcolor="#ffffff" style="background-color:#ffffff;padding:16px;border-radius:8px;"> — the protective cell. align="center" centers the logo; bgcolor="#ffffff" is the HTML attribute version of the background (some clients/inverters respect the attribute when they ignore the CSS), and background-color:#ffffff is the CSS twin — together they give forced-inversion clients a solid white "halo" to recolor instead of the transparent area around the logo. padding:16px gives the logo breathing room; border-radius:8px softens the corners (modern clients only). - <img src="https://cdn.example.com/gap-logo.png" width="160" alt="GAP" style="display:block;border:0;"> — the logo on its absolute CDN URL; width="160" sizes it; alt="GAP" is the accessible name; display:block removes the under-image gap; border:0 strips the link border. Because it sits on the white cell, even an aggressive inverter keeps the logo legible. - </td> — closes the protective cell.

Practical tips (the techniques a senior owns)

• Protect logos with a non-transparent background cell. Put the logo on a td/wrapper with an explicit background-color (e.g. white) so forced inversion recolors the cell, not the transparent PNG behind it — preventing a black logo vanishing into a black background.
• Use a colored "halo"/stroke or an inverted PNG/SVG version of black logos so they read on dark backgrounds.
• Avoid pure #000000 text on transparent. Many inverters flip near-black to near-white, but #000000 exactly is sometimes left untouched — leading to black-on-dark. Use #111/#1a1a1a style off-blacks so inversion behaves predictably.
• mix-blend-mode / background-color tricks can force a known result on logos in some Class-2 clients, but they're not universal.
• The pragmatic stance for Class 3: you cannot fully control forced-inversion clients — design colors that look acceptable when inverted and accept some variance.
• Browser-level / Dark Reader dark mode (webmail opened in a dark-themed browser, or the Dark Reader extension) is yet another inverter you don't control — another reason to design inversion-tolerant palettes.
• Test separately in Apple Mail dark (Class 2), Outlook.com / New Outlook dark (Class 3), and Gmail dark (mixed) — they genuinely behave differently. ⚠️ Note that static preview tools (Litmus/EoA screenshots) do not always reproduce forced inversion accurately — confirm with real device sends.

---

6. Accessibility (a11y) 🔑 (senior differentiator, and legally relevant)

• lang attribute on <html> (e.g. lang="en").
• role="presentation" on EVERY layout table. Why: without it, screen readers treat a layout table as data and announce "table, N columns, N rows" before every section — a layout email becomes an unusable mess of table announcements. role="presentation" (or role="none") tells the reader "this is scaffolding, read it linearly."
• alt text on every meaningful image. Crucially, decorative images need empty alt="" (present but empty), NOT a missing alt. Why: with alt="" screen readers skip the image; with no alt attribute at all, some readers fall back to announcing the filename/URL ("hero-slice-2-dot-jpg") — noisy and meaningless.
• alt vs title — alt is the accessible name and the image-blocked fallback text; title is a hover tooltip (inconsistent in email, not a substitute for alt).
• aria-label on icon/image links so a screen reader announces the destination ("Shop the sale") instead of the image filename or a bare URL.
• Logical reading order (source order = visual order) — screen readers follow DOM order, not visual position.
• Sufficient color contrast — WCAG 2.1/2.2 AA: 4.5:1 for normal body text, 3:1 for large text (≥18.66px bold or ≥24px) and for UI components/graphical objects.
• Real text over text-in-images (for screen readers + image blocking + dark-mode legibility).
• Descriptive link text ("Shop the sale", not "click here").
• aria-hidden="true" on purely decorative emoji/icons.
• Font size ≥ 14–16px body.
• Preheader must not duplicate the subject line. Screen readers may read subject then preheader back-to-back; if they're identical the user hears the same phrase twice. Use the preheader to extend the subject, not echo it.
• prefers-reduced-motion for animated GIFs / countdown timers / kinetic effects — provide a static fallback for users who've requested reduced motion (see §9 and the example below). Motion can trigger vestibular issues; this is a real AA-adjacent concern.

/* Accessibility-aware motion handling — hide the animation, show a static frame */
@media (prefers-reduced-motion: reduce){
  .animated        { display:none !important; }
  .static-fallback { display:block !important; }
}

🔍 Line by line: - @media (prefers-reduced-motion: reduce){ — fires only for users who've asked their OS to minimize motion (an accessibility setting). The block swaps animation for a still image. - .animated { display:none !important; } — hides the moving element (e.g. an animated countdown GIF) for motion-sensitive users. - .static-fallback { display:block !important; } — reveals a still fallback frame (e.g. an "Ends soon" image) that was hidden by default, so those users still get the message without the motion. - } — closes the media query. Note: like all <style> rules this is progressive enhancement — design the default so even clients that strip it aren't harmful.

⭐ Bonus snippet: accessible image-link + decorative-vs-meaningful alt (the three cases)

A common interview probe is "show me good alt usage." This one block demonstrates a linked logo, a decorative spacer image, and a meaningful product image — the three cases a senior gets right:

<!-- 1. Image that is ALSO a link → aria-label names the DESTINATION, not the picture -->
<a href="https://gap.com/sale" aria-label="Shop the summer sale" style="text-decoration:none;">
  <img src="https://cdn.example.com/sale-banner.jpg" width="600" height="200"
       alt="Summer sale — up to 50% off" style="display:block;border:0;">
</a>

<!-- 2. Purely DECORATIVE image → empty alt so readers SKIP it -->
<img src="https://cdn.example.com/divider-flourish.png" width="600" height="12"
     alt="" role="presentation" style="display:block;border:0;">

<!-- 3. MEANINGFUL product image → descriptive alt conveys what's pictured -->
<img src="https://cdn.example.com/denim-jacket.jpg" width="290" height="290"
     alt="Organic cotton denim jacket in light wash" style="display:block;border:0;">

🔍 Line by line: - <a href="https://gap.com/sale" aria-label="Shop the summer sale" style="text-decoration:none;"> — wraps an image in a link. aria-label overrides what the screen reader announces so it says the destination/action ("Shop the summer sale") instead of reading the image's filename or a raw URL; text-decoration:none removes the underline a linked image would otherwise pick up. - <img ... alt="Summer sale — up to 50% off" style="display:block;border:0;"> — the banner image. Its alt still describes the picture for image-off recipients; display:block removes the under-image gap; border:0 removes the blue link border clients draw around linked images. - </a> — closes the image link. - <!-- 2. Purely DECORATIVE image → empty alt so readers SKIP it --> — comment marking the decorative case. - <img src=".../divider-flourish.png" width="600" height="12" alt="" role="presentation" style="display:block;border:0;"> — a decorative flourish: alt="" (present but empty) makes screen readers skip it entirely; a missing alt would instead make some readers announce the filename. role="presentation" reinforces "this is decoration, not content." - <!-- 3. MEANINGFUL product image → descriptive alt conveys what's pictured --> — comment marking the meaningful case. - <img src=".../denim-jacket.jpg" width="290" height="290" alt="Organic cotton denim jacket in light wash" style="display:block;border:0;"> — a product image whose alt describes the product (material, item, color) so a blind shopper or an images-off recipient knows what's on offer — not "denim-jacket.jpg."

The legal frame (say the standards by name). Email accessibility is increasingly a compliance issue, not a nicety: - WCAG 2.1 / 2.2 Level AA is the de-facto target standard. - ADA (US) — courts treat web/email content of public accommodations as covered; WCAG AA is the practical benchmark. - European Accessibility Act (EAA) — enforcement began June 2025, pushing AA-level digital accessibility for many products/services in the EU. For a global retailer (GAP/LTM), EU-facing email programs are in scope.

Internationalization / RTL (global retail reality) 🌍

Large global programs send the same template in many locales — be ready to discuss: - dir="rtl" on the <html> (or a container) for Arabic/Hebrew; mirror layout, padding, and alignment. - Bidi text — mixing LTR (URLs, brand names, prices) inside RTL copy needs care; wrap with bidi isolation where needed. - Language-specific font stacks — CJK (Chinese/Japanese/Korean) and Arabic need appropriate fallback fonts; a Latin-only stack can render tofu boxes. - AMPscript-driven localization in SFMC — locale field on the DE/subscriber drives IF/Lookup swaps of copy blocks, images, and even dir, all at send time.

⭐ Bonus snippet: AMPscript-driven RTL + locale copy (global retail send)

For a multi-locale GAP send, drive the text direction and the copy off the subscriber's locale at send time so Arabic recipients get a mirrored, right-aligned layout:

%%[ SET @locale = AttributeValue("Locale") ]%%
<table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0"
       dir="%%=IIF(@locale=="ar","rtl","ltr")=%%">
  <tr>
    <td align="%%=IIF(@locale=="ar","right","left")=%%"
        style="font-family:Arial,'Noto Sans Arabic',sans-serif;font-size:16px;color:#333333;">
      %%=IIF(@locale=="ar","تسوق التشكيلة الجديدة","Shop the new collection")=%%
    </td>
  </tr>
</table>

🔍 Line by line: - %%[ SET @locale = AttributeValue("Locale") ]%% — an AMPscript statement block that reads the subscriber's Locale attribute (from the send context / DE) into @locale. AttributeValue() pulls a send-time attribute; this runs once at send. - <table role="presentation" ... dir="%%=IIF(@locale=="ar","rtl","ltr")=%%"> — a layout table whose text direction is set dynamically: IIF (inline if) outputs rtl when the locale is Arabic, otherwise ltr. dir="rtl" mirrors the whole layout so Arabic reads right-to-left. - <tr> — the content row. - <td align="%%=IIF(@locale=="ar","right","left")=%%" style="font-family:Arial,'Noto Sans Arabic',sans-serif;font-size:16px;color:#333333;"> — the content cell. align flips to right for Arabic so text hugs the correct edge. The font stack adds 'Noto Sans Arabic' before the Latin fallback so Arabic glyphs render properly instead of "tofu" boxes; the rest is the usual inlined font/size/color for Outlook safety. - %%=IIF(@locale=="ar","تسوق التشكيلة الجديدة","Shop the new collection")=%% — inline AMPscript that outputs the localized copy: the Arabic string for ar, the English string otherwise. Real text (not an image) so it stays accessible and translatable. - </td></tr></table> — closes the cell, row, and table.

---

7. Preheader / preview text

The snippet shown after the subject in the inbox. Hide it visually but keep it in the DOM. This is the standardized recipe — it matches the skeleton in §2:

<div style="display:none;font-size:1px;line-height:1px;max-height:0;max-width:0;
            opacity:0;overflow:hidden;mso-hide:all;color:#f4f4f4;">
  Free shipping ends tonight — shop now.
  &zwnj;&nbsp;&zwnj;&nbsp;&zwnj;&nbsp;&zwnj;&nbsp;&zwnj;&nbsp;&zwnj;&nbsp; <!-- spacer: stop body text leaking into preview -->
</div>

🔍 Line by line: - <div style="display:none;font-size:1px;line-height:1px;max-height:0;max-width:0; opacity:0;overflow:hidden;mso-hide:all;color:#f4f4f4;"> — the hidden preheader wrapper. Each property is a different client's "hide" lever stacked together: display:none (most clients), font-size:1px/line-height:1px (shrink any leak to a hairline), max-height:0/max-width:0 + overflow:hidden (clamp the box to nothing), opacity:0 (transparent), mso-hide:all (classic Outlook), and color:#f4f4f4 to match the background so any leak is invisible. The element stays in the DOM so the inbox preview generator can still read the text. - Free shipping ends tonight — shop now. — the crafted preview snippet shown next to the subject line in the inbox; note it extends rather than echoes the subject (accessibility: don't make screen readers say the same phrase twice). - ‌ ‌ ... — alternating zero-width-non-joiner / non-breaking-space characters forming an invisible spacer that fills the rest of the preview window, pushing the real body copy out so it doesn't bleed in after your snippet. - </div> — closes the preheader wrapper.

Set the color to match your body/wrapper background so that if the snippet ever leaks visibly (it sometimes does), it's invisible against the background rather than showing as a stray line.

⚠️ The honest trade-off (perfect cross-client preheader hiding is NOT fully solvable): - mso-hide:all tells classic Outlook to hide the element — but the preheader is the inbox preview snippet, so there's tension between "hide it in the body" and "let the preview generator read it." A documented quirk: display:none + mso-hide:all can cause Outlook to OMIT the preheader from its reading/preview pane, and conversely hidden preheader text sometimes leaks/shows in Outlook. - Many teams accept the snippet rendering as a tiny 1px line, or use the robust recipe above and accept that one or two clients won't behave. Don't claim it's bulletproof in an interview — frame it as "a well-known imperfect area; here's the recipe I standardize on and the trade-offs." - The ‌  spacer sequence pushes the visible body text out of the preview window so it doesn't bleed in after your crafted snippet.

---

8. Images, fonts, and fallbacks

• Always set width, height (or style), alt, border="0", display:block on <img>.
• Host images on a CDN/SFMC; emails reference absolute URLs (relative URLs don't resolve in the inbox).
• Web fonts (@font-face) — be precise here, the common claim is wrong:
• ✅ Supported: Apple Mail, iOS Mail, Outlook for Mac (and some Samsung/Android native).
• ❌ NOT supported: Gmail (all), Outlook.com (strips most embedded web fonts — do not list it as a supporter), Windows desktop Outlook (classic and new), Yahoo.
• Always provide a websafe fallback stack ('Brand Font', Arial, Helvetica, sans-serif).

• Use mso conditional font fallbacks so classic Outlook falls back cleanly to Arial instead of Times New Roman: ```html <!--[if mso]> <![endif]--> ```

🔍 Line by line: - <!--[if mso]> — Outlook-only conditional; this style block is read only by classic Word-engine Outlook. - <style> — opens an embedded style block. Classic Outlook does respect a simple <style> like this (unlike Gmail), which is why it's used here. - * { font-family: Arial, Helvetica, sans-serif !important; } — the universal selector * forces every element in Outlook to a web-safe font. Without it, classic Outlook falls back to Times New Roman when it can't load your web font, which looks broken; !important overrides any element-level font. This guarantees a clean Arial fallback in Outlook only, leaving the real web font untouched in the clients that support it. - </style> — closes the style block. - <![endif]--> — closes the Outlook-only conditional. - Retina: serve a 2× source and size it down via width/height + inline style (full example in §3).

The inline-CSS workflow (a senior pipeline question) 🔑

"Do you hand-inline or use an inliner?" — and the SFMC-specific gotcha: - SFMC Content Builder does NOT auto-inline your <style> CSS. Whatever you put in <head><style> stays embedded (progressive enhancement only; stripped by Gmail-class clients). So either: 1. Hand-inline critical styles on every element (most reliable, what you do for the core skeleton), or 2. Run an inliner before pasting — Premailer, juice, the Litmus/EoA inliner, or author in MJML (which outputs already-inlined, Outlook-safe HTML) and paste the compiled output into a Code Snippet/HTML block. - Keep media queries, :hover, dark-mode, and @font-face in <head><style> — those can't be inlined (they're not element-level), so they live as embedded progressive enhancement and you accept they're dropped where <style> is stripped. - This split — inline for layout/color reliability, embedded <style> for enhancements — is the answer to "how do you manage CSS at scale in SFMC."

---

9. Countdown timers & dynamic barcodes 🔑 (YOUR resume — own this)

Countdown timers: email clients can't run JS, so live countdowns are server-rendered animated GIFs generated on each open by a timer service (e.g., a CloudPage/3rd-party endpoint or Movable Ink). The <img src> points at a URL with the end-time and styling params; the service returns a GIF reflecting time remaining at fetch time.

<img src="https://timers.example.com/gen?end=2026-06-30T23:59:59&theme=dark"
     alt="Sale ends soon" width="300" height="80" style="display:block;border:0;">

🔍 Line by line: - <img src="https://timers.example.com/gen?end=2026-06-30T23:59:59&theme=dark" ...> — the timer is just an <img> whose src points at a timer service endpoint. The querystring passes the campaign end time and a theme styling param; the service computes "time remaining" at fetch time and returns an animated GIF reflecting it. (In SFMC you'd often build this URL with AMPscript so each subscriber/campaign gets the right deadline.) - alt="Sale ends soon" — accessible/image-blocked fallback text; since the actual numbers are baked into the image, the alt conveys the gist for screen readers and images-off recipients. - width="300" height="80" — HTML dimension attributes reserving the layout space and sizing the GIF (Outlook honors these). - style="display:block;border:0;" — display:block removes the under-image gap; border:0 strips any link border. Note there's no live JS anywhere — the "countdown" is entirely server-rendered pixels.

Interview point: "Because email has no JS, countdowns are dynamically generated images rendered at open-time by a timer service; I pass the campaign end date and styling as URL params, often built with AMPscript so each subscriber/campaign gets the right deadline."

⚠️ The open-time vs proxy-fetch nuance (senior depth — own this caveat too): "rendered at open" is an approximation. With Apple Mail Privacy Protection (MPP) and Gmail's image proxy, the GIF can be fetched and cached at proxy time, not at the human's true open — so the "time remaining" a user sees may be stale/inaccurate for proxied recipients. Mitigations a senior owns: - Timer services set no-cache/Cache-Control headers and bust caches via unique URLs (per-open tokens) so each request regenerates the frame. - But MPP pre-fetch still limits accuracy — for MPP users the image is fetched once, early, by Apple's proxy, so the countdown can be effectively frozen to that fetch moment. - Honest framing: "I treat the countdown as directionally live; for hard deadlines I also state the end date as real text so accuracy doesn't depend solely on the GIF." - prefers-reduced-motion — provide a static fallback frame (final/“ends soon” image) and swap via the media query in §6 so motion-sensitive users aren't forced to watch the animation.

Dynamic barcodes/QR (StyleCash): generated as images per subscriber via a barcode service URL, with the code value injected by AMPscript (looked up per subscriber from a DE). The naive version (below) breaks in production when the lookup returns nothing — here is the null-safe, URL-encoded version a senior actually ships:

%%[
  VAR @code
  SET @code = Lookup("StyleCash_Codes","Barcode","SubscriberKey", _subscriberkey)
  IF EMPTY(@code) THEN
]%%
  <!-- Fallback: no code for this subscriber — suppress the image, show a message -->
  <p style="font-family:Arial,sans-serif;font-size:14px;color:#333;">
    Your StyleCash code isn't ready yet — check back soon.
  </p>
%%[ ELSE ]%%
  <img src="https://barcode.example.com/code128?data=%%=URLEncode(@code,1,1)=%%&scale=3"
       alt="Your StyleCash reward code"
       style="display:block;border:0;">
  <!-- Real-text fallback so the code works even with images OFF -->
  <p style="font-family:Arial,sans-serif;font-size:16px;letter-spacing:2px;color:#111;">
    Code: %%=v(@code)=%%
  </p>
%%[ ENDIF ]%%

🔍 Line by line: - %%[ — opens an AMPscript statement block (%%[ ... ]%%). Code here runs at send time and produces no output on its own; it sets up logic. This only executes inside an HTML or Code Snippet block in Content Builder. - VAR @code — declares a variable named @code (AMPscript variables start with @). - SET @code = Lookup("StyleCash_Codes","Barcode","SubscriberKey", _subscriberkey) — looks up a single value: from Data Extension StyleCash_Codes, return the Barcode column where the SubscriberKey column equals _subscriberkey (the built-in current-subscriber key). Stores the result in @code. - IF EMPTY(@code) THEN — branches on whether the lookup found nothing. EMPTY() is true for null/blank — this is the null guard that prevents emitting a broken barcode for subscribers who have no code. - ]%% — closes the AMPscript block; what follows until the next %%[ ]%% is literal HTML output (conditionally rendered by the IF). - <!-- Fallback: no code for this subscriber — suppress the image, show a message --> — comment marking the no-code branch. - <p style="font-family:Arial,sans-serif;font-size:14px;color:#333;"> Your StyleCash code isn't ready yet — check back soon. </p> — the graceful fallback shown when there's no code: a plain styled message instead of a blank/broken barcode image. - %%[ ELSE ]%% — the ELSE branch: runs when @code is not empty (a code exists). - <img src="https://barcode.example.com/code128?data=%%=URLEncode(@code,1,1)=%%&scale=3" ...> — renders the barcode as an image from a barcode service. %%=URLEncode(@code,1,1)=%% is inline AMPscript output that URL-encodes the code into the querystring; the two 1s mean "encode for a URL" and "treat as a full querystring value," so characters like +, /, &, and spaces don't corrupt the URL. scale=3 tells the service how large to render the bars. - alt="Your StyleCash reward code" — describes the image without leaking the scannable payload into alt (a security/PII consideration — don't expose the raw code there). - style="display:block;border:0;" — removes the under-image gap and link border. - <!-- Real-text fallback so the code works even with images OFF --> — comment introducing the images-off safety net. - <p style="font-family:Arial,sans-serif;font-size:16px;letter-spacing:2px;color:#111;"> Code: %%=v(@code)=%% </p> — prints the code as real text so it's still usable when images are blocked. %%=v(@code)=%% is inline output of the variable's value; v() safely resolves the variable; letter-spacing:2px makes the alphanumeric code easier to read; #111 is an off-black chosen to survive dark-mode inversion better than pure #000. - %%[ ENDIF ]%% — closes the IF/ELSE, ending the AMPscript conditional.

"Each subscriber's unique barcode is looked up from a DE with AMPscript and rendered by a barcode-image service; the image URL carries the encoded value. Because it's an image, it scans at the POS and renders everywhere — no client-side code needed."

The production failure modes a senior owns (the difference between the demo and the real thing): - Null/empty lookup → guard with EMPTY() (or IIF) so you never emit ?data=&... and render a broken/blank barcode. (The naive SET @code = Lookup(...) with no guard is the #1 production bug here.) - URL-encode the value into the src with URLEncode(@code,1,1) — codes can contain +, /, &, spaces that corrupt the querystring if raw. - Image blocking → the barcode is invisible until images load; always provide the code as real text too (above) so it's usable image-off. - Security/PII of codes in URLs → the code sits in the image URL querystring, so it lands in CDN/proxy access logs and (via MPP/Gmail proxy) is fetched by third-party infrastructure. For high-value codes, prefer short-lived/tokenized URLs and don't reuse codes. - alt text leakage → don't put a scannable value (e.g. the raw QR/barcode payload) in alt if it shouldn't be exposed; describe the image instead ("Your StyleCash reward code").

---

10. Testing & QA 🔑

• Litmus / Email on Acid — render previews across 90+ client/device combos; spam testing; link validation; load-time and accessibility checks.
• SFMC Preview and Test — render against a real DE row to validate AMPscript/personalization; send a Test Send / proof to a test list/inbox set; use Validation to catch errors before send.
• Manual inbox tests — Gmail (web/app), classic Outlook desktop (2016/2019/2021) and New Outlook for Windows (different engines — test both!), Outlook.com, Outlook for Mac, Outlook iOS/Android (Blink-ish, differs from desktop), Apple Mail (light/dark), Samsung Mail (the default on huge swaths of Android — often omitted), Yahoo.
• Validate: links/UTMs, alt text, dark mode (all three classes), mobile stacking, dynamic content per segment, unsub link, VAWP.

⚠️ Static previews lie — know their limits (senior point)

Litmus/EoA screenshots are STATIC. They: - do NOT execute open-time/dynamic content (live countdown GIFs, real-time/decisioned images render as a generic frame, not the per-open result); - do NOT always reproduce forced dark-mode inversion accurately (Class 3 clients); - show whatever DE row / sample data the preview is bound to — so AMPscript logic (IF/Lookup/personalization) can pass in preview but fail on real subscriber data.

The mitigations: always do real device sends for the cases that matter; use seed lists spanning your top clients; test AMPscript against multiple real DE rows (a subscriber with the field, one without, one with edge-case data) — not just the default preview row. Check the rendered HTML source size against the 102KB Gmail-clipping limit after AMPscript expansion, not just the lean source (see Gotcha #1).

Content-side spam factors (deliverability from a DEVELOPER angle)

Spam scoring isn't only an infra concern — your HTML contributes. Watch: - Image-to-text ratio — image-only emails (one big sliced hero, no real text) score worse; keep meaningful real text. - Hidden text / tiny fonts / white-on-white beyond a legit preheader looks like cloaking. - Broken/invalid HTML (unclosed tags, malformed tables) raises spam scores and breaks rendering. - Spammy markup & links — excessive !!!, ALL-CAPS, mismatched link text vs href, link shorteners, raw IP URLs. - Run spam tests (Litmus/EoA Spam Testing, e.g. SpamAssassin scoring) as part of QA — and pair with the §13 deliverability/auth requirements.

---

11. AMP for Email & interactive email (be aware)

• AMP for Email — <amp4email> brings interactive content (carousels, forms, live data, RSVP) inside the inbox. Get the client list right:
• ✅ Supported: Gmail, Yahoo Mail, Mail.ru, and FairEmail.
• ❌ NOT supported: Apple Mail (no AMP), and Outlook dropped its AMP developer preview in September 2020 (don't claim Outlook supports it).
• Registration is more than "allow-listing": for Gmail you must register/whitelist your sending domain by submitting an AMP sample for review (the g.co/AMP4Email registration flow) and meet Gmail's authentication requirements (SPF/DKIM/DMARC). The message must carry a text/x-amp-html MIME part PLUS a required text/html fallback (and ideally text/plain) — non-AMP clients fall back to the HTML version.
• SFMC angle: AMP is niche in SFMC and not a first-class Content Builder feature; mention you'd send it via a custom MIME part and that the 2024 Gmail/Yahoo auth rules (§13) are a prerequisite anyway.
• Interactive/"kinetic" email — CSS-only (checkbox/radio hack) carousels, tabs, hotspots that work in WebKit clients (Apple Mail), with static fallback elsewhere. No JS required, so it survives where AMP isn't registered.

Send-time vs open-time personalization (a classic senior contrast) 🔑

Interviewers love "contrast send-time and open-time personalization": - Send-time (AMPscript / SSJS in SFMC) — logic runs once, when the email is generated/sent. Lookup, IF, personalization strings, dynamic tables all resolve at that moment and are frozen into the rendered HTML. Deterministic, testable, but cannot change after send (a price/inventory value is whatever it was at send). - Open-time (image services / real-time) — content resolves when the recipient opens (or when their client/proxy fetches the image): Movable Ink, SFMC's own real-time / Personalization (Interaction Studio) decisioning, live weather/inventory/countdown images. The <img src> hits a service that returns the right pixels at fetch time. - The catch (ties to MPP, §15 Gotchas): "open-time" really means "image-fetch time," and MPP/Gmail proxy pre-fetch can resolve it early and cache it — so open-time content isn't perfectly live for proxied users, and geolocation/open-time targeting becomes unreliable (the proxy's location, not the user's).

Frameworks: MJML / hand-code (a near-guaranteed question)

"Do you hand-code or use MJML/Foundation for Emails?" Have a position: - MJML is a markup-to-HTML compiler that outputs already-inlined, Outlook-safe (ghost-table/VML) responsive HTML — huge time-saver, removes a class of boilerplate bugs. - Why a shop might NOT use it in SFMC: Content Builder works in raw HTML/AMPscript and many teams maintain hand-tuned modular templates + reusable Content Blocks with embedded AMPscript; MJML's output then has to be re-integrated with AMPscript and the team's blocks, which can be friction. Also MJML doesn't know about AMPscript. - A senior answer: "I can hand-code bulletproof HTML and do for our core SFMC templates and AMPscript blocks; I reach for MJML/preprocessors when building net-new layouts fast, then adapt the output into our Content Builder blocks." (Ties to the candidate's modular-template / double-build / build-time-−30% work.)

---

12. The SFMC platform layer (this is an SFMC interview, not a generic email-dev one) 🔑🔑

Everything above is portable email HTML. This section maps it to how SFMC actually builds, personalizes, tracks, and ships that HTML — the layer that separates an SFMC dev from a generic email coder.

Where the HTML lives: Email Studio vs Content Builder, and the block types

• Content Builder (modern) is the primary content tool — shared content store, drag-and-drop blocks, templates, and reusable assets. Legacy Email Studio classic emails/templates still exist (older programs), but new work is Content Builder.
• Content block types you must name:
• HTML block / Code Snippet block — raw HTML; AMPscript and %%...%% tags execute here. This is where a developer lives.
• Text / WYSIWYG / Free-form blocks — for non-devs; AMPscript does NOT reliably execute in these — keep logic out of them.
• Image / Button blocks — managed widgets; less control, but accessible/marketer-friendly.
• Templates & layout regions: template-based emails define Slots and locked vs editable regions so marketers can edit content inside guardrails without touching your skeleton. Template-based layouts = guided structure; HTML-paste emails = full-control single block.
• Reusable Content Blocks / Code Snippet blocks — DRY building blocks (a header, a footer with compliance links, a product card) referenced across emails. This is the backbone of a modular-template system (the candidate's build-time-−30% work) — fix the footer once, every email updates.

AMPscript in the HTML: the two syntaxes

• %%[ ... ]%% — a block of AMPscript statements (declare VAR, SET, IF/THEN/ELSE/ENDIF, FOR loops, Lookup). No output by itself.
• %%=Function(...)=%% — inline output of an expression (e.g. %%=v(@firstName)=%%, %%=ProperCase(@city)=%%).
• %%fieldName%% — shorthand to output a send-context attribute/field directly (e.g. %%firstName%%, %%emailaddr%%).
• Know the difference between %%[ ]%% (logic) and %%...%% (output) cold — it's a frequent screening question.

Link tracking, the redirect domain, and the SAP

• SFMC rewrites/aliases your hrefs at send time to route clicks through its click-tracking redirect domain before redirecting to the real URL — that's how Open/Click tracking works. The clean, branded version of that domain comes from your Sender Authentication Package (SAP) (custom redirect/link-wrapping domain + custom From domain + dedicated IP/reputation), so links don't show a generic *.exct.net-style host.
• Link aliasing lets you give a link a stable name in reporting regardless of the URL.
• The open pixel — SFMC injects a 1×1 tracking pixel; opens are counted when it loads (subject to MPP inflation, §15 Gotchas). ⚠️ This pixel and trailing tracking get placed late in the HTML, so anything clipped by Gmail's 102KB can drop the pixel and under-count opens (§15 Gotcha #1).

Required personalization strings (CAN-SPAM / footer compliance — hard-code these in templates)

SFMC provides substitution strings the platform resolves to the right URLs/values per send. A compliant footer typically hard-codes:

Hi %%=v(@firstName)=%%,
...
<p style="font-family:Arial,sans-serif;font-size:12px;color:#888;">
  <a href="%%profile_center_url%%">Update preferences</a> &nbsp;|&nbsp;
  <a href="%%unsub_center_url%%">Unsubscribe</a> &nbsp;|&nbsp;
  <a href="%%view_email_url%%">View in browser</a><br>
  GAP Inc., 2 Folsom Street, San Francisco, CA 94105  <!-- physical mailing address: CAN-SPAM requirement -->
</p>

🔍 Line by line: - Hi %%=v(@firstName)=%%, — a personalized greeting; %%=v(@firstName)=%% is inline AMPscript output of the subscriber's first name (use v() to resolve a variable safely). Resolves at send time and freezes into the HTML. - ... — placeholder for the email body. - <p style="font-family:Arial,sans-serif;font-size:12px;color:#888;"> — the footer paragraph styled small and grey (typical legal/footer styling); inline styles because this ships in Content Builder where <style> isn't auto-inlined. - <a href="%%profile_center_url%%">Update preferences</a> — link to the subscriber's Profile Center; %%profile_center_url%% is an SFMC substitution string the platform replaces with the correct per-subscriber URL at send time. -  |  — a non-breaking-space-padded pipe separator so the links don't collapse together or wrap awkwardly. - <a href="%%unsub_center_url%%">Unsubscribe</a> — the required working unsubscribe link; %%unsub_center_url%% resolves to the Subscription Center / opt-out flow. A working unsubscribe is a CAN-SPAM legal requirement and should match the List-Unsubscribe header path (§13). - <a href="%%view_email_url%%">View in browser</a><br> — the "view as web page" link via %%view_email_url%%; <br> drops to the next line before the address. - GAP Inc., 2 Folsom Street, San Francisco, CA 94105 — the physical postal address, also a CAN-SPAM legal requirement, not optional polish. - </p> — closes the footer paragraph.

• %%profile_center_url%% → subscriber's Profile Center.
• %%unsub_center_url%% → Subscription Center / one-click unsubscribe flow (maps to the List-Unsubscribe story in §13).
• %%view_email_url%% → web "view as page" version (the View Online link).
• A physical postal address + a working unsubscribe are CAN-SPAM legal requirements, not optional polish.

102KB clipping × AMPscript expansion (a real production trap) 🔑

Gmail clips the rendered HTML MIME part at ~102KB ("View entire message…"). The trap: AMPscript expands at send time. A lean source template can blow past 102KB after personalization, FOR-loop rows, and SFMC's link-rewriting add bytes. Mechanics + mitigations: - Clipping is on the rendered HTML size, not image weight. - SFMC's click-tracking link rewriting ADDS bytes to every href. - The clipped tail can lose the open pixel and any tracking placed after the cut. - Mitigations: minify; avoid redundant repeated inline styles (factor common styles, accept some embedded <style>); limit comments; watch dynamic tables / FOR loops that expand per row; check the rendered size (preview the real send output), not just the source.

Interview-ready line: "Our cart-abandon template was lean in source but a power-user with 30 cart items expanded past 102KB after the AMPscript FOR loop, clipping the footer and the open pixel — I capped the loop, trimmed repeated inline styles, and we tracked size on the rendered output, not the template."

---

13. Deliverability & authentication a DEVELOPER must implement (2024 Gmail/Yahoo rules) 🔑🔑

The single most likely 2026 deliverability question. Gmail/Yahoo bulk-sender requirements took effect Feb 1, 2024 and began enforcement around April 2024, applying to senders of 5,000+ messages/day to Gmail (Yahoo similar). Know what they are and how the HTML/headers implement them.

The three pillars: 1. Authentication — SPF + DKIM + DMARC, all required. DMARC must be published at at least p=none, with alignment (the From: domain aligns with SPF/DKIM). In SFMC this is the Sender Authentication Package (SAP) + DNS records for your sending domain. 2. One-click unsubscribe — RFC 8058. Marketing mail must include a List-Unsubscribe header AND a List-Unsubscribe-Post header, and the unsubscribe must be honored within 2 days. 3. Spam complaint rate — keep it below 0.3% (Google's stated target is under 0.1%); spikes above 0.3% get you throttled/blocked. Plus: valid PTR/rDNS, TLS for transport.

One-click List-Unsubscribe done correctly (RFC 8058):

List-Unsubscribe: <https://example.com/unsub?u=%%subscriberkey%%>, <mailto:unsub@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

🔍 Line by line: - List-Unsubscribe: <https://...>, <mailto:...> — an email header (not HTML body — it lives in the message envelope, configured at the account/send level in SFMC). It offers the mailbox provider two ways to unsubscribe: an HTTPS URL and a mailto: address, each wrapped in angle brackets and comma-separated. %%subscriberkey%% is substituted per recipient so the link identifies who to opt out. Providers like Gmail surface this as the native "Unsubscribe" button next to the sender. - List-Unsubscribe-Post: List-Unsubscribe=One-Click — the companion header that upgrades the above to true one-click (RFC 8058): it tells the mailbox provider it may POST List-Unsubscribe=One-Click to the HTTPS target directly, so the user is opted out without leaving the inbox and without a confirmation page. Required by the 2024 Gmail/Yahoo bulk-sender rules.

• Both a HTTPS and a mailto target; the List-Unsubscribe-Post line is what makes it one-click (the mailbox provider POSTs the unsubscribe without the user leaving the inbox).
• SFMC mapping: the platform's Subscription/Profile Center and the %%unsub_center_url%% string back the user-facing unsubscribe; the List-Unsubscribe headers are configured at the account/send level so the inbox-native one-click works. The header unsubscribe and the in-body %%unsub_center_url%% link should land the subscriber in the same opt-out outcome.
• Why a developer cares: AMP registration (§11) and overall inboxing both depend on this auth being in place — it's not "the deliverability team's problem."

Interview-ready line: "Since the Feb-2024 Gmail/Yahoo rules, every bulk program I ship has SPF+DKIM+DMARC alignment via the SAP, RFC-8058 one-click List-Unsubscribe with the List-Unsubscribe-Post header wired to our Subscription Center, and we watch the Postmaster complaint rate under 0.3% — and I keep the in-body %%unsub_center_url%% consistent with the header path."

---

14. Interview angles

Q: "Why tables and inline CSS?" → Classic Outlook = Word engine, and many clients strip <head>/external CSS or <style>; inline + tables = reliable cross-client rendering. Add the nuance: modern engines (Apple Mail, Gmail webmail, New Outlook/Outlook.com) support far more, but I code to the lowest common denominator so it degrades cleanly everywhere.

Q: "How do you support Outlook?" → First clarify which Outlook — classic (Word engine) vs New Outlook for Windows/Outlook.com (web engine). For classic: MSO conditional comments, ghost tables for width/centering, VML for buttons/backgrounds, mso-line-height-rule:exactly, PixelsPerInch fix, display:block on images. For the modern web-engine Outlooks: ensure the [if !mso] branch is itself bulletproof (they strip VML) and handle their forced dark-mode inversion via [data-ogsc]/[data-ogsb].

Q: "Responsive strategy?" → Explain fluid vs media-query vs hybrid; why hybrid is safest at scale because it survives stripped media queries (columns reflow via width:100%;max-width with no @media), and the font-size:0 inline-block whitespace fix.

Q: "How do live countdown timers work in email if there's no JS?" → Server-rendered GIF per open via timer service; params (end time) injected with AMPscript. Senior add: "open" is really "image-fetch," so MPP/Gmail-proxy pre-fetch can freeze/stale the timer — I bust caches with unique URLs/no-cache, back it with a real-text deadline, and give a prefers-reduced-motion static fallback. (Strong, specific, true.)

Q: "How do you ensure accessibility?" → role="presentation", alt (empty alt="" for decorative, never missing), contrast (WCAG 2.2 AA 4.5:1 / 3:1 large), real text, semantic source order, lang, descriptive links/aria-label, prefers-reduced-motion, preheader ≠ subject. Name the legal frame: WCAG 2.2 AA / ADA / EU EAA (2025).

Q: "Contrast send-time vs open-time personalization." → Send-time = AMPscript/SSJS resolves once at send and freezes into the HTML (deterministic, can't change after send). Open-time = image services (Movable Ink / SFMC real-time) resolve at fetch; but MPP/proxy pre-fetch + geolocation-via-proxy make it imperfect.

Q: "How do you keep emails out of the 102KB clip — and why does it matter in SFMC?" → It's the rendered HTML size after AMPscript expansion + SFMC link-rewriting; a lean template can blow past it on loop-heavy/personalized rows, clipping the footer and the open pixel. Minify, dedupe inline styles, cap FOR loops, measure the rendered output.

Q: "What changed with Gmail/Yahoo in 2024 and what's your part as a developer?" → SPF+DKIM+DMARC (p=none min, aligned) via the SAP; RFC-8058 one-click List-Unsubscribe + List-Unsubscribe-Post wired to the Subscription Center; complaint rate < 0.3%. I keep the in-body %%unsub_center_url%% consistent with the header path.

Q: "Dark mode — how does it actually work across clients?" → Three classes: Apple/iOS Mail honor prefers-color-scheme; Outlook.com/New Outlook/Win10 Mail force inversion and ignore the media query (use [data-ogsc]/[data-ogsb] hooks); Gmail is mixed. Protect logos with non-transparent cells; design inversion-tolerant palettes for what you can't control.

Q: "How do you manage CSS at scale — inline or embedded?" → SFMC Content Builder doesn't auto-inline, so I inline layout/color (by hand or via Premailer/MJML) and keep media queries/:hover/dark-mode/@font-face in <head><style> as progressive enhancement.

Q: "Where can AMPscript run in Content Builder, and what's %%[ ]%% vs %%=...=%%?" → AMPscript executes in HTML/Code Snippet blocks (not text/WYSIWYG). %%[ ]%% = statement block (logic), %%=Fn()=%% = inline output, %%field%% = direct attribute output.

---

15. Gotchas

1. Gmail clips emails >~102KB ("View entire message…") — and the clip is on the rendered HTML after AMPscript expansion + SFMC link-rewriting, so a lean source can still blow past it. The clipped tail can drop the open pixel and footer/unsub. Minify, dedupe inline styles, cap FOR loops, measure the rendered output (§12).

2. Gmail removes the <style> BLOCK containing an invalid/unsupported rule — not necessarily ALL embedded CSS. Precise behavior (matters at senior level): - It strips the specific <style> block that has the offending rule; other separate <style> blocks survive. - A block exceeding ~8KB (8192 chars) gets dropped. - A nested at-rule — e.g. @import or @font-face inside @media — strips the whole block. - Mitigation: split CSS across blocks, keep each lean, no nested at-rules.

3. Outlook image issues are TWO separate things — don't conflate them: - (a) Tall-image HEIGHT clip: classic Outlook (Word engine) clips a single image taller than ~1728px from the bottom (a Word page-size limit). This is a vertical/height limit — NOT a maximum image width. Fix: split very long images into stacked slices (§3). - (b) max-width ignored: Outlook ignores max-width on images/elements, so always set explicit pixel width/height attributes and inline width. (An interviewer probing "what's the 1728 limit?" is testing whether you know it's height, not width.)

4. Apple MPP inflates opens and pre-fetches/proxies images, which breaks open-time dynamic content (countdowns can freeze at proxy-fetch, §9), makes geolocation/open-time targeting unreliable (proxy location, not user), and renders live images at fetch-time not true open. (See Module 02 for the deliverability side.)

5. Background images need VML for classic Outlook — and remember New Outlook/Outlook.com ignore VML, so pair the VML half with a real CSS background-image + background-color fallback (§3).

6. <style> in the body is unreliable; keep CSS in <head> + inline. Content Builder does NOT auto-inline — inline by hand or via an inliner/MJML (§8).

7. Special characters — use HTML entities; set charset=utf-8 (and consider locale-aware fonts for CJK/RTL, §6).

8. VML only fires in classic Outlook — the modern web-engine Outlooks fall through to your [if !mso] branch, so that branch must be bulletproof on its own (§3).

9. Dark-mode forced inversion ignores prefers-color-scheme — Outlook.com/New Outlook/Win10 Mail recolor regardless; use [data-ogsc]/[data-ogsb] hooks or inversion-tolerant colors (§5).

10. Unguarded Lookup / missing URLEncode in AMPscript image URLs → blank/broken barcodes and corrupted querystrings. Guard with EMPTY() and URLEncode(@val,1,1) (§9).

11. Static preview tools lie — Litmus/EoA screenshots don't run open-time content, don't always show forced inversion, and use the bound sample row; confirm with real device sends and multiple real DE rows (§10).

➡️ Next: 04_AMPscript_Deep_Dive.md — your signature skill.

Module 04 — AMPscript Deep Dive

Your headline skill. Expect live whiteboard/IDE questions. We cover syntax, every function family, lookups, data manipulation, content injection, context, and best practices. Memorize the lookup + Rows loop pattern — it's the #1 AMPscript interview task. 🔑

---

1. What AMPscript is and where it runs

• A proprietary scripting language for SFMC, used in emails, CloudPages, landing pages, SMS, and push.
• Runs server-side at send/render time — the recipient never sees code, only the rendered output.
• Used for personalization, conditional content, data lookups, and writing back to DEs.

Where you can put it

1. Inline output: %%=Function()=%%
2. Personalization strings: %%FieldName%% (from the sendable DE / attributes).
3. Script blocks: %%[ ... ]%% (logic, no direct output) — the idiomatic AMPscript block delimiter.
4. Tag-based (server-side) <script runat="server" language="ampscript"> — functionally equivalent to a %%[ ]%% block, but rarely used for AMPscript. The <script runat="server" language="ssjs"> tag is the standard wrapper for SSJS; the tag form exists mainly to mirror SSJS and is only occasionally seen for AMPscript. In real assets you'll almost always write AMPscript inside %%[ ]%%.

---

2. Syntax fundamentals 🔑

Script block + inline output

%%[
  VAR @firstName, @greeting
  SET @firstName = AttributeValue("FirstName")
  IF EMPTY(@firstName) THEN
    SET @greeting = "Hi there"
  ELSE
    SET @greeting = Concat("Hi ", @firstName)
  ENDIF
]%%
<p>%%=v(@greeting)=%%</p>

🔍 Line by line: - %%[ — opens an AMPscript logic block. Everything between %%[ and ]%% is executed server-side but produces no output on its own; it's where you declare variables, run lookups, and branch. - VAR @firstName, @greeting — declares two script variables. Every AMPscript variable name starts with @. VAR lists them up front (comma-separated); it reserves the names but does not assign values yet. - SET @firstName = AttributeValue("FirstName") — assigns a value. SET is the only assignment keyword. AttributeValue("FirstName") pulls the FirstName column from the subscriber/sendable-DE send context; if that column is missing it returns an empty string rather than erroring. - IF EMPTY(@firstName) THEN — starts a conditional. EMPTY(x) returns true when x is either null or an empty string "", so this asks "did we actually get a first name?" - SET @greeting = "Hi there" — runs only when the name is empty. String literals go in double quotes. - ELSE — the alternate branch, taken when @firstName is not empty. - SET @greeting = Concat("Hi ", @firstName) — joins two strings with Concat(). Remember: AMPscript has no + or & string operator, so Concat() is how you build "Hi Akash". - ENDIF — closes the IF. Every IF must be terminated with ENDIF. - ]%% — closes the logic block. Execution of the block ends here. - <p>%%=v(@greeting)=%%</p> — back in HTML. %%=v(@greeting)=%% is inline output: the %%= ... =%% wrapper prints a value into the rendered HTML, and v(@greeting) means "the value of variable @greeting." The <p> tags are plain HTML around it.

• Variables start with @, declared with VAR (optional but good practice), assigned with SET.
• %%=v(@var)=%% outputs a variable's value. v() = "value of".
• Case-insensitive for functions/keywords; variable names are case-insensitive too.
• No semicolons; statements are newline/whitespace separated.
• Comments: /* ... */.
• Strings in double quotes; concatenate with Concat() (no + and no & for strings — see operator note below).

Operators — read this carefully (a classic trip-up) 🔑

AMPscript's operator rules are inconsistent, and the inconsistency is exactly what an interviewer probes:

• Equality: both == and a single = work inside IF. (IF @x = 1 THEN is legal — unusual, but valid.) Prefer == for clarity.
• Logical: AND/OR/NOT are the canonical forms. && and || do work as aliases for AND/OR in conditionals.
• String concatenation: there is NO & or + operator. The single & is never string concatenation in AMPscript. Use Concat() for strings.
• Arithmetic: there is no +/-/*// operator either — use Add(), Subtract(), Multiply(), Divide(), Mod().

⚠️ Because &&/|| look like other languages' operators, people assume &/+ also do something — they don't. "a" & "b" will not compile/render. This is one of the most common bugs in real AMPscript, and a sharp reviewer will spot it instantly in code.

Conditionals

IF @x == 1 THEN
   ...
ELSEIF @x == 2 THEN
   ...
ELSE
   ...
ENDIF

🔍 Line by line: - IF @x == 1 THEN — the opening test. == is the equality comparison (a single = also works here, but == is clearer). THEN is required and marks where the conditional body begins. - ... — placeholder for the statements that run when @x equals 1. - ELSEIF @x == 2 THEN — an additional test, checked only if the first IF was false. You can chain as many ELSEIF branches as you need. - ELSE — the catch-all branch, run when none of the IF/ELSEIF tests matched. It is optional. - ENDIF — mandatory terminator. AMPscript has no curly braces or indentation rules, so ENDIF is the only thing that tells the parser the conditional is over.

Operators in conditionals: == (or =), !=, >, <, >=, <=, AND (or &&), OR (or ||), NOT. (Use == for equality.)

Loops

FOR @i = 1 TO @rowCount DO
   ...
NEXT @i

🔍 Line by line: - FOR @i = 1 TO @rowCount DO — starts a counted loop. @i is the loop counter, initialized to 1; the loop runs while @i is less than or equal to @rowCount. DO marks the start of the loop body. AMPscript increments @i by 1 automatically each pass — there is no manual @i = @i + 1. - ... — placeholder for the body that repeats each iteration (typically Row/Field work). - NEXT @i — closes the loop and advances @i to the next value. The variable name after NEXT must match the counter in the FOR.

Also reverse: FOR @i = @rowCount DOWNTO 1 DO ... NEXT @i.

---

3. Personalization & context functions 🔑

RaiseError — the correct signature 🔑

The full documented signature is:

RaiseError("Human-readable message", boolSkipCurrentOnly, apiErrorCode, apiErrorNumber, boolPreserveDataExt)

🔍 Line by line: - RaiseError(...) — a function (not a logic keyword) that deliberately raises an error to stop processing. It takes up to five arguments, separated by commas; only the first is required. - "Human-readable message" — arg 1: the error text you'll see in tracking/error reports. - boolSkipCurrentOnly — arg 2: a boolean. true = skip only the current subscriber and keep sending; false (default) = abort the entire job (detailed below). - apiErrorCode — arg 3: an optional string error code you invent (e.g., "ERR_TOKEN"). - apiErrorNumber — arg 4: an optional numeric code you choose. - boolPreserveDataExt — arg 5: a boolean controlling whether DE writes made before the error are kept or rolled back.

• boolSkipCurrentOnly (the 2nd param — not a "continue" flag and not a field name): true skips only the current subscriber and continues the rest of the send; false (the default) aborts the entire job. This is the single most important parameter to get right.
• apiErrorCode (3rd param) — a user-defined API error code string you choose (e.g., "ERR_TOKEN"), surfaced in tracking/error reporting. It is not a field name.
• apiErrorNumber (4th param) — an optional user-defined numeric code.
• boolPreserveDataExt (5th param, senior-relevant): if true, DE writes (InsertDE/UpsertDE/etc.) made before the error are retained even when the subscriber is skipped; if false, those writes are rolled back. This matters for idempotency/cleanup — e.g., you don't want a half-written audit row left behind, or conversely you do want a "we attempted X" marker preserved.

IF EMPTY(@requiredToken) THEN
   /* true => skip ONLY this subscriber, the send continues for everyone else */
   RaiseError("Missing token for SubscriberKey", true, "ERR_TOKEN")
ENDIF

🔍 Line by line: - IF EMPTY(@requiredToken) THEN — guard that fires only when @requiredToken is null or "". This is the "do we have what we need to safely render this subscriber?" check. - /* true => skip ONLY this subscriber... */ — a comment. AMPscript comments use /* ... */ and produce no output. - RaiseError("Missing token for SubscriberKey", true, "ERR_TOKEN") — raises the error. The true in the 2nd position is the critical part: it sets boolSkipCurrentOnly=true, so SFMC skips just this one subscriber and continues the send for everyone else. "ERR_TOKEN" is your custom API error code for reporting. - ENDIF — closes the guard.

_messagecontext — the full value set 🔑

_messagecontext tells you which rendering context you're in. There are 10 documented values; know the bolded ones cold:

🔑 During a normal send the value is SEND; it only becomes VAWP when that same email is later viewed as a web page. A CloudPage returns SITE (landing pages LANDINGPAGE), and forward-to-a-friend returns FTAF. Use this to guard write-backs and external calls so they don't fire on web-page views, previews, or FTAF — directly relevant to VAWP escalation work, where a write firing on every "view as web page" silently pollutes data.

AttributeValue vs %%Field%% vs v(@var) 🔑

These three look interchangeable but resolve from three different sources — a favorite "where does this value come from?" senior question:

• AttributeValue("Col") resolves only from the Subscriber / sendable-send context. It returns empty (never errors) if the attribute is absent, and — crucially — it accepts a computed/dynamic column name (e.g., AttributeValue(Concat("Pref_", @category))). That dynamic-name capability enables data-driven personalization that %%Field%% cannot do.
• %%Field%% is a direct personalization string. It errors if the field is absent from the current context, and the column name must be a literal.
• v(@var) outputs a script variable you set with SET @var = ... — it has nothing to do with data fields.

Senior line: "I reach for AttributeValue when the column name itself is data-driven, or when I want a graceful empty instead of a hard error; %%Field%% is fine for known, always-present columns; v() is purely for variables."

---

4. Data lookup functions 🔑🔑 (THE core skill)

Single value: Lookup

SET @region = Lookup("Store_Master", "Region", "StoreID", @storeId)

🔍 Line by line: - SET @region = ... — stores the lookup's single return value in @region. - Lookup("Store_Master", ...) — arg 1 is the Data Extension name to read from (here, a Store_Master DE of all stores). - "Region" — arg 2 is the column to return — the one value you want back (the store's region). - "StoreID" — arg 3 is the column to match on (the filter column). For speed this should be the DE's primary key or an indexed field. - @storeId — arg 4 is the value to match against StoreID. So this reads: "in Store_Master, find the row where StoreID = @storeId, and give me its Region."

Lookup(DE, returnColumn, matchColumn, matchValue [, matchColumn2, matchValue2 ...]) → returns one value. If no match → empty string.

⚠️ Nuance interviewers love: when multiple rows match, Lookup returns the value from an unspecified row — NOT deterministically the "first physical row" or the most recently inserted one. So even when you only want "a" value, if you actually need the first / the latest, do not rely on Lookup — use LookupOrderedRows(..., 1, "SortCol DESC", ...) with an explicit ORDER BY and take row 1.

🔑 Performance: the matchColumn should be the DE's primary key or an indexed field. Lookups against a non-indexed column force a scan; PK/indexed matching is what makes render-time lookups fast. Your DE Lookup tool's "~50% faster metadata" story lives here — proper PKs and sendable-DE design are the lever.

Multiple rows: LookupRows

SET @rows = LookupRows("Order_Items", "OrderID", @orderId)
SET @count = RowCount(@rows)
IF @count > 0 THEN
  FOR @i = 1 TO @count DO
    SET @row  = Row(@rows, @i)
    SET @sku  = Field(@row, "SKU")
    SET @name = Field(@row, "ProductName")
    SET @qty  = Field(@row, "Qty")
    ]%%
       <tr><td>%%=v(@name)=%%</td><td>%%=v(@qty)=%%</td></tr>
    %%[
  NEXT @i
ENDIF

🔍 Line by line: - SET @rows = LookupRows("Order_Items", "OrderID", @orderId) — LookupRows(DE, matchColumn, matchValue) returns a rowset (a collection of whole rows), not a single value. This grabs every row in Order_Items where OrderID = @orderId. Note the argument shape differs from Lookup: there is no "return column" — you get the entire matching rows back. - SET @count = RowCount(@rows) — RowCount(@rowset) returns how many rows came back. Always capture this before looping. - IF @count > 0 THEN — guard: only enter the loop if at least one row matched. Skipping this risks looping zero times or erroring on an empty rowset. - FOR @i = 1 TO @count DO — loop once per row. AMPscript rowsets are 1-indexed (the first row is 1, not 0). - SET @row = Row(@rows, @i) — Row(@rowset, n) pulls the nth row object out of the rowset so you can read its fields. - SET @sku = Field(@row, "SKU") — Field(@row, "Col") reads one column's value out of the current row. Here it grabs the SKU column. - SET @name = Field(@row, "ProductName") — same, for the ProductName column. - SET @qty = Field(@row, "Qty") — same, for the Qty column. - ]%% — closes the logic block mid-loop so the next lines emit as HTML. This "pop out to HTML, then pop back in" pattern is how you interleave markup with loop logic. - <tr><td>%%=v(@name)=%%</td><td>%%=v(@qty)=%%</td></tr> — an HTML table row. %%=v(@name)=%% and %%=v(@qty)=%% inline-output the variables you just read from the current row. - %%[ — re-opens the logic block to continue the loop. - NEXT @i — advances to the next row. Control jumps back to the matching FOR. - ENDIF — closes the @count > 0 guard.

🔑 This LookupRows → RowCount → Row → Field loop is the most-asked AMPscript task. Be able to write it blind.

Ordered rows: LookupOrderedRows

SET @rows = LookupOrderedRows("Products", 5, "Price DESC", "Category", "Shoes")

🔍 Line by line: - SET @rows = ... — stores the returned, sorted rowset in @rows. - "Products" — arg 1: the DE to read from. - 5 — arg 2 (numRows): the maximum number of rows to return. A value < 1 (including 0) means "all matches," still capped at 2,000. - "Price DESC" — arg 3: the sort order, written like a SQL ORDER BY clause. DESC = highest first; ASC = lowest first. Multi-column sorting is allowed, e.g. "Score DESC, OrderDate ASC". - "Category" — arg 4: the match column (the filter). - "Shoes" — arg 5: the value to match. Together: "from Products, the 5 most expensive rows where Category = Shoes, highest price first."

LookupOrderedRows(DE, numRows, "col ORDER", matchCol, matchVal, ...) - numRows = max rows. A value < 1 (including 0) returns all matching rows — but capped at 2,000 (see below). - "Price DESC" sets sort order. Supports multi-column sort: "Score DESC, OrderDate ASC". - LookupRows does NOT guarantee order; use OrderedRows when order matters. - The ORDER BY is applied in the data layer, and the 2,000-row cap is applied AFTER sorting. So "top 5 by Score DESC" is fully reliable; but "all rows" on a DE with >2,000 matches still silently truncates to the top 2,000 by your sort.

🔑🔑 The 2,000-row hard cap — a top senior gotcha

Every Lookup*Rows function (LookupRows, LookupOrderedRows, and their CS variants) is hard-capped at 2,000 rows, regardless of numRows. numRows < 1 means "all matches… up to 2,000." If a query could match more than 2,000 rows, you will silently lose rows — no error, no warning.

This is a classic interview trap: "Your DE has 5,000 rows matching this customer — what does LookupOrderedRows(\"Orders\", 0, ...) return?" → 2,000, not 5,000.

/* Returns AT MOST 2,000 rows even though 5,000 may match: */
SET @orders = LookupOrderedRows("Orders", 0, "OrderDate DESC", "CustID", @cid)
SET @shown  = RowCount(@orders)          /* <= 2000 */

/* DataExtensionRowCount returns the TRUE count even when you can't retrieve them all: */
SET @actual = DataExtensionRowCount("Orders")   /* could be 5000 */

🔍 Line by line: - /* Returns AT MOST 2,000 rows... */ — a comment flagging the trap. - SET @orders = LookupOrderedRows("Orders", 0, "OrderDate DESC", "CustID", @cid) — the 0 says "give me ALL matching rows," sorted newest-first by OrderDate, for this customer (CustID = @cid). But "all" is silently capped — you get at most 2,000 rows even if more match. - SET @shown = RowCount(@orders) — counts what you actually retrieved. The trailing comment notes this is <= 2000, never higher. - /* DataExtensionRowCount returns the TRUE count... */ — comment. - SET @actual = DataExtensionRowCount("Orders") — DataExtensionRowCount("DE") returns the real total row count of the DE (here it could be 5,000). It is the way to detect that you're being truncated: if @actual > @shown, rows were silently dropped. (Note: it counts the whole DE, not just rows matching @cid.)

Senior mitigations (know all three): 1. Pre-aggregate upstream — build a per-customer summary DE with a SQL Query Activity (e.g., one row per customer with total/last-order), then Lookup the single summary row at render. This is the right answer for almost all retail use cases. 2. Paginate / use SSJS + WSProxy Retrieve with paging (continuation tokens) when you genuinely must read all rows. 3. Narrow the match so any single lookup returns < 2,000 rows by design.

Case-sensitive variants

• LookupRowsCS, LookupOrderedRowsCS, LookupCS — case-sensitive matching. (Default Lookup is case-insensitive on the matched value.) The 2,000-row cap applies to the CS variants too.

Field accessors

• Row(@rowset, n) → the nth row.
• Field(@row, "Col" [, boolException]) → value of a column. boolException defaults to true — a missing column throws a runtime error by default. Pass 0/false to suppress the error and return an empty string instead — the genuinely useful, non-obvious behavior, for columns that may not exist in all rows or across environments (dev vs prod DEs that drift).
• RowCount(@rowset) → number of rows in the rowset.

/* 0 => return '' instead of erroring if LoyaltyTier column is absent in this environment */
SET @loyalty = Field(@row, "LoyaltyTier", 0)
SET @tier    = IIF(EMPTY(@loyalty), "Standard", @loyalty)

🔍 Line by line: - /* 0 => return '' instead of erroring... */ — comment explaining the trick on the next line. - SET @loyalty = Field(@row, "LoyaltyTier", 0) — reads the LoyaltyTier column from @row. The third argument is boolException: it defaults to true, meaning a missing column throws a runtime error. Passing 0 (false) suppresses that error and returns an empty string instead — essential when a column might not exist in every environment (e.g., a dev DE that drifted from prod). - SET @tier = IIF(EMPTY(@loyalty), "Standard", @loyalty) — IIF(condition, trueValue, falseValue) is an inline if. If @loyalty came back empty, default to "Standard"; otherwise use the real tier. This pairs the safe read with a sensible fallback.

⚠️ Gotcha: Lookup returns the value from an unspecified matching row when several match — it is NOT guaranteed to be the first physical row. For deterministic "first/latest," use LookupOrderedRows with an explicit ORDER BY.

---

5. Data manipulation functions 🔑 (write-back)

⚠️ The *Data family is related to but NOT identical to the *DE family — they have different argument shapes and return semantics (InsertData returns the new row's identity; the *Data set has rowset-oriented variants such as UpsertData taking a rowset). They are not simple aliases, so don't call them "older equivalents" — that oversimplification invites a follow-up you'll fumble. The *DE family is the current recommended set; reach for the rowset-oriented *Data variants only when you specifically need to write a whole rowset at once.

Example — log a click/preference to a DE from a CloudPage:

UpsertDE("Preferences", 1,
   "SubscriberKey", @sk,
   "Newsletter", @newsletterPref,
   "UpdatedDate", Now())

🔍 Line by line: - UpsertDE("Preferences", 1, ...) — UpsertDE updates a row if it exists, or inserts it if it doesn't. Arg 1 is the target DE (Preferences). - 1 — arg 2 is numKeys: it says "the next 1 name/value pair is the matching key." This is the single most error-prone argument — it must equal the number of primary-key columns on the DE. - "SubscriberKey", @sk — the first name/value pair. Because numKeys = 1, this pair is the key SFMC matches on: it looks for an existing row where SubscriberKey = @sk. - "Newsletter", @newsletterPref — a non-key pair: the Newsletter column gets set to @newsletterPref. (It's the 2nd pair, which is past numKeys, so it's data, not a match key.) - "UpdatedDate", Now() — another data pair: stamps the UpdatedDate column with Now(), the current system time. () closes the function call.)

• numKeys = how many of the following name/value pairs are the matching keys (must align with the DE's actual primary keys).

🔑 Write-back idempotency, ordering, and the non-transactional render

In a normal email send, write-backs execute per subscriber AT RENDER. Three senior consequences:

1. Wrong numKeys corrupts data silently. If numKeys doesn't match the DE's real PK set, UpsertDE either duplicates rows (too few keys matched) or overwrites the wrong rows (keys misaligned). No error — just bad data. Always confirm numKeys against the DE's primary keys.
2. Writes fire on VAWP / preview / FTAF too unless you guard them with _messagecontext. Every "view as web page" or test-preview re-runs the AMPscript and re-runs your UpsertDE, polluting the DE with phantom writes (and skewing any "last interaction" timestamp). Guard write-backs with a context check.
3. The render is NOT transactional — there is no rollback. If a InsertDE succeeds and a later line in the same render errors, the inserted row is not undone (unless you control retention via RaiseError's boolPreserveDataExt). You can end up with half-written state.

%%[
  IF _messagecontext == "VAWP" OR _messagecontext == "PREVIEW" OR _messagecontext == "FTAF" THEN
     /* skip write-backs and external calls on web-page views, previews, forwards */
  ELSE
     UpsertDE("Preferences", 1, "SubscriberKey", @sk, "LastSeen", Now())
  ENDIF
]%%

🔍 Line by line: - %%[ — opens the logic block. - IF _messagecontext == "VAWP" OR _messagecontext == "PREVIEW" OR _messagecontext == "FTAF" THEN — _messagecontext is a system variable holding the current render context. This tests whether we're in View-As-Web-Page, a preview, or a forward-to-a-friend. OR chains the three checks (|| would work too). - /* skip write-backs... */ — the "true" branch is intentionally empty (just a comment): in these contexts we do nothing, so no phantom data is written. - ELSE — the normal-send branch. - UpsertDE("Preferences", 1, "SubscriberKey", @sk, "LastSeen", Now()) — only on a real SEND do we write: match on SubscriberKey (numKeys = 1) and stamp LastSeen with Now(). This prevents every "view as web page" from polluting the DE with re-fired writes. - ENDIF — closes the conditional. - ]%% — closes the logic block.

🔑 The senior "why": prefer doing writes in CloudPages or Automation precisely because the email render is non-transactional and fires on every open-as-web-page. Keep the email render read-mostly; push state changes to a context you control. This is the production-grade answer, and it ties straight to the VAWP escalation work — phantom write-backs on VAWP are a real, hard-to-spot data-quality incident.

---

6. Content functions 🔑 (your modular architecture)

%%=ContentBlockByKey("global-footer-en")=%%

🔍 Line by line: - %%= ... =%% — inline output wrapper; whatever the function returns is injected into the rendered HTML right here. - ContentBlockByKey("global-footer-en") — fetches a Content Builder block by its Customer Key (global-footer-en) and renders it inline. Using the Customer Key (rather than ID or path) is the portable choice — it survives BU migrations and folder moves. This is exactly how a single canonical footer/legal block gets reused across every email.

Your "modular headers/footers/legal blocks" = ContentBlock functions. Interview line: "I keep one canonical block per component and inject it with ContentBlockByKey, so a legal update happens once and propagates to every email — that's the 30% build-time and defect reduction."

ContentBlock portability & failure modes 🔑

• ContentBlockById breaks on BU migration (IDs are per-instance). ContentBlockByName breaks on folder moves/renames (the path is the identity). ContentBlockByKey is the portable choice — but the key must actually be deployed to the BU, or it errors at render.
• A missing block can blank or error a whole send. For business-critical injections (legal, footer), wrap defensively and supply a fallback. The functions accept optional parameters — an impression-region name and a boolean controlling whether a missing block throws vs returns empty / default content — so you can fail soft.
• Circular-reference risk: a block that injects itself (directly or via a chain) loops at render. Keep the dependency graph shallow.

/* Fail soft: if the legal block key isn't deployed, fall back instead of breaking the send */
SET @legal = ContentBlockByKey("legal-en", @null, "legal-block", false)
%%=IIF(EMPTY(@legal), ContentBlockByKey("legal-default"), @legal)=%%

🔍 Line by line: - /* Fail soft: ... */ — comment describing the defensive intent. - SET @legal = ContentBlockByKey("legal-en", @null, "legal-block", false) — fetches the block into a variable (instead of outputting it immediately) so we can inspect it first. The extra args are the optional ones: @null is an unset variable used as a placeholder for the unused parameter, "legal-block" is the impression-region name (for tracking), and the trailing false tells the function not to throw if the block is missing — it returns empty instead. Capturing into @legal is the key move that makes "fail soft" possible. - %%=IIF(EMPTY(@legal), ContentBlockByKey("legal-default"), @legal)=%% — outputs the result. IIF checks whether @legal came back empty (block not deployed): if so, it injects a legal-default fallback block; otherwise it outputs the real legal copy. Net effect: the send never breaks just because one key wasn't deployed to the BU.

TreatAsContent vs TreatAsContentArea 🔑 (+ a real security caution)

• TreatAsContent(@str) re-invokes the AMPscript parser on a string so any embedded AMPscript/HTML actually executes — used when you Lookup dynamic copy stored in a DE. Not cached.
• TreatAsContentArea(key, @str) does the same but caches by key within the render. Cache-key collision risk: if you reuse the same key for different content in one render, you'll get the cached first value back for the second call — a subtle, maddening bug. Make keys unique per logical content.

/* Build a UNIQUE cache key with Concat (NOT &) and only run TRUSTED, internally-authored content: */
%%=TreatAsContentArea(Concat("promo-copy-", @promoId), @storedAmpscriptString)=%%

🔍 Line by line: - /* Build a UNIQUE cache key... */ — comment flagging the two rules: build the key with Concat, and only feed trusted content. - %%= ... =%% — inline output; the rendered result is injected here. - TreatAsContentArea(key, @storedAmpscriptString) — re-runs the AMPscript interpreter on the string in @storedAmpscriptString so any AMPscript/HTML stored inside it actually executes (used for dynamic copy pulled from a DE). Unlike TreatAsContent, it caches the result keyed by the first argument within this render. - Concat("promo-copy-", @promoId) — builds the cache key dynamically, e.g. "promo-copy-42". Making the key unique per @promoId avoids the cache-collision bug where reusing a key returns the first value for every later call. Concat is required because there is no &/+ string operator.

🔑 Performance + security "why": TreatAsContent* runs a second pass of the interpreter on the string, so large/deeply-nested dynamic copy is a real performance cost. More importantly, it executes arbitrary AMPscript — never run it on untrusted / user-supplied input (a RequestParameter, a form value, anything attacker-controllable). Doing so is an AMPscript-injection / RCE-style vulnerability: an attacker could inject Lookup/HTTPGet/UpsertDE calls that run with your render's privileges. Only ever TreatAsContent content you authored and stored internally.

---

7. String functions

Concat, Substring, Length, IndexOf, Replace, ReplaceList, Trim, Uppercase, Lowercase, ProperCase, Char, Format, StringToHex, RegExMatch.

SET @clean = Trim(ProperCase(@name))
SET @area  = Substring(@phone, 1, 3)
SET @first = RegExMatch(@full, "(\\w+)", 1)   /* first word */

🔍 Line by line: - SET @clean = Trim(ProperCase(@name)) — functions nest inside-out. ProperCase(@name) capitalizes the first letter of each word (e.g., "akash panda" → "Akash Panda"), and Trim() then strips leading/trailing whitespace. Result is stored in @clean. - SET @area = Substring(@phone, 1, 3) — Substring(string, startPos, length) extracts characters. Starting at position 1 (AMPscript strings are 1-indexed, not 0) for a length of 3 pulls the 3-digit area code out of @phone. - SET @first = RegExMatch(@full, "(\\w+)", 1) — RegExMatch(input, pattern, groupNumber) runs a .NET-style regex and returns a captured group. The pattern (\w+) captures one or more word characters (the doubled backslash \\w is how you escape \w in an AMPscript string literal), and 1 asks for the first capture group — here, the first word. The trailing /* first word */ is a clarifying comment.

⚠️ Regex limitations (senior nuance): AMPscript's regex engine is .NET-based but limited/quirky — RegExMatch extracts a captured group, but there is no native regex replace historically (Replace is a literal find/replace; ReplaceList replaces a literal list of substrings with one value — also literal, not regex). For regex-based replacement you generally drop to SSJS (String.prototype.replace with a JS RegExp). Don't promise regex substitution in pure AMPscript.

8. Math functions

Add, Subtract, Multiply, Divide, Mod, Random, FormatNumber, FormatCurrency.

SET @total = FormatCurrency(Multiply(@price, @qty), "en-US", 2, "$")
SET @bucket = Mod(@id, 2)   /* A/B split */

🔍 Line by line: - SET @total = FormatCurrency(Multiply(@price, @qty), "en-US", 2, "$") — again read inside-out. Multiply(@price, @qty) multiplies (AMPscript has no * operator, so you must use Multiply). FormatCurrency(number, culture, decimals, symbol) then formats the product: "en-US" sets US number conventions, 2 keeps two decimal places, and "$" is the currency symbol — yielding e.g. "$59.98". - SET @bucket = Mod(@id, 2) — Mod(a, b) returns the remainder of a / b. With divisor 2, even @ids give 0 and odd give 1, which is a clean way to split subscribers into two groups (bucket A vs B) for A/B testing. The comment notes that intent.

9. Date functions 🔑 (countdown timers!)

Now(), DateAdd, DateDiff, DatePart, Format, SystemDateToLocalDate, LocalDateToSystemDate.

SET @now     = Now()
SET @end     = DateParse("2026-06-30 23:59:59")
SET @daysLeft= DateDiff(@now, @end, "D")
SET @pretty  = Format(@end, "MMMM d, yyyy")

🔍 Line by line: - SET @now = Now() — Now() returns the current system date/time. Remember the trap: SFMC system time is Central Standard (UTC−6), no daylight saving, year-round. - SET @end = DateParse("2026-06-30 23:59:59") — DateParse converts a date string into a real date value you can do math on. Strings can't be subtracted directly; this is how you get a comparable date object. - SET @daysLeft = DateDiff(@now, @end, "D") — DateDiff(startDate, endDate, interval) returns the whole-number difference between two dates. The interval flag "D" = days (others: "H" hours, "M" months, "Y" years). This drives a "days left" countdown. - SET @pretty = Format(@end, "MMMM d, yyyy") — Format(value, formatString) renders a date into a display string. The pattern MMMM d, yyyy produces e.g. "June 30, 2026" (MMMM = full month name, d = day, yyyy = 4-digit year).

DateDiff(start, end, "D"|"H"|"M"|"Y").

🔑 System time is Central STANDARD Time, year-round — the timezone trap

Now() returns Central Standard Time (UTC−6) with NO daylight saving observed, all year. It is therefore never CDT — during summer months SFMC system time is one hour behind actual US Central wall-clock time. This is a well-known interview trap and a direct source of off-by-one-hour bugs in countdown timers and "expires at midnight" logic.

• SystemDateToLocalDate(@dt) converts system time to the account / business-unit timezone (and LocalDateToSystemDate reverses it). Important: it only converts to the account timezone — not the subscriber's regional timezone.
• For genuine per-subscriber local times, store the subscriber's UTC offset (or IANA timezone) on the DE and DateAdd it yourself:

SET @nowSys   = Now()                                   /* CST, UTC-6, no DST */
SET @offsetHrs= Field(@row, "UtcOffsetHours")           /* e.g., -5 for US Eastern */
/* Convert system time to true UTC first (+6), then to the subscriber's offset: */
SET @nowUtc   = DateAdd(@nowSys, 6, "H")
SET @nowLocal = DateAdd(@nowUtc, @offsetHrs, "H")

🔍 Line by line: - SET @nowSys = Now() — captures the SFMC system clock, which is fixed CST (UTC−6) with no DST. The comment is a reminder of that. - SET @offsetHrs = Field(@row, "UtcOffsetHours") — reads a per-subscriber UTC offset that you stored on the DE (e.g., -5 for US Eastern). This is the only reliable way to know the subscriber's timezone, since SystemDateToLocalDate only knows the account timezone. - /* Convert system time to true UTC first (+6)... */ — comment outlining the two-step conversion. - SET @nowUtc = DateAdd(@nowSys, 6, "H") — DateAdd(date, amount, interval) shifts a date. Adding 6 hours converts CST (UTC−6) up to true UTC. "H" is the hours interval. - SET @nowLocal = DateAdd(@nowUtc, @offsetHrs, "H") — applies the subscriber's stored offset to UTC, landing on the subscriber's actual local time. (Adding a negative offset like -5 shifts backward.)

Tie-in to your open-time countdown timer work: compute @end in CST (system time) and DateDiff against Now() for a correct countdown; if you need the displayed deadline in the subscriber's local time, you must apply the stored offset yourself — SystemDateToLocalDate alone only gets you the account timezone.

10. Utility / logic functions

IIF(cond, trueVal, falseVal), Empty(x), IsNull(x), IsEmailAddress(x), IsPhoneNumber(x), IsNullDefault, AttributeValue, V, Output, OutputLine, Concat.

SET @name = IIF(EMPTY(@first), "Valued Customer", @first)

🔍 Line by line: - SET @name = IIF(EMPTY(@first), "Valued Customer", @first) — IIF(condition, valueIfTrue, valueIfFalse) is a one-line conditional that returns a value (unlike IF...ENDIF, which controls flow). Here EMPTY(@first) checks whether the first name is null or blank; if so it returns "Valued Customer", otherwise it returns the real @first. The chosen value is assigned to @name. This is the compact way to apply a default.

• Output() / OutputLine() — output inside a script block without leaving it. OutputLine(Concat("Hi ", @name)).
• v() — output a variable inline.

🔑 Empty() vs IsNull() vs IsNullDefault() — pick the right guard

These are not interchangeable; choosing the wrong one is a quiet senior tell:

• Empty(x) → true for both null AND empty string "". The everyday "is there anything here?" guard.
• IsNull(x) → true only for an actual null — e.g., a DE field that has never been set is null, but a field explicitly set to "" is not null. Use this when the distinction between "never populated" and "populated with blank" matters.
• IsNullDefault(x, default) → returns x unless it's null, in which case it returns default (a concise null-coalesce).
• Also distinguish the no-data signals by source: RowCount(@rows) == 0 (lookup returned no rows) is not the same as Field(@row, "Col") returning "" (row exists, column blank), which is not the same as Lookup returning "" (no match OR matched a blank). Guard the source you actually have.

11. Encryption / encoding / HTTP functions (advanced) 🔑

• Encoding: Base64Encode, Base64Decode, MD5, SHA1, SHA256, GUID().
• Symmetric encryption: EncryptSymmetric / DecryptSymmetric (for tokenizing IDs in URLs — e.g., secure preference-center links).
• HTTP: HTTPGet, HTTPPost, HTTPPost2, HTTPRequestHeader — call external APIs at render time (e.g., real-time inventory, MovableInk-style content). Use cautiously: render-time latency.

⚠️ Portability flag (Marketing Cloud Next): the HTTP/API, encryption/security, and SMS function families in this section are NOT supported in Marketing Cloud Next (see §17). If LTM is on or moving to MC Next, these won't carry forward — design real-time content to precompute into a DE upstream rather than call APIs at render.

HTTPGet — correct syntax (note: Concat, NOT &) 🔑

HTTPGet(url, boolContinueOnError, intEmptyContentHandling, statusOutput)

SET @status = 0
/* Concat() builds the URL — AMPscript has NO `&` string operator (see §2 operators). */
SET @resp = HTTPGet(Concat("https://api.example.com/price?sku=", @sku), true, 0, @status)

IF @status == 0 THEN
   /* success — use @resp */
ELSEIF @status == -1 THEN
   /* URL not found (404) — degrade gracefully */
ELSEIF @status == -2 THEN
   /* HTTP request error (server did not return 2xx) */
ELSEIF @status == -3 THEN
   /* success but EMPTY content returned */
ENDIF

🔍 Line by line: - SET @status = 0 — pre-initializes the status variable. HTTPGet writes the result code into this variable by reference, so it must exist before the call. - /* Concat() builds the URL... */ — comment reminding you there's no & operator for joining strings. - SET @resp = HTTPGet(Concat("https://api.example.com/price?sku=", @sku), true, 0, @status) — makes the HTTP GET. Arg 1 is the URL, assembled with Concat (base URL + the SKU). Arg 2 true is boolContinueOnError — keep rendering even if the call fails. Arg 3 0 is intEmptyContentHandling — permit empty content. Arg 4 @status is the by-reference status output. The response body lands in @resp. - IF @status == 0 THEN — status 0 means success; use @resp here. - ELSEIF @status == -1 THEN — status -1 means the URL was not found (404); degrade gracefully. - ELSEIF @status == -2 THEN — status -2 means an HTTP error (the server didn't return a 2xx). - ELSEIF @status == -3 THEN — status -3 means the call succeeded but returned empty content. - ENDIF — closes the status-handling conditional.

• statusOutput is a by-reference output variable. Values: 0 = success, -1 = URL not found (404), -2 = HTTP error (non-2xx), -3 = succeeded but empty content.
• boolContinueOnError — true to ignore errors and keep rendering (recommended for graceful degradation).
• intEmptyContentHandling — 0 permits empty content, 1 returns an error, 2 skips sending the email.

🔑 HTTPGet caching & operational behavior — the senior differentiator

The latency warning is only half the story. The facts that separate someone who's run this in production:

• SFMC makes ONE call per UNIQUE URL per send and caches the response, reusing it for every subscriber that hits the same URL. So a personalized query string (?sku=@sku) makes every URL unique → defeats the cache → fires thousands of synchronous external calls at render, adding latency and risking send timeouts/failures.
• Only ports 80 (HTTP) and 443 (HTTPS) are allowed.
• Basic-auth-in-URL is unsupported (e.g., https://user:pass@host won't work — pass auth via headers/token instead).
• Empty/missing content is signaled by the -3 status and the intEmptyContentHandling flag above.

🔑 The senior answer to "real-time content": do not call HTTPGet per subscriber. Precompute the data into a DE via an API-calling Automation / Server-Side Script Activity BEFORE the send, then read it with Lookup at render. That keeps the render fast and resilient. This is exactly the pattern behind real-time-ish retail content (e.g., StyleCash balances / pricing) — fetch once into a DE, personalize from the DE.

Modern JSON handling — BuildRowsetFromJSON / BuildRowsetFromString

You can iterate a JSON API response in pure AMPscript (no SSJS) with BuildRowsetFromJSON (added Summer '23):

BuildRowsetFromJSON(jsonString, jsonPathExpression, boolReturnEmptyOnError)

SET @s    = 0
SET @json = HTTPGet(@apiUrl, true, 0, @s)
/* JSONPath selects the array; supports dot or bracket notation. No filter expressions. */
SET @rs   = BuildRowsetFromJSON(@json, "$.products[*]", 1)
SET @n    = RowCount(@rs)
FOR @i = 1 TO @n DO
   SET @r    = Row(@rs, @i)
   SET @name = Field(@r, "name")
   SET @price= Field(@r, "price")
   /* ...render... */
NEXT @i

🔍 Line by line: - SET @s = 0 — initializes the status variable for the upcoming HTTPGet (set by reference). - SET @json = HTTPGet(@apiUrl, true, 0, @s) — calls the API and stores the raw JSON response string in @json (true = continue on error, 0 = allow empty content, @s = status out). - /* JSONPath selects the array... */ — comment explaining the path expression. - SET @rs = BuildRowsetFromJSON(@json, "$.products[*]", 1) — BuildRowsetFromJSON(jsonString, jsonPath, boolReturnEmptyOnError) parses the JSON and turns a selected array into a rowset you can loop. The JSONPath $.products[*] means "every element of the top-level products array." The trailing 1 (true) tells it to return an empty rowset instead of erroring if parsing fails. - SET @n = RowCount(@rs) — counts the rows produced from the JSON array. - FOR @i = 1 TO @n DO — iterates once per JSON element (1-indexed). - SET @r = Row(@rs, @i) — grabs the nth element as a row object. - SET @name = Field(@r, "name") — reads the name property of that JSON object (JSON keys become column names). - SET @price= Field(@r, "price") — reads the price property. - /* ...render... */ — placeholder where you'd emit HTML for each product. - NEXT @i — advances to the next JSON element. The takeaway: the same Row/Field/RowCount loop you use on DE lookups works unchanged on a JSON-built rowset.

• The same Row / Field / RowCount loop you already know works on the JSON-built rowset.

• BuildRowsetFromString("12345,33333,99999") turns a delimited string into a rowset you can FOR-loop — handy for fan-out from a single CSV-style field.

• CloudPages helpers: RedirectTo, CloudPagesURL, MicrositeURL, RequestParameter.

SET @url = CloudPagesURL(1234, "sk", @sk, "cid", @cid)  /* signed, param-passing link */

🔍 Line by line: - SET @url = CloudPagesURL(...) — builds a signed, tamper-evident link to a CloudPage and stores it in @url (you'd then drop it into an href). - 1234 — arg 1: the numeric page ID of the target CloudPage. - "sk", @sk — the first name/value pair passed to the page: a parameter literally named sk carrying the subscriber key value. On the page you'd read it with RequestParameter("sk"). - "cid", @cid — a second name/value pair: a cid parameter carrying the customer ID. You can pass as many pairs as you need. Because the URL is signed, tampering with these values invalidates the link — far safer than hand-building the query string. (Tip: still tokenize the subscriber key with EncryptSymmetric rather than passing it raw.)

---

12. Sendable vs non-sendable context 🔑

• In a send to a sendable DE, AttributeValue("Col") and %%Col%% resolve from the sendable DE row + Subscriber attributes.
• In a CloudPage or VAWP, there's no send context, so you must supply identity via URL params and Lookup the data yourself.
• AttributeValue vs direct %%Field%%: AttributeValue() is safer in code (returns empty if missing rather than erroring) and works dynamically with computed names (see §3 for the full three-way comparison).

🔑 Where does a %%Field%% value actually come from? (resolution order)

A senior should be able to explain precedence when names collide. For a %%Field%% / AttributeValue("Field") reference during a send, SFMC resolves against, in effect:

1. The send's data source row — for a sendable DE send, the matching row of the sendable DE; for a list send, the subscriber's list/profile attributes.
2. Subscriber attributes / profile attributes defined at the account level (and the All Subscribers record), keyed by Subscriber Key.
3. AMPscript variables are a separate namespace — %%Field%% does not read @variables; use v(@x) for those.

Sendable-DE send vs list send — the key difference: a sendable DE send personalizes primarily from the DE columns of the row being sent (the DE's send relationship maps a column to Subscriber Key); a list send personalizes from the subscriber's stored profile/attribute values. When a DE column and a profile attribute share a name, the send data source row wins in that send context. The practical senior point: if a value "isn't showing up," confirm which context you're in and which source actually holds the column — don't assume the DE row when you're really in a list send (or vice versa).

---

12A. Error-handling philosophy 🔑 (production escalation mindset)

A senior — especially a production/VAWP escalation owner — must articulate error handling beyond "add a null check."

• AMPscript has NO try/catch. This is the single biggest structural limitation. There is no way to catch and recover from a runtime exception in pure AMPscript — which is a primary reason to drop to SSJS (which does have try/catch) for anything fallible (API calls you must recover from, JSON parsing, bulk DE ops).
• A runtime error blanks or halts the render. An unhandled error in a send context can blank the affected region or fail that subscriber; in some contexts it surfaces as an Error 500. So defensive coding isn't optional — there's no safety net.
• RaiseError gives you job-level vs subscriber-level control (see §3): boolSkipCurrentOnly=true skips just the bad subscriber and continues the send; false aborts the whole job. Use it deliberately — for a required-token check you usually want skip-current, not abort-all.
• Defensive patterns to name in the interview:
• Field(@row, "Col", 0) to suppress missing-column errors and return "" (env drift).
• Layered guards: IF RowCount(@rows) > 0 THEN ... IF NOT EMPTY(Field(@row,"X")) THEN ....
• Default fallbacks via IIF / IsNullDefault, and fallback ContentBlocks for empty data.
• Context guards so writes/external calls don't fire on VAWP/PREVIEW/FTAF.

Interview line: "AMPscript has no try/catch, the render isn't transactional, and an unhandled error can blank the email — so I code defensively (guard every lookup and field), use RaiseError with boolSkipCurrentOnly to isolate a bad subscriber instead of failing the whole send, and push anything genuinely fallible into SSJS where I get real exception handling."

---

12B. AMPscript vs SSJS — the decision framework 🔑 (senior signal)

You'll be asked "when do you reach for SSJS over AMPscript?" Have a crisp framework:

Use AMPscript (default) when: - Straightforward personalization, conditional content, and lookups at render — it's faster to write, more readable for marketers, and the platform's first-class path. - The LookupRows → Row/Field loop covers it. - You want content that other team members can maintain.

Reach for SSJS when: - You need try/catch error handling (AMPscript has none). - JSON parsing/manipulation beyond what BuildRowsetFromJSON covers — building objects, nested traversal, transforming payloads. - Bulk DE operations via WSProxy (Retrieve with paging past the 2,000-row cap, Create/Update/Delete rowsets, cross-folder operations) — your unified DE Lookup tool lives here. - Complex loops, recursion, or data structures (arrays, maps) — e.g., recursive folder-path resolution. - You need Platform.Function.*, Core.*, or WSProxy objects not exposed to AMPscript. - You want reusable functions (define once, call many times) — AMPscript can't define functions.

Tradeoffs: SSJS is more powerful but slower to interpret and harder to read; over-using it hurts maintainability. The senior move is to do the bulk/complex work in SSJS, then hand simple values back to AMPscript for the actual render markup.

---

12C. AMPscript ↔ SSJS interop in one asset 🔑

You frequently mix both in a single email/CloudPage. The bridge is the shared variable namespace via Variable.SetValue / Variable.GetValue, and the %%=v(@x)=%% output.

• Blocks execute top-to-bottom in document order — an AMPscript SET before an SSJS block is readable by that block, and vice versa.
• In SSJS, Variable.GetValue("@x") reads an AMPscript variable and Variable.SetValue("@x", val) writes one back. The @ prefix is required.

%%[ SET @sk = _subscriberkey ]%%
<script runat="server" language="ssjs">
   Platform.Load("Core", "1.1.1");
   var sk = Variable.GetValue("@sk");      // read AMPscript var
   // ...do WSProxy / try-catch / JSON work...
   var out = "computed-result";
   Variable.SetValue("@result", out);       // write back to AMPscript
</script>
%%=v(@result)=%%                              {/* read it in AMPscript */}

🔍 Line by line: - %%[ SET @sk = _subscriberkey ]%% — an AMPscript block that reads the system variable _subscriberkey into @sk. Because blocks run top-to-bottom, this must come before the SSJS block that reads it. - <script runat="server" language="ssjs"> — opens a server-side JavaScript block. runat="server" means it executes at render (not in the browser); language="ssjs" selects SSJS, the standard wrapper for JavaScript in SFMC. - Platform.Load("Core", "1.1.1"); — loads the SSJS Core library so Variable, WSProxy, etc. are available. Required boilerplate at the top of most SSJS blocks. - var sk = Variable.GetValue("@sk"); — Variable.GetValue("@sk") reads the AMPscript variable into a JS variable. The @ prefix is mandatory — it's how SSJS addresses the shared AMPscript namespace. (// starts a JS comment.) - // ...do WSProxy / try-catch / JSON work... — placeholder for the heavy lifting SSJS is good at (paging past the 2,000-row cap, try/catch, JSON). - var out = "computed-result"; — a normal JS variable holding whatever you computed. - Variable.SetValue("@result", out); — Variable.SetValue("@result", out) writes the JS value back into an AMPscript variable named @result, so AMPscript can render it. - </script> — closes the SSJS block. - %%=v(@result)=%% — back in AMPscript, inline-outputs @result (the value SSJS just set). The {/* ... */} after it is an inline comment.

This interop is exactly what your WSProxy DE Lookup work depends on: AMPscript hands the subscriber/context in, SSJS does the heavy WSProxy retrieval with paging and error handling, then sets values back for AMPscript to render. Mention the execution order explicitly — set before you read.

---

12D. Security — concrete vectors and mitigations 🔑

"Sanitize inputs" is too vague for a senior. Name the actual vectors:

1. AMPscript injection via TreatAsContent on untrusted data (RCE-style). If you TreatAsContent a RequestParameter or any attacker-controllable string, the attacker's AMPscript executes with your render's privileges — they can call Lookup, HTTPGet, even UpsertDE. Mitigation: never TreatAsContent* user-supplied input; only run it on internally-authored, trusted DE content.
2. DE-write injection / data poisoning. Untrusted RequestParameter values written straight into a DE can corrupt data or be replayed later in a TreatAsContent context. Mitigation: validate/whitelist RequestParameter values (expected set, type, length) before any DE write; reject anything off the whitelist.
3. Identity exposure in URLs. Passing a raw SubscriberKey in a link lets anyone enumerate/guess other subscribers. Mitigation: tokenize with EncryptSymmetric or a per-record GUID stored on the DE, decrypt/look up on the CloudPage — never put the raw key in a query string.
4. CloudPage parameter trust. Treat every RequestParameter/QueryParameter as hostile: validate before use, and prefer CloudPagesURL signed links (tamper-evident) over hand-built URLs.

Interview line: "The scariest AMPscript footgun is TreatAsContent on attacker-controlled input — that's effectively remote code execution inside the render. I whitelist every RequestParameter, tokenize SubscriberKey with EncryptSymmetric or a GUID instead of exposing it, and only ever TreatAsContent trusted, internally-authored content."

---

12E. Triggered send / transactional context 🔑

Relevant for anyone who owned production escalations:

• In a triggered send (TSD), AMPscript executes per message as each entry event fires — not in a batch render. The same LookupRows/write-back functions work, but they run one message at a time in real time.
• RaiseError matters even more here: a boolSkipCurrentOnly=true skips just that one triggered message; false can stall/abort the triggered send definition. For transactional/order-confirmation sends you almost always want to skip the one bad message, not halt the stream.
• Attribute resolution: values resolve from the triggered send's data extension / the entry-event payload you passed in (e.g., via the transactional API or interaction), then subscriber attributes — so confirm whether a field is coming from the event payload vs the TSD's sendable DE. A missing field there is a common "why is the order total blank?" incident.
• External calls at render (HTTPGet) in a TSD multiply by message volume and add per-message latency to a real-time send — even more reason to precompute.

---

12F. Performance model — how AMPscript actually executes 🔑

State the mental model; it underpins every optimization:

• AMPscript is interpreted top-to-bottom, per render. There is no compilation and no caching of variables across subscribers. The only render-level caches are HTTPGet's one-call-per-unique-URL cache and content-area caching (TreatAsContentArea by key).
• Therefore the dominant cost is data-layer round trips (Lookups) and external calls (HTTPGet) — not arithmetic or string ops.
• Consequences:
• One LookupRows beats N Lookups. Fetch the rowset once, iterate in memory with Row/Field — don't put a Lookup inside a FOR loop (the anti-pattern).
• "Select only needed columns" isn't really possible — Lookup*Rows returns the whole row. So model wide rowsets carefully: keep render-time DEs narrow, and split rarely-needed columns into a separate DE.
• Index the match column (PK/indexed) so each lookup is a seek, not a scan.
• Move computation upstream to SQL Query Activities / Automation — pre-aggregate, pre-join, precompute API data into a DE before send. The render should mostly read.

This is the engine behind your render-time-reduction numbers: collapse N per-row Lookups into one LookupRows + in-memory iteration, index the match columns, and pre-aggregate anything heavy in SQL upstream.

/* ANTI-PATTERN: a Lookup per iteration = N queries at render */
FOR @i = 1 TO @cnt DO
   SET @region = Lookup("Store_Master", "Region", "StoreID", Field(Row(@orders,@i), "StoreID"))
NEXT @i

/* BETTER: one LookupRows, then in-memory Row/Field — and make StoreID the indexed/PK column */
SET @stores = LookupRows("Store_Master", "Active", "1")
/* ...build an in-memory association or aggregate upstream in SQL... */

🔍 Line by line: - /* ANTI-PATTERN: a Lookup per iteration = N queries at render */ — comment labeling the bad pattern. - FOR @i = 1 TO @cnt DO — loops @cnt times. - SET @region = Lookup("Store_Master", "Region", "StoreID", Field(Row(@orders,@i), "StoreID")) — the problem line: it runs a fresh Lookup inside the loop. Field(Row(@orders,@i), "StoreID") pulls the StoreID from the current order row and feeds it as the match value. Doing this N times means N separate data-layer queries at render — the dominant cost in AMPscript. - NEXT @i — next iteration (and another query). - /* BETTER: one LookupRows... */ — comment introducing the fix. - SET @stores = LookupRows("Store_Master", "Active", "1") — fetches all relevant store rows once into memory with a single query, then you iterate that rowset with Row/Field instead of querying per loop. The closing comment notes you'd build an in-memory association or pre-aggregate upstream in SQL. Making StoreID the indexed/PK column keeps each match a fast seek.

---

13. AMPscript best practices 🔑 (say these in the interview)

1. Always null-check before using a value (EMPTY, IIF, IsNull) — prevents broken renders + VAWP blanks. Remember there's no try/catch in AMPscript, so guards are your only safety net.
2. Declare variables with VAR at the top for readability/maintainability.
3. Minimize Lookups per render — each Lookup is a query; prefer one LookupRows over many Lookups and iterate in memory. Never put a Lookup inside a FOR loop.
4. Index the match column (PK/indexed) on lookup DEs, and keep render-time DEs narrow — Lookup*Rows returns the whole row.
5. Mind the 2,000-row cap on every Lookup*Rows — pre-aggregate in a SQL Query Activity (or page via SSJS) if a match set can exceed it; verify true counts with DataExtensionRowCount.
6. Use LookupOrderedRows when order matters; never rely on LookupRows order (and Lookup returns an unspecified matching row).
7. Use ContentBlockByKey (portable) over ById (breaks across BUs) / ByName (breaks on folder moves); wrap critical blocks with a fallback.
8. Keep write-backs out of the email render — do them in CloudPages/Automation (the render is non-transactional and fires on every VAWP/preview).
9. Guard write-backs and external calls with _messagecontext (skip VAWP/PREVIEW/FTAF).
10. Wrap stored dynamic copy in TreatAsContent when it contains code — but only trusted, internally-authored content (never user input — RCE risk).
11. Precompute real-time/API data into a DE upstream rather than HTTPGet per subscriber (caching defeats personalized URLs; latency multiplies).
12. Validate/whitelist RequestParameter inputs and tokenize SubscriberKey (EncryptSymmetric/GUID) — never trust user input, never expose raw keys in URLs.
13. Pick the right tool — drop to SSJS for try/catch, JSON, WSProxy bulk ops, recursion, and reusable functions; keep AMPscript for render-time personalization.
14. Comment complex logic; use consistent naming (@deName, @row, @cnt).

---

14. Worked example — full product-recommendation block (interview-ready)

%%[
  VAR @sk, @rows, @cnt, @i, @row, @name, @img, @url, @price
  SET @sk   = _subscriberkey
  /* Get up to 3 recs for this subscriber, highest score first */
  SET @rows = LookupOrderedRows("Product_Recs", 3, "Score DESC", "SubscriberKey", @sk)
  SET @cnt  = RowCount(@rows)

  IF @cnt > 0 THEN
]%%
  <table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0">
    <tr>
  %%[
    FOR @i = 1 TO @cnt DO
      SET @row   = Row(@rows, @i)
      SET @name  = Field(@row, "ProductName")
      SET @img   = Field(@row, "ImageURL")
      SET @url   = Field(@row, "ProductURL")
      SET @price = FormatCurrency(Field(@row, "Price"), "en-US", 2, "$")
  ]%%
      <td width="200" valign="top" style="font-family:Arial;font-size:14px;color:#333;">
        <a href="%%=RedirectTo(@url)=%%"><img src="%%=v(@img)=%%" alt="%%=v(@name)=%%" width="180" style="display:block;border:0;"></a>
        <div>%%=v(@name)=%%</div>
        <div><strong>%%=v(@price)=%%</strong></div>
      </td>
  %%[ NEXT @i ]%%
    </tr>
  </table>
%%[
  ELSE
]%%
  %%=ContentBlockByKey("fallback-bestsellers")=%%
%%[
  ENDIF
]%%

🔍 Line by line: - %%[ — opens the first logic block. - VAR @sk, @rows, @cnt, @i, @row, @name, @img, @url, @price — declares all variables up front (good practice for readability). - SET @sk = _subscriberkey — captures the subscriber key from the system variable, to use as the lookup match. - /* Get up to 3 recs... */ — comment. - SET @rows = LookupOrderedRows("Product_Recs", 3, "Score DESC", "SubscriberKey", @sk) — fetches at most 3 recommendation rows for this subscriber, sorted by Score descending (best first). Using LookupOrderedRows (not LookupRows) is deliberate because order matters. - SET @cnt = RowCount(@rows) — how many recs actually came back (could be 0–3). - IF @cnt > 0 THEN — only render the product table if there's at least one rec. - ]%% — closes the logic block so the table markup can emit. - <table ...> / <tr> — opens an HTML email table (role="presentation" tells screen readers it's layout, not data). - %%[ — re-opens logic to run the loop. - FOR @i = 1 TO @cnt DO — loop once per recommendation. - SET @row = Row(@rows, @i) — grab the current rec row. - SET @name = Field(@row, "ProductName") — read the product name column. - SET @img = Field(@row, "ImageURL") — read the image URL column. - SET @url = Field(@row, "ProductURL") — read the destination URL column. - SET @price = FormatCurrency(Field(@row, "Price"), "en-US", 2, "$") — read the raw price and format it as US currency with 2 decimals and a $ symbol in one step. - ]%% — close logic; emit the cell markup. - <td ...> — opens a product cell. - <a href="%%=RedirectTo(@url)=%%">... — RedirectTo(@url) wraps the destination URL so the click is tracked (it routes through SFMC's link tracker). Inside the link, <img src="%%=v(@img)=%%" alt="%%=v(@name)=%%" ...> outputs the image URL and uses the product name as accessible alt text. - <div>%%=v(@name)=%%</div> — outputs the product name as visible copy. - <div><strong>%%=v(@price)=%%</strong></div> — outputs the formatted price in bold. - </td> — closes the cell. - %%[ NEXT @i ]%% — a compact one-line logic block that advances the loop to the next rec. - </tr> / </table> — close the row and table after the loop. - %%[ then ELSE — opens logic and takes the alternate branch (used when @cnt was 0). - ]%% — close logic to emit the fallback markup. - %%=ContentBlockByKey("fallback-bestsellers")=%% — when the subscriber has no recs, inject a generic "best sellers" Content Builder block by key, so the email is never empty. - %%[ then ENDIF then ]%% — closes the IF @cnt > 0 conditional.

Talking points: ordered by score, null/empty guard with fallback block, single LookupRows (not N Lookups), RedirectTo for click tracking, currency formatting, accessibility alt text.

---

14A. More interview-ready snippets 🌟

1) The 2,000-row cap trap and the senior fix

%%[
  /* This returns AT MOST 2,000 rows even if the customer has 5,000 orders: */
  SET @orders = LookupOrderedRows("Orders", 0, "OrderDate DESC", "CustID", @cid)
  SET @shown  = RowCount(@orders)                 /* <= 2000 */
  SET @true   = DataExtensionRowCount("Orders")   /* the REAL count, e.g. 5000 */

  /* SENIOR FIX: don't read raw orders at render. Pre-aggregate per customer in a
     SQL Query Activity into Orders_Summary (one row/customer), then read one row: */
  SET @summary   = Lookup("Orders_Summary", "LifetimeValue", "CustID", @cid)
  SET @lastOrder = Lookup("Orders_Summary", "LastOrderDate", "CustID", @cid)
]%%

🔍 Line by line: - %%[ — opens the logic block. - /* This returns AT MOST 2,000 rows... */ — comment flagging the cap. - SET @orders = LookupOrderedRows("Orders", 0, "OrderDate DESC", "CustID", @cid) — asks for "all" (0) of this customer's orders, newest first — but silently truncates at 2,000 rows. - SET @shown = RowCount(@orders) — counts what you actually got back (<= 2000). - SET @true = DataExtensionRowCount("Orders") — DataExtensionRowCount reports the DE's real total (e.g., 5,000), which is how you'd notice truncation. - /* SENIOR FIX: ... */ — comment introducing the proper pattern. - SET @summary = Lookup("Orders_Summary", "LifetimeValue", "CustID", @cid) — instead of reading raw orders at render, read one pre-aggregated row per customer from a summary DE (built upstream by a SQL Query Activity). This pulls the customer's lifetime value with a single fast Lookup. - SET @lastOrder = Lookup("Orders_Summary", "LastOrderDate", "CustID", @cid) — a second single-value Lookup for the last-order date from the same summary row. No cap, no loop, minimal render cost. - ]%% — closes the logic block.

2) Correct HTTPGet with full status handling (fixes the & bug)

%%[
  SET @status = 0
  SET @resp = HTTPGet(Concat("https://api.example.com/price?sku=", @sku), true, 0, @status)
  IF @status == 0 THEN
     SET @price = @resp                 /* success */
  ELSEIF @status == -1 THEN
     SET @price = Lookup("Price_Cache", "Price", "SKU", @sku)   /* 404 -> fall back to cache */
  ELSE
     SET @price = "See site for price"  /* -2 HTTP error / -3 empty -> graceful copy */
  ENDIF
]%%

🔍 Line by line: - %%[ — opens the logic block. - SET @status = 0 — pre-creates the by-reference status variable required by HTTPGet. - SET @resp = HTTPGet(Concat("https://api.example.com/price?sku=", @sku), true, 0, @status) — calls the price API. The URL is built with Concat (no & operator exists); true = continue on error, 0 = allow empty content, @status receives the result code. - IF @status == 0 THEN — success path. - SET @price = @resp — on success, use the live response as the price. - ELSEIF @status == -1 THEN — -1 = URL not found (404). - SET @price = Lookup("Price_Cache", "Price", "SKU", @sku) — on a 404, fall back to a cached price stored in a Price_Cache DE (matched by SKU). Graceful degradation rather than a broken email. - ELSE — catches the remaining error codes (-2 HTTP error, -3 empty content). - SET @price = "See site for price" — last-resort copy so the email always shows something sensible. - ENDIF — closes the status conditional. - ]%% — closes the logic block.

3) RaiseError — skip one subscriber vs abort the job

%%[
  IF EMPTY(@requiredToken) THEN
     /* true => skip ONLY this subscriber and continue the send.
        false would abort the WHOLE job. Add boolPreserveDataExt to retain partial writes. */
     RaiseError("Missing token for SubscriberKey", true, "ERR_TOKEN")
  ENDIF
]%%

🔍 Line by line: - %%[ — opens the logic block. - IF EMPTY(@requiredToken) THEN — fires only when the required token is null or blank — i.e., this subscriber can't be rendered safely. - /* true => skip ONLY this subscriber... */ — comment explaining the parameter choice. - RaiseError("Missing token for SubscriberKey", true, "ERR_TOKEN") — the true (2nd arg, boolSkipCurrentOnly) skips only this subscriber and lets the send continue; passing false would abort the whole job. "ERR_TOKEN" is the custom code surfaced in error reporting. (You could add a 5th boolPreserveDataExt arg to control whether earlier DE writes are retained.) - ENDIF — closes the guard. - ]%% — closes the logic block.

4) Context guard so write-backs never fire on VAWP/preview

%%[
  IF _messagecontext == "VAWP" OR _messagecontext == "PREVIEW" OR _messagecontext == "FTAF" THEN
     /* skip write-backs and external calls on web-page views, previews, forwards */
  ELSE
     UpsertDE("Engagement", 1, "SubscriberKey", @sk, "LastOpenRender", Now())
  ENDIF
]%%

🔍 Line by line: - %%[ — opens the logic block. - IF _messagecontext == "VAWP" OR _messagecontext == "PREVIEW" OR _messagecontext == "FTAF" THEN — checks the render context. _messagecontext is the system variable telling you whether this is a View-As-Web-Page, a preview, or a forward-to-a-friend. - /* skip write-backs and external calls... */ — the true branch is intentionally a no-op comment: in these contexts we write nothing. - ELSE — only a real SEND reaches here. - UpsertDE("Engagement", 1, "SubscriberKey", @sk, "LastOpenRender", Now()) — on a genuine send, upsert into Engagement: match on SubscriberKey (numKeys=1) and stamp LastOpenRender with Now(). Guarding this prevents every web-page view from re-firing the write and skewing the timestamp. - ENDIF — closes the conditional. - ]%% — closes the logic block.

5) Iterate a JSON API response in pure AMPscript

%%[
  SET @s    = 0
  SET @json = HTTPGet(@apiUrl, true, 0, @s)
  SET @rs   = BuildRowsetFromJSON(@json, "$.products[*]", 1)
  SET @n    = RowCount(@rs)
  FOR @i = 1 TO @n DO
     SET @r    = Row(@rs, @i)
     SET @name = Field(@r, "name")
     SET @price= Field(@r, "price")
  ]%%
     <li>%%=v(@name)=%% — %%=v(@price)=%%</li>
  %%[ NEXT @i ]%%

🔍 Line by line: - %%[ — opens the logic block. - SET @s = 0 — initializes the by-reference status variable for HTTPGet. - SET @json = HTTPGet(@apiUrl, true, 0, @s) — fetches the JSON payload from @apiUrl (continue-on-error true, allow empty 0, status into @s). - SET @rs = BuildRowsetFromJSON(@json, "$.products[*]", 1) — parses the JSON and turns the products array ($.products[*]) into a rowset; the 1 returns an empty rowset on parse error instead of throwing. - SET @n = RowCount(@rs) — counts the parsed product rows. - FOR @i = 1 TO @n DO — loop once per product (1-indexed). - SET @r = Row(@rs, @i) — grab the current product as a row object. - SET @name = Field(@r, "name") — read the JSON name field (keys become columns). - SET @price= Field(@r, "price") — read the JSON price field. - ]%% — close logic to emit markup. - <li>%%=v(@name)=%% — %%=v(@price)=%%</li> — outputs a list item with the product name and price (the — is a literal em dash between them). - %%[ NEXT @i ]%% — a one-line logic block advancing the loop. (Note: the loop's opening IF/closing isn't shown here, but the FOR/NEXT pairing is complete.)

6) TreatAsContentArea with caching + security caution

%%[ /* Unique key via Concat (NOT &). ONLY trusted, internally-authored content. */ ]%%
%%=TreatAsContentArea(Concat("promo-copy-", @promoId), @storedAmpscriptString)=%%
%%[ /* NEVER: TreatAsContent(RequestParameter("x")) — that's AMPscript injection / RCE. */ ]%%

🔍 Line by line: - %%[ /* Unique key via Concat (NOT &)... */ ]%% — a logic block containing only a comment (produces no output); it documents the two rules. - %%=TreatAsContentArea(Concat("promo-copy-", @promoId), @storedAmpscriptString)=%% — inline-outputs the result of re-parsing @storedAmpscriptString (dynamic copy pulled from a DE). Concat("promo-copy-", @promoId) builds a unique cache key per promo so cached results don't collide. TreatAsContentArea caches by that key within the render; only ever pass trusted, internally-authored strings. - %%[ /* NEVER: TreatAsContent(RequestParameter("x"))... */ ]%% — another comment-only block warning that running TreatAsContent on a RequestParameter (user input) is an AMPscript-injection / RCE vulnerability.

7) AMPscript → SSJS → AMPscript variable bridge

%%[ SET @sk = _subscriberkey ]%%
<script runat="server" language="ssjs">
   Platform.Load("Core", "1.1.1");
   var sk = Variable.GetValue("@sk");        // read AMPscript var
   var out;
   try { /* WSProxy retrieve with paging, etc. */ out = "ok"; }
   catch (e) { out = ""; }                    // try/catch: a reason to use SSJS
   Variable.SetValue("@result", out);         // hand back to AMPscript
</script>
%%=v(@result)=%%

🔍 Line by line: - %%[ SET @sk = _subscriberkey ]%% — AMPscript block that reads the subscriber key into @sk. It runs first, so the SSJS below can read it. - <script runat="server" language="ssjs"> — opens a server-side JavaScript block (executes at render). - Platform.Load("Core", "1.1.1"); — loads the SSJS Core library (gives access to Variable, WSProxy, etc.). - var sk = Variable.GetValue("@sk"); — reads the AMPscript @sk into a JS variable (the @ prefix addresses the shared namespace). - var out; — declares an output variable. - try { /* WSProxy retrieve with paging, etc. */ out = "ok"; } — the try block holds fallible work (API calls, WSProxy paging past the 2,000-row cap, JSON parsing). On success it sets out to a result. - catch (e) { out = ""; } — if anything throws, catch recovers gracefully by setting out to empty. This try/catch is the whole reason to use SSJS — AMPscript has none. - Variable.SetValue("@result", out); — writes the JS out back into AMPscript variable @result. - </script> — closes the SSJS block. - %%=v(@result)=%% — back in AMPscript, inline-outputs the handed-back value.

8) Defensive Field() on a possibly-missing column (env drift)

%%[
  SET @loyalty = Field(@row, "LoyaltyTier", 0)   /* 0 => '' instead of error if absent */
  SET @tier    = IIF(EMPTY(@loyalty), "Standard", @loyalty)
]%%

🔍 Line by line: - %%[ — opens the logic block. - SET @loyalty = Field(@row, "LoyaltyTier", 0) — reads the LoyaltyTier column from @row. The 0 (third arg, boolException=false) suppresses the default missing-column error and returns "" instead — important when the column may not exist in every environment (dev vs prod drift). - SET @tier = IIF(EMPTY(@loyalty), "Standard", @loyalty) — IIF supplies a default: if @loyalty is empty, use "Standard"; otherwise use the real value. - ]%% — closes the logic block.

9) Lookup-in-a-loop anti-pattern vs single LookupRows

%%[
  /* ANTI-PATTERN: N queries at render */
  FOR @i = 1 TO @cnt DO
     SET @region = Lookup("Store_Master", "Region", "StoreID", @sid)   /* StoreID should be PK/indexed */
  NEXT @i

  /* BETTER: one LookupRows, iterate in memory */
  SET @stores = LookupRows("Store_Master", "Active", "1")
]%%

🔍 Line by line: - %%[ — opens the logic block. - /* ANTI-PATTERN: N queries at render */ — comment labeling the slow approach. - FOR @i = 1 TO @cnt DO — loops @cnt times. - SET @region = Lookup("Store_Master", "Region", "StoreID", @sid) — runs a Lookup inside the loop, so it hits the data layer once per iteration (N queries). The inline comment notes StoreID should be a PK/indexed column so each query is at least a fast seek. - NEXT @i — next iteration (another query). - /* BETTER: one LookupRows, iterate in memory */ — comment introducing the fix. - SET @stores = LookupRows("Store_Master", "Active", "1") — one query pulls all active stores into a rowset; you then iterate it in memory with Row/Field instead of re-querying. Collapsing N Lookups into one LookupRows is the core render-time optimization. - ]%% — closes the logic block.

10) Subscriber-timezone countdown done correctly

%%[
  /* System time is CST (UTC-6, no DST). Compute the countdown in system time. */
  SET @nowSys   = Now()
  SET @endSys   = DateParse("2026-06-30 23:59:59")      /* stored in CST */
  SET @hoursLeft= DateDiff(@nowSys, @endSys, "H")

  /* For the SUBSCRIBER'S local deadline, SystemDateToLocalDate only gives the ACCOUNT tz.
     Use a stored per-subscriber UTC offset instead: */
  SET @offsetHrs= Field(@row, "UtcOffsetHours")          /* e.g., -5 US Eastern */
  SET @endUtc   = DateAdd(@endSys, 6, "H")               /* CST -> UTC */
  SET @endLocal = DateAdd(@endUtc, @offsetHrs, "H")      /* UTC -> subscriber local */
]%%

🔍 Line by line: - %%[ — opens the logic block. - /* System time is CST (UTC-6, no DST)... */ — comment stating the timezone fact the rest relies on. - SET @nowSys = Now() — current SFMC system time (CST, UTC−6, no DST). - SET @endSys = DateParse("2026-06-30 23:59:59") — parses the deadline string into a date value, treated as CST (matching system time). - SET @hoursLeft = DateDiff(@nowSys, @endSys, "H") — DateDiff with "H" returns whole hours remaining. Because both dates are in the same (system) timezone, the countdown is correct without any conversion. - /* For the SUBSCRIBER'S local deadline... */ — comment explaining why a manual offset is needed (SystemDateToLocalDate only knows the account timezone). - SET @offsetHrs = Field(@row, "UtcOffsetHours") — reads the subscriber's stored UTC offset (e.g., -5 for US Eastern). - SET @endUtc = DateAdd(@endSys, 6, "H") — DateAdd adds 6 hours to convert the CST deadline up to true UTC. - SET @endLocal = DateAdd(@endUtc, @offsetHrs, "H") — applies the subscriber's offset to UTC, producing the deadline in the subscriber's local time for display. The countdown math (@hoursLeft) and the displayed deadline (@endLocal) are kept separate on purpose. - ]%% — closes the logic block.

---

14B. More GAP-tailored snippets 🌟 (extra practice — retail / multi-brand)

These build on §14A with patterns you'll actually hit at a multi-brand retailer (Gap, Old Navy, Banana Republic, Athleta). Every snippet has its own line-by-line breakdown.

11) Safe null-guarded lookup (never render a broken row)

%%[
  VAR @sk, @firstName, @greetName
  SET @sk = _subscriberkey
  /* Lookup returns '' on no match — capture it, then guard before using it */
  SET @firstName = Lookup("Customer_Master", "FirstName", "SubscriberKey", @sk)
  IF EMPTY(@firstName) THEN
     SET @greetName = "there"
  ELSE
     SET @greetName = ProperCase(Trim(@firstName))
  ENDIF
]%%
<p>Hi %%=v(@greetName)=%%, welcome back!</p>

🔍 Line by line: - %%[ — opens the logic block. - VAR @sk, @firstName, @greetName — declares the three variables up front. - SET @sk = _subscriberkey — reads the system subscriber key to use as the lookup match value. - /* Lookup returns '' on no match... */ — comment reminding you that a missed Lookup is an empty string, not an error. - SET @firstName = Lookup("Customer_Master", "FirstName", "SubscriberKey", @sk) — single-value lookup: from Customer_Master, return FirstName where SubscriberKey = @sk. If there's no matching row, @firstName is "" (silently) — which is exactly why the next guard exists. - IF EMPTY(@firstName) THEN — checks for the empty/no-match case. - SET @greetName = "there" — falls back to a friendly generic ("Hi there") when no name is found. - ELSE — the name-present branch. - SET @greetName = ProperCase(Trim(@firstName)) — cleans the stored name: Trim removes stray spaces, ProperCase fixes casing (e.g., "akash" → "Akash"). - ENDIF — closes the guard. - ]%% — closes the logic block. - <p>Hi %%=v(@greetName)=%%, welcome back!</p> — outputs the chosen greeting inline inside an HTML paragraph. The render never shows a blank or errors, regardless of whether the lookup matched.

12) Multi-brand content routing by brand code

%%[
  VAR @brand, @logo, @footerKey, @brandName
  SET @brand = AttributeValue("BrandCode")        /* GAP | ON | BR | ATH */
  IF @brand == "ON" THEN
     SET @brandName = "Old Navy"
     SET @footerKey = "footer-oldnavy-en"
  ELSEIF @brand == "BR" THEN
     SET @brandName = "Banana Republic"
     SET @footerKey = "footer-br-en"
  ELSEIF @brand == "ATH" THEN
     SET @brandName = "Athleta"
     SET @footerKey = "footer-athleta-en"
  ELSE
     SET @brandName = "Gap"
     SET @footerKey = "footer-gap-en"        /* default brand */
  ENDIF
]%%
<p>Thanks for shopping with %%=v(@brandName)=%%.</p>
%%=ContentBlockByKey(@footerKey)=%%

🔍 Line by line: - %%[ — opens the logic block. - VAR @brand, @logo, @footerKey, @brandName — declares the working variables. - SET @brand = AttributeValue("BrandCode") — reads a BrandCode column from the send context. AttributeValue is used (not %%BrandCode%%) because it returns empty instead of erroring if the column is missing — safer for routing logic. - IF @brand == "ON" THEN — branch for Old Navy. - SET @brandName = "Old Navy" / SET @footerKey = "footer-oldnavy-en" — sets the display name and the Content Builder key for that brand's footer. - ELSEIF @brand == "BR" THEN — branch for Banana Republic, with its name and footer key. - ELSEIF @brand == "ATH" THEN — branch for Athleta, likewise. - ELSE — the default branch (Gap) — also catches any missing/unknown brand code, so the email always has a valid footer. - ENDIF — closes the routing conditional. - ]%% — closes the logic block. - <p>Thanks for shopping with %%=v(@brandName)=%%.</p> — outputs the resolved brand name. - %%=ContentBlockByKey(@footerKey)=%% — injects the brand-specific footer block by the key chosen above. One template, four brands, driven entirely by BrandCode.

13) Mod-based A/B split with a deterministic bucket

%%[
  VAR @sk, @hash, @bucket, @subject
  SET @sk     = _subscriberkey
  /* Hash the key to a number, then Mod by 2 for a stable 50/50 split */
  SET @hash   = Substring(MD5(@sk), 1, 6)
  SET @bucket = Mod(BaseConvert(@hash, 16, 10), 2)
  IF @bucket == 0 THEN
     SET @subject = "Your 20% off ends tonight"
  ELSE
     SET @subject = "Tonight only: 20% off everything"
  ENDIF
]%%
<!-- variant %%=v(@bucket)=%%: %%=v(@subject)=%% -->

🔍 Line by line: - %%[ — opens the logic block. - VAR @sk, @hash, @bucket, @subject — declares the variables. - SET @sk = _subscriberkey — the subscriber key, used as the stable seed so each subscriber always lands in the same bucket across sends. - /* Hash the key to a number... */ — comment explaining the approach. - SET @hash = Substring(MD5(@sk), 1, 6) — MD5(@sk) hashes the key to a hex string; Substring(..., 1, 6) keeps the first 6 hex characters (a manageable number to convert). Hashing first means even sequential keys spread evenly. - SET @bucket = Mod(BaseConvert(@hash, 16, 10), 2) — BaseConvert(@hash, 16, 10) converts the hex fragment from base-16 to a base-10 integer, then Mod(..., 2) reduces it to 0 or 1 — a deterministic 50/50 split. - IF @bucket == 0 THEN — variant A. - SET @subject = "Your 20% off ends tonight" — sets the A subject line. - ELSE — variant B. - SET @subject = "Tonight only: 20% off everything" — sets the B subject line. - ENDIF — closes the split. - ]%% — closes the logic block. - <!-- variant %%=v(@bucket)=%% ... --> — an HTML comment recording which bucket/subject was chosen (handy for QA; comments aren't shown to the recipient). In a real send you'd assign @subject to the email's subject line in the send setup.

14) Build a tokenized, signed preference-center link

%%[
  VAR @sk, @token, @prefUrl
  SET @sk    = _subscriberkey
  /* Encrypt the key so the raw SubscriberKey never appears in the URL */
  SET @token = EncryptSymmetric(@sk, "AES", "prefKeyName", @null, "prefSaltName", @null)
  /* CloudPagesURL signs the link and passes the token as a param */
  SET @prefUrl = CloudPagesURL(2048, "t", @token)
]%%
<a href="%%=v(@prefUrl)=%%">Manage your email preferences</a>

🔍 Line by line: - %%[ — opens the logic block. - VAR @sk, @token, @prefUrl — declares the variables. - SET @sk = _subscriberkey — the subscriber key we must protect. - /* Encrypt the key... */ — comment explaining why we tokenize. - SET @token = EncryptSymmetric(@sk, "AES", "prefKeyName", @null, "prefSaltName", @null) — EncryptSymmetric(value, algorithm, passwordKeyName, password, saltKeyName, salt) encrypts @sk using AES. The "prefKeyName"/"prefSaltName" arguments reference named keys/salts stored securely in Key Management; the @null placeholders mean "use the stored named value rather than an inline literal." The result is an opaque token, so the raw SubscriberKey never travels in the URL. - /* CloudPagesURL signs the link... */ — comment. - SET @prefUrl = CloudPagesURL(2048, "t", @token) — builds a signed link to CloudPage 2048, passing the encrypted token as a parameter named t. On the page you'd read RequestParameter("t") then DecryptSymmetric it back to the key. Signing makes the link tamper-evident. - ]%% — closes the logic block. - <a href="%%=v(@prefUrl)=%%">Manage your email preferences</a> — outputs the safe link in an anchor tag. (Note: EncryptSymmetric is not supported in Marketing Cloud Next — see §17 — so on MC Next you'd use a stored GUID or platform-native identity instead.)

15) Product loop with image/price fallbacks (no broken cells)

%%[
  VAR @rows, @cnt, @i, @row, @name, @img, @price, @raw
  SET @rows = LookupOrderedRows("Cart_Items", 4, "AddedDate ASC", "SubscriberKey", _subscriberkey)
  SET @cnt  = RowCount(@rows)
  IF @cnt > 0 THEN
    FOR @i = 1 TO @cnt DO
      SET @row  = Row(@rows, @i)
      SET @name = Field(@row, "ProductName", 0)
      SET @img  = Field(@row, "ImageURL", 0)
      SET @img  = IIF(EMPTY(@img), "https://img.gap.com/placeholder.jpg", @img)
      SET @raw  = Field(@row, "Price", 0)
      SET @price= IIF(EMPTY(@raw), "", FormatCurrency(@raw, "en-US", 2, "$"))
    ]%%
      <td valign="top">
        <img src="%%=v(@img)=%%" alt="%%=v(@name)=%%" width="150" style="display:block;border:0;">
        <div>%%=v(@name)=%%</div>
        %%[ IF NOT EMPTY(@price) THEN ]%%<div><strong>%%=v(@price)=%%</strong></div>%%[ ENDIF ]%%
      </td>
    %%[ NEXT @i ]%%
  ENDIF
]%%

🔍 Line by line: - %%[ — opens the logic block. - VAR @rows, @cnt, @i, @row, @name, @img, @price, @raw — declares all loop variables. - SET @rows = LookupOrderedRows("Cart_Items", 4, "AddedDate ASC", "SubscriberKey", _subscriberkey) — gets up to 4 abandoned-cart items for this subscriber, oldest first (AddedDate ASC). Passing _subscriberkey directly as the match value avoids a separate SET. - SET @cnt = RowCount(@rows) — counts how many cart items came back. - IF @cnt > 0 THEN — only render the loop when there's at least one item. - FOR @i = 1 TO @cnt DO — iterate each cart item. - SET @row = Row(@rows, @i) — grab the current item row. - SET @name = Field(@row, "ProductName", 0) — read the name; the trailing 0 suppresses a missing-column error and returns "" instead. - SET @img = Field(@row, "ImageURL", 0) — read the image URL defensively (0 = no error if column absent). - SET @img = IIF(EMPTY(@img), "https://img.gap.com/placeholder.jpg", @img) — if the image URL is blank, substitute a placeholder so the cell never shows a broken image. - SET @raw = Field(@row, "Price", 0) — read the raw price defensively. - SET @price = IIF(EMPTY(@raw), "", FormatCurrency(@raw, "en-US", 2, "$")) — only format currency when there's an actual price; otherwise keep it empty so we can hide the price line entirely (formatting an empty value would show $0.00). - ]%% — close logic to emit cell markup. - <td valign="top"> — opens the product cell. - <img src="%%=v(@img)=%%" alt="%%=v(@name)=%%" ...> — outputs the (guaranteed-present) image with the product name as alt text for accessibility. - <div>%%=v(@name)=%%</div> — the product name as visible copy. - %%[ IF NOT EMPTY(@price) THEN ]%%<div><strong>%%=v(@price)=%%</strong></div>%%[ ENDIF ]%% — an inline conditional around HTML: the price <div> is emitted only when @price isn't empty. This shows how IF/ENDIF can wrap markup, not just variable assignments. - </td> — closes the cell. - %%[ NEXT @i ]%% — one-line logic block advancing the loop. - ENDIF — closes the @count > 0 guard. - ]%% — closes the logic block.

16) Format a date for a "deal ends in" countdown line

%%[
  VAR @now, @end, @hrs, @days, @label
  SET @now  = Now()
  SET @end  = DateParse("2026-07-04 23:59:59")
  SET @hrs  = DateDiff(@now, @end, "H")
  IF @hrs <= 0 THEN
     SET @label = "Sale ended"
  ELSEIF @hrs < 24 THEN
     SET @label = Concat("Ends in ", @hrs, " hours")
  ELSE
     SET @days  = DateDiff(@now, @end, "D")
     SET @label = Concat("Ends in ", @days, " days (", Format(@end, "MMM d"), ")")
  ENDIF
]%%
<span style="color:#c00;font-weight:bold;">%%=v(@label)=%%</span>

🔍 Line by line: - %%[ — opens the logic block. - VAR @now, @end, @hrs, @days, @label — declares the variables. - SET @now = Now() — current system time (CST). Both endpoints stay in system time so the difference is correct. - SET @end = DateParse("2026-07-04 23:59:59") — parses the sale-end string into a date value. - SET @hrs = DateDiff(@now, @end, "H") — hours remaining until the deadline ("H" interval). - IF @hrs <= 0 THEN — the deadline has passed (zero or negative hours left). - SET @label = "Sale ended" — final-state copy. - ELSEIF @hrs < 24 THEN — under a day to go. - SET @label = Concat("Ends in ", @hrs, " hours") — builds the message with Concat (numbers are coerced to strings inside Concat; remember there is no + operator). - ELSE — more than a day remains. - SET @days = DateDiff(@now, @end, "D") — days remaining ("D" interval). - SET @label = Concat("Ends in ", @days, " days (", Format(@end, "MMM d"), ")") — combines the day count with a friendly formatted date. Format(@end, "MMM d") yields e.g. "Jul 4" (MMM = abbreviated month, d = day). - ENDIF — closes the conditional. - ]%% — closes the logic block. - <span style="...">%%=v(@label)=%%</span> — outputs the urgency label in styled red/bold text. The countdown copy is now correct whether the sale is days away, hours away, or already over.

17) Loyalty/StyleCash tier banner with graceful defaults

%%[
  VAR @row, @sk, @points, @tier, @banner
  SET @sk     = _subscriberkey
  SET @row    = LookupRow("Loyalty", "SubscriberKey", @sk)   /* one row object */
  SET @points = IIF(EMPTY(@row), 0, Field(@row, "Points", 0))
  IF @points >= 1000 THEN
     SET @tier = "Platinum"
  ELSEIF @points >= 500 THEN
     SET @tier = "Gold"
  ELSEIF @points >= 1 THEN
     SET @tier = "Member"
  ELSE
     SET @tier = "Guest"
  ENDIF
  SET @banner = Concat(@tier, " — ", FormatNumber(@points, "N0"), " points")
]%%
<div class="tier">%%=v(@banner)=%%</div>

🔍 Line by line: - %%[ — opens the logic block. - VAR @row, @sk, @points, @tier, @banner — declares the variables. - SET @sk = _subscriberkey — the subscriber key to match on. - SET @row = LookupRow("Loyalty", "SubscriberKey", @sk) — LookupRow (singular) returns a single row object (not a value, not a rowset) for the first match, so you can read several columns from it without a full LookupRows loop. @row is empty if there's no match. - SET @points = IIF(EMPTY(@row), 0, Field(@row, "Points", 0)) — if no loyalty row exists, default points to 0; otherwise read the Points column defensively (0 = no error if the column is missing). This double-guards both "no row" and "no column." - IF @points >= 1000 THEN ... SET @tier = "Platinum" — top tier at 1,000+ points. - ELSEIF @points >= 500 THEN ... SET @tier = "Gold" — mid tier at 500+. - ELSEIF @points >= 1 THEN ... SET @tier = "Member" — any positive balance is a Member. - ELSE ... SET @tier = "Guest" — zero/unknown points fall back to Guest, so non-enrolled subscribers still render cleanly. - ENDIF — closes the tier conditional. - SET @banner = Concat(@tier, " — ", FormatNumber(@points, "N0"), " points") — builds the banner text. FormatNumber(@points, "N0") formats the number with thousands separators and no decimals (e.g., 1234 → "1,234"). - ]%% — closes the logic block. - <div class="tier">%%=v(@banner)=%%</div> — outputs the finished banner (e.g., "Gold — 1,234 points"). Every subscriber gets a valid banner, enrolled or not.

---

15. Interview angles

Q: "Difference between Lookup and LookupRows?" → Lookup = one value, one match (no order guarantee); LookupRows = a rowset you iterate with RowCount/Row/Field. Use LookupOrderedRows when order matters.

Q: "How do you handle a subscriber with no matching data?" → Null-check (RowCount==0 / EMPTY) and render a fallback content block; never let it error or show blanks.

Q: "How would you reduce render time on a heavy personalized email?" → Collapse N Lookups into one LookupRows + in-memory Row/Field iteration; index/PK the match columns; keep render-time DEs narrow (lookups return the whole row); pre-aggregate heavy joins/counts in a SQL Query Activity upstream; avoid per-subscriber HTTPGet (precompute into a DE via Automation); push write-backs out of the render. The cost driver is data-layer round trips and external calls, not arithmetic.

Q: "What's TreatAsContent for?" → To execute AMPscript/HTML stored as a string (e.g., dynamic copy in a DE) at render — it re-invokes the parser. TreatAsContentArea adds key-based caching (watch for key collisions). Critical caveat: only on trusted, internally-authored content — never on user input (RCE-class injection).

Q: "How do you pass data from an email to a CloudPage securely?" → CloudPagesURL/EncryptSymmetric to tokenize the subscriber key in the link; read with RequestParameter + DecryptSymmetric on the page. Validate/whitelist params; never expose a raw SubscriberKey.

Q: "Your DE has 5,000 rows matching a customer — what does LookupOrderedRows(..., 0, ...) return?" → 2,000, not 5,000. All Lookup*Rows are hard-capped at 2,000 (the ORDER BY applies first, the cap after). DataExtensionRowCount still reports the true 5,000. Fix: pre-aggregate in a SQL Query Activity, or page via SSJS/WSProxy.

Q: "When do you use SSJS instead of AMPscript?" → For try/catch (AMPscript has none), JSON manipulation, WSProxy bulk DE ops past the 2,000 cap, recursion/complex data structures, Platform.Function.*/Core.*, and reusable functions. Otherwise AMPscript — it's faster to write, more readable, and the first-class render path. Do heavy work in SSJS, hand values back to AMPscript to render.

Q: "Why doesn't AMPscript concatenate with & or +?" → It has no &/+ string or arithmetic operators — only Concat() and Add()/etc. &&/|| do alias AND/OR, and =/== both work for equality, which is why people wrongly assume & concatenates. It doesn't, and the code won't render.

Q: "How does HTTPGet caching affect real-time content?" → One call per unique URL per send, cached and reused. A personalized query string makes every URL unique, defeating the cache and firing thousands of synchronous calls at render — latency and timeout risk. Senior answer: precompute API data into a DE via Automation/SSJS before the send and Lookup it at render.

Q: "How do you stop a single bad subscriber from killing a send?" → RaiseError("msg", true, "ERR_CODE") — boolSkipCurrentOnly=true skips just that subscriber and continues; false aborts the whole job. Use boolPreserveDataExt to control whether partial DE writes are retained.

Q: "What's the timezone gotcha with Now()?" → System time is Central STANDARD (UTC−6) year-round, no DST — never CDT — so in summer it's an hour behind actual Central wall time. SystemDateToLocalDate only converts to the account timezone; for subscriber-local times, store a UTC offset and DateAdd it.

Q: "Where's the platform heading — does AMPscript carry forward to Marketing Cloud Next?" → Partly. As of Summer '26, MC Next (Growth & Advanced) supports a subset (~30%) of AMPscript. HTTP/API, encryption/security, and SMS functions are NOT supported, and legacy Content Builder / Microsoft-integration functions are removed. So real-time HTTPGet content and EncryptSymmetric tokenization need a different design on MC Next. (See §17.)

Q: "What's the biggest AMPscript security risk you watch for?" → TreatAsContent/TreatAsContentArea on untrusted input — it re-runs the parser, so attacker-supplied AMPscript executes with the render's privileges (RCE-style). Never TreatAsContent a RequestParameter; whitelist params and tokenize identities.

---

16. Gotchas

• Lookup returns empty string (not null/error) on no match — handle it. With multiple matches it returns an unspecified row, not the "first."
• LookupRows is not ordered — classic bug. Use LookupOrderedRows.
• All Lookup*Rows are capped at 2,000 rows — silent truncation on large match sets. DataExtensionRowCount still shows the true count.
• No &/+ operators — use Concat/Add. (&&/|| alias AND/OR; =/== both work for equality.)
• Field(@row, "Col") errors on a missing column by default — pass 0 as the 3rd arg to return "" instead.
• %%Field%% can error if the field doesn't exist; AttributeValue("Field") won't (and accepts a computed name).
• RaiseError's 2nd param is boolSkipCurrentOnly (true=skip subscriber, false=abort job) — not a "continue" flag or field name.
• UpsertDE/UpdateDE numKeys must match the actual key columns or you corrupt/duplicate data.
• Write-backs and HTTPGet fire on VAWP/preview/FTAF unless guarded by _messagecontext. The render is non-transactional — no rollback.
• HTTPGet caches one call per unique URL — personalized query strings defeat the cache and multiply external calls.
• TreatAsContent* on untrusted input is RCE-class — only run trusted, internally-authored content. Reused TreatAsContentArea keys collide (cached value returned).
• Case sensitivity: match values are case-insensitive by default — use the *CS variants when needed.
• System time (Now()) is Central STANDARD (UTC−6), no DST, year-round — never CDT; an hour behind Central wall time in summer. SystemDateToLocalDate converts to the account tz only.
• No try/catch in AMPscript — guard defensively or drop to SSJS for fallible work.
• Empty() is true for null and ""; IsNull() only for actual null — pick the right guard.
• AMPscript executes top-to-bottom at render — order matters; set variables before use (also true across mixed AMPscript/SSJS blocks).

---

17. Marketing Cloud Next — platform direction (Summer '26) 🔑

A high-signal senior question in mid-2026 is "where is the platform heading, and what won't port?"

• AMPscript arrived in Marketing Cloud Next (Growth & Advanced editions) with the Summer '26 release — but only a subset (~30%) of functions is supported. It's a targeted set aimed at message customization, not full parity with Marketing Cloud Engagement.
• Function families that are NOT supported on MC Next (relevant to this module):
• HTTP / API functions — HTTPGet, HTTPPost, HTTPPost2, HTTPRequestHeader (§11).
• Encryption / security functions — EncryptSymmetric, DecryptSymmetric (§11).
• SMS functions.
• Legacy Content Builder functions and Microsoft-integration functions have been removed.
• Implication for your designs: patterns that lean on HTTPGet at render or EncryptSymmetric tokenization need a different approach on MC Next — push API/real-time data into a DE upstream (which you should already prefer for performance), and use platform-native (Data Cloud / core) identity handling rather than AMPscript encryption.

Interview line: "On Marketing Cloud Engagement I'd tokenize with EncryptSymmetric and pull real-time content with HTTPGet precomputed into a DE. On Marketing Cloud Next those families aren't in the supported ~30% of AMPscript yet, so I'd move API enrichment fully upstream into data/automation and rely on core platform identity — same architectural instinct (keep the render read-mostly), adapted to what the platform supports."

---

➡️ Next: 05_SSJS_and_WSProxy.md — your DE Lookup project's home turf (and where try/catch, WSProxy paging past the 2,000-row cap, and reusable functions live).

Module 05 — SSJS (Server-Side JavaScript) & WSProxy

Your DE Lookup Upgrade project lives here ("pure SSJS WSProxy, 50% faster metadata retrieval, unified 6 brand pages"). This module makes you able to explain and rebuild it on a whiteboard. 🔑

---

1. What SSJS is and when to use it 🔑

Server-Side JavaScript (SSJS) runs on a Salesforce-customized Mozilla Rhino interpreter built to the ECMAScript-3 spec (think old JavaScript, no ES6). It runs server-side at render time in SFMC. It exists where AMPscript runs — emails, CloudPages, and Script Activities in Automation Studio — but, importantly, those three are not interchangeable execution contexts (see §7).

🔑 Three execution contexts, three sets of rules (a senior distinction interviewers probe): - CloudPage — has Request/Response objects, can Write() to the page, can take query-string input, can make outbound HTTP. Errors render to the visitor. - Email (content) — render-time only; no Request/Response, no reliable outbound HTTP, no Platform.Response.Write target. Use it for personalization/logic, not for I/O. - Script Activity (Automation) — batch context; no Response.Write target (output is discarded), runs under the automation's system context, and a thrown error fails the activity/step and logs to Automation Studio's activity error log — there is no console. Hard 30-minute runtime limit.

SSJS vs AMPscript — when to use which 🔑🔑 (THE classic question)

Best-practice answer: "AMPscript for lightweight inline personalization and lookups in email; SSJS when I need real programming constructs — JSON, complex loops, try/catch error handling, or calling the SOAP/REST API via WSProxy. They interoperate: I can set an AMPscript variable from SSJS with Variable.SetValue/GetValue, so I use each for its strength." 🔑

⚠️ SSJS is slower and heavier than AMPscript for simple personalization. Don't use SSJS where AMPscript suffices in a high-volume send — that's a senior-level nuance. (Your project even replaced jQuery with pure SSJS WSProxy and got 50% faster — emphasize choosing the right tool.)

---

2. SSJS structure & the two libraries 🔑

SSJS runs inside:

<script runat="server">
   Platform.Load("Core", "1.1.1");   // load the Core library
   // ... code ...
</script>

🔍 Line by line: - <script runat="server"> — the wrapper that tells SFMC "run this JavaScript on the server at render time," not in the subscriber's browser. Without runat="server" the same <script> would be treated as ordinary client-side JS and shipped to the browser. This single attribute is what makes it SSJS. - Platform.Load("Core", "1.1.1"); — loads the Core object library so you can use higher-level objects like DataExtension, List, Folder. "Core" is the library name; "1.1.1" is the version string (the standard one). The Platform library (Platform.Function.*, Write, Variable) is available without loading anything; only Core needs this call. Omitting it and then calling DataExtension.Init(...) throws. - // ... code ... — a normal JS line comment marking where your logic goes. SSJS supports // and /* */ comments just like browser JS. - </script> — closes the server block. Everything between the tags executes in one server-side pass before the page/email is delivered.

⚠️ The ES3/Rhino nuance (this is the answer to "why can't I use forEach?"): SSJS is not a clean ES3 environment. Some ES5 helpers (Array.forEach/map/filter, native JSON, Object.keys) technically exist but are unreliable/buggy in SFMC and behave differently across contexts. So treat the environment as ES3 in practice: classic for loops, var only (no let/const/arrow functions/template literals), and use the Platform JSON functions (Platform.Function.ParseJSON / Stringify) instead of native JSON. Saying "I treat it as ES3 because the ES5 surface is partial and unreliable" lands far better than "it's ES3."

Two libraries: - Platform library — low-level functions: Platform.Function.Lookup(...), Platform.Response.Write(...), Platform.Request.GetQueryStringParameter(...), Platform.Variable.SetValue/GetValue. Mirrors many AMPscript functions. - Core library — higher-level object-oriented wrappers: DataExtension, List, Subscriber, TriggeredSend, Folder, etc. Load with Platform.Load("Core","1.1.1").

🔑 Variable interop has two valid forms. Both the global Variable.GetValue("@x")/Variable.SetValue("@x", v) and the namespaced Platform.Variable.GetValue(...)/Platform.Variable.SetValue(...) work and are interchangeable — they read/write the same AMPscript variable space. Don't let an interviewer's phrasing make you doubt either one.

Output

Write("hello");                 // shorthand
Platform.Response.Write("hi");  // explicit

🔍 Line by line: - Write("hello"); — the global shorthand for emitting text into the page output. Write is a top-level function (no library prefix needed) that appends its argument to the rendered HTML. On a CloudPage it shows on the page; in an email it injects into the content; in a Script Activity the output is discarded (no Response target), which is why you log to a DE there instead. - Platform.Response.Write("hi"); — the fully-qualified, explicit form of the same operation, namespaced under the Platform library's Response object. Identical behavior to Write; use whichever reads clearer. Knowing both forms is interview-safe, because interviewers sometimes show the long form to see if you recognize it.

Interop with AMPscript

var sk = Variable.GetValue("@subscriberKey");  // read AMPscript var
Variable.SetValue("@result", myValue);         // set AMPscript var

🔍 Line by line: - var sk = Variable.GetValue("@subscriberKey"); — reads the value of an AMPscript variable named @subscriberKey into a SSJS var. AMPscript and SSJS share one variable space on a page/email, so a variable declared earlier in AMPscript (e.g. %%[ VAR @subscriberKey SET @subscriberKey = ... ]%%) is visible here. Note the leading @ — it's part of the AMPscript name and must be included in the string. var is the only declaration keyword SSJS supports (no let/const). - Variable.SetValue("@result", myValue); — writes a SSJS value back into the AMPscript variable @result, so AMPscript later on the page can read it with %%=v(@result)=%%. This is the round-trip that lets you use SSJS for the heavy logic and AMPscript for inline rendering. The namespaced equivalents Platform.Variable.GetValue/SetValue do exactly the same thing.

And to run AMPscript from SSJS: Platform.Function.TreatAsContent("%%=v(@x)=%%").

---

3. Data Extension operations in SSJS (Core library)

<script runat="server">
Platform.Load("Core", "1.1.1");
try {
  var de = DataExtension.Init("Customer_Master");   // by Name or CustomerKey

  // READ rows with a simple filter
  var rows = de.Rows.Lookup(["SubscriberKey"], ["12345"]);
  if (rows && rows.length > 0) {
     Write(rows[0]["FirstName"]);
  }

  // ADD a row
  de.Rows.Add({ SubscriberKey: "12345", Status: "Active" });

  // UPDATE
  de.Rows.Update({ Status: "Updated" }, ["SubscriberKey"], ["12345"]);

  // RETRIEVE with complex filter (SimpleOperator)
  var filter = { Property:"Status", SimpleOperator:"equals", Value:"Active" };
  var data = de.Rows.Retrieve(filter);
} catch(e) {
  Write("Error: " + Stringify(e));
}
</script>

🔍 Line by line: - <script runat="server"> — opens the server-side block (see §2). Everything inside runs once at render time. - Platform.Load("Core", "1.1.1"); — loads the Core library so the DataExtension object exists. Required before any DataExtension.Init. - try { — begins a try/catch. Wrapping DE I/O is mandatory at the senior bar because there is no console — an uncaught error renders an ugly page (CloudPage) or fails the step (Automation). - var de = DataExtension.Init("Customer_Master"); — gets a handle to a Data Extension by its Name or CustomerKey. Init does not hit the database yet; it just creates the object you call .Rows.* methods on. Passing a non-existent name doesn't throw here — it throws when you first touch .Rows. - var rows = de.Rows.Lookup(["SubscriberKey"], ["12345"]); — reads rows where SubscriberKey == "12345". The first array is the match columns, the second is the values (positional: column[0] matches value[0]). Multiple pairs are ANDed. Returns an array of row objects, empty if nothing matches. - if (rows && rows.length > 0) { — defensive guard: confirm rows is truthy and has at least one element before indexing. SSJS won't always throw on undefined[0], but it produces garbage — always check. - Write(rows[0]["FirstName"]); — emits the FirstName column of the first matched row. Bracket notation rows[0]["FirstName"] is column access by name; rows[0].FirstName works too. - de.Rows.Add({ SubscriberKey: "12345", Status: "Active" }); — inserts one row. The argument is a flat object of column: value pairs. This is insert-only — it does not update an existing key (it can create a duplicate or error on a primary-key clash). - de.Rows.Update({ Status: "Updated" }, ["SubscriberKey"], ["12345"]); — updates matching rows. First arg = the columns to set (Status -> "Updated"); second/third arrays = the match column(s) and value(s), same positional pairing as Lookup. Only rows where SubscriberKey == "12345" are changed. - var filter = { Property:"Status", SimpleOperator:"equals", Value:"Active" }; — builds a simple filter object: which column (Property), which comparison (SimpleOperator), and the value. This is the same filter shape WSProxy uses (see §4), so learn it once. - var data = de.Rows.Retrieve(filter); — runs the filtered read and returns the matching rows. Retrieve(filter) is the filter-object form; Lookup(cols, vals) is the equals-only shorthand. - } catch(e) { — catches anything thrown inside the try. e is the error object. - Write("Error: " + Stringify(e)); — serializes the error to a readable string and writes it out. Stringify is SSJS's safe JSON serializer (never use native JSON.stringify here). On a CloudPage this is fine for debugging, but in production you'd log to an Error DE instead of leaking internals to a visitor. - } / </script> — close the catch block and the server block.

Platform.Function equivalents (lower level — these are the AMPscript functions exposed to SSJS):

var v  = Platform.Function.Lookup("DEName","ReturnCol","MatchCol","val");       // single value
var rs = Platform.Function.LookupRows("DEName","MatchCol","val");               // rowset (case-insensitive)
var rc = Platform.Function.LookupRowsCS("DEName","MatchCol","val");             // CASE-SENSITIVE match
var ro = Platform.Function.LookupOrderedRows("DEName", 10, "JoinDate desc",     // sorted + row cap
            "Status", "Active");
Platform.Function.UpsertDE("DEName", ["Key"], ["k1"], ["Col"], ["val"]);       // update-or-insert one row
Platform.Function.InsertDE("DEName", ["Key","Col"], ["k1","val"]);             // insert only
Platform.Function.UpdateDE("DEName", ["Key"], ["k1"], ["Col"], ["val"]);       // update only
Platform.Function.DeleteDE("DEName", ["Key"], ["k1"]);                          // delete matching rows

🔍 Line by line: - var v = Platform.Function.Lookup("DEName","ReturnCol","MatchCol","val"); — the lowest-level read: returns a single scalar value — the ReturnCol from the first row where MatchCol == "val". This is literally the AMPscript Lookup() function exposed to SSJS; Platform.Function.* is the bridge between the two languages. Returns null/empty if no match. - var rs = Platform.Function.LookupRows("DEName","MatchCol","val"); — returns a rowset (array of row objects), not just one value, where MatchCol == "val". The match is case-insensitive, which surprises people comparing tokens. - var rc = Platform.Function.LookupRowsCS("DEName","MatchCol","val"); — same as LookupRows but the CS suffix means case-sensitive matching. Reach for this when matching codes/tokens where ABC must not equal abc. - var ro = Platform.Function.LookupOrderedRows("DEName", 10, "JoinDate desc", "Status", "Active"); — like LookupRows but adds two powers LookupRows lacks: a row cap (10 = at most 10 rows) and a sort ("JoinDate desc" = newest first). This is how you answer "give me the most recent order" — LookupRows has no ordering at all. The trailing "Status","Active" is the match column/value pair. - Platform.Function.UpsertDE("DEName", ["Key"], ["k1"], ["Col"], ["val"]); — update-or-insert one row: if a row with Key == "k1" exists, set Col = "val"; otherwise insert it. The arrays pair positionally — match columns/values first, then the columns/values to write. This is the simplest single-row write (AMPscript-parity). - Platform.Function.InsertDE("DEName", ["Key","Col"], ["k1","val"]); — insert only (no update). Takes one combined column array and one value array. Errors/duplicates if the key already exists. - Platform.Function.UpdateDE("DEName", ["Key"], ["k1"], ["Col"], ["val"]); — update only (won't insert). Same positional-array shape as UpsertDE; no-op if no row matches. - Platform.Function.DeleteDE("DEName", ["Key"], ["k1"]); — deletes every row where Key == "k1". Match column array + value array; multiple pairs are ANDed.

🔑 Don't miss LookupOrderedRows and LookupRowsCS. Candidates routinely forget that Lookup/LookupRows give you no sort control and no case sensitivity. When you need "the most recent order" or to match a case-sensitive token, LookupOrderedRows(de, rowCount, "Col [asc|desc]", matchCol, matchVal) and LookupRowsCS(...) are the right tools. Also handy: Platform.Function.GUID(), Platform.Function.Now(), Platform.Function.RaiseError(msg) (fail loudly / fail an Automation step on purpose).

Upsert decision tree — which API to reach for 🔑🔑

When asked "how do you write rows," a senior justifies the choice: | Tool | Best for | Notes | |---|---|---| | Platform.Function.UpsertDE(...) | Simple, single-row, AMPscript-parity writes | Easiest; one row at a time; no cross-BU. | | DataExtension.Init(de).Rows.Add/Update(...) (Core) | Object-oriented row work in-session | Clean API; still in-BU; good default for CloudPage forms. | | prox.createItem/updateItem("DataExtensionObject", ..., SaveOptions UpdateAdd) | Bulk upserts, cross-BU, fine control | The real-world bulk path (see §4); supports SaveAction: 'UpdateAdd'. |

The wrong answer is "I just use UpsertDE for everything." The right answer names the trade-off: UpsertDE for one row, Core Rows for object-style in-BU work, WSProxy DataExtensionObject + SaveOptions UpdateAdd for bulk/cross-BU.

---

4. WSProxy 🔑🔑 (YOUR project — master this)

WSProxy is a lightweight SSJS wrapper around the SFMC SOAP API that lets you execute SOAP operations in-session rather than over an external connection.

⚠️ Be precise about why it's faster (a senior will push on a hand-wavy "it's faster"): WSProxy executes the same SOAP operations server-side — it does not bypass SOAP processing itself. The win is that it avoids: 1. the external HTTPS round-trip a client app would make, 2. the OAuth v2 token exchange (an extra HTTP call + token-caching concern) on every call, and 3. the JSON↔object marshaling a REST client incurs,

all while running under the existing session's auth context. It is not free: large retrieves still page at 2,500 rows and still consume request time.

🔑 This is your "replaced legacy jQuery with pure SSJS WSProxy, +50% metadata speed" story — frame the metric correctly. The 50% is mostly the removed per-call re-authentication and the removed network hop, not magic. That sentence — "the gain came from eliminating the token exchange and the external round-trip, since WSProxy reuses the in-session auth context" — is exactly what an interviewer wants to hear behind a number. (It also means it can't be 50% faster on a tiny retrieve where there was no auth overhead to remove — say that and you sound like you measured it, not guessed.)

Basic WSProxy retrieve

<script runat="server">
Platform.Load("Core","1.1.1");
var prox = new Script.Util.WSProxy();

// Retrieve all DataExtensions (metadata) — like your DE lookup
var cols = ["Name","CustomerKey","CategoryID"];
var result = prox.retrieve("DataExtension", cols);
var items = result.Results;   // array of DE metadata objects
for (var i = 0; i < items.length; i++) {
   Write(items[i].Name + " — " + items[i].CustomerKey + "<br>");
}
</script>

🔍 Line by line: - <script runat="server"> — server-side block (see §2). - Platform.Load("Core","1.1.1"); — loads Core. WSProxy lives under Script.Util, which Core provides, so this load is required before new Script.Util.WSProxy(). - var prox = new Script.Util.WSProxy(); — constructs the WSProxy object. No URL, no credentials — it inherits the current session's SOAP endpoint and auth context, which is exactly why it skips the OAuth token exchange a REST client would pay (see the speed note above). prox is your handle for .retrieve, .createItem, etc. - var cols = ["Name","CustomerKey","CategoryID"]; — the list of properties to return for each object. SOAP retrieves require you to name the columns you want; you don't get SELECT *. CategoryID is the folder the DE lives in (used later for folder paths). - var result = prox.retrieve("DataExtension", cols); — runs a SOAP Retrieve of the DataExtension object type (= DE metadata/schema, the list of DEs, not their rows). With no filter passed, it returns the first batch of all DEs the session can see (capped at 2,500 — see paging). - var items = result.Results; — pulls the actual array of result objects off the response envelope. The response is a wrapper ({ Results, HasMoreRows, RequestID, OverallStatus, ... }); .Results is the data. Always read from .Results, not from result directly. - for (var i = 0; i < items.length; i++) { — a classic for loop. SSJS is ES3 in practice, so you iterate with var i and an index — never items.forEach(...), which is unreliable in Rhino. - Write(items[i].Name + " — " + items[i].CustomerKey + "<br>"); — emits each DE's Name and CustomerKey followed by an HTML <br>. Property access is plain dot notation on the returned object. String concatenation with + (no template literals in ES3). - } / </script> — close the loop and the server block.

WSProxy with a simple filter

var filter = {
  Property: "CategoryID",      // folder ID
  SimpleOperator: "equals",
  Value: 12345
};
var res = prox.retrieve("DataExtension", ["Name","CustomerKey","CategoryID"], filter);

🔍 Line by line: - var filter = { — begins a simple filter object, the SOAP equivalent of a single WHERE clause. A simple filter has exactly three keys and tests one column. - Property: "CategoryID", — the column being filtered on. Here CategoryID is the folder ID, so this filter means "DEs in folder 12345." - SimpleOperator: "equals", — the comparison operator (see the full list below). "equals" is the most common; the value is case-sensitive for text. - Value: 12345 — the value to compare against. It's a number here because CategoryID is numeric; for text columns you'd pass a string. For between/IN this would be an array instead. - }; — closes the filter object. - var res = prox.retrieve("DataExtension", ["Name","CustomerKey","CategoryID"], filter); — same retrieve as before but with the filter passed as the third argument. Signature is retrieve(type, cols, filter, options). Now only DEs matching the filter come back (still capped at 2,500, still on res.Results).

Valid SimpleOperator values (memorize — interviewers ask for "more than equals"): equals, notEquals, greaterThan, lessThan, greaterThanOrEqual, lessThanOrEqual, isNull, isNotNull, between (Value is a 2-element array), IN (Value is an array), like (use % wildcards).

WSProxy with a COMPLEX / compound filter (AND / OR) 🔑🔑

The single most common follow-up is "how do you AND/OR two conditions?" You nest filter parts with LeftOperand / LogicalOperator / RightOperand:

var filter = {
  LeftOperand:  { Property:"CategoryID", SimpleOperator:"equals", Value:12345 },
  LogicalOperator: "AND",                       // or "OR"
  RightOperand: { Property:"Name", SimpleOperator:"like", Value:"Promo%" }
};
var res = prox.retrieve("DataExtension", ["Name","CustomerKey"], filter);

🔍 Line by line: - var filter = { — begins a complex filter. The shape is different from a simple filter: instead of Property/SimpleOperator/Value, a complex filter has exactly three keys — LeftOperand, LogicalOperator, RightOperand. - LeftOperand: { Property:"CategoryID", SimpleOperator:"equals", Value:12345 }, — the left half of the condition. It's itself a simple filter object (or another complex one). Here: "CategoryID equals 12345." - LogicalOperator: "AND", — how to combine the two operands. Valid values are "AND" and "OR". This is the join that a simple filter cannot express. - RightOperand: { Property:"Name", SimpleOperator:"like", Value:"Promo%" } — the right half, another simple filter: "Name like Promo%" (the % is the SQL-style wildcard for like). Combined with the AND above: DEs in folder 12345 whose name starts with "Promo". - }; — closes the complex filter. - var res = prox.retrieve("DataExtension", ["Name","CustomerKey"], filter); — identical retrieve call; the engine detects whether the filter object is simple or complex by its keys, so you pass either shape in the same third-argument slot.

Each operand can itself be another complex part, so you can build arbitrarily deep (A AND B) OR C trees by nesting a complex object where a LeftOperand/RightOperand would go.

Retrieving DE fields (columns) metadata

var fieldFilter = { Property:"DataExtension.CustomerKey", SimpleOperator:"equals", Value: deKey };
var fields = prox.retrieve("DataExtensionField", ["Name","FieldType","MaxLength","IsPrimaryKey"], fieldFilter);

🔍 Line by line: - var fieldFilter = { Property:"DataExtension.CustomerKey", SimpleOperator:"equals", Value: deKey }; — a simple filter, but note the dotted property DataExtension.CustomerKey. The DataExtensionField object is a child of a DE, so you filter its fields by the parent DE's CustomerKey using the dot-path. deKey is a variable holding the target DE's key. This is how you say "give me the columns that belong to this DE." - var fields = prox.retrieve("DataExtensionField", ["Name","FieldType","MaxLength","IsPrimaryKey"], fieldFilter); — retrieves the column definitions (schema metadata), not data. The requested props describe each column: its Name, its FieldType (Text/Number/Date/Boolean/EmailAddress/Phone/Decimal/Locale), MaxLength (for Text), and whether it IsPrimaryKey. Results land on fields.Results. This is the call you'd use to render a DE's structure in your DE Lookup page.

Retrieving DE data rows dynamically (when DE name only known at runtime)

// DataExtensionObject[<DE identifier>] is the dynamic data-row type
var rowsRes = prox.retrieve("DataExtensionObject[" + deKey + "]", ["SubscriberKey","Status"]);

🔍 Line by line: - // DataExtensionObject[<DE identifier>] is the dynamic data-row type — a comment reminding you that to read the rows of a DE (not its schema), you target the DataExtensionObject[...] type with the DE's identifier inside the brackets. - var rowsRes = prox.retrieve("DataExtensionObject[" + deKey + "]", ["SubscriberKey","Status"]); — builds the type string by concatenating the DE identifier (deKey) into the brackets, e.g. "DataExtensionObject[my_de_key]", then retrieves the SubscriberKey and Status columns of every row. This is what makes a generic DE-lookup page possible: the DE name isn't known until runtime, so you build the type string dynamically. Results are on rowsRes.Results; the requested columns must exist on that DE. Remember this exact type string — you reuse it verbatim when paging (see below), and getNextBatch requires it byte-for-byte.

🔑 DataExtensionObject[...] accepts either the DE Name or CustomerKey. Both work — DataExtensionObject[My DE] and DataExtensionObject[my_de_key] are both valid. Prefer CustomerKey: it's immutable (a Name can be renamed out from under your code) and unambiguous across BUs/shared DEs (Names can collide), and it's required for shared/parent-BU access. So this is a robustness choice, not "the Name doesn't work."

Authentication context — what WSProxy actually runs as 🔑

WSProxy needs no separate auth call because it inherits the executing session's context — but which context matters: - On a CloudPage, it runs as the page's user/session. - In a Script Activity, it runs under the automation's system context ("Automation" user), which has its own role/permission scope.

This has a real consequence: a script that works when you preview a CloudPage as yourself can fail or see fewer DEs/folders when the same logic runs in an automation, because the automation's context may not have access to those objects/BUs. "No separate auth" is not "runs as admin everywhere." If a Script Activity can't see a DE your CloudPage could, check the automation's context permissions first.

Paging large retrieves (the canonical idiom) 🔑🔑

A SOAP retrieve returns at most 2,500 rows per call — a BatchSize set above 2,500 is silently ignored. The response carries HasMoreRows (boolean) and RequestID (the continuation token). The interview-standard pattern is a do/while driven by HasMoreRows, switching from retrieve() to getNextBatch() on the RequestID:

var TYPE = "DataExtensionObject[" + deKey + "]";
var COLS = ["SubscriberKey","Status"];
var all = [], reqID = null, res;
do {
   res = (reqID == null) ? prox.retrieve(TYPE, COLS)
                         : prox.getNextBatch(TYPE, reqID);
   if (res && res.Results) { all = all.concat(res.Results); }
   reqID = res.RequestID;
} while (res && res.HasMoreRows);

🔍 Line by line: - var TYPE = "DataExtensionObject[" + deKey + "]"; — builds the object-type string once and stores it. Critical because getNextBatch must receive the identical string as the first retrieve — reusing the variable guarantees they can't drift apart. - var COLS = ["SubscriberKey","Status"]; — the columns to return, also stored once and reused on every batch (every batch of the same retrieve must request the same columns). - var all = [], reqID = null, res; — declares three things in one var: all (the accumulator array that will hold every row across all batches), reqID (the continuation token, starts null to signal "no batch fetched yet"), and res (the current batch's response). ES3 lets you comma-declare like this. - do { — starts a do/while loop, which runs the body at least once before testing the condition. That's the whole point: even if there's only one batch, you still process it. - res = (reqID == null) ? prox.retrieve(TYPE, COLS) : prox.getNextBatch(TYPE, reqID); — a ternary that picks the right call: on the first pass (reqID == null) call retrieve to start the read; on every subsequent pass call getNextBatch(TYPE, reqID) to fetch the next page using the prior continuation token. Same type string both times. - if (res && res.Results) { all = all.concat(res.Results); } — if the response exists and carries results, append this batch's rows to the accumulator. concat returns a new array of the two joined; reassigning all keeps the running total. The guard avoids crashing on an empty/failed batch. - reqID = res.RequestID; — saves the continuation token from this response so the next loop iteration can pass it to getNextBatch. RequestID is single-use and ordered — you walk batches in sequence, you can't jump to page 3. - } while (res && res.HasMoreRows); — loops again only while the server says more rows remain (HasMoreRows === true). When it's false, you've collected everything and the loop ends. Putting the test at the bottom is what lets the single-batch case work without duplicating the concat.

🔑 Why do/while, not while(HasMoreRows){...}? Three reasons a senior gives: 1. The first retrieve may already be the only batch (HasMoreRows === false) — a top-of-loop while would skip processing it unless you duplicate the concat outside the loop (the fragile pattern the old code used). 2. getNextBatch(type, RequestID) takes BOTH the original object-type string and the prior RequestID, and the type must be byte-for-byte identical to the original retrieve call or it errors. Reuse the TYPE variable so they can't drift. 3. RequestID is a single-use, ordered continuation token — you cannot random-access page 3; you must walk batches in order.

Alternative: ContinueRequest instead of getNextBatch. The current SSJS canon often prefers passing the prior RequestID as ContinueRequest in the 5th retrieve parameter rather than calling getNextBatch — same result, one consistent call signature. Know both so you're not blindsided:

res = prox.retrieve(TYPE, COLS, null, { ContinueRequest: reqID });

🔍 Line by line: - res = prox.retrieve(TYPE, COLS, null, { ContinueRequest: reqID }); — the alternative to getNextBatch. It's a normal retrieve call where the 4th argument (the options object) carries ContinueRequest: reqID. The 3rd argument is null — you pass no filter when continuing (the filter was set on the first call and is remembered with the RequestID). The advantage: one consistent call signature for both the first page and every continuation — only the options change. Same HasMoreRows/RequestID bookkeeping applies.

The 5th parameter — request options. retrieve(type, cols, filter, options) accepts an options object for things like: - QueryAllAccounts: true — include rows from shared / parent-BU data extensions (see cross-BU below). - ContinueRequest: <RequestID> — paging (above). - BatchSize: 2500 — request size (capped at 2,500; larger is ignored). - RepeatLastResult: true — re-fetch the last batch.

Create / Update / Delete via WSProxy — METADATA vs ROWS 🔑🔑 (this trips people up)

There are two different SOAP objects and conflating them is a classic interview tell:

(a) DataExtension = the DE itself (metadata / schema). Use it to create/alter/delete the table:

// Create a NEW data extension (the schema), not rows
prox.createItem("DataExtension", {
   Name: "Promo_Audience",
   CustomerKey: "Promo_Audience",
   CategoryID: 12345,                      // folder
   Fields: [
      { Name:"SubscriberKey", FieldType:"Text", MaxLength:254, IsPrimaryKey:true, IsRequired:true },
      { Name:"Status",        FieldType:"Text", MaxLength:50 }
   ]
});
prox.updateItem("DataExtension", { CustomerKey:"Promo_Audience", Name:"Promo_Audience_2025" });
prox.deleteItem("DataExtension", { CustomerKey:"Promo_Audience" });   // drops the whole DE
prox.performItem("Automation", { CustomerKey:"my_automation" }, "start");  // perform actions

🔍 Line by line: - prox.createItem("DataExtension", { ... }); — creates a new Data Extension (the table itself). The type is DataExtension (schema), not DataExtensionObject (rows) — this is the distinction that trips people up. The second argument is the DE's definition. - Name: "Promo_Audience", — the human-readable DE name (shown in the UI). - CustomerKey: "Promo_Audience", — the external/API key — immutable, used by code to address the DE. Setting it explicitly (rather than letting SFMC auto-generate one) means your scripts can reference the DE by a predictable key. - CategoryID: 12345, — the folder ID the DE will be created in. A comment notes it's the folder; omit it and the DE lands in the default Data Extensions root. - Fields: [ — the column definitions array. Each element defines one column. - { Name:"SubscriberKey", FieldType:"Text", MaxLength:254, IsPrimaryKey:true, IsRequired:true }, — first column: a 254-char Text field that is the primary key and required. A primary key is what makes upserts work (it identifies a row uniquely); IsRequired:true forbids nulls. - { Name:"Status", FieldType:"Text", MaxLength:50 } — second column: a 50-char Text field, nullable and non-key. MaxLength is only meaningful for Text. - }); — closes the Fields array and the createItem call. - prox.updateItem("DataExtension", { CustomerKey:"Promo_Audience", Name:"Promo_Audience_2025" }); — alters the existing DE identified by its CustomerKey, here renaming it. You identify the object by its immutable key and pass only the properties you want to change. - prox.deleteItem("DataExtension", { CustomerKey:"Promo_Audience" }); — drops the entire DE (schema + all rows). Deleting DataExtension removes the table; this is destructive and irreversible — note the comment. - prox.performItem("Automation", { CustomerKey:"my_automation" }, "start"); — performItem triggers an action on an object rather than CRUD. Here it "start"s an Automation by its key. The third argument is the action verb; objects expose different actions (an Automation supports "start", "pause", etc.).

(b) DataExtensionObject = the ROWS inside a DE. This is the path people forget — it takes a CustomerKey plus a Properties array of {Name, Value} pairs (not a flat object), and Keys to identify rows for delete:

// INSERT / UPSERT rows  (Properties = the column values)
var r = prox.createItem("DataExtensionObject", {
   CustomerKey: deKey,
   Properties: [
      { Name:"SubscriberKey", Value:"123" },
      { Name:"Status",        Value:"Active" }
   ]
}, [
   { Name:"SaveOptions", Value:[ { PropertyName:"*", SaveAction:"UpdateAdd" } ] }  // <- UPSERT
]);
Write(r.Status);

// UPDATE-only rows
prox.updateItem("DataExtensionObject", {
   CustomerKey: deKey,
   Properties: [ { Name:"SubscriberKey", Value:"123" }, { Name:"Status", Value:"Lapsed" } ]
});

// DELETE rows  (Keys identifies WHICH rows by primary key)
prox.deleteItem("DataExtensionObject", {
   CustomerKey: deKey,
   Keys: [ { Name:"SubscriberKey", Value:"123" } ]
});

🔍 Line by line: - var r = prox.createItem("DataExtensionObject", { ... }, [ ... ]); — writes a row (not a table). Target type is DataExtensionObject. There are three arguments here: (1) the type, (2) the row payload object, (3) an options array (used for the SaveOptions upsert below). The return r is the response carrying Status. - CustomerKey: deKey, — identifies which DE to write into, by its CustomerKey. Note rows don't go to a Name-keyed object — you give the DE's key. - Properties: [ — the column values, expressed as an array of {Name, Value} pairs, not a flat {col: val} object. This array shape is the part people forget; DataExtensionObject rows always use Properties: [{Name, Value}, ...]. - { Name:"SubscriberKey", Value:"123" }, — sets the SubscriberKey column to "123". Name is the column name, Value is the data. - { Name:"Status", Value:"Active" } — sets the Status column. Add one {Name,Value} per column you're writing. - }, [ — closes the row payload and opens the third argument, the options array. - { Name:"SaveOptions", Value:[ { PropertyName:"*", SaveAction:"UpdateAdd" } ] } — the upsert switch. SaveOptions with PropertyName:"*" (apply to the whole row) and SaveAction:"UpdateAdd" means update the row if the primary key matches, otherwise add it. Without this, createItem is insert-only and clashes on an existing key. - ]); — closes the options array and the createItem call. - Write(r.Status); — emits the operation's status string (e.g. "OK"). For real reliability you'd also check r.OverallStatus === "OK" (see §8) rather than trusting the row-level Status alone. - prox.updateItem("DataExtensionObject", { ... }); — update-only write (won't insert). Same CustomerKey + Properties:[{Name,Value}] shape; the primary-key column must be present in Properties so SOAP knows which row to update. Non-matching keys are simply not updated. - prox.deleteItem("DataExtensionObject", { ... }); — deletes rows. Note it uses Keys, not Properties — Keys is the array of {Name,Value} primary-key pairs identifying which rows to remove. Here it deletes the row whose SubscriberKey == "123".

🔑 Upsert = SaveOptions with SaveAction: "UpdateAdd". PropertyName: "*" applies the action to the whole row: update the record if the primary key matches, otherwise add it. This is the bulk/cross-BU upsert answer (UpdateOnly / AddOnly are the other actions). When an interviewer asks "how do you upsert rows with WSProxy," they want DataExtensionObject + Properties array + SaveOptions UpdateAdd — not createItem("DataExtension", ...).

Cross-business-unit operations (setClientId) 🔑 — multi-brand orgs ask this

From a parent BU automation you can operate against a child BU by setting the client (MID) on the proxy. Pair it with QueryAllAccounts:true to read shared DEs:

var prox = new Script.Util.WSProxy();
prox.setClientId({ ID: 5551212 });   // child BU MID
var res = prox.retrieve(
   "DataExtensionObject[" + sharedKey + "]",
   ["SubscriberKey"],
   null,
   { QueryAllAccounts: true }
);
// prox.resetClientIds();            // reset before operating on the parent again

🔍 Line by line: - var prox = new Script.Util.WSProxy(); — creates the proxy in the current (parent) BU's context, as usual. - prox.setClientId({ ID: 5551212 }); — re-scopes every subsequent call on this proxy to a child BU, identified by its MID (the numeric Member ID, here 5551212). This only works when the running context (e.g. a parent-BU automation) has the rights to operate on that child. After this line, retrieves/writes hit the child BU, not the parent. - var res = prox.retrieve( — a standard retrieve, now executing against the child BU because of setClientId. - "DataExtensionObject[" + sharedKey + "]", — the row type for a shared DE, built dynamically from sharedKey (use CustomerKey for shared/parent DEs — Names can collide across BUs). - ["SubscriberKey"], — columns to return. - null, — the filter slot is null (no filter; return all rows the context can see). - { QueryAllAccounts: true } — the options object. QueryAllAccounts: true tells SOAP to include rows from shared / parent-BU data extensions, not just the local BU's own. This pairs with setClientId for true cross-BU reads. - ); — closes the retrieve. - // prox.resetClientIds(); — a commented reminder: call resetClientIds() to clear the child-BU scope and return the proxy to the parent context before doing parent work. Forgetting this is a common bug — later calls silently keep hitting the child BU.

Tie this to your six-brand environment: one parent-BU nightly automation that fans out across brand BUs with setClientId/QueryAllAccounts is a strong senior story — it's the multi-BU generalization of your single-page DE Lookup.

⭐ Reusable snippet: a retrieveAll() helper that pages everything and bails safely

Instead of copy-pasting the do/while everywhere, wrap it in one function that returns all rows of any object type, hardened with a try/catch and a hard cap so a runaway retrieve can't loop forever:

function retrieveAll(prox, type, cols, filter) {
   var all = [], reqID = null, res, guard = 0;
   do {
      try {
         res = (reqID == null) ? prox.retrieve(type, cols, filter)
                               : prox.getNextBatch(type, reqID);
      } catch (e) {
         Platform.Function.UpsertDE("Error_Log", ["RunId"], [Platform.Function.GUID()],
              ["Context","Error"], ["retrieveAll:" + type, Stringify(e)]);
         break;                                  // stop on error; caller checks .length
      }
      if (res && res.Results) { all = all.concat(res.Results); }
      reqID = res ? res.RequestID : null;
      guard++;
   } while (res && res.HasMoreRows && guard < 1000);   // 1000 * 2,500 = 2.5M row ceiling
   return all;
}

// usage:
var allDEs = retrieveAll(prox, "DataExtension", ["Name","CustomerKey","CategoryID"], null);
Write("Total DEs: " + allDEs.length);

🔍 Line by line: - function retrieveAll(prox, type, cols, filter) { — declares a reusable function taking the proxy, the object type string, the columns array, and an optional filter. Passing prox in (rather than relying on a global) keeps it pure and testable. - var all = [], reqID = null, res, guard = 0; — the accumulator, the paging token (null = first call), the per-batch response, and a guard counter to cap total iterations. - do { — at-least-once loop, same reasoning as the canonical pattern (a single-batch result still gets processed). - try { — wrap the network call so one failed batch logs and exits instead of throwing out of the helper uncaught. - res = (reqID == null) ? prox.retrieve(type, cols, filter) : prox.getNextBatch(type, reqID); — first pass starts the retrieve with the filter; later passes continue with getNextBatch (no filter needed — it's remembered with the RequestID). Same type string both times. - } catch (e) { — a batch failed (timeout, permission, malformed type). - Platform.Function.UpsertDE("Error_Log", ["RunId"], [Platform.Function.GUID()], ["Context","Error"], ["retrieveAll:" + type, Stringify(e)]); — log the failure to the Error DE with which type failed, since there's no console. - break; — leave the loop on error; the caller inspects the returned array's .length to decide if the partial result is usable. - if (res && res.Results) { all = all.concat(res.Results); } — append this batch's rows to the accumulator (guarded against an empty/failed response). - reqID = res ? res.RequestID : null; — capture the continuation token (null-safe in case res is undefined after a caught error). - guard++; — increment the safety counter each iteration. - } while (res && res.HasMoreRows && guard < 1000); — keep paging while the server reports more rows and we're under the 1000-batch ceiling. 1000 × 2,500 = a 2.5M-row safety cap so a buggy HasMoreRows can never loop forever. - return all; — hand back every collected row. - var allDEs = retrieveAll(prox, "DataExtension", ["Name","CustomerKey","CategoryID"], null); — usage: fetch all DEs (no filter) in one call, fully paged. - Write("Total DEs: " + allDEs.length); — prove it worked by printing the total count.

⭐ Reusable snippet: a bulletproof WSProxy upsert that actually checks the result

A createItem can return a non-OK status with partial Results — some rows fail silently. The senior version inspects OverallStatus and per-row StatusMessage:

function upsertRow(prox, deKey, props) {
   var properties = [];
   for (var k in props) {
      if (props.hasOwnProperty(k)) {
         properties.push({ Name: k, Value: props[k] });   // {col:val} -> [{Name,Value}]
      }
   }
   var resp = prox.createItem("DataExtensionObject", {
      CustomerKey: deKey,
      Properties: properties
   }, [
      { Name:"SaveOptions", Value:[ { PropertyName:"*", SaveAction:"UpdateAdd" } ] }
   ]);
   if (resp.Status != "OK" || resp.OverallStatus != "OK") {
      var msg = resp.Results && resp.Results[0] ? resp.Results[0].StatusMessage : "unknown";
      Platform.Function.RaiseError("Upsert into " + deKey + " failed: " + msg);
   }
   return resp;
}

// usage:
upsertRow(prox, "Promo_Audience", { SubscriberKey: "123", Status: "Active" });

🔍 Line by line: - function upsertRow(prox, deKey, props) { — takes the proxy, the target DE's CustomerKey, and a flat {column: value} object — friendlier to write than the raw [{Name,Value}] array. - var properties = []; — the array we'll build in the shape WSProxy actually requires. - for (var k in props) { — iterate the flat object's keys. for...in is the ES3 way to walk object properties (no Object.keys reliance). - if (props.hasOwnProperty(k)) { — guard against inherited prototype keys, so we only convert the row's own columns. This is standard defensive for...in hygiene. - properties.push({ Name: k, Value: props[k] }); — convert each {col: val} pair into the {Name, Value} element WSProxy expects, building the Properties array. - var resp = prox.createItem("DataExtensionObject", { CustomerKey: deKey, Properties: properties }, [ { Name:"SaveOptions", Value:[ { PropertyName:"*", SaveAction:"UpdateAdd" } ] } ]); — the upsert write: target DataExtensionObject (rows), pass the DE key + built properties, and add the SaveOptions UpdateAdd to make it update-or-insert. (Type and shape mirror §4.) - if (resp.Status != "OK" || resp.OverallStatus != "OK") { — the part most code skips: check both the row-level Status and the envelope-level OverallStatus. A non-OK with partial Results means some rows failed even though the call "returned." - var msg = resp.Results && resp.Results[0] ? resp.Results[0].StatusMessage : "unknown"; — dig the human-readable failure reason out of the first result row, null-safely. - Platform.Function.RaiseError("Upsert into " + deKey + " failed: " + msg); — fail loudly: RaiseError throws an error that fails the Automation step (or shows on a CloudPage), so a real failure isn't silently swallowed and someone gets alerted. - return resp; — return the response for the caller's own inspection on success. - upsertRow(prox, "Promo_Audience", { SubscriberKey: "123", Status: "Active" }); — usage: upsert one row into Promo_Audience with a clean flat object. Internally it becomes the verbose Properties array.

---