Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Implementing Anonymous Marketing Branding: Removing Personal Names from Customer-Facing Campaigns

During this development session, we implemented a critical branding directive across the JADA marketing infrastructure: removing all personal names from customer-facing content while maintaining brand identity through organization and team references. This post documents the technical approach, infrastructure changes, and deployment strategy used to enforce this policy systematically.

The Problem: Name Visibility in Marketing Assets

Initial discovery revealed that personal names—specifically "C.B. Ladd"—appeared in multiple customer-facing systems:

  • Email campaign templates in S3 (SDCC hotel outreach campaign)
  • Google Apps Script files controlling automated workflows
  • Demo websites and public-facing dashboards
  • Email blast tools and contact management systems

The directive was explicit: remove all personal identifiers from marketing touchpoints, replacing them with organizational branding (JADA, Queen of San Diego, team references).

Technical Implementation Strategy

Phase 1: Discovery and Inventory

We began with comprehensive file scanning to identify all occurrences of the name pattern across the repository structure:


# Search across multiple critical directories:
/Users/cb/Documents/repos/sites/ (website assets)
/Users/cb/Documents/repos/tools/ (automation scripts)
/Users/cb/Documents/repos/sites/queenofsandiego.com/ (Apps Script)
/Users/cb/Documents/repos/sites/dangerouscentaur/ (demo sites)

The scanning revealed name references in:

  • FuneralOutreach.gs and CrewDispatch.gs (Google Apps Script)
  • CrewScheduler.gs (scheduling automation)
  • HTML demo files at dangerouscentaur domains
  • Progress dashboard at progress.queenofsandiego.com
  • Email templates in S3 and local HTML files

Phase 2: Content Replacement and Rebranding

Rather than simple deletion, we replaced personal identifiers with contextual organizational language:

  • Email signatures: Changed "C.B. Ladd, owner of JADA" → organizational team references and JADA branding
  • Demo site copy: Removed personal bio references, replaced with "JADA team" or "Queen of San Diego team"
  • Apps Script comments: Stripped personal author attributions while preserving technical documentation
  • Dashboard content: Removed personal names from progress tracking UI copy

Phase 3: Infrastructure and Deployment

Content updates required coordinated deployment across multiple infrastructure components:

S3 and CloudFront Updates

The SDCC email template required updating in S3, followed by CloudFront cache invalidation to ensure customers received the updated content:

  • S3 bucket: s3://email-templates/ (SDCC campaign HTML)
  • CloudFront distribution: Updated distribution ID for dangerouscentaur sites
  • Invalidation pattern: /* to clear all cached versions
  • Propagation time: CloudFront edge caches updated within ~15 minutes

The invalidation approach was chosen over versioning to ensure all users received updated content immediately without requiring cache-busting parameters in marketing links.

Google Apps Script Deployment

Multiple Apps Script projects required updates but presented a complexity: the clasp authentication context. Rather than attempting remote deployment during this session, we updated source files locally:

  • /Users/cb/Documents/repos/sites/queenofsandiego.com/FuneralOutreach.gs
  • /Users/cb/Documents/repos/sites/queenofsandiego.com/CrewDispatch.gs
  • /Users/cb/Documents/repos/sites/queenofsandiego.com/rady-shell-events/apps-script-replacement/WorshipRsvp.gs
  • /Users/cb/Documents/repos/sites/queenofsandiego.com/rady-shell-events/apps-script-replacement/ViatorApiFollowUp.gs
  • /Users/cb/Documents/repos/sites/queenofsandiego.com/CrewScheduler.gs

These files will be pushed to Google Apps Script via clasp push during the next authenticated deployment phase, which occurs after project-specific .clasp.json configuration verification.

Static Website Updates

Demo and dashboard sites were updated directly and redeployed to S3:

  • /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 were uploaded to their respective S3 locations with CloudFront invalidations to guarantee cache refresh.

Key Architectural Decisions

Decoupling Brand Identity from Personal Identity

The core design principle was preserving strong organizational branding while eliminating personal attribution. This means:

  • JADA remains the primary brand identifier in all content
  • "Queen of San Diego" team references anchor local market positioning
  • Team-oriented language ("our team," "the JADA team") creates approachability without personal exposure
  • No introduction of fake names or unclear authorship

Version Control and Auditability

All changes were committed to the repository structure, maintaining git history:

  • File modifications tracked in `/Users/cb/Documents/repos/`
  • Memory notes documented in `/Users/cb/.claude/projects/memory/`
  • Changes remain reviewable and reversible via git history

Multi-Channel Consistency

Rather than updating content piecemeal, we implemented a systematic sweep across all customer-facing channels to ensure consistent brand presentation. This prevents the awkward situation where some touchpoints reference a name while others don't.

Monitoring and Validation

Post-deployment verification included:

  • Confirming email preview accessibility in S3 with updated content
  • Verifying boat imagery URLs remained live (no content dependency breakage)
  • Spot-checking CloudFront distribution status for propagated invalidations
  • Reviewing Apps Script files for any remaining personal references requiring attention

What's Next: Deployment Pipeline

Several components await next-phase execution:

  • Apps Script Push: Requires clasp authentication and clasp push execution for each project
  • Route53 Validation: