Data Schemas for Email Marketing
Adjust Technical Level
Select your expertise level to customize content
Data schemas define the structure, relationships, and constraints of your marketing database. In email marketing, well-designed schemas facilitate personalization, segmentation, and automation by organizing subscriber attributes, behaviors, and preferences in a logically structured, accessible format for campaign execution and analysis.
Understanding Data Schemasβ
Technical Perspective
Why Data Organization Matters in Email Marketing
Think of a data schema like the blueprint for a well-organized filing cabinet:
- Filing Cabinets: Different categories of information you collect (customer details, purchase history, email engagement)
- Folders: Groups of related information within each category
- Labels: What kind of information goes in each section (names, email addresses, preferences)
- Format Rules: How each piece of information should be written down (dates in MM/DD/YYYY format, phone numbers with area codes)
- Cross-References: Notes that tell you where to find related information in other cabinets
- ID Numbers: Unique codes that identify each customer or transaction
- Verification Steps: Checks to make sure information is complete and accurate
When your customer data is well-organized, you can easily find what you need, group similar customers together, and personalize your messagesβmaking your email marketing more effective and efficient.
Non-Technical Perspective
Data Schema Fundamentals
In database terms, a schema is a blueprint that defines the organization of data, including:
- Tables/Entities: The primary data structures (e.g., Subscribers, Campaigns, Interactions)
- Fields/Attributes: Individual data points within each entity (e.g., email address, first name)
- Data Types: The format for each field (string, integer, datetime, boolean, etc.)
- Relationships: How different entities connect (one-to-one, one-to-many, many-to-many)
- Primary Keys: Unique identifiers for each record (e.g., subscriber_id, campaign_id)
- Foreign Keys: References to primary keys in other tables to establish relationships
- Constraints: Rules that enforce data integrity (e.g., not null, unique, check constraints)
- Indexes: Performance optimizations for faster data retrieval
Email marketing platforms implement these concepts either through traditional relational database models or through custom data extensions and data models specific to their architecture.
Core Data Entities for Email Marketingβ
Legend
Components
Connection Types
Essential Information Categories for Email Marketing
Your Main Information Categories
- Subscriber Information: Everything about the people you're emailing - names, contact information, when they joined your list, and whether they're active
- Campaign Details: Information about each email you send - the subject line, when it was sent, who it was from, and what it was about
- Email Content: The actual messages, images, and designs that make up your emails
- Subscriber Activity: Records of how people interact with your emails - whether they opened them, clicked links, or took other actions
- Audience Groups: Ways to organize subscribers based on what they're interested in or how they've interacted with you
Additional Useful Information
- Communication Preferences: How often people want to hear from you and what topics interest them
- Customer Journeys: The sequence of emails someone should receive based on their actions or timeline
- Purchase Information: What customers have bought, when, and for how much - to help you suggest relevant products
- Do-Not-Contact Lists: Records of people who have unsubscribed or had email delivery problems
- Results Tracking: Information that connects sales or conversions back to specific email campaigns
How These Categories Work Together
- Each subscriber can receive multiple campaigns
- Subscribers can belong to multiple audience groups
- Campaigns can have different content versions for testing what works best
- Each subscriber has their own history of email interactions
- Purchase information helps you understand what subscribers are interested in
When all these information categories are properly connected, you can create highly targeted, relevant email experiences that feel personalized to each recipient.
Example Data Schemasβ
- Subscriber Schema
- Campaign Schema
- Engagement Schema
- Segment Schema
{
"SubscriberSchema": {
"fields": [
{
"name": "subscriber_id",
"dataType": "string",
"isPrimaryKey": true,
"description": "Unique identifier for the subscriber"
},
{
"name": "email_address",
"dataType": "string",
"isRequired": true,
"isUnique": true,
"description": "Email address of the subscriber"
},
{
"name": "first_name",
"dataType": "string",
"description": "Subscriber's first name"
},
{
"name": "last_name",
"dataType": "string",
"description": "Subscriber's last name"
},
{
"name": "status",
"dataType": "string",
"allowedValues": ["active", "unsubscribed", "bounced", "pending"],
"defaultValue": "pending",
"description": "Current subscription status"
},
{
"name": "source",
"dataType": "string",
"description": "Where the subscriber came from (landing page, event, referral, etc.)"
},
{
"name": "signup_date",
"dataType": "datetime",
"description": "When the subscriber joined the list"
},
{
"name": "last_updated",
"dataType": "datetime",
"description": "When the subscriber record was last modified"
},
{
"name": "time_zone",
"dataType": "string",
"description": "Subscriber's time zone for send time optimization"
},
{
"name": "language_preference",
"dataType": "string",
"description": "Preferred language for communications"
}
],
"indexes": [
{
"fieldNames": ["email_address"],
"isUnique": true
},
{
"fieldNames": ["status", "signup_date"],
"isUnique": false
}
]
}
}
{
"CampaignSchema": {
"fields": [
{
"name": "campaign_id",
"dataType": "string",
"isPrimaryKey": true,
"description": "Unique identifier for the campaign"
},
{
"name": "name",
"dataType": "string",
"isRequired": true,
"description": "Internal name of the campaign"
},
{
"name": "subject_line",
"dataType": "string",
"isRequired": true,
"description": "Email subject line"
},
{
"name": "preheader",
"dataType": "string",
"description": "Preview text shown in inbox"
},
{
"name": "from_name",
"dataType": "string",
"description": "Sender name displayed to recipients"
},
{
"name": "from_email",
"dataType": "string",
"description": "Sender email address"
},
{
"name": "reply_to",
"dataType": "string",
"description": "Reply-to email address"
},
{
"name": "content_id",
"dataType": "string",
"isRequired": true,
"description": "Reference to the email content"
},
{
"name": "segment_id",
"dataType": "string",
"description": "Target audience segment"
},
{
"name": "status",
"dataType": "string",
"allowedValues": ["draft", "scheduled", "sending", "sent", "cancelled"],
"defaultValue": "draft",
"description": "Current status of the campaign"
},
{
"name": "scheduled_time",
"dataType": "datetime",
"description": "When the campaign is scheduled to send"
},
{
"name": "sent_time",
"dataType": "datetime",
"description": "When the campaign was actually sent"
},
{
"name": "campaign_type",
"dataType": "string",
"allowedValues": ["promotional", "newsletter", "transactional", "automated"],
"description": "Type of campaign"
},
{
"name": "utm_parameters",
"dataType": "object",
"description": "Tracking parameters for campaign analytics"
}
],
"indexes": [
{
"fieldNames": ["status", "scheduled_time"],
"isUnique": false
},
{
"fieldNames": ["campaign_type", "sent_time"],
"isUnique": false
}
]
}
}
{
"EngagementSchema": {
"fields": [
{
"name": "event_id",
"dataType": "string",
"isPrimaryKey": true,
"description": "Unique identifier for the engagement event"
},
{
"name": "subscriber_id",
"dataType": "string",
"isRequired": true,
"description": "Subscriber who performed the action"
},
{
"name": "campaign_id",
"dataType": "string",
"isRequired": true,
"description": "Campaign associated with the event"
},
{
"name": "event_type",
"dataType": "string",
"allowedValues": ["send", "delivery", "open", "click", "bounce", "complaint", "unsubscribe", "conversion"],
"isRequired": true,
"description": "Type of engagement event"
},
{
"name": "timestamp",
"dataType": "datetime",
"isRequired": true,
"description": "When the event occurred"
},
{
"name": "url",
"dataType": "string",
"description": "URL clicked (for click events)"
},
{
"name": "device_type",
"dataType": "string",
"allowedValues": ["desktop", "mobile", "tablet", "unknown"],
"description": "Device used by the subscriber"
},
{
"name": "user_agent",
"dataType": "string",
"description": "Browser or email client information"
},
{
"name": "ip_address",
"dataType": "string",
"description": "IP address of the subscriber (if available and compliant)"
},
{
"name": "geo_location",
"dataType": "object",
"description": "Geographic location data (country, region, city)"
},
{
"name": "conversion_value",
"dataType": "decimal",
"description": "Value of conversion (for conversion events)"
}
],
"indexes": [
{
"fieldNames": ["subscriber_id", "timestamp"],
"isUnique": false
},
{
"fieldNames": ["campaign_id", "event_type", "timestamp"],
"isUnique": false
},
{
"fieldNames": ["event_type", "timestamp"],
"isUnique": false
}
]
}
}
{
"SegmentSchema": {
"fields": [
{
"name": "segment_id",
"dataType": "string",
"isPrimaryKey": true,
"description": "Unique identifier for the segment"
},
{
"name": "name",
"dataType": "string",
"isRequired": true,
"description": "Name of the segment"
},
{
"name": "description",
"dataType": "string",
"description": "Description of the segment purpose or criteria"
},
{
"name": "created_date",
"dataType": "datetime",
"description": "When the segment was created"
},
{
"name": "last_updated",
"dataType": "datetime",
"description": "When the segment was last modified"
},
{
"name": "created_by",
"dataType": "string",
"description": "User who created the segment"
},
{
"name": "is_dynamic",
"dataType": "boolean",
"defaultValue": true,
"description": "Whether the segment updates automatically based on criteria"
},
{
"name": "filter_logic",
"dataType": "object",
"description": "Logic defining the segment (conditions, operators, values)"
},
{
"name": "sql_definition",
"dataType": "string",
"description": "SQL query defining the segment (for advanced segments)"
},
{
"name": "estimated_size",
"dataType": "integer",
"description": "Estimated number of subscribers in the segment"
},
{
"name": "last_calculated",
"dataType": "datetime",
"description": "When the segment membership was last calculated"
}
],
"indexes": [
{
"fieldNames": ["is_dynamic", "last_calculated"],
"isUnique": false
}
]
}
}
Data Schema Design Patterns for Email Marketingβ
Pattern | Description | Best For | Considerations |
---|---|---|---|
Flat Contact Model | All subscriber attributes in a single table or data extension | Simple email programs, small businesses, limited attribute sets | Easy to implement but can become unwieldy with many attributes; limited relational capabilities |
Normalized Subscriber Model | Core subscriber data separated from preferences, behaviors, and other attributes in related tables | Mid-size programs with moderate complexity, growing attribute sets | Better organization and reduced redundancy, but requires more complex queries for full profiles |
Dimensional Data Model | Facts (metrics) and dimensions (attributes) separated for analytical purposes | Advanced analytics needs, data warehousing approaches | Optimized for reporting and analysis; more complex to maintain |
Event-Based Model | Focus on subscriber events and activities with timestamps as primary data points | Behavioral-driven programs, journey mapping | Excellent for time-series analysis and behavioral targeting but requires stream processing capabilities |
Hierarchical Account Model | Structured for B2B with organization hierarchy above individual contacts | B2B marketing, account-based marketing approaches | Supports complex organizational relationships but increases data model complexity |
Journey-Oriented Model | Organized around customer journey stages and touchpoints | Lifecycle marketing, complex multi-step nurture programs | Aligns well with marketing strategy but may duplicate some data across journey stages |
Hybrid Transaction/Analytical | Combines operational needs (sending) with analytical capabilities | Enterprise email programs with both operational and analytical requirements | Supports both functions but increases system complexity and may require ETL processes |
Identity Resolution Model | Focuses on connecting multiple identifiers to a single customer identity | Cross-channel marketing, programs with multiple customer touchpoints | Powerful for omnichannel marketing but complex to implement and maintain |
Consent-Centric Model | Prioritizes storing detailed consent and preference data with audit trails | Highly regulated industries, GDPR-focused implementations | Strong for compliance but adds overhead to data operations |
Microservices Data Model | Different aspects of data distributed across specialized services | Modern cloud architecture, large scale operations | Scalable and flexible but requires robust integration and governance |
Data Schema Implementation across ESPsβ
How Different Email Platforms Organize Your Data
Salesforce Marketing Cloud
Think of it like a system of connected spreadsheets:
- Data Extensions: Custom spreadsheets where you store different types of information
- Shared Data Extensions: Spreadsheets that multiple teams can access
- Synchronized Data Extensions: Spreadsheets that automatically update from your other business systems
- Contact Builder: A visual tool where you can see how all your customer information connects
- Query Activities: Ways to sort, filter, and reorganize your information
Adobe Campaign
Organized like a detailed blueprint system:
- Schemas: Blueprints that define exactly how each type of information should be structured
- Recipient Schema: The main blueprint for subscriber information
- Schema Extensions: Ways to add custom information without changing the original blueprints
- Workflows: Tools that help you move, clean, and transform your data
Mailchimp
Organized more like an address book with labels:
- Audience: Your main contact list with basic and custom fields
- Tags: Labels you can attach to subscribers (like sticky notes)
- Segments: Filtered views of your audience based on specific criteria
- Customer Journeys: Sequences of emails triggered by specific actions
- E-commerce Data: Special section for store and purchase information
HubSpot
Structured like a business directory:
- Objects: Different categories like Contacts, Companies, and Deals
- Properties: Specific pieces of information within each category
- Associations: Connections showing how contacts relate to companies and deals
- Lists: Ways to group contacts based on criteria
- Timeline: A chronological record of everything that happens
Iterable
Structured like a flexible digital profile system:
- User Profiles: Digital cards that can hold any information about your customers
- Events: Timeline of everything a user does
- Collections: Lists of related information (like all purchases)
- Catalog: Library of products and content you can reference in emails
Each platform organizes data differently, but they all aim to help you store customer information, track behaviors, and use that data to send more relevant emails.
Data Schema Migration and Managementβ
- Schema Planning
- Migration Strategies
- Data Governance
- Performance Optimization
Planning Your Data Schema
Key Steps in Schema Design:
- Inventory Data Requirements
- Identify all necessary subscriber attributes (demographic, behavioral, preferential)
- Document data types and validation requirements
- Map data sources and integration points
- Consider future data needs to build flexibility
- Map Business Processes
- Document email marketing workflows and automation requirements
- Identify segmentation and personalization needs
- Consider reporting and analytics requirements
- Map customer journey touchpoints and data needs
- Design Entity Relationships
- Identify core entities (subscribers, campaigns, content, etc.)
- Define relationships between entities
- Determine normalization level based on platform capabilities
- Plan for proper indexing and query optimization
- Plan for Growth and Scale
- Estimate data volume and growth rate
- Consider performance implications of schema design
- Plan for archiving and data lifecycle management
- Build in flexibility for future attribute additions
Documentation Essentials:
- Data dictionary defining all fields and their properties
- Entity relationship diagrams
- Data flow diagrams showing integration points
- Field mapping documents for migrations and integrations
- Access control and data governance policies
Migrating Between Email Platforms
Migration Approach Options:
- Big Bang Migration
- Approach: Complete cutover from old to new system at once
- Pros: Faster completion, clear transition point, less maintenance of parallel systems
- Cons: Higher risk, more complex planning, potential for service disruption
- Best for: Smaller email programs, less complex data models, tight deadlines
- Phased Migration
- Approach: Move data and functionality in planned stages
- Pros: Lower risk, ability to test and validate each phase, smoother transition
- Cons: Longer timeline, need to maintain multiple systems, more complex integration
- Best for: Larger programs, complex data models, business-critical email operations
- Parallel Running
- Approach: Run both systems simultaneously for a period, gradually shifting traffic
- Pros: Lowest risk, easy rollback capability, gradual validation
- Cons: Most resource-intensive, potential for duplication/sync issues
- Best for: Mission-critical programs, complex integrations, high-volume senders
Key Migration Steps:
- Data Mapping: Create detailed field mappings between source and target platforms
- Data Cleansing: Clean and normalize data before migration
- Data Transformation: Convert data formats to match the target schema
- Test Migration: Perform test migrations with sample data
- Validation Process: Verify data integrity after migration
- Subscription Status Management: Carefully preserve opt-in status and preferences
- Historical Data Strategy: Decide how to handle historical engagement data
- Automation Rebuilding: Recreate workflows and automations in the new system
- Integration Reconfiguration: Update all system integrations
- Post-Migration Monitoring: Watch for issues after migration completion
Data Governance for Email Marketing
Key Governance Elements:
- Data Quality Management
- Establish data quality standards and metrics
- Implement validation rules and data cleansing processes
- Create procedures for handling incomplete or invalid data
- Schedule regular data audits and cleanup
- Data Access Controls
- Define role-based access permissions
- Document who can view, edit, or export different data types
- Implement field-level security for sensitive information
- Create audit trails for data access and changes
- Data Retention Policies
- Define how long different data types should be retained
- Establish archiving procedures for historical data
- Create processes for secure data deletion
- Ensure compliance with regulatory requirements
- Metadata Management
- Maintain up-to-date data dictionaries
- Document data sources and transformation processes
- Track data lineage (where data originated and how it's been modified)
- Define standards for naming conventions and documentation
Governance Roles and Responsibilities:
- Data Stewards: Subject matter experts responsible for data quality in their domain
- Data Custodians: Technical staff responsible for data storage and security
- Data Governance Committee: Cross-functional team overseeing data policies
- Compliance Officer: Ensures data handling meets regulatory requirements
- End Users: Marketing staff who use the data for campaigns
Compliance Considerations:
- Documentation of consent collection and management
- Processes for handling data subject access requests
- Privacy impact assessments for new data uses
- Data processing documentation for regulatory compliance
- Regular compliance audits and remediation
Optimizing Data Schema Performance
Performance Challenges in Email Marketing Data:
- High volume of engagement data (opens, clicks) accumulating rapidly
- Complex queries for segmentation and personalization
- Real-time data needs for triggered emails
- Large subscriber datasets in enterprise marketing programs
- Heavy reporting and analytics requirements
Schema Optimization Techniques:
- Indexing Strategy
- Create indexes on frequently queried fields
- Use composite indexes for common query combinations
- Avoid over-indexing as it impacts write performance
- Regularly review and maintain indexes based on query patterns
- Data Partitioning
- Partition large tables by date ranges for historical data
- Consider horizontal partitioning for very large subscriber bases
- Implement archiving strategies for older engagement data
- Use materialized views for common reporting queries
- Query Optimization
- Optimize segmentation queries to use indexes effectively
- Pre-calculate common segments rather than running complex queries repeatedly
- Use query hints where supported by the ESP
- Monitor and tune slow-running queries
- Schema Structure
- Use appropriate data types to minimize storage requirements
- Consider denormalization for read-heavy operations
- Create summary tables for analytical queries
- Implement efficient hierarchical data structures for nested data
Platform-Specific Optimizations:
- Salesforce Marketing Cloud: Optimize SQL queries in Query Activities, use appropriate Retention Policies on Data Extensions
- Adobe Campaign: Utilize appropriate indexing in XML schema definitions, optimize workflow temporary tables
- HubSpot: Use calculated properties for frequently used computations, optimize list criteria
- Mailchimp: Efficiently use merge fields and avoid excessive custom fields
- Iterable: Structure JSON user profiles efficiently, use event filters appropriately
Compliance and Privacy Considerationsβ
Technical Implementation of Privacy Requirements
Organizing Data with Privacy in Mind
Keeping Track of Permission and Consent
Your data system needs to record:
- Specific Permissions: What exactly people have agreed to receive
- Where Consent Came From: Which form or page someone signed up on
- When Consent Happened: The exact date and time
- Consent Evidence: A record of what the sign-up form said
- Proof of Action: Details that help prove the person really opted in
- Terms Version: Which version of your privacy policy was in effect
- Confirmation Status: Whether they confirmed their subscription via a follow-up email
- Communication Preferences: Different options for different types of messages
Supporting Customer Rights
Your data needs to be organized so you can:
- Provide All Data: Give people a complete copy of their information when requested
- Correct Information: Update incorrect information and track those changes
- Delete Information: Remove someone's data without breaking your system
- Limit Processing: Stop using someone's data in certain ways while keeping their record
- Export in Standard Format: Provide data in a format that works with other systems
- Record Objections: Track when someone objects to certain uses of their data
Building in Protection
Your data system should also include:
- Data Minimization: Only collecting information you actually need
- Automatic Cleanup: Fields that help you identify when data should be deleted
- Usage Controls: Ways to restrict how certain data can be used
- Sensitivity Labels: Marking which information requires special protection
- Usage Tracking: Records of how and where you've used people's data
- Location Tracking: Information about where data is stored globally
- Security Indicators: Notes about which information is encrypted and how
This approach not only helps with legal compliance but also builds trust with your subscribers who are increasingly concerned about how their data is used.
Privacy-Friendly Data Organization
Data Schema Requirements for Privacy Compliance
Consent Management Schema Elements
- Consent Fields: Structured fields capturing specific permissions (email marketing, profiling, third-party sharing)
- Consent Source: Where and how consent was obtained (form URL, import, verbal)
- Consent Timestamp: When consent was granted or updated
- Consent Evidence: Record of exact language/form used for consent collection
- IP Address: For evidence of opt-in (with appropriate retention policy)
- Consent Version: Which version of terms/privacy policy was accepted
- Double Opt-in Verification: Fields tracking confirmation status and timing
- Granular Permission Structure: Separate flags for different communication types and channels
Data Subject Rights Implementation
- Right to Access: Schema structure allowing complete profile extraction
- Right to Correction: Update history tracking and audit fields
- Right to Erasure: Anonymization or deletion capability while maintaining referential integrity
- Right to Restriction: Processing limitation flags and enforcement fields
- Data Portability: Schema structure supporting standardized data export formats
- Right to Object: Preference management and objection tracking fields
Technical Safeguards
- Data Minimization: Schema designed to collect only necessary data
- Storage Limitation: Date fields and triggers for automated data lifecycle management
- Processing Limitation Flags: Fields controlling how data can be used in automations
- Data Classification: Fields identifying sensitive data categories
- Data Usage Fields: Tracking how and where data has been used
- Cross-Border Transfer Tracking: Fields documenting data location and movement
- Encryption Indicators: Fields noting which elements are encrypted and how
Best Practices for Data Schema Designβ
Making Your Email Marketing Data Work Better
Smart Data Organization Strategies
- Balance Organization and Speed
- Organize information to avoid duplication while keeping it easy to access
- Sometimes duplicate strategic information to make common tasks faster
- Pre-calculate information you use frequently rather than calculating it every time
- Create shortcuts (indexes) to information you search for often
- Use Good Identification Systems
- Use unique IDs that don't follow simple patterns for better security
- Keep the same ID for each person across all your systems
- Create special identification methods for complex relationships
- Plan for connecting customer information across different channels
- Prepare for Growth
- Choose efficient ways to store information to save space
- Plan how to organize large amounts of information before you have it
- Create strategies for archiving and removing old data
- Test how your system performs with the amount of data you expect to have in the future
- Make Your System Adaptable
- Build your data system so you can add new types of information easily
- Consider flexible storage for information that varies a lot between customers
- Design ways to extend your system without changing the core structure
- Keep track of how your data organization changes over time
Practical Recommendations
- Setting Up Fields Correctly
- Store each type of information in the right format (numbers as numbers, not text)
- Use consistent date formats and account for time zones
- Decide how to handle missing information consistently
- Use dropdown lists for fields with a fixed set of possible values
- Document rules for what makes information valid
- Connecting With Other Systems
- Design your system knowing there may be limits on data transfers
- Create efficient ways to sync only information that has changed
- Use temporary storage when moving data between systems
- Decide which information needs real-time updates and which can wait
- Managing Subscriptions Properly
- Track detailed subscription statuses, not just "subscribed" or "unsubscribed"
- Keep a history of subscription changes for compliance reasons
- Design systems that handle preferences for different communication channels
- Store evidence of consent in accordance with privacy laws
- Making Everything Faster
- Identify which information you access most often and optimize for that
- Create shortcuts (indexes) based on your most common searches
- Consider special storage methods for analytical data
- Design your system to process multiple things at once when possible
Summaryβ
The way you organize your email marketing data is like creating a blueprint for a house β it determines how everything fits together and functions. Here are the key takeaways about data organization for email marketing:
- Essential Information Categories: A good system organizes subscriber details, campaign information, email content, and engagement records in a way that shows how they're all connected
- Different Approaches: You can organize your data simply (like one big spreadsheet) or in more sophisticated ways (like interconnected specialized tables) depending on your needs
- Platform Differences: Each email marketing platform has its own way of organizing data, from Salesforce's interconnected data extensions to Mailchimp's audience-and-tags approach
- Performance Matters: How you organize data affects how quickly you can send emails, run reports, and create segments
- Privacy Requirements: Modern data organization needs to track permissions, consent, and preferences in detail to stay compliant with privacy laws
- Connected Systems: Your data structure needs to support connections with other business systems like your website or CRM
- Good Housekeeping: Well-organized data includes plans for who can access what, how quality is maintained, and when old data should be archived or deleted
When your email marketing data is properly organized, you can create more personalized campaigns, better understand customer behavior, automate more effectively, and make data-driven decisions while maintaining customer trust through proper data handling.
Additional Resourcesβ
- The Salesforce Marketing Cloud Data Model - Official documentation on SFMC data structures
- Adobe Campaign Data Schema Reference - Comprehensive guide to Adobe Campaign schemas
- Data Management Best Practices for Email Marketing - Litmus guide on email data management
- GDPR and Email Marketing - Guide to data privacy compliance in email marketing