Leads Pipeline

Q: How does attribution work across sessions?

The Apex pixel (apex.js) sets a _apex_src cookie on first touch with source, medium, landing page, and timestamp. When a visitor submits a contact form, the site's thin proxy route passes the form data, attribution cookie, and geo metadata to POST /api/leads/submit on Apex. Lead records store the full attribution chain for later querying.

Q: Why route leads through a central Apex endpoint?

Sending notification emails per-site requires each site to have its own verified SES domain, DKIM, and SPF setup, which is operationally expensive at network scale. The submit endpoint handles both the DynamoDB write and the SES notification in a single call, removing the need for per-site email infrastructure entirely.

Q: What dashboards does the module surface?

Four tabs. Overview shows KPI cards, a donut chart, daily trend, and lead feed. Journey renders a Sankey diagram of source to landing page to conversion. Coverage maps lead geography via Mapbox. Google Ads shows a campaign table with spend, CTR, CPC, and conversions, enabled for tenants with a google_ads_customer_id set.

Q: Are there rate limits or PII controls?

Yes. The rate limit is 100 leads per day per tenant, enforced at the ingest endpoint. PII is nulled server-side for medical tenants to keep the pipeline aligned with the compliance posture those clients require. Push notifications fire on every new lead event through both Expo and Web Push surfaces.

What is the iSimplifyMe Leads Pipeline?

The Leads Pipeline is the Apex module responsible for capturing, attributing, and displaying visitor conversions across iSM-network sites. A first-touch attribution pixel, form proxy routes, and the AI concierge all feed a unified ingest endpoint that handles SES notification email, DynamoDB storage, and source attribution in a single call. It replaces per-site SES and DKIM configuration with a shared ingest surface.

Abstract

Problem

Leads arriving through organic search, AI referrals, paid ads, and contact forms need a unified attribution model that survives across sessions and can be queried later by campaign, source, and page. A site-specific lead handler solves the immediate notification problem but produces siloed data with no cross-channel view.

Sending notification emails per-site also requires each site to have its own verified SES domain, DKIM, and SPF setup — operationally expensive to maintain as the network grows.

Approach

Attribution capture

The Apex pixel (`apex.js`) sets a first-touch _apex_src cookie with source, medium, landing page, and timestamp. When a visitor submits a contact form, the site's thin proxy route passes the form data, attribution cookie, and geo metadata to `POST /api/leads/submit` on Apex.

The submit endpoint handles both the DynamoDB write and the SES notification in a single call — no per-site email infrastructure required.

Lead storage

Lead records store the full attribution chain: source, medium, campaign, gclid, ai_referrer, and landing_page. A daily LEADSUMMARY record aggregates totals by source, form, and page.

Google Ads campaign data syncs daily via a 6am CT cron, enabling spend-to-lead attribution.

Dashboard

The dashboard presents four tabs: Overview (KPI cards, donut chart, daily trend, lead feed), Journey (Sankey diagram of source → landing page → conversion), Coverage (Mapbox lead geography heatmap), and Google Ads (campaign table with spend, CTR, CPC, and conversions).

Status

Live on multiple iSM-network sites with pixel, proxy routes, and attribution flowing.
Push notifications (Expo + Web Push) fire on every new lead.
Google Ads sync active for tenants with a Google Ads customer ID configured.
Rate limit: 100 leads/day per tenant; PII nulled server-side for medical tenants.

Frequently asked

How does attribution work across sessions?

Why route leads through a central Apex endpoint?

What dashboards does the module surface?

Are there rate limits or PII controls?