Lead Re-Engagement & Affiliate Monetization Platform

This document is the engineering blueprint for the platform. It describes what the system does, the major components, how data flows between them, the key algorithms, and a recommended technology stack so the build team can start estimating and architecting immediately.

Ecommerce brands acquire customers through paid channels (Meta, TikTok, etc.). Over time a large share of those buyers stop opening, clicking, and purchasing — they become dead leads with no remaining value to the brand. Our platform takes ownership of those lapsed subscribers and turns them back into revenue: we re-engage them with genuinely useful, niche-relevant content and earn an affiliate payout each time one of them buys a product from a third-party advertiser.

We sit between three parties: the ecommerce brands who supply the leads, the subscribers we re-engage, and the advertisers whose offers we promote. Revenue comes from the advertiser side on a pay-per-sale (CPA) basis.

Where the value is created

The platform is a multi-tenant application made of a handful of cooperating services. The diagram below shows the end-to-end flow from a lead arriving to revenue being earned, plus the cross-cutting services (suppression, scheduling, analytics) that touch every send.

Component responsibilities

Five entities form the backbone of the data model. Getting these relationships right up front prevents painful re-work later.

Subdomain & landing-page strategy

For a client "Happy Gut" under main domain wellnessexperts.com, we provision happygut.wellnessexperts.com as the sending domain (SPF, DKIM, DMARC, and a tracking CNAME all configured against it). At the registrar/DNS level, the subdomain's web root can be pointed (CNAME or reverse proxy) to the brand's existing landing page, so a subscriber who visits sees a familiar experience while we keep sending reputation isolated per client.

Brands hand off lapsed leads by calling our webhook. The brand decides when a lead is "dead" (typically 60 or 90 days of no engagement) and fires the event at that moment.

The timing logic (brand side)

A customer acquired on July 1, 1:00 PM who stops engaging triggers a handoff 60 days later — September 1, 1:00 PM. That decision lives on the brand's side; our platform simply needs to receive the event reliably and act on it immediately.

Webhook contract

We expose a per-client authenticated endpoint. A suggested JSON payload:

// POST https://api.wellnessexperts.com/v1/leads
// Header: Authorization: Bearer <client_api_key>
{
  "email": "jane@example.com",
  "first_name": "Jane",
  "niche": "gut_health",        // maps to the target list
  "source_brand": "happy_gut",
  "acquired_at": "2026-07-01T13:00:00Z",
  "handoff_reason": "inactive_60d",
  "consent": { "marketing": true, "source": "checkout_optin" },
  "external_id": "cust_88213",        // brand's customer id
  "meta": { "ltv": 0, "last_order_at": "2026-07-01" }
}

What the Ingestion API does on receipt

1. Authenticate & rate-limit

   Verify the client API key / HMAC signature and apply per-client rate limits.

2. Validate & normalize

   Check email syntax/MX, normalize casing, confirm niche maps to an existing list for that client.

3. Check suppression & dedupe

   Reject if the email is on the global DNM list or already an active subscriber on that list.

4. Create / update profile

   Upsert the subscriber, attach to the correct niche list, store consent + source metadata.

5. Enqueue welcome flow

   Emit a lead.ingested event that triggers the Automation Engine's welcome sequence.

6. Acknowledge

   Return 202 Accepted with a lead id. Failed/rejected leads return a clear reason for the brand's logs.

Onboarding is configuration, not custom code

Every brand's payload looks different. Rather than hand-coding an integration per partner, the platform maps each partner's incoming fields onto a single canonical schema (email, name, niche/area-of-interest, consent, source, timestamps). Onboarding a new brand becomes a configuration step — point a webhook at us, auto-detect the inbound fields, and confirm the mapping — not an engineering project.

Ingestion adapters (for non-technical partners)

Not every brand can fire a webhook. The platform should ship a small set of fallback adapters so any partner can be onboarded: direct webhook (preferred), CSV upload, Google Sheet sync, and pull from the partner's email platform (Klaviyo, etc.). All four funnel through the same mapping layer into the canonical schema.

A simplified relational schema. The engagement and event tables are the highest-volume and most performance-critical — they feed both the Governor and reporting.

The platform owns all campaign logic; the ESPs (SendGrid, Postmark, Mailgun, and others) are used purely as delivery relays. Critically, different send types are spread across different providers to isolate reputation and diagnose problems fast.

Provider abstraction layer

A single internal "Send" interface sits in front of every provider. Whether a provider speaks SMTP relay or HTTP API, the rest of the platform calls the same method. Each provider is wrapped in an adapter that handles auth, formatting, retries, and inbound event webhooks (deliveries, opens, bounces, complaints) normalized back into engagement_events.

Send-type → provider routing

The routing policy is configuration, not code — it can be re-balanced without a deploy. A starting policy:

Capabilities every provider adapter must implement

