Facebook Lead Tracking — Audit + Rebuild SOW

1The short version

Your visual atlas (the screen recording of the old, working setup) shows lead tracking as three layers: count every real conversation the moment it starts, with the ad it came from; when the bot finishes qualifying someone, extract their details, quality-check them, and log the hand-off; and a form path for leads a human transfers by hand.

You currently have delivery without bookkeeping. Leads reach you (that pipeline was rebuilt and proven end-to-end on Jul 28), but there is no reliable log of qualified conversations → transfers → which ad produced them — which is exactly the visibility the atlas had.

Nothing in this SOW touches ads, budgets, or live customer messages. It is tracking and logging only. Every change lands paused or is read back and verified before it counts as done.

2How the atlas says it should work

Layer 1 — Count every real conversation (atlas: "Qualified Convo Tracking")

• An AI step reads the first message and filters out spam, accidental clicks, and people selling to you.
• Real inquiries get a tracking row: date, time, name, client, message, status, campaign.
• The contact card saves the first message plus the full ad fingerprint — traffic source, campaign, medium, content, the Facebook click ID, and the exact ad ID.

Layer 2 — Track every automated hand-off (atlas: "Auto Transfer Tracking")

• AI steps pull the lead's phone, location, ZIP, city, project type, and a short project description out of the conversation.
• A quality-control gate checks for missing fields, placeholder text, and AI-sounding leaks before anything reaches a client.
• Fails → needs-review alert + tag. Passes → transfer row logged, tagged "transferred", client notified, you notified.

Layer 3 — Track manual hand-offs (atlas: "Manual Transfer Tracking")

3What is actually live today

Checked against the Jul-25 full-account map, re-verified against the live system on Jul 28 — nothing in the account changed in between.

What changed since the map: the qualified-lead stamp feeding the delivery rail was cut Jul 25 and rebuilt Jul 28 (new trigger + the n8n sender), then proven with synthetic leads end-to-end. That rail is the delivery half — this SOW is the tracking half the atlas describes.

4Pixels + Conversions API datasets — what exists and who sends what

The EyeFly-era setup (what the atlas shows)

• One shared web pixel for the whole client fleet — "EyeFly Client Data" 1302204368413290, stamped into every client's account settings. Deprecated April 2026 for messaging clients and kept only for diagnostics — Messenger leads never touch a web page, so a web pixel can't see them.
• One messaging dataset per client, linked to their Facebook page — 37 clients carry one in the brain today. This is the thing Meta actually optimizes on for click-to-Messenger ads. Events are LeadSubmitted with the person identified by page ID + their Messenger ID (messaging datasets only accept LeadSubmitted and Purchase — not "Lead", not "QualifiedLead").
• The atlas send path — the "Qualified Tag → Lead Submitted Event" workflow fires on the qualified tag and does two sends: a webhook to the n8n relay and GHL's built-in "Meta Conversion API" action (event "Lead", token + dataset pulled from the account's custom values). The built-in action used the deprecated shared pixel and unresolvable merge fields — which is exactly why the double-fire question in Phase 0 exists: the atlas itself shipped with both senders wired.
• Why the n8n relay became the real sender — GHL's webhook can't resolve the Messenger ID field (ships blank, Meta rejects the event). When that silently broke in April 2026, cost per qualified conversation went from ~$58 to ~$428 in two weeks. The fix was a server-side relay: look the contact up properly, build the identity payload, post to the client's dataset with the fleet system-user token, log every fire to a ledger. Weekly health monitor + backfill + per-dataset test-fire tooling wrapped around it.
• That EyeFly relay went quiet Jun 22 — 4,025 events logged lifetime, zero since. If any EyeFly client campaigns are still spending, Meta has been optimizing blind for them for five weeks (flagging, not asserting — needs one check against active client spend).

The St. Pierre setup (live right now)

5The gaps, numbered

• 1. Layer 2 has never run — no automated transfer has ever been logged with extracted, quality-checked data.
• 2. Layer 1 logs into the retired EyeFly spreadsheet — the numbers land where nobody looks.
• 3. The possible double-report to Facebook — one unknown toggle, the single highest-risk item.
• 4. The manual-transfer form path is unverified and probably broken.
• 5. Ad-fingerprint capture is unaudited field-by-field — this morning's real transfers had "unknown" city/ZIP on some rows.
• 6. Sleep-the-bot steps may point at the wrong bot — which would keep it messaging people after transfer.

6The rebuild plan

7Who does what

8Decisions needed

• 1 · Where do tracking rows live? ★ The brain database with your dashboards on top — matches the standing "own pages + database" reporting doctrine. The atlas used Google Sheets; say "sheets too" and we mirror rows to a sheet as well for the atlas-identical view.
• 2 · Layer 2 home? ★ Rebuild the atlas semantics inside the proven n8n rail and delete the dead workflow. Alternative: wire a trigger into the existing dead workflow and fix it in place — slower, and duplicates the rail that already works.
• 3 · Manual path: ★ one log, two doors (form feeds the same rail) vs. an atlas-literal separate workflow.
• 4 · Phase 0 result: report what the Facebook-reporting toggle showed so the account map can be marked resolved.

9Technical notes