CRM interview questions

Einstein STO analyses each subscriber's historical email engagement data (opens, clicks) to predict the time of day and day of week when that individual is most likely to engage with email. The Journey Builder Einstein STO activity holds each contact's message delivery until their predicted optimal send window.
How it works:
1. Einstein models analyse up to 90 days of engagement history per subscriber.
2. A send window is defined (e.g., deliver within the next 7 days).
3. The contact waits at the STO activity until their predicted optimal time within the window.
4. If a subscriber has insufficient history, they are sent at the default time or a random time within the window.
Requirements: Requires Einstein Engagement Scoring licence. Needs at least 6 months of send data from the same MID for meaningful predictions. Not suitable for time-sensitive transactional messages.

Marketing Cloud Connect integrates Marketing Cloud with a Salesforce CRM org, enabling data synchronisation and Journey Builder triggers based on CRM events.
Configuration: Requires a Connected App in the Salesforce CRM org with OAuth credentials, and the MC Connect managed package installed in CRM.
Synchronized Data Sources: CRM objects are synced to read-only data extensions in Marketing Cloud on a configurable schedule (near real-time for supported objects). Supported objects include: Contact, Lead, User, Account, Campaign, Campaign Member, and custom objects (with configuration).
Journey Builder Salesforce Entry: Contacts/Leads enter a journey when a CRM record meets defined criteria.
Sales/Service Cloud Activity: Journey steps can create Tasks, update fields, or log activity in CRM as a contact progresses through a journey.
Token management: OAuth tokens must be refreshed; expired tokens cause sync failures — monitor via the Salesforce Connector page in Marketing Cloud Setup.

Sender Profile: Defines the From Name, From Email address, and optional Reply-To address used in a send. Multiple sender profiles can be created for different brands or teams.
Delivery Profile: Specifies the physical mailing address (required by CAN-SPAM), header/footer, and IP address pool used for sending. The delivery profile determines which IP addresses are used.
Send Classification: Combines a Sender Profile, Delivery Profile, and classification type into a reusable configuration. The classification type is the most important property:
— Commercial: Respects the global unsubscribe list. Used for marketing email.
— Transactional: Does NOT respect the unsubscribe list. Used for order confirmations, password resets, and other transactional messages where the subscriber must receive the email regardless of opt-out status.
Choosing the wrong classification type can lead to legal issues (sending commercial email to unsubscribed users) or subscriber experience problems.

Signals of subscriber fatigue:
— Steadily decreasing open rates over time for a segment
— Increasing unsubscribe and complaint rates
— Declining CTOR despite stable open rates
— Engagement Recency data showing subscribers who haven't opened in 60+ days
— Email client caching: Apple MPP pre-loads pixels, inflating open rates and masking true engagement decline
Mitigation strategies:
— Implement Einstein Engagement Frequency to auto-suppress over-messaged contacts
— Build a re-engagement journey for subscribers inactive for 60–90 days (win-back campaign)
— Offer a preference centre allowing subscribers to choose frequency/topics
— Sunset non-engagers: suppressed contacts inactive after 6–12 months improve deliverability for the active list
— Reduce send frequency for low-engagement segments while maintaining high-value content quality

Delivery rate (delivered ÷ sent): Target >98%. Below 95% indicates list quality or deliverability issues.
Open rate (unique opens ÷ delivered): Industry average ~20–30% but heavily distorted by Apple Mail Privacy Protection (MPP) since 2021, which pre-loads tracking pixels. Use CTOR as a more reliable engagement signal.
CTOR (Click-to-Open Rate) (unique clicks ÷ unique opens): More meaningful than raw click rate post-MPP. Target >10–15%.
Bounce rate: Hard bounces <0.5%; soft bounces <4%.
Unsubscribe rate: Below 0.2% per send; above 0.5% signals content/frequency issues.
Complaint rate: Below 0.08% (Gmail FBL threshold from Feb 2024). Above 0.3% causes significant deliverability damage.
Spam placement rate: Monitored via inbox placement tools (Validity, GlockApps). Target <5% to spam.

