Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Implementing Marketing Anonymity: Removing Personal Branding from Customer-Facing Communications

What Was Done

This session focused on a critical business requirement: removing personal name references from all customer-facing marketing materials and automating enforcement of this policy across the organization's communication infrastructure. The directive was clear—no personal identifiers in outward-facing content—and required both immediate remediation of existing campaigns and architectural changes to prevent future violations.

The work spanned three major areas: (1) identifying and scrubbing existing content across multiple domains and email templates, (2) implementing automated checks in the email blast pipeline, and (3) establishing deployment patterns that enforce the policy at infrastructure boundaries.

Technical Details: Content Audit and Remediation

The first challenge was comprehensive discovery. We systematically searched across multiple repositories and deployment targets:

  • /Users/cb/Documents/repos/sites/queenofsandiego.com/ - Google Apps Script files (FuneralOutreach.gs, CrewDispatch.gs, CrewScheduler.gs)
  • /Users/cb/Documents/repos/sites/dangerouscentaur/demos/ - Demo site HTML files
  • /Users/cb/Documents/repos/tools/jada_blast.py - Email blast tool templates
  • /tmp/sdcc-hotel-outreach-2026.html - SDCC campaign email preview
  • /Users/cb/Documents/repos/sites/progress.queenofsandiego.com/index.html - Progress dashboard

For each location, we performed regex searches targeting "C.B. Ladd" and "CB Ladd" variations. When found, replacement text used brand-neutral alternatives: "JADA Team," "Queen of San Diego," or role-based descriptions that maintained context without personal attribution.

The SDCC email campaign required special handling. The original template contained introductory text: "I'm C.B. Ladd, owner of JADA". This was replaced with a team-focused introduction maintaining the original voice and campaign intent without personal identification.

Infrastructure: S3 and CloudFront Deployment

Updated assets were deployed to AWS S3 with the following structure:

  • S3 Bucket: tech.queenofsandiego.com (primary static assets)
  • CloudFront Distribution: Serves dangerouscentaur and progress.queenofsandiego.com sites
  • Invalidation Strategy: Post-deployment cache invalidation on both distributions to ensure immediate propagation

Updated files deployed:

# Demo site HTML (dangerouscentaur)
/demos/3028fiftyfirststreet.92105.dangerouscentaur.com/index.html
/demos/demo.dangerouscentaur.com/index.html

# Progress dashboard  
/progress/index.html

# SDCC email preview
/sdcc-hotel-outreach-2026.html

Each deployment was followed by CloudFront invalidation to clear edge caches, ensuring users see updated content immediately rather than stale versions.

Email Pipeline: jada_blast.py Integration

The most important architectural change was hardening the email blast tool itself. Rather than relying on manual review, we added automated validation to /Users/cb/Documents/repos/tools/jada_blast.py:

  • Template validation layer: Before loading any email template, the blast script now scans for prohibited patterns
  • Suppression list integration: Combined AWS SES suppression list data (bounce/complaint records) with contact scrubbing to prevent sending to invalid addresses
  • Content scanning: Template content is validated against a blocklist before rendering to any contact

This prevents future violations at the tool level rather than depending on process discipline. A developer could load a template with prohibited content, but the blast tool itself will refuse to send it and surface the violation immediately.

Google Apps Script Audits

Several Google Apps Script files required review and updates:

  • FuneralOutreach.gs - Handles funeral service outreach workflows
  • CrewDispatch.gs - Crew scheduling and notification system
  • WorshipRsvp.gs - Event RSVP management
  • ViatorApiFollowUp.gs - API follow-up automation
  • CrewScheduler.gs - Crew availability and assignment

Each script was searched for hardcoded references in email templates, error messages, or signature blocks. When found, references were replaced with team-based language or removed entirely where they served no functional purpose.

Platform and Credential Management

During this work, we also identified that credentials for various marketing platforms were stored in /Users/cb/Documents/repos/repos.env. While not modified in this session, the task to create platform-specific task cards for non-live platforms (GetMyBoat, WeddingWire, etc.) was documented for future team execution. This ensures marketing expansion doesn't reintroduce personal branding.

Key Architectural Decisions

Why validate in the tool, not the process: Manual review processes fail at scale. By embedding validation in jada_blast.py, we make policy violation expensive (the tool stops) rather than relying on humans to remember the rule.

Why scrub both source and compiled output: We cleaned templates in the repository, but also validated compiled emails before sending. This provides defense in depth—if someone updates a template in the future, the blast tool catches it.

Why include SES suppression data: We integrated AWS SES bounce and complaint records into contact scrubbing. This served two purposes: (1) improve deliverability by not sending to known bad addresses, and (2) prevent sending to contacts who've already complained about previous campaigns.

Why CloudFront invalidation matters: Demo and public-facing sites are cached globally. Without invalidation, users in different regions would see old content for hours. Invalidation ensures within-minute propagation of policy-compliant content.

What's Next

Several follow-up tasks remain in the development pipeline:

  • Platform expansion: Platform-specific task cards for GetMyBoat, WeddingWire, and other non-live marketing channels need to be created and executed with the same name-removal requirements
  • Cadence widening: Implementation of "widening-gap cadence" in the blast tool to optimize email frequency based on engagement patterns
  • Hyper-local personalization: Template system update to support location-based personalization while maintaining brand anonymity
  • Clasp deployment: Google Apps Script files currently exist in the repository but need clasp configuration to be deployed to production Apps Script environments with automated deployment gates

The policy is now actively enforced at multiple layers: template validation in the blast tool, automated S3/CloudFront deployment, and infrastructure that makes violations expensive and immediately visible to developers.

```