g;
syncFrequency: 'REALTIME' | 'DAILY' | 'MANUAL';
piiFields: Array<'EMAIL' | 'PHONE' | 'ADDRESS' | 'NAME'>;
}
function validateIdentityConsistency(maps: SubscriberIdentityMap[]): boolean {
const keys = maps.map(m => m.sfmcKey);
const uniqueKeys = new Set(keys);
if (keys.length !== uniqueKeys.size) {
throw new Error('Duplicate SFMC keys detected across sources. Resolve before DE creation.');
}
return true;
}
**Architecture Rationale:** Centralizing identity resolution prevents segmentation drift. When CRM and e-commerce data share a deterministic key, SQL queries and Automation Studio activities execute predictably. PII field tagging enables automated masking in tracking extracts and reporting exports.
### Phase 2: Routing & Classification Architecture
Marketing and transactional emails require distinct routing, IP allocation, and compliance handling. Collapsing them into a single send classification breaks CAN-SPAM compliance, ruins sender reputation, and complicates preference center logic.
**Implementation:**
Establish volume thresholds to determine IP strategy. Volumes under 250,000 monthly sends operate efficiently on shared IPs. Volumes exceeding this threshold require dedicated IP allocation and a structured warming plan.
```typescript
interface SendRoutingConfig {
classification: 'MARKETING' | 'TRANSACTIONAL';
monthlyVolume: number;
ipStrategy: 'SHARED' | 'DEDICATED';
warmingSchedule?: Array<{ week: number; targetVolume: number }>;
requiresConsentCheck: boolean;
}
function determineIPStrategy(config: SendRoutingConfig): string {
if (config.monthlyVolume > 250000) {
return 'DEDICATED';
}
return 'SHARED';
}
Architecture Rationale: Dedicated IPs isolate reputation risk. Transactional emails (password resets, order confirmations, security alerts) must bypass marketing suppression lists and preference center opt-outs. Separating classifications at the routing layer ensures compliance and deliverability stability.
Phase 3: Integration & Ingestion Pipeline Design
Data ingestion paths dictate automation complexity and latency. Marketing Cloud Connect, SFTP drops, and real-time APIs serve different operational models.
Implementation:
Map ingestion methods to use-case latency requirements. CRM syncs require MC Connect with explicit object mapping. E-commerce events benefit from real-time API ingestion. Flat-file imports suit batch reporting or legacy migrations.
interface IngestionPipeline {
source: string;
method: 'MC_CONNECT' | 'SFTP' | 'REST_API';
targetDE: string;
conflictResolution: 'UPSERT' | 'OVERWRITE' | 'APPEND';
encryption: 'NONE' | 'PGP' | 'TLS';
}
function validateIngestionSecurity(pipeline: IngestionPipeline): boolean {
if (pipeline.encryption === 'NONE' && pipeline.method === 'SFTP') {
console.warn('SFTP without PGP/TLS violates PII handling standards. Enable encryption.');
return false;
}
return true;
}
Architecture Rationale: MC Connect provides native CRM synchronization but requires careful object selection to avoid sync bloat. SFTP pipelines demand strict file naming conventions and encryption standards. Real-time APIs require rate-limit handling and idempotency keys. Choosing the correct path prevents data staleness and integration failures.
Phase 4: Operational & Compliance Guardrails
Post-handoff operations dictate template complexity, approval workflows, and reporting structure. Compliance frameworks (GDPR, PDPA, CAN-SPAM) mandate explicit consent tracking, physical sender addresses, and unsubscribe synchronization.
Implementation:
Build consent tracking directly into the primary Data Extension schema. Index consent fields for query performance. Route preference center updates back to the source system via API or sync activity.
CREATE TABLE [SubscriberConsent] (
[CustomerGUID] VARCHAR(50) PRIMARY KEY,
[EmailAddress] VARCHAR(254) NOT NULL,
[MarketingOptIn] BIT DEFAULT 0,
[ConsentTimestamp] DATETIME2 DEFAULT GETUTCDATE(),
[ConsentSource] VARCHAR(50),
[GDPR_EU_Resident] BIT DEFAULT 0,
[PDPA_TH_VN_Resident] BIT DEFAULT 0,
[Unsubscribed] BIT DEFAULT 0,
[Bounced] BIT DEFAULT 0,
INDEX [IX_ConsentTracking] NONCLUSTERED ([MarketingOptIn], [Unsubscribed], [GDPR_EU_Resident])
);
Architecture Rationale: Indexed consent fields accelerate segmentation queries and compliance audits. Storing consent source and timestamp creates an immutable audit trail. Routing unsubscribe events back to CRM ensures cross-platform consistency and prevents accidental sends to suppressed contacts.
Pitfall Guide
1. Email Address as Primary Key
Explanation: Email addresses change, are shared across households, and frequently contain typos. Using email as the unique identifier causes duplicate records, broken personalization, and failed deduplication.
Fix: Enforce a deterministic GUID or CRM ContactKey as the primary key. Map email to the GUID during ingestion. Use email only for send routing and display purposes.
2. Ignoring IP Warming Thresholds
Explanation: Deploying high-volume campaigns on a new dedicated IP without a warming schedule triggers spam filters, spikes complaint rates, and damages sender reputation.
Fix: Implement a progressive warming plan. Start at 5,000 sends/day, increase by 20-30% daily, and monitor bounce/complaint rates. Automate volume caps via Automation Studio until the IP reaches full capacity.
3. Collapsing Send Classifications
Explanation: Routing transactional and marketing emails through the same classification bypasses preference center logic, violates CAN-SPAM requirements, and complicates reporting.
Fix: Create separate Send Classifications, Sender Profiles, and Delivery Profiles. Route transactional emails through a classification that disables unsubscribe suppression and excludes marketing suppression lists.
4. Overlooking Preference Center Sync
Explanation: Building a preference center without syncing unsubscribe events back to the source system creates data fragmentation. CRM and SFMC diverge, leading to compliance violations and duplicate sends.
Fix: Configure API callbacks or MC Connect sync activities to push preference updates to the source system. Validate sync latency and implement retry logic for failed updates.
5. Underestimating Business Unit Complexity
Explanation: Enterprise accounts often require multiple Business Units for brand separation, regional compliance, or team isolation. Failing to map data sharing rules early causes cross-BU send failures and reporting gaps.
Fix: Document BU hierarchy, data sharing requirements, and sender domain allocations before provisioning. Use Shared Data Extensions for cross-BU subscriber data and configure appropriate permissions.
6. Skipping Transactional Exception Routing
Explanation: Safety notices, password resets, and account security alerts must reach contacts who have unsubscribed from marketing. Standard send classifications block these sends.
Fix: Create a dedicated transactional classification with SendClassificationType = Transactional. Configure the preference center to exclude these categories from opt-out logic.
7. Assuming Flat File Ingestion Scales
Explanation: Relying on manual CSV imports for high-frequency segmentation creates operational bottlenecks and data staleness. Automation Studio file drops lack real-time validation.
Fix: Migrate to MC Connect or REST API ingestion for dynamic data. Use SFTP only for batch migrations or legacy system exports. Implement file validation scripts to reject malformed payloads before DE insertion.
Production Bundle
Action Checklist
Decision Matrix
| Scenario | Recommended Approach | Why | Cost Impact |
|---|
| <250k monthly sends, single brand | Shared IP + Marketing Cloud Connect | Lower infrastructure overhead, native CRM sync | Minimal |
| >250k monthly sends, multi-brand | Dedicated IP + Separate BUs + API Ingestion | Reputation isolation, brand compliance, real-time data | Moderate (IP leasing + engineering) |
| High compliance region (EU/SEA) | Indexed Consent DE + Preference Center API Sync | Audit readiness, regulatory alignment, reduced legal risk | Low (schema adjustment + API config) |
| Legacy flat-file dependency | SFTP with PGP encryption + Validation Script | Secure batch processing, gradual migration path | Low-Moderate (automation setup) |
Configuration Template
{
"sfmcFoundation": {
"identity": {
"primaryKey": "CustomerGUID",
"sourceMapping": {
"crm": "ContactKey",
"ecommerce": "ShopifyCustomerID",
"warehouse": "MemberUUID"
}
},
"routing": {
"marketing": {
"classification": "MKT_Classification",
"senderProfile": "MKT_Sender",
"ipStrategy": "SHARED",
"monthlyThreshold": 250000
},
"transactional": {
"classification": "TXN_Classification",
"senderProfile": "TXN_Sender",
"suppressUnsubscribed": false,
"canSpamPhysicalAddress": true
}
},
"compliance": {
"gdpr": true,
"pdpa": false,
"consentTracking": true,
"preferenceCenterSync": true,
"auditRetentionDays": 2555
},
"operations": {
"approvalWorkflow": true,
"approvers": ["Legal", "Brand", "Compliance"],
"operatorSkillLevel": "ENGINEERING",
"reportingDestination": "POWER_BI"
}
}
}
Quick Start Guide
- Run the Identity & Source Mapping Phase: Document every system holding subscriber data. Assign a deterministic GUID as the primary key. Validate consistency across sources using the TypeScript validator.
- Configure Routing & Classification: Create separate Send Classifications for marketing and transactional emails. Set IP strategy based on monthly volume thresholds. Draft a warming schedule if deploying a dedicated IP.
- Build the Consent Schema: Deploy the primary Data Extension with indexed consent fields. Configure preference center API callbacks to sync unsubscribe events back to the source system.
- Validate Ingestion Pipelines: Select MC Connect, SFTP, or REST API based on latency requirements. Enable encryption for PII payloads. Test file validation or API idempotency before production routing.
- Execute MVP Deployment: Ship the first use case (typically welcome or onboarding). Monitor bounce, complaint, and engagement metrics daily for 14 days. Adjust segmentation and routing based on observed data.