Wait activities:
— Wait by Duration: Pauses for a fixed time period (hours/days/weeks).
— Wait Until Date: Pauses until a specific date/time field on the contact record.
Decision activities:
— Decision Split: Routes contacts down different paths based on data attribute conditions (up to 10 paths + default).
— Engagement Split: Routes based on whether a contact opened or clicked a previous email in the journey.
Einstein activities:
— Einstein Send Time Optimisation (STO): Delays each contact's email send to their individually predicted optimal send time within a window.
— Einstein Engagement Frequency: Suppresses contacts who are predicted to be over-messaged.
Other activities: Email send, SMS, Push Notification, Update Contact, Sales/Service Cloud Activity, Advertising Audience, Custom Split (via API activity).

Journey Builder supports multiple entry source types:
Salesforce Data Entry: Contacts enter based on Salesforce CRM records (Contact, Lead, or custom object) meeting filter criteria, or when a record is created/updated.
API Event: External systems inject contacts via a REST API call to an EventDefinitionKey. Used for behavioural triggers (cart abandonment, form submission, purchase event).
Scheduled Audience: A data extension is evaluated at a scheduled time; all contacts in the DE (meeting filter criteria) enter the journey. Supports recurring schedules for re-entry.
Cloud Pages Form Capture: A Smart Capture form on a CloudPage can be an entry source — form submission directly injects the contact into a journey.
Inbound Chat/WhatsApp: For MC Personalisation or WhatsApp-enabled journeys (newer entry sources added with MC Growth/Advanced editions).

Automation Studio supports several schedule types for automations:
Scheduled: Run once, daily, weekly, or monthly at a specified time. Supports time zone selection.
File Drop (Triggered): The automation starts automatically when a specific file is uploaded to a designated SFTP folder. The file name can be an exact match or a wildcard pattern. Ideal for data-import-triggered workflows (e.g., import a new segment file and immediately send an email).
Wait Activity: Pauses the automation for a specified duration before the next step. Used to sequence activities (e.g., import, wait 15 minutes, query, then send).
Run Once: Manually triggered or scheduled for a one-time execution. Automation activities within a single run execute sequentially in defined order.

A/B testing in Content Builder allows splitting your send audience to test up to 10 variants before sending the winner to the remainder.
Test variables:
— Subject line (most commonly tested)
— From name
— Email content (different content block variants)
— Send time (with or without Einstein STO)
Test setup: Define the test percentage (e.g., 10% to each variant) and the winner determination period (e.g., 4 hours after send).
Winner criteria:
— Open rate (unique opens)
— Click rate (unique clicks)
— Revenue (if MC is integrated with Commerce Cloud or e-commerce tracking)
Automatic winner send: After the winner determination period, Marketing Cloud automatically sends the winning variant to the remaining audience. Results include statistical confidence metrics to validate significance.

GDPR (General Data Protection Regulation) applies to email marketing to EU/EEA residents. Key impacts:
Lawful basis: You need a valid lawful basis to send marketing email. For most marketing, this is consent (freely given, specific, informed, unambiguous). Other bases (legitimate interest, contractual necessity) are less reliable for direct marketing.
Consent records: You must be able to demonstrate when, how, and what the subscriber consented to. Store consent timestamps and source in a DE. Marketing Cloud's preference centre can capture and store this.
Right to erasure (Right to be Forgotten): When a subscriber requests deletion, you must remove their personal data from Marketing Cloud — subscriber record, all DEs containing their data, and ensure they are suppressed from future sends. Marketing Cloud's contact deletion API (POST /contacts/v1/contacts/actions/delete) handles this.
Data minimisation: Only collect and store data necessary for the declared purpose.

CAN-SPAM (Controlling the Assault of Non-Solicited Pornography And Marketing Act) applies to commercial email sent to US recipients:
1. Honest From header: The From name and address must accurately identify the sender.
2. Honest subject line: Must not be deceptive or misleading about the email's contents.
3. Physical address: A valid postal address (or PO box) of the sending organisation must be included in the email body.
4. Opt-out mechanism: A clear and conspicuous way for recipients to unsubscribe must be present in every commercial email.
5. Honour opt-outs within 10 business days: Unsubscribe requests must be processed within 10 business days; you cannot require the subscriber to pay a fee or provide information beyond their email address.
6. Transactional exemption: Transactional emails (order confirmations, password resets) are largely exempt from CAN-SPAM requirements but must still not be deceptive.

