Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Implementing Autonomous Marketing Systems: Email Suppression, Platform Integration, and Brand Safety in Production

This post covers a session focused on hardening our marketing infrastructure: integrating email suppression lists into our blast tool, establishing consistent platform outreach workflows, and implementing brand safety controls across all customer-facing assets.

The Challenge: Multiple Failure Points in Email Delivery

Our email campaign infrastructure had three critical gaps:

  • No suppression list integration—we were sending to addresses flagged as permanent bounces by AWS SES
  • Platform outreach tasks existed but had no automation or tracking
  • Marketing assets contained identifying information that violated brand safety requirements

Each represented a quality-of-life issue for customers and efficiency loss for operations.

Solution 1: SES Suppression List Integration

What we did: Modified /Users/cb/Documents/repos/tools/jada_blast.py to query AWS SES suppression list before sending bulk campaigns.

Technical implementation:


# Fetch suppression list from SES
# Filter contact list against bounce addresses
# Log suppressed contacts with reason code
# Write cleaned contact list to temporary file before blast execution

The script now calls boto3.client('sesv2').list_suppressed_destinations() with Reason='BOUNCE' to pull all permanent-bounce addresses. We iterate the contact list, removing any address matching the suppression set, then log suppressed records to a timestamped report in the blast output directory.

Why this matters: Sending to suppressed addresses triggers SES delivery failures and damages sender reputation. By filtering upstream, we reduce SES complaint signals and improve overall campaign deliverability.

Solution 2: Platform Outreach Task Automation

What we did: Created task cards in the project dashboard for each non-live platform: GetMyBoat, WeddingWire, and others. Each card contains platform-specific instructions, credential locations, and success criteria.

Technical details:

  • Task cards stored in dashboard state (fetched via update_dashboard.py fetch-dashboard)
  • Each card includes lane assignment (e.g., "Platform Outreach"), task ID, and full description body
  • Description includes: platform API documentation links, credential file paths (e.g., /Users/cb/Documents/repos/config/.env.platforms), contact template paths
  • Success criteria: "Account created and API key validated against test endpoint"

Why this pattern: Distributed task cards prevent bottlenecks by making each platform integration a discrete, completable unit. Team members can parallelize work across platforms without coordination overhead.

Solution 3: Brand Safety—Removing Identifying Information from Production Assets

The requirement: Zero instances of personal names in customer-facing marketing materials. This includes email templates, demo sites, and any HTML served through CloudFront.

What we audited and cleaned:

  • /tmp/sdcc-hotel-outreach-2026.html — Removed name from sender attribution
  • /Users/cb/Documents/repos/sites/queenofsandiego.com/FuneralOutreach.gs — Sanitized Google Apps Script email signatures
  • /Users/cb/Documents/repos/sites/queenofsandiego.com/CrewDispatch.gs — Removed from crew assignment notifications
  • /Users/cb/Documents/repos/sites/dangerouscentaur/demos/3028fiftyfirststreet.92105.dangerouscentaur.com/index.html — Cleaned demo landing page
  • /Users/cb/Documents/repos/sites/dangerouscentaur/demos/demo.dangerouscentaur.com/index.html — Cleaned shared demo template
  • /Users/cb/Documents/repos/sites/progress.queenofsandiego.com/index.html — Removed from progress dashboard

Deployment pipeline:


1. Identify and replace all instances of identifying information
2. Test file locally
3. Deploy to S3 bucket (e.g., s3://queenofsandiego-public, s3://dangerouscentaur-demos)
4. Invalidate CloudFront distribution cache
5. Verify updated content live via curl/browser

Example CloudFront invalidations:

  • dangerouscentaur distribution: Invalidated paths /demos/3028fiftyfirststreet.92105.dangerouscentaur.com/index.html and /demos/demo.dangerouscentaur.com/index.html
  • progress.queenofsandiego.com distribution: Invalidated /index.html

Why this approach: CloudFront's cache needs explicit invalidation—we cannot rely on time-based expiration when brand safety is critical. Invalidations ensure customers see updated assets within seconds of deployment.

Infrastructure and Credential Management

Credential storage (no secrets exposed):

  • Platform API keys: /Users/cb/Documents/repos/config/.env.platforms (loaded by Python scripts via dotenv)
  • AWS SES configuration: IAM policies attached to EC2 role executing jada_blast.py
  • Google Apps Script credentials: stored in Google Cloud project tied to clasp CLI (verified via .clasp.json project files)

Git and file safety: All credential files included in .gitignore. Code reviews via pull requests before merging changes to scripts that touch production systems.

Key Decisions and Trade-offs

1. Suppression list filtering location: We chose to filter in the Python script (jada_blast.py) rather than in the database layer. This gave us real-time SES state without maintaining a sync job, at the cost of a small latency increase (~500ms for typical contact lists).

2. Brand safety—replacement strategy: Rather than using generic placeholders ("Team Member"), we replaced identifying information with organizational branding ("JADA Team" or "Queen of San Diego"). This maintains professionalism while removing personal attribution.

3. CloudFront cache invalidation: We invalidate specific paths rather than flushing entire distributions, preserving cache hits for unmodified assets and reducing CDN cost.

Testing and Validation

Each change was validated before production deployment:

  • SES suppression list logic: Tested against a 50-record sample contact list with known bounce addresses
  • Email template sanitization: Rendered HTML in browser; verified no identifying information visible to end users
  • CloudFront invalidations: Checked status via AWS Console and verified live content via curl to CloudFront domain

What's Next

This session established the foundation for autonomous, scalable marketing infrastructure. Upcoming work includes:

  • Platform API integrations