HITEK website lead tracking: what was broken, what we fixed, what is left

For Herald, Joe and Doug. Checked live on Oct 19, 2026, 2:55-3:05 PM CDT. Every number below says where it came from.

Where things stand right now

The fix is built, tested and on GitHub, but it is not live yet. The live quote form at cms.hitekcrm.com is still the old build (main.d4675b3c671a2d7f.js, the same file as this morning). Three steps from Herald turn it on (section 7). Until then, website leads keep reaching the CRM but not Google or Meta.

1. Short answer

Herald is partly right. The quote form does have a Meta pixel helper, and it takes each shop's pixel ID from the dealer settings menu. But the ad platforms are not receiving the leads:

Google (GA4 and Google Ads) got nothing from the form. The form never tells the website a lead was saved, and the website is what sends leads to Google.
Meta got almost nothing it could use. The form's own pixel runs inside a frame on a different domain, cannot see the ad click, and Meta's own log shows zero events from the form's domain on HITEK Houston's pixel.
The CRM threw away the ad click IDs, so nothing could be matched to an ad later either.

2. The numbers (HITEK Houston)

What	Count	Period	Source
Website quote leads saved in the CRM	63	Sep 28 - Oct 17	CRM
GA4 `generate_lead` (form leads Google saw)	2	Sep 19 - Oct 18	GA4 property "HITEK Houston Website" (556212718)
GA4 sessions / phone taps (`contact`)	1,003 / 47	Sep 19 - Oct 18	GA4, same property
Meta `Lead`, current pixel 3713730712101569	4	Oct 13 - Oct 19	Meta Events, read through Meta's official API
Meta events from the form's domain (`cms.hitekcrm.com`) on that pixel	0	Oct 13 - Oct 19	Meta, events by host: every event came from hitekhouston.com
Meta `Lead`, old pixel 1455610065567129	0	Sep 22 - Oct 13	Meta; this pixel stopped firing Oct 13, but one active ad set still optimizes for it
Google Ads website lead conversion (AW-16607334109)	never fired	recent months	Ryze audit of the Google Ads account

So roughly 63 real website leads produced 2 Google signals and 4 Meta signals. Ads were being judged and optimized on a small fraction of the real results.

3. How a lead is supposed to flow, and where it broke

1. Ad clickVisitor lands on hitekhouston.com with gclid or fbclid in the address

2. WebsiteSaves the click ID; GA4, Google Ads and Meta tags are installed and waiting

3. Quote formHerald's form, shown inside the page in a frame from cms.hitekcrm.com

4. "Lead saved" messageForm should tell the page. Never sent.

5. Conversions fireGA4, Google Ads, Meta Lead. Never happened.

6. CRMShould keep the click ID. Only kept utm_source.

Problem A: the form never tells the website a lead was saved main cause

The HITEK Marketing website fires its lead events only when the embedded form sends it this message from https://cms.hitekcrm.com: {source: "hitek-embed", action: "lead", submission_id} (or when the visitor returns with ?hk_lead=). The live form's code contains that message 0 times. So GA4 generate_lead, the Google Ads lead conversion and the website's Meta Lead never fire. The website side was set up correctly; it was waiting for a message that never came.

Problem B: why the form's own Meta pixel is not enough why it looked like it worked

It runs on the wrong page. The pixel fires inside the frame on cms.hitekcrm.com, not on the shop's site. The ad click ID (fbclid) is in the shop site's address, not the frame's. The form asks the page for it (requestParentSearch), but the shop sites do not run the matching bridge script, so it never gets an answer.
Browsers block it. A pixel inside another site's frame is a third-party tracker. Safari and Firefox block or partition its cookies by default (Chrome too when the visitor blocks third-party cookies), so Meta cannot tie the Lead to the ad click.
Meta's log shows nothing from the form. Since this pixel started firing on Oct 13, every event on it came from hitekhouston.com; none from cms.hitekcrm.com. Either the pixel ID saved in the menu for HITEK Houston is blank or a different pixel, or the browser blocked it. Worth checking in the dealer settings, but either way Meta was not getting usable leads.
Privacy problem. The helper sent the customer's email and phone number to the parent page with target "*", which means any website that embeds the form could read them. Reproduced in our browser test (control c2).

Problem C: the CRM did not keep the ad click

The lead record stored only utm_source. No gclid, fbclid or landing page. So even with the message fixed, a lead could never be uploaded to Google or Meta later and matched to the ad that produced it.

Problem D: bookings, deposits and completed jobs never went back to the ads

The "Book appointment" button leaves the site for cms.hitekcrm.com, so the site's tags never see bookings, and nothing on the server reported booked jobs, deposits or completed jobs to Google or Meta. The ads could only ever learn "form filled", never "customer paid".

4. What we built (release 2)

Pushed to Herald's GitHub on Oct 19 at 1:35 PM as new branches. Nothing on main or dev was touched.