Global unsubscribe (All Subscribers list): The subscriber is marked as globally unsubscribed across all commercial sends from the entire Marketing Cloud account. They will not receive any commercial email regardless of which list or DE they appear in.
Publication list unsubscribe: The subscriber opts out of a specific publication list (email category/topic). They still receive emails from other publication lists. Enables a preference centre experience where subscribers manage their communication preferences.
One-click unsubscribe (RFC 8058 / List-Unsubscribe-Post): A machine-actionable unsubscribe mechanism required by Gmail and Yahoo since February 2024 for bulk senders (>5,000/day). The email header includes a List-Unsubscribe-Post header; email clients expose a native unsubscribe button that POSTs directly to the unsubscribe endpoint without the subscriber needing to click a link in the email body. Marketing Cloud SAP enables this automatically.

Hard bounce (permanent): The receiving server permanently rejects the email — the address does not exist or the domain is invalid. Marketing Cloud automatically sets the subscriber status to Undeliverable after 1 hard bounce. Threshold: keep hard bounce rate below 0.5%.
Soft bounce (temporary): A temporary delivery failure — mailbox full, server temporarily unavailable, message too large. Marketing Cloud retries soft bounces up to 4 times over 72 hours before marking as undeliverable. Threshold: keep below 4%.
Blocked bounce: The receiving server or ISP actively blocked delivery, often due to IP/domain blacklisting or content filtering. Indicates a reputation problem.
Technical bounce: Miscellaneous technical errors (DNS failures, connection timeouts). Should be monitored but don't necessarily indicate a list quality issue.

Shared IP: Multiple senders share the same sending IP address. Reputation is influenced by all senders on that IP. Marketing Cloud's shared IP pools are managed by Salesforce and are pre-warmed. Suitable for lower-volume senders (typically below 50,000 emails/month) who cannot maintain sufficient volume to keep a dedicated IP warm.
Dedicated IP: A single IP address reserved exclusively for your organisation's sends. Your reputation is entirely determined by your own sending practices. Requires deliberate warming from cold. Typically recommended for senders above 50,000–100,000 emails/month who send consistently (at least weekly). Multiple dedicated IPs can be grouped into an IP pool for load distribution.
Key consideration: If you stop sending on a dedicated IP for more than 30 days, the reputation fades and the IP effectively goes cold again, requiring re-warming.

IP warming is the process of gradually increasing sending volume from a new or cold IP address to build a positive sending reputation with ISPs before sending full volume.
Typical ramp-up: Start with 500–1,000 emails/day to your most engaged subscribers (opened in last 30 days). Double volume roughly every 2–3 days, targeting engaged segments before the broader list.
Seed lists: Include internal seed addresses at major MBPs (Gmail, Yahoo, Outlook.com) to monitor inbox placement during warm-up.
Metrics to monitor:
— Bounce rate: should stay below 2% (hard bounces under 0.5%).
— Spam complaint rate: must stay below 0.08% (Gmail threshold); above 0.3% causes serious reputation damage.
— Open rate: target at least 20% from warmed segments.
— Spam trap hits: monitored via tools like Validity/Return Path.
— Inbox placement rate: percentage landing in inbox vs spam vs missing. Target above 90%.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a DNS TXT record at _dmarc.domain.com that specifies what receiving mail servers should do when a message fails SPF and DKIM alignment checks.
p=none: Monitor mode — no action taken on failing messages; aggregate reports (rua) and forensic reports (ruf) are sent to the specified email. Used during initial deployment to identify legitimate sending sources.
p=quarantine: Failing messages are routed to the spam/junk folder. Intermediate enforcement step.
p=reject: Failing messages are outright rejected and not delivered. Full protection against domain spoofing.
BIMI requirement: Brand Indicators for Message Identification (BIMI) — which displays your brand logo in supporting inboxes — requires p=quarantine or p=reject DMARC enforcement and a Verified Mark Certificate (VMC) for Gmail.
pct: Percentage of failing mail to apply the policy to (default 100). Useful for gradual rollout.

DKIM (DomainKeys Identified Mail) adds a cryptographic digital signature to the email header. The sending server signs outgoing mail with a private key; the public key is published as a DNS TXT record at selector._domainkey.domain.com. Receiving servers retrieve the public key and verify the signature — confirming the email has not been tampered with in transit and originated from an authorised sender.
Alignment: DMARC requires DKIM alignment — the d= domain in the DKIM signature must match (or be a subdomain of) the RFC5322 From header domain. When Marketing Cloud sends with its own DKIM key (@exacttarget.com), DKIM alignment with your From domain fails. The Sender Authentication Package (SAP) provides your own private domain and DKIM keys, enabling proper alignment.
Relaxed vs strict alignment: Relaxed allows subdomain matching; strict requires exact domain match.

