Iron Corp / Military.com | Go To War Strategy | June 2, 2026
The May 2026 daily report has leads_sold, click_lead, click_lead_revenue, and lead_revenue all at zero for every single day of the month. This is not a reporting cosmetic — it means QuoteWizard's accept-rate, sold-lead count, and per-lead payout data are not flowing anywhere: not into Iron Corp's internal reporting, not into the CRM, and not into Meta. Meta's algorithm is optimizing on raw lead volume at a $21–28 CPL with zero visibility into which of those leads became revenue. The result is what the GTW audit called "value-blind CAPI" — Meta is flying blind, buying the cheapest leads rather than the most valuable ones, and the performance collapse from Week 1 to Week 4 of May (net-per-lead down 88%, ROAS 1.55 → 1.07) is the measurable cost of that blindness.
The CAPI rebuild is the single highest-leverage technical action available before the July-August measurement window opens. This document is Mo's working brief for the Tuesday June 2 office visit with the dev team. It is not a finished spec — it is the diagnostic and design framework that becomes a finished spec after Tuesday's answers are in.
Run through this with the dev lead in sequence. Do not skip to solutions. Every architectural decision in Parts 2 and 3 depends on answers here.
Lead event fire on form submit? Does PageView fire on the confirmation/thank-you page? Is there a ViewContent or InitiateCheckout analog anywhere in the funnel?em), hashed phone (ph), first name (fn), last name (ln), zip (zp)? If yes, where is that data coming from (form fields captured pre-submit, confirmed-data post-submit)?event_id deduplication parameter being sent on both the browser Pixel and the server-side CAPI call for the same event?Lead event?<iframe> on a military.com page. Iron Corp's domain is in the URL bar; QW form is sandboxed inside.
- Redirect: User lands on military.com, clicks a CTA, gets redirected to a QW-hosted URL (qwlead.com or similar), fills out the form on QW's domain, then gets redirected back.
- Iron Corp page posting to QW API: The form lives on military.com, form fields post directly to QW's lead intake API, confirmation is displayed on military.com. No iframe, no redirect.The goal is to move Meta from optimizing on raw Lead volume to optimizing on AcceptedLead value — and eventually on SoldLead or PaidLead revenue. Each event below is a step up the value chain.
| Event Name | Trigger | Value Passed | Match Keys | Firing Mode |
|---|---|---|---|---|
Lead |
Form submit (client-side Pixel + server-side CAPI dedup) | $0 placeholder | em, ph, fn, ln, zp, fbp, fbc, client_ip_address, client_user_agent |
Browser Pixel + server-side CAPI with shared event_id |
QualityLead |
Server confirms: Jornaya LeadiD valid, TrustedForm cert validates, anti-bot checks pass, no duplicate | $0 placeholder | Same + lead_id (Iron Corp internal), jornaya_id, trustedform_url |
Server-side CAPI only |
AcceptedLead |
QW postback returns "accepted" status for this lead | QW payout value in USD (e.g., $18.50) | Same + qw_lead_id |
Server-side CAPI real-time if webhook; offline CAPI batch upload if CSV/email postback |
SoldLead |
QW postback returns "sold to carrier" status | Carrier payout value in USD | Same + carrier_id |
Server-side CAPI offline upload (typically lags 24–72h) |
PaidLead |
Revenue cleared in Iron Corp CRM / finance system | Actual paid amount | Same | Server-side CAPI offline upload (net-14 or net-30 cycle) |
Lead
- Server endpoint: Iron Corp application server (same domain as form or same domain as form-hosting page). Fires immediately on form submit.
- Payload: Standard CAPI payload — event_name: "Lead", event_time (Unix timestamp), event_id (UUID generated at submit, shared with Pixel), user_data block with em + ph SHA-256 hashed, fn + ln hashed, zp hashed, fbp and fbc passed from cookies, client_ip_address, client_user_agent. custom_data block: content_name (product line — "auto" or "home"), content_category ("insurance"), value: 0, currency: "USD".
- Deduplication: event_id must be identical on both the browser Pixel call and the server CAPI call for the same submission. Meta deduplicates on this field within a 48-hour window.
- Backfill: No — fires real-time on submit.
QualityLead
- Server endpoint: Iron Corp application server, fires after cert validation and anti-bot logic completes (typically <200ms post-submit if synchronous, or async within seconds).
- Payload: Same as Lead plus custom_data.lead_id (internal), custom_data.jornaya_id, custom_data.trustedform_cert_url. value: 0.
- Deduplication: Unique event_id. No browser Pixel counterpart — this event is server-side only and will not have a duplicate to resolve.
- Backfill: If cert validation is not currently happening server-side, this event can initially be fired as a proxy by Iron Corp's server confirming non-duplicate submission. Full cert validation added in Week 3.
AcceptedLead
- Server endpoint: Iron Corp webhook receiver (a new endpoint built in Week 2). QW POSTs accept signals here; the endpoint transforms the payload and forwards to Meta CAPI.
- Payload: Same match keys as above (looked up from Iron Corp's lead store by qw_lead_id → iron_corp_lead_id). custom_data.value = QW payout amount (e.g., 18.50). custom_data.currency: "USD". custom_data.qw_lead_id.
- Deduplication: event_id constructed as "accepted_" + qw_lead_id. No browser Pixel counterpart.
- Backfill: If QW delivers postbacks via CSV or daily email rather than real-time webhook, this event uses Meta's offline Conversions API upload (same endpoint, same payload, event_time set to the actual accept timestamp from QW's data). Historical May data — if QW can provide it — should be backfilled in Week 3 to bootstrap signal.
SoldLead
- Server endpoint: Same webhook receiver or a second handler if QW delivers "sold" signals separately from "accepted."
- Payload: Same match keys. custom_data.value = carrier payout (if known; use QW sold value if carrier payout is not separately reported). custom_data.carrier_id.
- Deduplication: event_id = "sold_" + qw_lead_id.
- Backfill: Likely requires offline upload. QW's "sold to carrier" signal may lag 24-72 hours. Batch upload acceptable initially.
PaidLead
- Server endpoint: Triggered by Iron Corp's finance/CRM reconciliation process, not a live webhook.
- Payload: Same match keys. custom_data.value = actual USD amount received. This is the ground-truth event for long-term algorithm training.
- Deduplication: event_id = "paid_" + iron_corp_lead_id.
- Backfill: Offline upload on net-14 or net-30 cycle. Lower urgency — implement after AcceptedLead is stable. Most important for annual model quality.
Lead. Do not change the optimization event until CAPI is verified working and AcceptedLead has at least 50 events/week flowing (Meta's minimum for Value Optimization).AcceptedLead volume >= 50/week, test switching to QualityLead optimization first (higher volume, lower noise than AcceptedLead). Run as a holdout — not a full account switch.AcceptedLead signal is clean and volume sufficient, switch Meta campaign objectives to AcceptedLead with value optimization. This is the point where Meta starts buying the right leads instead of just more leads.Iron Corp's development team hosts a lightweight HTTPS endpoint on their existing application infrastructure — the same servers that already handle form submission processing. This is not a third-party middleware product (Stape, Elevar, etc.) unless the dev team has a strong preference. Third-party middleware is acceptable if Iron Corp's infra cannot make outbound HTTPS calls to Meta or if the dev team lacks bandwidth, but it adds a vendor dependency and a monthly cost. The spec below assumes Iron Corp infrastructure; if the Tuesday diagnostic reveals a blocker, the Stape/GTM server-side option is the fallback with the same event taxonomy.
Lead with a UUID event_id generated at submit time.https://graph.facebook.com/v19.0/{pixel_id}/events with the Lead event payload including the same event_id.event_id, deduplicates, and counts one Lead with higher match confidence than either signal alone.iron_corp_lead_id, timestamp, hashed PII, fbp, fbc, product line, form source, Jornaya ID, TrustedForm URL, consent language snapshot.Two sub-paths depending on how QW delivers postbacks (the Tuesday diagnostic determines which):
Path A — Real-time webhook (preferred):
QW sends an HTTP POST to Iron Corp's webhook receiver endpoint each time a lead is accepted, sold, or paid. The endpoint looks up the original iron_corp_lead_id using the qw_lead_id from the postback, retrieves the stored hashed PII and match keys, constructs the AcceptedLead or SoldLead CAPI payload with the actual payout value, and forwards to Meta within seconds of the QW signal.
Path B — Batch postback (CSV/email/SFTP):
Iron Corp receives a daily file from QW. An automated process (cron job or triggered script) parses the file, looks up each qw_lead_id in Iron Corp's lead store, constructs the CAPI payload for each resolved lead, and submits them as a batch to Meta's offline Conversions API endpoint. The event_time in each payload is set to the actual accept/sold timestamp from QW's data — not the upload time. Meta accepts events up to 7 days old for standard CAPI; up to 90 days for offline events API. Historical backfill of May data uses this same mechanism.
Daily automated reconciliation report (can be a simple email or Slack notification):
- Total browser Lead events fired (from Pixel)
- Total server-side Lead events fired (from CAPI)
- Dedup match rate (should be >90% after Week 2)
- Total AcceptedLead events (from QW postback)
- Total QualityLead events
- Discrepancy flag: if server Lead count differs from browser Lead count by more than 5%, alert
Monthly reconciliation: CAPI AcceptedLead count and total value vs QW's partner statement vs Iron Corp CRM revenue record. Any delta > $500 triggers a manual audit.
EMQ is the single fastest win before the full CAPI rebuild is complete. The steps in order of impact:
1. Pass hashed email + phone on every Lead event. If these are not being passed today, adding them can raise EMQ from 4–5 range to 7+ in 48 hours.
2. Add fbp and fbc cookie values to every server-side event. These cookies are set by the browser Pixel and should be captured on form submit and stored server-side.
3. Add fn, ln, zp hashed on every event where the user provides them.
4. Verify client_ip_address and client_user_agent are being passed on every CAPI event — these are mandatory for match quality and are frequently omitted in basic implementations.
Goal: Leave Tuesday June 2 with answers to every question in Part 1. By Friday June 6, have a locked technical spec that the dev team has signed off on.
Actions: - Mo runs Part 1 diagnostic with dev lead on Tuesday June 2. Takes notes; does not push toward solutions until all questions are answered. - Review Events Manager on Tuesday live — EMQ score, current event volume, any CAPI status. - If EMQ is below 7.0 and the fix is purely additive (pass hashed email/phone to existing Pixel), push to do this Tuesday or Wednesday. This is a one-line GTM or code change and should not require a sprint cycle. - Dev lead confirms: (a) which form architecture (iframe / redirect / own-page-to-QW-API), (b) whether QW postback is webhook or batch, (c) whether Iron Corp has a lead store that retains QW lead IDs. - Deliverable: Written technical spec incorporating Tuesday's answers, shared back with dev team by Thursday June 5.
Blocking risks: Dev team is unavailable or has no sprint capacity until the following week. Mitigation: Mo identifies the single EMQ fix that can ship without a sprint (hashed PII passthrough), and the dev lead commits to one engineer for the CAPI work.
Dev capacity ask: One developer, part-time (estimated 3-5 hours for assessment, 2-3 hours for EMQ fix).
Goal: Iron Corp's server-side CAPI endpoint is running in test mode. Lead and QualityLead events are firing server-side and deduplicating correctly with the browser Pixel.
Actions:
- Dev stands up the HTTPS endpoint. Integrates with Meta CAPI using the test event tool in Events Manager (test event code lets you verify payloads without counting toward real data).
- Verify: event_id deduplication working. EMQ score rising. Server Lead count matching browser Lead count within 5%.
- Begin building the QW postback receiver (if webhook) or the batch processor (if CSV/email). Even if this is not live to Meta yet, the Iron Corp side of the pipeline needs to exist.
- Confirm: Iron Corp lead store is being populated with qw_lead_id and iron_corp_lead_id linkage. This is the linchpin — without the ID mapping, backfill is impossible.
Blocking risks: QW does not deliver a real-time webhook and the daily CSV process requires a new ingestion pipeline. Mitigation: Start with the CSV/batch path as the fallback; it is slower but achievable in the same week.
Dev capacity ask: One developer, approximately 15-20 hours across the week. If the dev team is resource-constrained, the QW postback processor can slip to Week 3 without blocking the Lead event work.
Goal: AcceptedLead events are flowing to Meta — both historical (May data backfilled) and live (new accepts firing in near-real-time). Meta begins seeing lead value for the first time.
Actions:
- Request from QW: export of all accepted leads from May 1-May 30 with accept timestamps and payout amounts. If QW can provide this, backfill via offline CAPI upload. Even 1,000 historical AcceptedLead events with real USD values will immediately change what Meta knows about this account.
- Turn on the live AcceptedLead pipeline (webhook or batch) in production. First live AcceptedLead events hit Meta.
- Monitor: Does Meta's Events Manager show the AcceptedLead event populating? Does average event value look correct relative to expected QW payout rates?
- Add cert validation to QualityLead if not already in place.
Blocking risks: QW refuses to provide the May historical export. Mitigation: Even without historical data, forward-looking AcceptedLead events from June start training the Meta algorithm. The algorithm needs 50 events/week to be useful; if June volume supports it, optimization signal builds within 2-3 weeks from go-live.
Dev capacity ask: One developer, approximately 10 hours (mostly integration testing and the historical upload script). QW partnership contact needed to request the data export — this is Mo's ask, not dev's.
Goal: Meta campaign is running with real value data flowing. Test switching at least one campaign's optimization objective from Lead to a value-based event.
Actions:
- Review AcceptedLead weekly volume. If >= 50 events/week, propose test: create a duplicate campaign optimizing on QualityLead with Highest Value bidding. Run alongside existing Lead-optimized campaign as a holdout (not an A/B split that disrupts existing performance).
- If AcceptedLead weekly volume is below 50, do not switch — report the volume gap and set a July target date.
- Set up the daily reconciliation report in whatever format works for Lauren and the dev team — spreadsheet email, Slack, or dashboard.
- Review SoldLead and PaidLead pipeline feasibility. If QW provides sold signals, stand up that event. If not, document it as a July item.
Blocking risks: Volume is too low to switch optimization event (< 50 AcceptedLead/week). This is the most likely blocker. At $25 CPL and a typical QW accept rate of 40-60%, ~3,500 leads/week should generate 1,400-2,100 accepts. If the accept-rate postback is working, volume should be sufficient. The risk is the postback itself not materializing.
Dev capacity ask: Minimal — monitoring and threshold-check logic. No new development required unless switching optimization events triggers a campaign rebuild.
Meta's published performance data for accounts that implement CAPI with quality-signal optimization (optimizing on a downstream conversion event with real value rather than raw lead count): - 15% lower cost-per-quality-lead (CPQL) - 44% higher quality-conversion rate (more accepted / sold leads per dollar spent)
These are averages across verticals. Insurance lead gen is a high-signal vertical — Meta's algorithm is well-trained on insurance purchase intent. The benchmarks are credible here.
Current state (May Week 1 baseline, the best week): - CPL: $22.23 (May 1) - RPL: $34.74 - Net margin: ~36% - Daily spend: ~$28K - Daily net revenue: ~$15.7K
After CAPI rebuild with AcceptedLead optimization (applying Meta's 15% CPQL reduction): - CPL drops from ~$25 average to ~$21.25 (conservative — using the 15% figure on May's average, not the week 1 low) - At the same ~33K leads/month: spend drops from ~$825K to ~$700K for the same lead volume, or the same spend produces ~18% more leads - At $34 average RPL (holding revenue per lead stable): same spend goes from ~$281K gross to ~$331K gross - Net impact: approximately +$40,000-$55,000/month in net revenue at constant spend, before any creative or audience improvements
More conservatively, if only the CPL improvement materializes (not the quality-conversion rate improvement): approximately +$20,000-$30,000/month.
These numbers assume nothing else changes. The CAPI rebuild compounds: - Creative testing becomes more efficient because Meta learns from accepted-lead signal, not raw click-through. - Audience expansion campaigns become less wasteful — Meta stops chasing cheap leads from low-intent audiences. - When form migration to Iron Corp's own form (Phase 2) happens, the CAPI infrastructure is already in place and the historical signal from QW-era leads provides continuity.
The CAPI rebuild is the prerequisite for everything else in July-August to work at its full potential.
This is the most architecturally critical section. The CAPI rebuild must not require changes to the QW integration — that migration is Phase 2 and is explicitly out of scope for the June-August measurement window. The implementation approach is different depending on which form architecture Tuesday reveals.
What it looks like: User stays on military.com (e.g., auto.military.com/insurance/). The form appears in an <iframe src="qw-hosted-url.com/...">. The URL bar shows military.com throughout.
The problem: Browser Pixel on the parent military.com page cannot read events that fire inside the QW iframe (cross-origin sandbox). The Pixel fires PageView on the parent page but has no visibility into form field entry or form submit inside the iframe.
CAPI implementation: Iron Corp's server-side endpoint is the primary event source. Iron Corp must receive a postback from QW at the moment of form submission (QW sends a "lead submitted" notification to an Iron Corp URL) — this postback triggers Iron Corp's CAPI Lead event. The browser Pixel fires Lead on the parent page using a custom event triggered by a postMessage from the QW iframe (QW must support this — confirm Tuesday). If QW does not support postMessage, the Pixel Lead event fires from Iron Corp's postback handler via a Meta Pixel server-side pixel event (not a browser event), and deduplication is handled purely server-side.
Risk level: Medium. Depends on QW's willingness to (a) send an Iron Corp postback on submit and (b) support postMessage. Both are standard QW partner features but need confirmation.
CAPI coexistence verdict: Workable without changing the QW form at all. Iron Corp just needs QW to fire a server-to-server "lead received" notification to a new Iron Corp endpoint.
What it looks like: User lands on military.com, clicks a form CTA, gets redirected to a QW-hosted URL (e.g., leads.quotelab.com/insurance/?...), fills out the form on QW's domain, and gets redirected back to a military.com thank-you page.
The problem: The form submit happens on QW's domain. Iron Corp's Pixel never sees the submit event. The only Iron Corp-domain events are the pre-redirect click and the post-redirect thank-you page load.
CAPI implementation: Iron Corp fires Lead on the thank-you page (when the user returns from QW's domain). This is reliable if QW always redirects back to a military.com URL with a lead status parameter. Iron Corp server fires the CAPI Lead event based on the QW return postback (same as Architecture A). Match quality may be slightly lower because IP/UA forwarding depends on QW including them in the redirect parameters or the return postback.
For fbp and fbc cookies: These persist on the military.com domain through the redirect and are available on the thank-you page. They should be captured on the thank-you page load and included in the server-side Lead event payload.
Risk level: Low to medium. The thank-you page is a clean trigger point. The gap is the ~10-15 second window between QW form submit and Iron Corp thank-you page where the lead technically exists but hasn't fired a CAPI event yet.
CAPI coexistence verdict: Straightforward. No QW form changes required. Iron Corp instructs the thank-you page and the QW return-postback handler.
What it looks like: The form HTML lives on military.com. On submit, JavaScript on the military.com page POST-s the form data to QW's lead intake API directly. QW returns a response (accepted/rejected/pending) and Iron Corp displays the confirmation on the same military.com page.
The problem: There isn't one. This is the simplest possible architecture for CAPI.
CAPI implementation: Iron Corp's server intercepts the form submit (or the API response), fires the browser Pixel Lead event from the same page, and simultaneously calls its own CAPI endpoint with the full user data payload. The CAPI endpoint hashes the PII and sends to Meta. No iframe sandboxing, no redirect gap, no cross-domain issues.
Risk level: Low. All events fire on Iron Corp's domain with full PII access. EMQ will be highest in this architecture.
CAPI coexistence verdict: Ideal. This is also closest to what the Phase 2 form migration will look like, so the CAPI infrastructure built here carries forward with minimal changes.
Based on what the May data shows (military.com URLs appearing in the funnel, QW as the lead buyer, no indication of cross-domain complexity in the reporting structure), Architecture A (iframe) or Architecture C (Iron Corp page posting to QW API) is most likely. Architecture B (full redirect to QW domain) would typically show QW-domain URLs in UTM attribution data. The diagnostic questions in Part 1-E will confirm within the first five minutes of the Tuesday conversation.
Assumptions made in this document:
QW is the sole or primary lead buyer for the insurance vertical. If there are additional buyers (EverQuote, SmartFinancial, etc.) receiving leads from the same forms, the AcceptedLead event taxonomy needs to accommodate multiple buyer postbacks with different payout structures.
Iron Corp has a server-side application layer (not a purely static site) that can be modified to make outbound HTTPS calls to Meta's CAPI endpoint. If military.com is a fully static or CDN-served site with no application server, a lightweight middleware service (Lambda, Cloud Run, or Stape) will need to stand up a new endpoint.
QW sends postback signals (at minimum a daily batch) that include QW lead ID and accept/reject status. If QW provides no postback whatsoever and all lead status data lives inside QW's portal without an export mechanism, the AcceptedLead event is blocked until Mo negotiates postback access as a contract term with QW.
The Meta Pixel is on a legitimate, active dataset that is linked to Iron Corp's active ad account. If the account is using a different Pixel ID than what is in Events Manager, or if there are multiple active Pixel IDs on different surfaces, deduplication will fail silently and EMQ will be artificially suppressed.
The May 2026 daily CSV columns leads_sold, click_lead, click_lead_revenue, and lead_revenue being all zeros indicates the reporting pipeline was never built to consume QW postback data — not that QW isn't sending it. QW almost certainly has this data. The gap is on Iron Corp's side.
Dev team has at least one engineer with Python or Node.js experience who can build the CAPI endpoint and QW postback handler. Estimated total dev hours for the full Phase 1 CAPI build: 40-60 hours across June.
Open questions for Tuesday June 2:
iron_corp_lead_id ↔ qw_lead_id? Without this mapping, backfill is not possible and real-time AcceptedLead events require the QW postback to carry enough PII to re-identify the user independently.