Repo / branch	Commit	What it does
`hitek-cms` / `ads-tracking-20261019`	`e3db852`	Form sends the "lead saved" message to the shop website after a successful save (contact and package forms), answers `hello`, passes the click IDs to the backend, stops sending customer email/phone to untrusted pages, never double-counts a Meta Lead.
`hitek-backend` / `ads-tracking-20261019`	`1d9a14e`	Saves click IDs and UTM values on the lead (new `attribution` column). Records lead, booked, deposit, paid and completed events once each in an outbox, and can send them server-side to Meta (Conversions API), GA4 (Measurement Protocol) and Google Ads (offline conversion feed). Senders are off until a shop is switched on. Includes Herald's dev plus a one-line compile fix.
`hitek-backend` / `weekend-fixes-20261019-on-dev`	`63fedd7`	The weekend CRM fixes (release 1), rebased on Herald's dev.
`hitek-web-v2` / `weekend-fixes-20261019-on-dev`	`2f86ae7`	Weekend web fixes. No tracking change is needed in the web app.

5. Proof it works (before going live)

Tested on a sealed copy on HITEK's server (no internet access, nothing sent to Google, Meta or customers), with Herald's real code plus the fix and real forms in a real browser.

Browser test, 18/18 passed (199 checks). Contact form after a Google ad click: exactly one GA4 generate_lead, one Google Ads conversion and one Meta Lead, all with the same event ID, and the lead saved with its gclid. Same for fbclid, a direct visit and the booking/package form. A double click counts once. A visitor who declines cookies or sends Global Privacy Control: no ad events, lead still saved. An untrusted website embedding the form gets nothing.
Control on Herald's unmodified form: no lead events at all, and email/phone posted to "*". That is today's live bug, reproduced.
Funnel test, 39/39 passed. Lead, booked, deposit, paid and completed each recorded once; repeat payment rejected without a second conversion; another shop's staff blocked.
Unit tests: backend 685 passed, 0 failed; form 24/24.

Not covered by the test: real delivery to Google and Meta (mocked on purpose). That is what the one live test lead in section 7 checks.

6. The website list in `env.ts` (the hard-coding question)

What the menu stores today: the dealer settings save each shop's Meta pixel ID (meta_pixel_id). That part is dynamic. They do not store the shop's website address. The dealers table has no website column (checked on Herald's dev as of today, commit d335ef9), and the dealer fields the public form loads do not include one.

Why no list was needed before: the old form trusted every https website, so it did not need one. But it also never sent the "lead saved" message, so the missing list was never the reason leads were lost. And "trust everyone" is what let any site receive customers' email and phone.

What the list does now: the form only talks to HITEK Marketing sites (hitekmarketing.com and its subdomains, automatic) and to the shop sites listed in env.ts. The 7 current shop sites were checked today; each one serves on its bare domain:

hitekhouston.com, premiumautowrap.com, thetexastinter.com, autowrapprosil.com, firstinfilmwindowtint.com, theshopnola.com, onpointprostyles.com

Can it be dynamic? Yes, and it is a small follow-up: add a "Website address" field to the dealer settings menu, include it in the dealer fields the form loads, and have the form trust that address. Then a new shop never needs a code change. We can build and test that on the same sealed copy. Until then, the list works today: a new shop on its own domain is one line plus a form rebuild.

7. What is left to go live

Herald: back up the production database, deploy backend release 2 and run its two migrations (AddLeadAttribution, AddConversionEvents). Nothing visible changes; the senders stay off.
Herald: add embedTrustedOrigins (the 7 sites above) inside the env object in the cms env.ts, build, and deploy the form.
One live test lead on hitekhouston.com/contact?gclid=TEST...: check GA4 Realtime shows generate_lead, Meta Test Events shows Lead, and the CRM lead has its attribution saved.
Server-side senders: switch on one shop with a Meta test code, confirm, then the rest.
Doug and Joe: mark generate_lead as a key event once it fires, link GA4 to Google Ads, and add a Meta pixel and Google Ads lead labels to each client site that will run ads. Move the "Dodge #2" ad set off the dead pixel.

8. Where everything is

Code: GitHub RadTek3000/hitek-backend, RadTek3000/hitek-cms, RadTek3000/hitek-web-v2, branches above.
Full handoff, go-live checklist, per-site readiness and test results: HANDOFF-FOR-HERALD-JOE.md, GO-LIVE-CHECKLIST.md, CLIENT-SITES-READINESS.md, E2E-G-RESULTS.md (Doug has them; also on HITEK's server under Christian's admin folder).
Questions: ask Doug, who can pass them to Claude with the evidence files.

Prepared by Claude for Doug Connell. Last checked 3:02 PM CDT, Oct 19 2026. Meta numbers read through Meta's official Ads API; GA4 through the HITEK MARKETING Analytics account (read-only); form code read from the live public file; nothing was submitted or changed on any live system to make this report.