SPF (Sender Policy Framework) is a DNS TXT record on the sending domain that lists the IP addresses and mail servers authorised to send email on behalf of that domain. Receiving servers look up the sending domain's SPF record and verify that the sending IP is listed.
include mechanism: Delegates to another domain's SPF record. Marketing Cloud SAP requires adding include:cust-spf.exacttarget.com to your SPF record.
~all (softfail): IPs not listed should be treated with suspicion but still accepted. Most MBPs accept softfail mail but may apply a spam score penalty. Recommended for initial SPF rollout.
-all (hardfail): IPs not listed should be rejected outright. Use -all once you are confident all legitimate sending sources are enumerated. SPF lookup limit is 10 DNS lookups — exceeding this causes a PermError.

Deliverability is the ability of an email to reach the recipient's inbox (not spam folder). Key factors:
Sender reputation: Composite score based on IP reputation, domain reputation, engagement rates, spam complaints, and bounce rates.
IP reputation: The sending IP address's history of sending behaviour. New or unwarmed IPs have no reputation — they must be warmed up gradually.
Domain reputation: The From domain's sending history. Major MBPs (Gmail, Yahoo, Outlook.com) now weight domain reputation more heavily than IP reputation.
Authentication: Valid SPF, DKIM, and DMARC alignment are increasingly required by major MBPs. Gmail and Yahoo mandated these from February 2024 for bulk senders.
Content: Spam trigger words, image-to-text ratio, link quality, and HTML coding issues affect spam filter scoring.
Engagement: High open/click rates and low unsubscribe/complaint rates signal to MBPs that recipients want the mail.

Rule-based dynamic content uses the Content Builder UI to define conditions (profile attributes or sendable DE field values) and map each condition to a specific content block variant. Rules are evaluated top-to-bottom; the first matching rule's content is rendered. A default block is shown when no rule matches. This approach requires no code and is ideal for marketers.
AMPscript-based dynamic content uses IF/ELSEIF/ELSE logic inside an HTML content block to conditionally render different HTML sections, call different ContentBlockByKey(), or output different personalisation tokens. This is more flexible and can reference multiple DE lookups, complex computed conditions, and nested logic. Use AMPscript when rule-based conditions are insufficient or when the number of variants is large.

Template-based emails in Content Builder use a template that defines the structural layout — headers, footers, column arrangements. The template defines content slots (also called content areas or editable regions).
Locked regions: Areas defined in the template that child email creators cannot modify. Typically used for brand-mandated headers, footers, and legal disclaimers. Locked via the locking property in the template code.
Unlocked regions: Slots where email creators can drag-and-drop content blocks (images, text, buttons, dynamic blocks). Each slot has a defined content type restriction (e.g., image only, any block).
This structure ensures brand consistency while giving content creators flexibility. Super content blocks can be inserted into templates as globally locked brand elements editable only by admins.

Content Builder uses a folder hierarchy for organisation (similar to a file system). Tags provide a cross-folder labelling system for quick filtering. Shared content lives in a parent Business Unit and is accessible to child BUs. Global content is locked content shared across BUs that child BUs cannot edit.
Content block types:
— HTML block: Raw HTML for complete custom control.
— Text block: Plain text or rich-text editor content.
— Image block: Hosted or external image with alt text and link.
— Button block: Styled CTA button with configurable colours and URL.
— Dynamic content block: Rule-based or AMPscript-powered content variation block.
— A/B test block: Two or more content variants for split testing within a single email slot.

Fluid (Liquid): Uses percentage-based widths so the email scales proportionally on any screen. No media queries required. Limitation: text can become too small or too wide without min/max-width constraints.
Hybrid (Spongy): Combines fluid percentage widths with max-width constraints using MSO conditional comments to fix Outlook rendering. The inner table uses width:100% and max-width in CSS, while Outlook sees a fixed-pixel table via VML/conditional comments. This is the most widely compatible approach today.
Responsive: Uses CSS media queries to change layout at breakpoints (e.g., stack columns below 600px). Works great in clients that support media queries (modern Gmail, Apple Mail, iOS Mail). Outlook desktop clients largely ignore media queries, so a hybrid fallback is still needed.
Outlook VML: Microsoft Outlook uses VML (Vector Markup Language) for background images and gradient fills — standard CSS background-image is ignored.

