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:
- Download preview HTML from S3 bucket (exact bucket path not disclosed for security)
- Search for name references in inline email markup
- Replace attribution lines with generic team language
- Verify embedded images (boat photography URLs) remained accessible
- Re-upload cleaned HTML to S3
- 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 workflowCrewDispatch.gs— Crew scheduling and notification systemCrewScheduler.gs— Calendar-based task generationWorshipRsvp.gsandViatorApiFollowUp.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:
- Located name references in HTML comments, meta tags, and footer text
- Replaced with generic team/company branding
- Re-uploaded modified files to S3 origins
- 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/) clasptool authenticates via service account credentials (stored in.clasp.jsonproject 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