• Authenticated send (SMTP relay preferred; HTTP API supported where the docs fit our needs)
• Per-message custom headers + tracking pixel / link wrapping under the client subdomain
• Inbound event webhook → normalized into engagement_events (delivered, open, click, bounce, complaint)
• Bounce & complaint feedback → auto-write to global suppression
• Rate / concurrency controls for IP warm-up and daily caps

This is the platform's smartest component. Its single job: keep each list's unique open rate at or above the 35% target by automatically tightening or loosening the "active opener" window — globally and per inbox provider.

How segments work

Every list sends to an opener segment — subscribers who have opened within the last N days. A wide window (e.g. 200-day openers) maximizes reach but eventually dilutes open rate as stale addresses creep in. A narrow window (e.g. 100-day openers) lifts open rate but reaches fewer people. The Governor continuously finds the widest window that still clears the target.

Per-inbox-provider (ISP) segmentation

Open-rate behavior differs sharply by mailbox provider. The Governor maintains an independent window per ISP for each list. Gmail might sustain a 200-day window at 45% while Yahoo needs a 50-day window to stay healthy. Each send is therefore composed of several ISP-specific sub-segments stitched together.

Governor control parameters (per list, configurable)

• Target open rate: default 35% (floor that triggers tightening)
• Recovery target: the rate to climb back to before re-widening (e.g. the prior 45%)
• Step size: how aggressively the window contracts/expands (e.g. ±25–50 days)
• Hysteresis / cooldown: minimum sends between adjustments to avoid oscillation
• Min volume guard: never tighten below a floor that would make the list too small to be worth sending

There is exactly one suppression list for the entire platform. An unsubscribe, complaint, or hard bounce anywhere removes that person from every active list, everywhere — permanently.

Two layers of enforcement

Design requirements

• Account-global, not per-list: one match suppresses the person across all clients and lists
• One-click unsubscribe compliant with RFC 8058 (List-Unsubscribe-Post header) — required by Gmail/Yahoo bulk-sender rules
• Reason + timestamp + source stored for every entry (audit & compliance)
• Irreversible by default: re-subscription only through a fresh, explicit opt-in
• Fast lookups: hashed-email index so pre-send filtering of large sends is instant

Modeled on the Morning Brew approach: genuinely valuable, niche-relevant content interleaved with native-style ads. Every daily issue is assembled automatically, per list, with a consistent structure.

Anatomy of an issue

Block types

Content uniqueness — no two emails identical future consideration

Ideally, the body text of any given issue should not be byte-for-byte identical across all recipients. Mailbox providers fingerprint repeated, identical bulk content, so introducing per-recipient variation can help both deliverability and the feel of a 1:1 newsletter. This is noted as a forward-looking consideration, not a launch requirement.

Feasibility is high and there are graduated ways to achieve it, from cheapest to richest:

A constant supply of fresh, niche-relevant content without a writing team: curate authority YouTube channels per niche, surface their newest videos in the newsletter, and turn each into a blog page that hosts the embedded video, an article transcription, and its own ads.

The flow in detail

1. Curate authority channels

   Maintain a database of the best YouTube channels per niche (weight loss, gut health, hair, etc.) that publish regularly. This is the editorial backbone.

2. Detect new uploads

   Poll the YouTube Data API (or PubSubHubbub push) for new videos from curated channels; capture title, thumbnail, URL, and publish date.

3. Transcribe & rewrite

   Pull captions or run speech-to-text, then use an LLM to turn the transcript into a readable article (with attribution to the creator).

4. Publish to our blog

   Create a blog page on the niche site: the embedded YouTube video at top, the article below, and display/native ad slots throughout for a second revenue stream.

5. Surface in the newsletter

   The Newsletter Builder pulls the freshest blog pieces for that niche into content blocks ① and ③, using the video's headline and thumbnail as the hook.

News sources, AI images & the content-quality loop

YouTube is the primary source, but the same pipeline can ingest curated news sources per niche for additional freshness. Article thumbnails/hero images can be AI-generated where a video thumbnail isn't suitable. Each blog page carries AdSense (or equivalent display ads), so organic content earns independently of the affiliate offers.

Critically, the platform measures first-party content performance separately from ad revenue — email click-through, scroll depth / read completion, dwell time, and internal clicks. These quality scores feed back into the content engine, biasing future harvesting toward the topics, sources, and formats that actually engage each niche.

Starting with ~40 offers loaded into the catalog, the engine decides which offers fill the two newsletter ad blocks (and the trending links) for each send. The goal is to maximize revenue per send while keeping offers fresh and respecting advertiser caps.

How an offer is selected

For each ad slot, the engine builds a candidate pool, scores each candidate, and picks via weighted selection so the best performers appear most often without the same offer monopolizing every issue.

Scoring inputs

Explore vs. exploit