Width: Use a max-width of 600px — most email clients, especially Outlook on Windows, render best at this width. Tables are still recommended for layout to handle Outlook's Word-based renderer.
CSS: Inline CSS is the most widely supported method. Embedded styles (<style> in <head>) are stripped by some clients (older Gmail, some mobile). External CSS is not supported in email.
Fonts: Use web-safe font stacks (Arial, Georgia, Times New Roman) with web font declarations (@font-face or Google Fonts) first, falling back gracefully. Many Outlook versions do not support web fonts.
Preheader text: Keep it 85–100 characters to display well across clients; hide any filler text using display:none or mso-hide:all.
Images: Always provide descriptive alt text. Many clients block images by default — the email must be readable without images.
Plain text: Always include a plain text version; some ESPs and spam filters penalise HTML-only emails.

Marketing Cloud enforces API rate limits per MID (business unit) to protect platform stability:
REST API: Generally 2,000 requests/minute. Some endpoints (e.g., contacts) have lower per-endpoint limits.
SOAP API: 2,000 requests/minute.
Transactional Messaging: Up to 2,500 emails/minute on dedicated IPs; shared IP limits are lower.
OAuth token requests: Throttled — cache tokens and reuse until near expiry (18 minutes).
Handling strategies:

1. Implement exponential back-off with retry on HTTP 429 responses.
2. Batch API calls where endpoints support it (e.g., TM API batch of 50).
3. Use the async data extension API for bulk DE operations rather than row-by-row REST calls.
4. Monitor rate limit headers (X-RateLimit-Remaining) in responses.
5. Distribute integrations across business units where architecture permits.

A Script Activity in Automation Studio runs SSJS server-side on a schedule or as part of an automation. Best practices:
Error handling: Wrap all logic in try { } catch(e) { } blocks. Log errors to a custom logging DE with fields: timestamp, scriptName, errorMessage, stackTrace.
Logging: Use Platform.Response.Write() sparingly (output is discarded in automation context); instead write log entries to a DE using Platform.Function.InsertDE() or WSProxy.
Idempotency: Check for existing records before inserting to avoid duplicate processing on retry.
Timeouts: Script Activities have a 30-minute limit. Break large batches into smaller automation runs or use Automation Studio loops with filtered DE segments.
Rate limits: Marketing Cloud APIs enforce rate limits (e.g., REST: 2,000 requests/minute). Implement back-off logic in SSJS using Platform.Function.Sleep(milliseconds).

PKCE (Proof Key for Code Exchange) is used when a public app (a client that cannot securely store a client_secret — e.g., a single-page app or mobile app) needs to authenticate against Marketing Cloud APIs.
Flow: The app generates a random code_verifier, hashes it to produce code_challenge, then initiates an authorization code flow with code_challenge_method=S256. After the user authenticates, the app receives an authorization code and exchanges it for tokens by sending the original code_verifier — the server validates the hash without ever receiving a client_secret.
In Marketing Cloud Installed Packages, choose Public App component type to enable PKCE. Server-to-Server components use client credentials flow (no PKCE needed). Web App components use standard authorization code flow with a client_secret stored server-side.

The Content Builder REST API uses the /asset/v1/content/assets endpoint:
Create: POST /asset/v1/content/assets with body containing name, assetType.id (e.g., 220 for HTML block), content (the HTML string), and optionally customerKey and category.id (folder).
Retrieve: GET /asset/v1/content/assets/{id} or search using GET /asset/v1/content/assets?$filter=name%20eq%20'MyBlock'.
Update: PATCH /asset/v1/content/assets/{id} with only the changed fields.
Delete: DELETE /asset/v1/content/assets/{id}.
Asset type IDs: 4 = webpage, 5 = webtemplate, 196 = template, 207 = HTML email, 220 = HTML content block, 230 = text content block.

Triggered Sends use the legacy SOAP/REST triggered send definition and are associated with a triggered send DE; they have limited throughput and configuration flexibility.
Transactional Messaging API (TM API) is the modern replacement: POST /messaging/v1/email/messages/{messageKey}. Key differences:
— TM API has higher throughput (up to 2,500 emails/minute per MID on dedicated IPs).
— Supports synchronous send status response in near real time.
— Batch endpoint: POST /messaging/v1/email/messages/ accepts up to 50 recipients per batch call.
— Supports attributes and content.customerKey overrides per message.
— Requires a Transaction Definition Key created in Email Studio under Triggered Sends > Transactional Sends.

