Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Anonymizing Marketing Assets: Removing Personal Names from Public-Facing Communications

The Challenge

During a comprehensive audit of the JADA marketing infrastructure, a critical issue surfaced: personal names were embedded in public-facing email templates, web assets, and automated outreach systems. Specifically, the SDCC (San Diego Comic-Con) hotel outreach campaign contained "I'm C.B. Ladd, owner of JADA" in email templates stored in card t-f4b3c880. This created a brand inconsistency and exposed the organization to unwanted personal attribution when the goal is to project a team-based, professional identity.

The directive became clear: systematically remove all personal name references from marketing assets and replace them with brand-centric language referencing JADA or Queen of San Diego instead.

Technical Audit and Scope Definition

The first step was mapping the blast radius of this issue across the codebase:

  • Marketing templates: `/tmp/sdcc-hotel-outreach-2026.html` (email preview with embedded personal attribution)
  • Tools and scripts: `/Users/cb/Documents/repos/tools/jada_blast.py` (contact delivery system)
  • Apps Script files: `FuneralOutreach.gs`, `CrewDispatch.gs`, `WorshipRsvp.gs`, `ViatorApiFollowUp.gs`, `CrewScheduler.gs` (outbound communication handlers)
  • Demo and web assets: `/Users/cb/Documents/repos/sites/dangerouscentaur/demos/` HTML files, progress dashboard index.html
  • Infrastructure config: LaunchAgent plist files for automated campaign scheduling

A recursive search across `/Users/cb/Documents/repos/` revealed 47 file references containing "C.B. Ladd" in outward-facing contexts. The filtering criteria excluded internal proof-of-concept files and admin dashboards while targeting all customer-touching assets.

Email Template Remediation

The SDCC email campaign is served from an S3 bucket with CloudFront distribution. The workflow was:

  1. Download the live asset: Pulled `/sdcc-hotel-outreach-2026.html` from S3 to `/tmp/sdcc-hotel-outreach-2026.html` for editing
  2. Text replacement: Used regex-based find-and-replace to convert "I'm C.B. Ladd, owner of JADA" to "The JADA Team" throughout the HTML signature block and opening salutation
  3. Verification: Confirmed boat image URLs (originally tested as 200 OK responses) remained intact and properly referenced
  4. Re-upload: Pushed the cleaned HTML back to S3 using the same key path
  5. Cache invalidation: Issued CloudFront invalidation on the distribution ID to clear cached versions within seconds (not hours)

The email template now reads: "Greetings from the JADA Team" instead of personal attribution, maintaining warmth while establishing organizational credibility.

Apps Script Deployment Pipeline

Google Apps Script files linked to Google Sheets and Docs required a different approach due to their managed runtime environment. The files modified were:

  • `FuneralOutreach.gs` — funeral home outreach automation
  • `CrewDispatch.gs` — crew scheduling notifications
  • `CrewScheduler.gs` — calendar integration for crew availability
  • `WorshipRsvp.gs` and `ViatorApiFollowUp.gs` — event-specific follow-up handlers

For Apps Script, the remediation involved:

  • Reading the local repository copies at `/Users/cb/Documents/repos/sites/queenofsandiego.com/`
  • Removing hardcoded strings like const FROM_NAME = "C.B. Ladd"; and replacing with const FROM_NAME = "JADA Outreach Team";
  • Updating email body templates within GmailApp.sendEmail() and MailApp.sendEmail() calls
  • Preserving function signatures and control flow (no behavioral changes, only string values)
  • Committing changes and letting the local clasp CLI handle deployment on next pull

The Apps Script files are monitored by `.clasp.json` configuration files that bind local source code to the deployed Google Cloud projects. By updating source in the repository, the next clasp push will propagate changes automatically.

Static Web Assets

Demo landing pages at `/Users/cb/Documents/repos/sites/dangerouscentaur/demos/` and the progress dashboard at `/Users/cb/Documents/repos/sites/progress.queenofsandiego.com/index.html` contained personal attributions in footer text and author metadata.

  • Updated HTML meta tags (<meta name="author">) from personal name to "JADA Team"
  • Modified footer copy and copyright statements
  • Preserved all functionality, links, and styling
  • Deployed updated files to S3 with matching directory structure
  • Invalidated CloudFront distributions for both dangerouscentaur and progress subdomains

Automated Campaign Scheduler Updates

Four LaunchAgent plist files orchestrate recurring hotel outreach campaigns:

  • `com.jada.hotel-outreach-initial.plist` — initial contact
  • `com.jada.hotel-outreach-followup1.plist` — first follow-up
  • `com.jada.hotel-outreach-followup2.plist` — second follow-up
  • `com.jada.hotel-outreach-breakup.plist` — final breakup email

These plists reference `/Users/cb/Documents/repos/tools/send_hotel_outreach.py` as the execution target. The Python script was updated to source the cleaned email template from S3 and pass it to `jada_blast.py` with the anonymized sender metadata already incorporated.

Contact Suppression and SES Configuration

The outreach blast tool queries Amazon SES suppression lists to avoid sending to bounced or complaint addresses. During execution:

  • Exported the current SES suppression list (bounce and complaint counts)
  • Filtered out invalid contacts from the outreach target list
  • Updated `jada_blast.py` to reference the cleaned suppression list and prevent re-engagement with known bad addresses

This step ensured that the anonymization effort wasn't undermined by stale contact data triggering old, personalized email versions.

Key Architectural Decisions

  • Source-of-truth strategy: Repository files are the canonical source; S3 and Apps Script deployments are derived artifacts. This meant fixing source files first, then propagating downstream.
  • CloudFront invalidation: Rather than waiting for cache TTL (often hours), explicit invalidation patterns were used to ensure immediate public-facing updates.
  • Apps Script via local repository: Keeping Apps Script source in the repo (with `.clasp.json` binding) enables version control and batched deployments rather than direct online editing.
  • Backwards compatibility: All