Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Implementing Anonymous Brand Identity in Marketing Automation: A Case Study in Identity Abstraction

When scaling marketing operations, founder attribution in customer-facing communications can create unintended friction. This article documents how we refactored email campaign infrastructure to abstract personal identity while maintaining brand consistency across JADA's multi-platform outreach system.

The Challenge: Decoupling Founder Identity from Brand Voice

Our email templates and automation scripts contained explicit founder attribution ("I'm C.B. Ladd, owner of JADA") in customer-facing communications. While authentic, this approach created operational friction that needed to be addressed systematically across three layers:

  • Email templates in S3 and Google Apps Script projects
  • Blast automation scripts that reference sender identity
  • Web properties and demo sites with embedded marketing copy

The solution required a comprehensive audit and refactor without disrupting live campaigns or breaking dependencies.

Step 1: Centralized Template Audit and Inventory

We began by identifying all customer-facing email assets:

  • /Users/cb/Documents/repos/tools/jada_blast.py — Primary blast automation script
  • /tmp/sdcc-hotel-outreach-2026.html — San Diego Comic-Con hotel outreach campaign
  • /Users/cb/Documents/repos/sites/queenofsandiego.com/ — Multiple Google Apps Script projects (FuneralOutreach.gs, CrewDispatch.gs, CrewScheduler.gs, ViatorApiFollowUp.gs, WorshipRsvp.gs)
  • /Users/cb/Documents/repos/sites/dangerouscentaur/ — Demo properties with embedded marketing language
  • /Users/cb/Documents/repos/sites/progress.queenofsandiego.com/index.html — Public progress dashboard

Each file was systematically scanned for personal name references and founder attribution language.

Step 2: Email Template Refactoring

The SDCC hotel outreach campaign served as the pilot. The template was updated to replace founder-centric language with team and product-focused messaging:

Original approach: "I'm C.B. Ladd, owner of JADA"

Refactored approach: "The JADA team" or "Queen of San Diego's outreach specialists"

The email HTML file at /tmp/sdcc-hotel-outreach-2026.html was updated and uploaded to the production S3 bucket with CloudFront cache invalidation. After verification that all embedded image URLs (boat photography) were returning 200 OK responses, we invalidated the CloudFront distribution to ensure immediate propagation of the cleaned template.

Step 3: Google Apps Script Refactoring

Several Google Apps Script projects contained hardcoded founder attribution in email templates and function documentation:

  • FuneralOutreach.gs — Updated sender identification in email bodies
  • CrewDispatch.gs — Refactored crew member communication templates
  • CrewScheduler.gs — Updated scheduling confirmation messages
  • ViatorApiFollowUp.gs — Modified Viator API integration email signatures
  • WorshipRsvp.gs — Updated RSVP confirmation messages

Each file was updated to remove personal attribution and replace with organizational identity. Since these are deployed via clasp (Google Apps Script CLI), changes are propagated to live spreadsheet-bound scripts immediately upon push.

Step 4: Web Property Audit and Remediation

Demo and public-facing websites required comprehensive scrubbing:

  • /Users/cb/Documents/repos/sites/dangerouscentaur/demos/3028fiftyfirststreet.92105.dangerouscentaur.com/index.html
  • /Users/cb/Documents/repos/sites/dangerouscentaur/demos/demo.dangerouscentaur.com/index.html
  • /Users/cb/Documents/repos/sites/progress.queenofsandiego.com/index.html

These files contained embedded marketing copy with founder attribution. All instances were replaced with generic team/brand language. Files were then deployed to their respective S3 buckets and CloudFront distributions were invalidated.

Step 5: Blast Script Architecture Updates

The jada_blast.py script required modifications to support dynamic sender identity abstraction:

# Before: Hardcoded founder attribution
SENDER_NAME = "C.B. Ladd, JADA Owner"

# After: Template-based configuration
SENDER_IDENTITY_MAP = {
    "jada_primary": "JADA Team",
    "queen_of_san_diego": "Queen of San Diego Outreach",
    "platform_blast": "Platform Partnerships Team"
}

The script was updated to accept a sender_identity parameter that maps to appropriate team designations based on the campaign type. This allows different outreach initiatives to use contextually appropriate team identities without embedding personal names.

Additionally, we implemented SES suppression list management to clean bounce data and verified platform credentials across multiple third-party integrations (GetMyBoat, WeddingWire, and others).

Step 6: Infrastructure and Deployment

All changes followed a consistent deployment pattern:

  1. Local file modification and testing
  2. S3 upload with versioning enabled
  3. CloudFront cache invalidation using distribution IDs (specific to each property)
  4. DNS verification via Route53 CNAME records (no changes required)
  5. Google Apps Script updates via clasp push for bound scripts

For the SES suppression list, we exported bounce records, cleaned contact data matching previous bounces, and re-imported cleaned lists to jada_blast.py's contact filtering logic.

Key Decisions and Rationale

Why abstraction instead of anonymization: We chose to replace personal attribution with meaningful team/brand language rather than generic "no-reply" messaging. This maintains authenticity and relationship quality while removing founder-specific attribution that could create external perception issues.

Why configuration-driven sender identity: Rather than hardcoding team names in multiple files, we implemented a mapping system in the blast script. This allows rapid identity updates across campaigns without code changes—future campaign adjustments can be made via configuration files.

Why immediate CloudFront invalidation: For customer-facing assets, we prioritized immediate propagation over bandwidth costs. Invalidations were executed synchronously after S3 updates to ensure no stale content was served.

What's Next

Future work includes:

  • Implementing identity abstraction patterns in emerging platform integrations (GetMyBoat, WeddingWire outreach)
  • Creating a centralized template repository with versioning and approval workflows
  • Building automated scanning for personal name references in marketing asset pipelines
  • Extending sender identity abstraction to SMS and social media campaigns

This refactoring demonstrates how infrastructure-aware developers can implement organizational policy changes across complex, distributed systems without breaking functionality—and why configuration-driven patterns make future policy adjustments faster and safer.