The Journey Builder REST API allows external systems to inject contacts into a journey via an API Entry Event. Steps:
1. In Journey Builder, create an API Event entry source — this generates an EventDefinitionKey.
2. Define an Entry Source Data Extension with the fields you want to pass into the journey.
3. Publish the journey.
4. Call POST /interaction/v1/events with body: {"ContactKey":"sub123","EventDefinitionKey":"APIEvent-abc123","Data":{"FirstName":"Jane","Email":"jane@example.com"}}.
Marketing Cloud processes the event asynchronously and enters the contact at the journey's entry point. Unlike triggered sends, Journey API entries are rate-limited and best used for behavioural events (cart abandonment, form fill) rather than high-volume batch sends.

CloudPages is Marketing Cloud's content hosting platform that publishes landing pages, microsites, and smart capture forms on a Salesforce-managed domain (or custom domain). CloudPages fully support AMPscript and SSJS, making them ideal for:
Dynamic landing pages: Personalise content based on URL query parameters or subscriber attributes passed from email links.
Preference centres: Read and update subscriber preferences in real time using AMPscript DE functions.
Smart Capture forms: Collect data and write directly to a DE via form submission (InsertDE or UpsertDE).
Redemption pages: Use ClaimRow to issue unique codes on page load.
AMPscript on CloudPages executes server-side at page request time, not send time, so RequestParameter("paramName") retrieves URL query string values.

In Automation Studio, a Query Activity uses SQL SELECT statements. The output DE must be specified in the Query Activity configuration — you cannot use SQL INSERT INTO syntax directly; Marketing Cloud routes the results to the target DE. Example:
SELECT
c.SubscriberKey,
c.EventDate AS ClickDate,
c.URL,
m.FirstName
FROM _Click c
JOIN MyMasterDE m ON c.SubscriberKey = m.SubscriberKey
WHERE c.IsUnique = 1
AND c.EventDate >= DATEADD(DAY, -7, GETDATE())
The target DE must have matching column names. Overwrite mode replaces all rows; Append mode adds rows. Query Activities have a 30-minute execution time limit.

Data views are system-managed tables queryable via SQL in Automation Studio Query Activities:
_Subscribers — all subscriber records and status.
_Sent — send event records (JobID, ListID, BatchID, SubscriberID, EventDate).
_Open — open tracking events (IsUnique).
_Click — click tracking events (URL, IsUnique).
_Bounce — bounce events (BounceType: SoftBounce/HardBounce).
_Unsubscribed — unsubscribe events.
_JourneyActivity — Journey Builder activity-level events.
Data views retain data for 6 months. Example: SELECT s.SubscriberKey, o.EventDate FROM _Sent s JOIN _Open o ON s.JobID = o.JobID AND s.SubscriberID = o.SubscriberID WHERE s.JobID = 12345.

The SOAP API uses the Enterprise WSDL at https://YOUR_SUBDOMAIN.soap.marketingcloudapis.com/etframework.wsdl. A RetrieveRequest message specifies:
ObjectType: The API object name (e.g., DataExtension, Subscriber, Send).
Properties: Array of field names to return.
Filter: A SimpleFilterPart with Property, SimpleOperator (equals, notEquals, isNotNull, greaterThan, etc.), and Value. Multiple conditions use ComplexFilterPart with LogicalOperator AND/OR.
The response uses MoreDataAvailable and RequestID for pagination — re-submit with ContinueRequest until MoreDataAvailable = false. WSProxy in SSJS wraps all this automatically.

Triggered Sends: POST /messaging/v1/messageDefinitionSends/{definitionKey}/send — fires a triggered send to one or more subscribers. Body includes To.Address, To.SubscriberKey, and optional subscriberAttributes.
Contacts: POST /contacts/v1/contacts — creates or updates a contact. GET /contacts/v1/contacts/{contactKey} retrieves a contact.
Data Extensions (Async): POST /data/v1/async/dataextensions/{key}/rows — asynchronously upserts rows into a data extension. The async endpoint returns a request token; poll GET /data/v1/async/{requestToken} for status.
Data Extensions (Sync): POST /data/v1/customobjectdata/key/{key}/rowset — synchronous row insert for smaller payloads. Always prefer async for bulk operations.