New offers have no EPC history, so the engine reserves a share of impressions for exploration — giving fresh offers enough volume to prove themselves — while the majority of impressions exploit known winners. A multi-armed-bandit approach (e.g. Thompson sampling) is the natural fit and keeps the catalog self-tuning.

Closing the loop: conversion tracking

EPC is only as good as the conversion data feeding it. Every offer click is tracked through our own redirect (so we own first-party click data), and actual sales must be reported back from the advertiser. There are three common mechanisms — the platform should support all three since it's partner-controlled:

Every send is fully automated — no human ever composes or presses send. The Automation Engine orchestrates each subscriber from ingestion through the daily cadence, and a scheduler guarantees issues are built and sent on time.

Subscriber journey

Lifecycle rules

• Welcome first: on ingestion, every lead receives one high-value, niche-relevant welcome email engineered for maximum open rate.
• Reminder pass: non-openers get one reminder ~24h later (resend / new subject) to pull them into the opener segment.
• Openers graduate into the daily AM + PM cadence; only openers ever receive daily issues.
• Segment governed: who counts as an "active opener" each day is set by the Governor (§8), per list and per ISP.
• No manual sends: the scheduler builds and dispatches every issue on the fixed daily clock (e.g. 8 AM / 6 PM per list timezone).

The scheduler — guaranteeing automated sends

A reliable job scheduler is the heartbeat. For each list and each daily slot it: (1) resolves the active opener segment from the Governor, (2) filters against suppression, (3) asks the Newsletter Builder to assemble the issue (content + ads), (4) routes the send through the assigned provider, and (5) records results. Jobs must be idempotent, retried on failure, and alert a human only on anomalies — never to send mail, only to investigate.

A pragmatic, scalable stack that an experienced team can move fast on. Swap equivalents freely — the architecture, not the brand names, is what matters.

Alternative: a leaner MVP stack

The stack above is the scale-ready target. To ship an MVP fast, a lighter, managed-first stack (proposed in the partner overview) gets you live with far less infra work, and individual pieces can be swapped for the heavier options as volume grows.

Integration surface

The realistic integration count is small because we expose the contract and partners conform: roughly ~12 fixed integrations built once, ~4 ingestion adapters (webhook, CSV, Sheets, ESP-pull), and 1 per affiliate network. The genuinely hard, partner-controlled parts are heterogeneous contact ingestion and affiliate conversion tracking — both mitigated by publishing our webhook spec and postback URL.

Everything else is academic if the mail lands in spam. These are the non-negotiable practices baked into the platform — plus the real-time monitoring dashboard and automated domain warm-up that keep every sending domain healthy.

Real-time deliverability & Postmaster dashboard

The dashboard must surface domain Postmaster health for every sending subdomain in real time and the spam/complaint rate of every list as it happens, alongside the other signals the team needs to watch daily and weekly. This is a dedicated monitoring surface in the admin console, fed by Google Postmaster Tools, ESP feedback loops, seed-list placement tests, and our own engagement events.

Metrics to monitor

Automated domain warm-up for new clients

New client subdomains start with zero sending reputation, so mailing them at volume immediately would land in spam and damage the parent domain. To build reputation safely, the platform integrates third-party warm-up services — Warmy and/or InboxAlly — which generate positive engagement signals (opens, replies, moves-to-inbox) on a controlled ramp. This is wired into the platform and automated as much as possible.

How the automation works

1. Auto-enroll on provisioning

   When a client subdomain is created (§4), the platform calls the Warmy / InboxAlly API to start a warm-up campaign automatically — no manual setup.

2. Controlled ramp

   The warm-up service builds reputation with positive engagement on a gradual schedule, while the sending layer caps real volume in parallel (§7).

3. Monitor against Postmaster

   The dashboard tracks each warming domain's reputation, spam rate, and authentication % in real time so the ramp can be paused if signals dip.

4. Graduate automatically

   Once a domain holds healthy reputation and low spam rate for a set window, the platform raises its real send caps and tapers the warm-up service off — graduating it into full production sending.

5. Exception alerts only

   Humans are notified only on anomalies (reputation drop, blocklist hit, stalled warm-up) — never to run the warm-up by hand.

Consent & data

Because leads originate from the brands, the platform must capture and store the consent basis passed in the webhook, honor jurisdictional rules (CAN-SPAM, and GDPR/CASL where recipients fall under them), and maintain auditable records. The global suppression registry (§9) is the compliance backstop. A legal review of the lead-handoff consent chain and the content-republishing model (§11) is strongly recommended before scaling.

A phased path to a working platform, front-loading the pieces that protect deliverability and prove the revenue model.

Realistic timeline & the true bottleneck

Feasibility is high — this is mostly integration work and standard patterns, with no exotic ML. Rough build estimates: an end-to-end MVP in ~8–12 days of focused build, and a full production build in ~3–4 weeks.