```html

Implementing Anonymous Founder Marketing: Removing Personal Identity from Public-Facing Campaign Infrastructure

Context: The Problem

During an email campaign push for JADA's event outreach initiatives, personal founder information ("I'm C.B. Ladd, owner of JADA") was discovered embedded in marketing templates across multiple systems. This created a blocker: founder preference to maintain anonymity in public marketing while preserving brand identity and team messaging. The solution required a systematic sweep and reconstruction across distributed systems.

What Was Done

We executed a multi-layer identity removal and rebuild across:

  • Email templates and campaign preview assets in S3 + CloudFront
  • Google Apps Script automation files managing outreach workflows
  • Demo and public-facing HTML property pages
  • Marketing tool source code and blast delivery systems
  • Google Sheets dashboard integration and templating

Technical Details: Layer-by-Layer Remediation

Email Template Sanitization

The primary issue: SDCC hotel outreach email preview stored at s3://queenofsandiego-public/sdcc-hotel-outreach-2026.html contained founder attribution. Process:

  • Downloaded the HTML preview from S3
  • Searched for all name-based references (C.B. Ladd, full legal name variants)
  • Replaced founder identity with team-focused messaging: "The JADA Team" or "Queen of San Diego Events Team"
  • Re-uploaded sanitized HTML to the same S3 key
  • Invalidated CloudFront distribution E2XXXXXP to force cache refresh

Why S3 + CloudFront? Email templates need instant global delivery and version control without re-sending. S3 provides versioning; CloudFront edge caching ensures subscribers see consistent content within seconds of invalidation.

Google Apps Script Automation Cleanup

Four critical files required updates:

  • /Users/cb/Documents/repos/sites/queenofsandiego.com/FuneralOutreach.gs — Funeral home partnership outreach
  • /Users/cb/Documents/repos/sites/queenofsandiego.com/CrewDispatch.gs — Event crew scheduling and assignment
  • /Users/cb/Documents/repos/sites/queenofsandiego.com/rady-shell-events/apps-script-replacement/WorshipRsvp.gs — Religious event RSVP handling
  • /Users/cb/Documents/repos/sites/queenofsandiego.com/rady-shell-events/apps-script-replacement/ViatorApiFollowUp.gs — Tour operator follow-up sequencing

Each file contained string literals, template interpolation, or signature blocks with founder name. Replacements used consistent team-identity language across all scripts to maintain brand coherence in automated communications.

Public Demo Property Removal

Two dangerouscentaur.com demo properties referenced founder in proof-of-concept HTML:

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

These pages demonstrate real estate marketing automation. While demo-only, they're discoverable and indexed. Removed all attribution, leaving only property details and JADA technology features. Redeployed to S3 and invalidated CloudFront distribution for dangerouscentaur.

Marketing Tool Source Code Audit

The blast delivery system at /Users/cb/Documents/repos/tools/jada_blast.py underwent four iterations to:

  • Check for hardcoded founder names in email headers, footers, or signature templates
  • Verify template variables pulled from external files (not embedded credentials)
  • Ensure SES sender identities referenced team or brand accounts, not personal email
  • Add validation to reject any template content containing restricted personal identifiers

Why this matters: The blast script is the execution layer. If contaminated, it pushes bad messaging at scale. Making it identity-aware prevents future incidents.

Dashboard Integration

Updated /Users/cb/Documents/repos/sites/progress.queenofsandiego.com/index.html — an internal team dashboard tracking campaign metrics. While internal, it's accessed by collaborators and potentially exposed in demos. Scrubbed all founder references from KPI explanations and methodology notes.

Infrastructure & Deployment Strategy

S3 & CloudFront Pattern

Public assets (email previews, demo pages) follow a standard pattern:


S3 Bucket: queenofsandiego-public
Region: us-west-2
Versioning: Enabled
CloudFront Distribution: E2XXXXX (SDCC), E3XXXXX (dangerouscentaur)

Invalidation Command (example):
aws cloudfront create-invalidation \
  --distribution-id E2XXXXX \
  --paths "/*"

This setup allows immediate rollback: S3 version history preserves old content; CloudFront edge TTL is 1 hour, so invalidation guarantees refresh within seconds for browser hits.

Google Apps Script Deployment

Apps Script files live in version control but deploy via clasp (Google Apps Script command-line interface). Each file is tied to a Google Cloud Project with service account credentials stored securely.


Local workflow:
1. Edit .gs file in /repos/sites/queenofsandiego.com/
2. Run: clasp push
3. Clasp reads .clasp.json (project ID + local binding)
4. New version deployed to Google Apps Script backend
5. Bound sheets/docs auto-execute updated functions

Why Apps Script? Integrates with Google Sheets (dashboards) and Gmail (outreach) without external hosting. Founder identity removal in these files ensures all downstream automated messages stay compliant.

Key Decisions

1. Team-First Messaging Over Anonymous Obfuscation

We chose "The JADA Team" and "Queen of San Diego Events" over vague third-person language. Why? Removes founder identity without reducing credibility. Subscribers need to trust the sender; team messaging builds that better than impersonal corporate-speak.

2. Centralized Identity Validation in the Blast Tool

Rather than ad-hoc cleanup, we hardened the blast script to reject templates containing restricted identifiers. This is preventive: future template additions are automatically screened before sending.

3. Comprehensive Scope Over Minimal Fixes

We didn't just fix the SDCC email. We audited Google Apps Script, demo properties, and internal dashboards. Why? Founder concern was "criticism in public." Any discoverable asset counts as public. Piecemeal fixes leave vectors open.

4. Preservation of Version History

All changes were made in version control and S3 versioning enabled. If a future review requires the