Marketing Cloud uses OAuth 2.0 client credentials flow for server-to-server authentication. Steps:
1. Create an Installed Package in Setup with a Server-to-Server component and assign required API scopes.
2. Obtain client_id and client_secret from the package.
3. POST to https://YOUR_SUBDOMAIN.auth.marketingcloudapis.com/v2/token with body: {"grant_type":"client_credentials","client_id":"...","client_secret":"..."}.
4. The response includes access_token, token_type":"Bearer", expires_in (default 1080 seconds — 18 minutes), and rest_instance_url.
5. Include the token as Authorization: Bearer ACCESS_TOKEN on all subsequent API requests.
Cache and reuse the token until near expiry; do not request a new token for every API call.

SSJS provides the HTTP object (on CloudPages) and Platform.Function.HTTPGet/HTTPPost for API calls from Script Activities:
HTTP.Get(url): Returns a string response. No header control.
HTTP.Post(url, contentType, body): Sends a POST request.
For full header control (needed for authenticated REST API calls) use HTTP.Get(url, headerNames[], headerValues[]) and HTTP.Post(url, contentType, body, headerNames[], headerValues[], statusCode).
PUT/DELETE: Use HTTP.Post with a header X-HTTP-Method-Override: PUT or DELETE, since SSJS HTTP does not have native PUT/DELETE methods. Alternatively, use WSProxy for SOAP-based operations or call Marketing Cloud's own REST endpoints via HTTP.Post with appropriate method overrides.

WSProxy is a SSJS library that wraps the SOAP API. Example patterns:
Retrieve: var prox = new Script.Util.WSProxy(); var cols = ["Name","CustomerKey"]; var response = prox.retrieve("DataExtension", cols);
Create: prox.createItem("DataExtensionObject", {CustomerKey:"DE_Key", Properties:[{Name:"Email",Value:"test@x.com"}]});
Update: prox.updateItem("DataExtensionObject", {CustomerKey:"DE_Key", Properties:[...]});
Delete: prox.deleteItem("DataExtensionObject", {CustomerKey:"DE_Key", Properties:[{Name:"SubscriberKey",Value:"123"}]});
Upsert: prox.upsertItem("DataExtensionObject", {...});
WSProxy handles authentication automatically using the context token, avoiding manual OAuth flows in Script Activities.

AMPscript is a lightweight markup language designed for email personalisation. It is optimised for high-volume send-time rendering, has lower server overhead, and is the only scripting language supported inside email sends. Use AMPscript for email personalisation, DE lookups at send time, and simple conditional content.
SSJS (Server-Side JavaScript) runs on the Marketing Cloud application server. It supports modern JavaScript syntax, complex data structures, HTTP calls, and the full WSProxy/Core library. SSJS is available in CloudPages, Script Activities in Automation Studio, and landing pages, but not inside email sends. Use SSJS when you need API calls, complex logic, error handling, or cross-object data manipulation that exceeds AMPscript capabilities.

AttributeValue("attrName") retrieves a profile attribute or sendable data extension field value for the current subscriber being rendered. It looks up the value from the subscriber's profile attributes (All Subscribers list attributes) or, when sending from a data extension, from the columns in that DE. It is the fastest method for simple personalisation.
Lookup("DE", returnCol, matchCol, matchVal) performs an explicit query against any data extension. Use Lookup when you need to retrieve data from a non-sendable DE, a related record, or when you need fields not available on the subscriber's send record. Lookup incurs more processing overhead; cache results in variables when re-used multiple times in the same email.

RedirectTo(url) wraps a URL with Marketing Cloud click tracking and returns the tracked URL. To append UTM parameters you build the URL string first:
%%[
SET @baseUrl = "https://example.com/product"
SET @utm = "?utm_source=email&utm_medium=email&utm_campaign=spring2025"
SET @trackedUrl = RedirectTo(Concat(@baseUrl, @utm))
]%%
<a href="%%=@trackedUrl=%%">Shop Now</a>
The outer MC tracking layer records the click against the subscriber, and the UTM parameters are passed through to GA/analytics. Ensure special characters are URL-encoded using URLEncode() if parameter values contain spaces or special characters.

ContentArea(areaNumber) — retrieves a Classic Content Area by its numeric ID from the legacy Classic email content. Largely deprecated in favour of Content Builder.
ContentBlockByKey("externalKey") — retrieves a Content Builder content block by its Customer Key (External Key). This is the preferred method in modern implementations because keys are human-readable and portable across environments.
ContentBlockById(numericId) — retrieves a Content Builder content block by its internal numeric ID. Less portable because IDs differ between business units and environments.
Best practice: always use ContentBlockByKey in production for maintainability. Assign meaningful external keys in Content Builder when creating blocks.

