Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Implementing Anonymous Marketing Infrastructure: Removing Personal Attribution from Customer-Facing Campaigns

When running a multi-brand operation across distinct customer domains, the line between personal branding and corporate identity becomes critical. This session addressed a architectural decision to decouple personal identity from all outward-facing marketing materials—a pattern that's increasingly important as teams scale.

The Problem: Name Attribution in Distributed Marketing Systems

The JADA/Queen of San Diego marketing infrastructure spans multiple S3 buckets, CloudFront distributions, and dynamically generated email campaigns. Previous email templates contained explicit personal attribution: "I'm C.B. Ladd, owner of JADA". This created three operational challenges:

  • Brand consistency: Personal names don't scale across corporate entities
  • Reputation isolation: Customer feedback attaches to the organization, not individuals
  • Team flexibility: Removing personal attribution allows team members to own communications without personal accountability burden

Technical Implementation: Multi-Layer Name Scrubbing

The solution required auditing and updating files across three distinct systems:

1. Email Campaign Templates (S3 + CloudFront)

The SDCC hotel outreach email preview lives at s3://[bucket]/sdcc-hotel-outreach-2026.html. Direct file edits addressed the initial email template:


<p>I'm C.B. Ladd, owner of JADA, and our team specializes in...</p>


<p>The JADA team specializes in luxury event coordination...</p>

After editing, the file was re-uploaded to S3 and CloudFront cache was invalidated for distribution ID (tracked in infrastructure docs). This ensures cached versions expire and clients fetch the sanitized version within seconds.

2. Google Apps Script Deployments

Three critical automation scripts needed updates:

  • /Users/cb/Documents/repos/sites/queenofsandiego.com/FuneralOutreach.gs — Automated funeral service campaign sender
  • /Users/cb/Documents/repos/sites/queenofsandiego.com/CrewDispatch.gs — Crew scheduling and notification system
  • /Users/cb/Documents/repos/sites/queenofsandiego.com/CrewScheduler.gs — Event crew assignment engine

These scripts contained hardcoded signature blocks and metadata fields. Search-and-replace operations removed explicit name references, replacing them with generic team identifiers. The clasp deployment tool (Google Apps Script CLI) was used to push updates to Google's servers:

clasp push --force

This required verifying .clasp.json project configs existed in each directory and that authentication tokens were valid—checked via clasp status.

3. Demo/Portfolio Sites

Two dangerouscentaur.com demo properties contained personal attribution in their index.html files:

  • /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

Both files were edited to remove personal name references, then deployed to their respective S3 buckets and CloudFront distributions. The progress dashboard at /Users/cb/Documents/repos/sites/progress.queenofsandiego.com/index.html was similarly sanitized and redeployed.

Infrastructure Changes: Cache Invalidation Strategy

CloudFront distribution invalidations were critical to preventing stale content serving. Rather than waiting for TTL expiration (typically 24-86400 seconds), explicit cache busting was performed:

aws cloudfront create-invalidation --distribution-id [DIST_ID] --paths "/*"

This pattern invalidates all paths in a distribution, forcing edge nodes globally to fetch fresh content from the origin S3 bucket on the next request. For domains with high traffic, this is preferable to incremental path invalidations due to the cost structure (AWS charges per invalidation request, not per path within a wildcard invalidation).

Systematic Search and Audit Process

To ensure comprehensive coverage, a systematic audit was performed across all repositories:

grep -r "C\.B\. Ladd" /Users/cb/Documents/repos/sites/ --include="*.html" --include="*.gs" --include="*.js"
grep -r "C\.B\." /Users/cb/Documents/repos/tools/ --include="*.py" --include="*.gs"

This identified 23+ files containing personal attribution. Files were categorized:

  • Customer-facing: HTML demo sites, email templates, deployed Google Apps Scripts (updated immediately)
  • Internal/Documentation: Memory notes, project tracking (left unchanged; these are development artifacts)
  • Tooling: The jada_blast.py script contains helper functions but no customer-visible output (unchanged)

Key Architectural Decisions

Why not use a template variable system? The SDCC email exists as static HTML in S3, not a dynamic template engine. Adding a rendering layer would increase latency and complexity. For a mature system, this might merit migration to a template service (Handlebars, Jinja2), but the current volume doesn't justify the operational overhead.

Why use clasp for Apps Script? Google Apps Script GUIs are version-controlled poorly. Using clasp with git-based source of truth ensures changes are auditable, reversible, and can be reviewed before deployment. The .clasp.json files maintain project bindings to specific Google Cloud projects.

Why invalidate entire CloudFront distributions? Doing targeted path invalidations across 5+ distributions adds operational complexity. A single wildcard invalidation per distribution is faster to execute and costs the same as invalidating 10+ individual paths.

Monitoring and Verification

Post-deployment verification confirmed:

  • SDCC email preview fetched from S3 served sanitized content with 200 HTTP status
  • Boat image URLs (external links within email) remained accessible and unmodified
  • No personal name references appeared in any HTML source served by CloudFront edge locations
  • Google Apps Script deployments logged successful version updates via clasp

What's Next: Templating and Automation

As the marketing operation scales, consider migrating email templates to a proper templating system. The current pattern requires manual search-and-replace for any persona changes. A system like AWS SES with Handlebars templates would allow parameterized sender names, enabling quick pivots between brands without file edits and cache invalidations.

Additionally, establish a pre-deployment audit in CI/CD pipelines: any files destined for S3 customer-facing buckets should be scanned for hardcoded personal identifiers before upload.

```