```html

Implementing Brand Anonymity in Email Campaign Infrastructure: A Multi-System Refactor

This post details a significant architectural decision and its implementation across JADA's distributed marketing infrastructure: removing founder identification from all customer-facing communications and replacing it with team-centric branding.

The Directive: Why We Removed Personal Names from Public Marketing

After reviewing customer feedback and competitive positioning, we made a strategic decision: founder names would no longer appear in outbound marketing materials. The rationale was straightforward—focus attribution on the team and product (JADA, Queen of San Diego) rather than individual personalities. This decision required changes across multiple systems, not just email templates.

The scope included:

  • Email campaign HTML templates and preview artifacts in S3
  • Google Apps Script deployment files (GAS) in production
  • Demo/proof-of-concept sites served via CloudFront
  • Customer-facing dashboard applications
  • Outreach and contact management scripts

Technical Implementation: Finding and Replacing Across Distributed Systems

Phase 1: Inventory and Search

We started with a comprehensive audit of all customer-facing code paths. The repository structure spans multiple domains:

/Users/cb/Documents/repos/
├── sites/
│   ├── queenofsandiego.com/
│   │   ├── FuneralOutreach.gs
│   │   ├── CrewDispatch.gs
│   │   ├── CrewScheduler.gs
│   │   └── rady-shell-events/apps-script-replacement/
│   │       ├── WorshipRsvp.gs
│   │       └── ViatorApiFollowUp.gs
│   ├── dangerouscentaur/demos/
│   │   ├── 3028fiftyfirststreet.92105.dangerouscentaur.com/
│   │   └── demo.dangerouscentaur.com/
│   └── progress.queenofsandiego.com/
└── tools/
    └── jada_blast.py

We performed recursive searches across all these paths for variations of the founder's name (full name and initials). The search wasn't trivial—names appeared in:

  • GAS script comment blocks and string literals
  • HTML email templates with inline styling
  • Demo site footer and metadata
  • Dashboard progress indicators
  • Blast tool configuration comments

Phase 2: Email Campaign Artifacts

SDCC (San Diego Comic-Con) hotel outreach emails were staged in S3. The workflow was:

  1. Download preview HTML from S3 bucket (exact bucket path not disclosed for security)
  2. Search for name references in inline email markup
  3. Replace attribution lines with generic team language
  4. Verify embedded images (boat photography URLs) remained accessible
  5. Re-upload cleaned HTML to S3
  6. Invalidate CloudFront distribution cache

The email contained static image references that required separate verification. We confirmed all image URLs returned HTTP 200 responses before re-deployment to ensure the campaign wouldn't have broken media links.

Phase 3: Google Apps Script Deployments

Four GAS files required updates in the queenofsandiego.com domain project:

  • FuneralOutreach.gs — Email generation for funeral services workflow
  • CrewDispatch.gs — Crew scheduling and notification system
  • CrewScheduler.gs — Calendar-based task generation
  • WorshipRsvp.gs and ViatorApiFollowUp.gs — Event-specific handlers

Each file was manually reviewed for name references in email body templates, function documentation, and error messages. GAS files are deployed via clasp (Google's command-line Apps Script tool), which requires authentication credentials. After local modifications, changes would be pushed using:

clasp push --force

However, the actual deployment step was deferred pending verification of authentication state in the clasp project config files (.clasp.json).

Phase 4: Demo Sites and Public-Facing Web Content

Two demo sites under the dangerouscentaur domain had founder references in HTML:

  • /demos/3028fiftyfirststreet.92105.dangerouscentaur.com/index.html
  • /demos/demo.dangerouscentaur.com/index.html

Both are served via CloudFront distributions (distribution IDs not disclosed). Changes made:

  1. Located name references in HTML comments, meta tags, and footer text
  2. Replaced with generic team/company branding
  3. Re-uploaded modified files to S3 origins
  4. Invalidated CloudFront cache using distribution invalidation API for both distributions

We also updated the progress dashboard at progress.queenofsandiego.com/index.html, which displays task and workflow status to internal stakeholders.

Infrastructure and Deployment Architecture

S3 + CloudFront Pattern

All static assets (HTML templates, demo sites, dashboards) follow a standard pattern:

  • Source files stored in S3 buckets with versioning enabled
  • CloudFront distributions configured as origins for caching and edge delivery
  • Invalidation API calls after updates to purge cache and serve fresh content
  • HTTPS enforcement via CloudFront SSL/TLS certificates

Google Apps Script Deployment Pipeline

GAS files are managed via a git-based workflow:

  • Source files stored in the repo at specific paths (e.g., /sites/queenofsandiego.com/)
  • clasp tool authenticates via service account credentials (stored in .clasp.json project config)
  • Push to Apps Script project triggers automatic deployment to Google Sheets/Forms triggers
  • Live scripts execute within Google Workspace containers (Sheets, Gmail, Forms)

Multi-Tool Contact and Campaign Management

The blast tool at /tools/jada_blast.py orchestrates outbound campaigns. It reads:

  • Contact lists from CSV or database exports
  • Email templates (now cleaned of personal references)
  • Platform credentials (stored separately in repos.env)
  • AWS SES suppression lists for bounce management

Before sending campaigns, the tool queries the SES suppression list to filter bounced addresses, preventing reputation damage.

Key Decisions and Trade-offs

Why Not Use Find-Replace Globally?

We avoided automated find-and-replace across the entire repo. Reasons:

  • Names might appear in legitimate internal documentation or code comments meant for developers
  • Manual review