These AMPscript functions manipulate data extension records at send time (and on CloudPages):
InsertDE("DE", col1, val1, ...) — inserts a new row; returns 1 on success.
UpdateDE("DE", numMatchCols, matchCol, matchVal, updateCol, updateVal, ...) — updates matching rows; returns the number of rows updated.
UpsertDE("DE", numMatchCols, matchCol, matchVal, col, val, ...) — inserts or updates based on match; returns 1 for insert, number of rows updated for update.
DeleteDE("DE", numMatchCols, matchCol, matchVal) — deletes matching rows; returns the count of deleted rows.
ClaimRow("DE", returnCol, matchCol, matchVal) — atomically reserves a row (sets a flag) and returns the value of the specified column; used for one-time code distribution to prevent duplicate claims.

IIF(condition, trueVal, falseVal) — inline if/else in a single expression.
FormatDate(@date, "shortdate") — formats a date value; supports named patterns (shortdate, longdate) or custom patterns like "MM/DD/YYYY".
DateAdd(@date, numDays, "D") — adds units to a date; unit codes: D (days), M (months), Y (years), H (hours).
Substring(@str, start, length) — extracts characters; 1-based index.
Concat(str1, str2, ...) — concatenates strings.
Replace(@str, "find", "replace") — replaces all occurrences of a substring.
UpperCase(@str) — converts to uppercase; LowerCase and ProperCase also available.
Length(@str) — returns the number of characters in the string.

FOR @i = startValue TO endValue DO ... NEXT @i iterates a counter variable. The most common use is iterating over a LookupRows or LookupOrderedRows rowset:
%%[
SET @rows = LookupRows("Orders","Email",emailaddr)
SET @cnt = RowCount(@rows)
FOR @i = 1 TO @cnt DO
SET @row = Row(@rows, @i)
SET @product = Field(@row, "ProductName")
]%%
%%=@product=%%<br>
%%[ NEXT @i ]%%
Note that AMPscript does not support WHILE loops. All iteration must be done via FOR/NEXT with a known upper bound (use RowCount to get it).

AMPscript uses IF condition THEN ... ELSEIF condition THEN ... ELSE ... ENDIF for conditional logic. Conditions use comparison operators (==, !=, >, <) and logical operators (AND, OR, NOT). Example:
%%[
SET @tier = Lookup("Loyalty","Tier","Email",emailaddr)
IF @tier == "Gold" THEN
SET @msg = "Thank you, Gold member!"
ELSEIF @tier == "Silver" THEN
SET @msg = "Thank you, Silver member!"
ELSE
SET @msg = "Thank you for being a member!"
ENDIF
]%%
%%=@msg=%%
ENDIF is mandatory to close every IF block. Nested IFs are supported but can hurt readability.

Lookup returns a single scalar value — the value of the specified column from the first row matching the filter criteria. Syntax: Lookup("DE_Name","ReturnCol","FilterCol","FilterVal"). LookupRows returns a rowset object containing all matching rows. You iterate using Row(rowset, rowNum) and Field(row, "colName"). LookupOrderedRows returns a rowset sorted by a specified field (ascending or descending) and can be capped to a maximum row count. Use LookupOrderedRows when you need the most recent N records (e.g., last 3 purchases ordered by date descending).

VAR @name explicitly declares a variable, which is optional in most contexts — AMPscript will auto-declare on first SET. However, explicit VAR is recommended for clarity and is required in some strict server-side contexts (CloudPages with strict parsing). SET @name = expression assigns a value. Variables are page-scoped; they do not persist across send-time personalisation calls on different emails. Example: %%[ VAR @fname SET @fname = AttributeValue("FirstName") ]%% then output with Hello %%=@fname=%%.

%%[ ]%% delimits a multi-line AMPscript code block where you can write SET, VAR, IF, and function calls. @variable is the variable reference syntax — variables are declared with VAR @name and assigned with SET @name = value. Outside a block you reference a variable inline as %%=@name=%%. You can also use inline expressions with %%=FunctionName(args)=%% without opening a full block. The key rule is that executable statements (SET, IF, FOR) must live inside %%[ ]%%, while output references can appear anywhere in the content using the %%=...=%% inline syntax.