Conversion moments: how each tool signals success

Load this to establish or diagnose the conversion moment. Section 1 is the lead-gen problem (success must be inferred from a browser signal, and every tool signals differently); it carries literal, grep-able strings for working from (A) form mechanics, (B) static page source, (C) a headless browser, and (D) a codebase. Section 2 covers the moments this repo ships tested detectors for. Section 3 is the long tail. Section 4 is ecommerce, where the problem mostly does not exist.

Fix assets. When a finding here names a missing or wrong detection hook, the fix usually already exists in this skill. Tested listeners for 22 form and booking tools and 4 universal patterns (26 in all) live in ../assets/snippets/ (paste-in JS) and ../assets/gtm-recipes/detect/ (importable GTM containers), both pushing the canonical dataLayer event names listed in ../assets/gtm-recipes/event-map.json (for example gravity_form_submitted, typeform_form_submitted, calendly_event_scheduled). Diagnose against those exact names, fix by installing those exact assets.

1. Lead gen

A. Form submission mechanics

A.1 The four fundamental patterns

Stacking complications: multi-step forms (only final step converts; step events mistaken for submits; attribution scripts running only on step 1); popup/modal forms (not in DOM at load - delegated listeners or Element Visibility with "observe DOM changes"); full-page-reload confirmations with no URL change (default WPForms/Gravity non-AJAX - only hook is the confirmation div).

A.2 Per-platform catalog (literal strings)

Typeform - iframe. Embed: embed.typeform.com/next/embed.js; attrs data-tf-live=, data-tf-widget=; iframe src form.typeform.com/to/<id>. Parent receives message events from origin https://form.typeform.com with event.data.type === "form-submit" (also "form-started", "form-screen-changed"), payload has formId. Embed SDK: onSubmit callback with {formId, responseId}. Alternative: Ending screen redirect to first-party thank-you.

Calendly - iframe. Script assets.calendly.com/assets/external/widget.js; <div class="calendly-inline-widget" data-url=...>. Parent messages where e.data.event starts with "calendly.": profile_page_viewed, event_type_viewed, date_and_time_selected, event_scheduled (the conversion). Payload has event.uri + invitee.uri only - NO email (enhanced conversions need invitee API or prefill capture). Beware: date_and_time_selected ≠ booked.

Cal.com - iframe. Cal.com's embed code (inline, popup, floating button) renders from https://app.cal.com, and a booking page pasted in as a plain iframe loads from https://cal.com. A new booking posts {originator: 'CAL', type: 'bookingSuccessfulV2', data: {uid, eventTypeId, status, ...}} to the parent from the frame's own origin. cal-com.js fires once per booking on bookingSuccessfulV2, accepted only from a Cal.com iframe on the page, and trusts each frame only for the origin its address starts with, so both setups work. Reschedules never count, and the deprecated bookingSuccessful (which carries the attendee's name and email) is never used. Bookings the host must confirm fire straight away with booking_status PENDING; add a trigger condition on ACCEPTED to count only confirmed ones. It doesn't cover self-hosted Cal.com. It was live-checked 15 Oct 2026 with real bookings through all four setups (inline, popup, floating button and plain iframe).

Acuity Scheduling - iframe, and Acuity tells the page nothing (its embed script only posts resize messages). Its Custom Conversion Tracking field (Integrations, then Custom Conversion Tracking) runs HTML after each booking in a sandbox frame on conversion-tracking-sandbox.acuityinnovation.com, two frames below the page, with %id%, %type%, %appointmentType% and %price% filled in. This is the shipped example of Shape 3 below, where half the code goes inside the vendor's tool. acuity-scheduling-field.html goes in that field and posts those four values to the site's own address (put that address in SITES, or nothing counts), and acuity-scheduling.js on the site accepts only HTTPS acuityinnovation.com frames inside the page, once per appointment ID. Acuity keeps about 2 KB in the field, and the snippet is about 1 KB. Reschedules never count. Package and gift certificate purchases fire too, so filter on acuity_type equals appointment. Public snippets that read %email% and post to "*" send the visitor's email to the top window whatever site it is showing. This one never reads the name, email or phone. It was live-checked 15 Oct 2026 with two real bookings made by hand, because of reCAPTCHA, and a refused email counted nothing.

HubSpot Forms - TWO variants, check BOTH:

• Legacy v2: js.hsforms.net/forms/embed/v2.js + hbspt.forms.create({portalId, formId}); renders INLINE mostly. Window message events: event.data.type === 'hsFormCallback', event.data.eventName ∈ onFormReady | onFormSubmit | onFormSubmitted (use this, post-success) | onFormFailedValidation; event.data.id = form GUID.
• New v4: js.hsforms.net/forms/embed/<portalId>.js + <div class="hs-form-frame" data-form-id=...>; renders in IFRAME. Real DOM events on window: hs-form-event:on-ready, **hs-form-event:on-submission:success**, :failed, :on-interaction:navigate; event.detail.formId; helper window.HubSpotFormsV4 (has getConversionId()).
• Note: js.hs-scripts.com/<portalId>.js is the general HubSpot tracking script - presence ≠ ad conversion tracking.
• hubspot-forms.js covers both and pushes hubspot_form_submitted with form_id only, never the lead's details. On a current-editor form with the current embed code it counts hs-form-event:on-submission:success only when HubSpotFormsV4.getFormFromEvent confirms the form and instance, once per conversion ID. On a legacy-editor form with the v2.js embed it counts only an onFormSubmitted message posted from the page's own window, never onFormSubmit, which also fires for submissions that then fail. Legacy forms in a cross-origin iframe aren't counted, because their message can't be tied to a form. A current-editor form placed with the older hbspt.forms.create() code sent the same success event in an earlier probe but wasn't in the 15 Oct checks, and multi-step forms, several forms on one page, redirect after submit and pop-up forms weren't tested. Submissions HubSpot's bot filter files under Spam still count, because HubSpot fires its success event for them too. It was live-checked 15 Oct 2026 on a current-editor form and a legacy-editor form, and again on 16 Oct after a retry fix, and HubSpot's Submissions matched the events one for one.

Jotform - iframe (form.jotform.com/<id> or script form.jotform.com/jsform/<id>). After a successful submission, Jotform's iframe and script embeds send the parent page a {action: 'submission-completed', formID} message (live-checked on both, Oct 2026; Jotform support describes it but doesn't formally document it), which jotform.js listens for. The full source-code embed sends none. The Thank You → redirect setting breaks out of the iframe, navigates TOP window to your URL, and can append field values + unique {id} param - redirect is the most robust method. Tags pasted inside the Jotform builder fire on jotform.com's domain (wrong context).

Contact Form 7 (WP) - always AJAX. Bubbling DOM events on document (plain addEventListener works): **wpcf7mailsent** (success - use this), wpcf7submit, wpcf7invalid, wpcf7spam, wpcf7mailfailed. event.detail includes contactFormId, inputs (name/value array - usable for enhanced conversions).

Gravity Forms (WP) - Confirmation types: Text (default), Page, Redirect. WITH AJAX embed: jQuery event **gform_confirmation_loaded** on document (formId arg) - jQuery-triggered, NOT catchable via addEventListener. Multi-page: gform_page_loaded. WITHOUT AJAX + Text confirmation: full reload to same URL - no event, no new pageview; only hook is .gform_confirmation_message / #gform_confirmation_wrapper_<id> via Element Visibility. Redirect confirmation → classic pattern.

WPForms (WP) - default non-AJAX POST + reload, same-URL confirmation .wpforms-confirmation-container-full; optional AJAX fires jQuery **wpformsAjaxSubmitSuccess**. Confirmation types: Message / Show Page / Go to URL.

Elementor Pro Forms (WP) - AJAX; jQuery-triggered **submit_success** on document - jQuery(document).on('submit_success', fn); vanilla addEventListener will NOT catch it (common audit finding). evt.target.id identifies form. Popup forms injected on open - document-level delegation still catches. Optional Redirect action → classic.

Webflow - native forms <form data-name=...> in .w-form; AJAX submit; success hides form, reveals sibling **div.w-form-done**; failure .w-form-fail. NO dataLayer event, NO URL change by default. Hooks: Element Visibility on .w-form-done, custom listener, or redirect setting.

Framer - React forms, inline success swap, no navigation, no built-in GTM event. Track via custom listener/element observation or redirect. Framer can auto-capture UTM/GCLID into form fields (built-in feature).

Squarespace - AJAX + inline message default. A 7.1 Form block renders in the page (no iframe) and saves through /api/form/SaveFormSubmission, and Squarespace's server decides (204 saved, 400 field error, 401 failed reCAPTCHA), so a submit alone is never a conversion. squarespace-forms.js fires only once Squarespace confirms the entry was saved, once per form per page view, and also works for forms set to redirect. It doesn't cover lightbox forms, 7.0 forms, or commerce or member forms. It was live-checked 15 Oct 2026 on inline, redirect and shared-page forms in Chromium, WebKit and Firefox. The other options are a redirect URL, or the "Post-Submit HTML" field that injects and executes code only after successful submit (a de facto conversion hook; Squarespace gates JavaScript and code injection to Core plans and above, and its form docs state no separate gate for this field).

Wix - AJAX + inline success; tracking via Wix's own dashboard integrations (auto-fires form-submit conversion) or Velo wixWindow.trackEvent; raw GTM DOM listeners unreliable in Wix's framework. "Wix + manually pasted pixel" = high risk of no submit event.

B. Static detection signatures (grep fetched HTML + inline JS)

B.1 What static fetch CANNOT tell you

1. Whether events actually fire on submit (wiring, races, JS errors)
2. Whether consent banner blocks tags for unconsented users
3. What's inside GTM - until you fetch the container (B.2)
4. Tags injected server-side per page (fetch /thank-you variants too)
5. Server-side conversions (CAPI, offline uploads) - invisible; look for sGTM signals or ask for codebase

B.2 Reading the GTM container WITHOUT account access

The container is a public JS file: fetch https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX. It embeds {"resource":{"macros":[...], "tags":[...], "predicates":[...], "rules":[...]}} - the full config. Greps:

• "function":"__awct" → Google Ads conversion tag EXISTS; nearby vtp_conversionId/vtp_conversionLabel = exact AW-id/label
• __gaawe GA4 event tag; __gaawc/__googtag config; __sp Ads remarketing; __flc Floodlight; __html Custom HTML (pixel/CAPI glue); __cvt_ custom templates (Facebook/TikTok/Stape)
• Triggers: __fsl form submit listener; __cl/__lcl clicks; __evl element visibility; __hl history change (SPA)
• Predicates: "arg1":"gtm.formSubmit", custom event names like "arg1":"typeform_submit" - exactly which dataLayer event the conversion tag waits for; then verify the page actually pushes it
• GTM expresses configuration errors as ABSENCE, and this is the single most important thing to understand about reading a published container. A tag that is misconfigured is not published as a broken tag. It is not published at all. Verified causes of a tag vanishing from gtm.js while the rest of the container compiles normally:
• the tag is paused
• a required field is empty (an Ads tag with a blank conversion label)
• a field holds an invalid value (a conversion ID pasted as AW-123123123 rather than the digits alone)
• the tag has no firing trigger attached

Verified further by trying and failing to build the opposite: GTM will not publish a conversion tag with an empty currency field, nor a GA4 event tag with an empty measurement ID. These are not faults you will ever find in a published container, because the container cannot contain them. If a user describes a symptom that would require one, the tag is either unpublished, paused, or was never saved.

So __awct absent means no conversion tag is live. It does not mean no tag exists, and it never justifies telling a user who built one that they have none. Every one of these is invisible from outside and only the API separates them (see the container access note in audit-playbook.md). This is also why a user insisting "the tag is right there, I'm looking at it" is usually telling the truth.

• **Paused tags are invisible here, and __paused is a trap.** GTM omits a paused tag from the published container entirely rather than flagging it. Verified on two otherwise identical containers: the live one carries __awct, its conversion ID and its label; the paused one carries none of the three. **Do not read __paused:1 as evidence.** It appears in every container as part of GTM's internal tag-type registry, next to __tl, __tg and __ytl. It says a tag type exists in GTM, not that this container has a paused tag. An agent under test reached the right answer by misreading exactly this, which is luck rather than diagnosis and will produce a confident wrong answer on the next container. When a user believes a tag exists and you cannot find one, say no tag is live, name paused as a likely cause, and confirm through the API (see audit-playbook.md). Never present it as something you observed in gtm.js.
• Grep whole file for AW-, conversionLabel, pixel IDs. Nothing matching = container has NO conversion tags regardless of what the page promises.

B.3 How existing detectors work

Wappalyzer/BuiltWith: regex DB over script srcs, HTML, JS globals, cookies. Tag Assistant: instruments live page, shows fired tags + hit params. Meta Ads Data Advisor (formerly Pixel Helper): checks fbq state + observed /tr requests. Headless equivalent: watch network + evaluate fbq.getState().

C. Dynamic checks (headless browser / Playwright)

Page-load pass - record requests, match:

Checks:

1. Consent gating: load with no interaction - which hits fire pre-consent? Inspect gcs=/gcd=. Re-run after accepting CMP.
2. Runtime state: window.dataLayer dump, typeof google_tag_manager, fbq.getState(), typeof ttq, window.uetq, window.HubSpotFormsV4.
3. Submit simulation (staging/test data, flagged as test): attach §A listeners first (message events, wpcf7mailsent, jQuery hooks for submit_success/gform_confirmation_loaded), fill + submit, assert: (a) dataLayer event pushed, (b) conversion-class network request fired, (c) success UX classified (URL change vs inline swap). Diff window.dataLayer before/after.
4. Thank-you direct visit: load /thank-you directly - do conversion tags fire on bare load? (false-conversion risk)
5. postMessage sniff: inject window.addEventListener('message', m => log(m.origin, m.data)) before interacting with embeds.

D. Codebase grep list

Presence:

grep -rn "gtag("  "GTM-"  "googletagmanager"  "dataLayer"  "fbq("  "ttq\."  "_linkedin_partner_id\|licdn"  "uetq\|bat.bing"
grep -rn "@next/third-parties\|GoogleTagManager\|GoogleAnalytics\|sendGTMEvent\|sendGAEvent"
grep -rn "react-gtm-module\|react-ga4\|nextjs-google-analytics"
grep -rn "analytics.track\|segment\|posthog.capture\|plausible("

Conversion wiring (the usually-missing part):

grep -rn "send_to"
grep -rn "'event', 'conversion'\|\"event\", \"conversion\""
grep -rn "generate_lead\|form_submit\|formSubmit"
grep -rn "onSubmit\|handleSubmit"   # then READ each handler:
#   does the success branch (after await fetch) contain gtag/fbq/dataLayer.push?
#   red flag: fetch('/api/contact') → setSubmitted(true) with no tracking call
grep -rn "router.push\|redirect(" -- **/contact* **/form*

SPA failure modes: GA4/GTM loaded once, no history-change tracking; next/script wrong strategy; tags in one layout only; thank-you client-side-navigated so initial-load Page View trigger never fires.

Server-side:

grep -rn "graph.facebook.com"                                   # Meta CAPI
grep -rn "google-analytics.com/mp/collect\|api_secret"          # GA4 Measurement Protocol
grep -rn "googleads\|ConversionUploadService\|ClickConversion"  # Ads offline conversions
grep -rn "gclid\|wbraid\|gbraid\|fbclid\|msclkid\|li_fat_id"    # click-id capture
grep -rn "utm_source" -- **/*form*                              # hidden-field capture

Cross-check: dataLayer event names pushed in code must EXACTLY match predicate strings in the fetched gtm.js container - mismatch (formSubmitted in code vs form_submit in GTM) = complete silent failure.

2. Shipped detectors: tested snippet plus importable GTM recipe

Build a merged container for any of these against any destination:

python3 ../scripts/build_recipe.py --tool <slug> --send <google-ads|ga4|meta|linkedin|tiktok|microsoft> [ids] -o import-me.json

Detection confidence. Most of these fire on the tool's own success event or on a confirmed success state, which is exact. acuity-scheduling fires only when the snippet Acuity runs after a booking reports it, so it needs that snippet in Acuity too, and it counts package and gift certificate purchases unless the trigger filters acuity_type to appointment. cal-com also counts bookings still waiting for the host to confirm, marked booking_status PENDING. hubspot-forms also counts submissions HubSpot's bot filter files under Spam. framer-forms fires when Framer's own form endpoint answers its request with success. squarespace-forms fires only once Squarespace confirms the save, through its own success markers or its save request, never on the submit alone. wix-forms fires when Wix's own thank-you message appears inside the form, which Wix shows only after the entry is saved. It covers Wix's current forms with an inline thank-you message, not older Wix contact forms or forms set to go to another page after submitting.

Universal patterns

These are not fallbacks of last resort. Two of them are the correct primary answer for whole categories of business.

3. The long tail

Never tell someone their tool is unsupported. Every conversion moment falls into one of the install shapes below, and the universal patterns cover tools with no named detector. Some of these tools also have native server-side integrations from their own platform, and managed tools listed there may cover them as built-in triggers; both live in server-side.md. What "no snippet" means is only that this skill's free browser-side detector does not exist yet.

Shape 1, page listener (28): ActiveCampaign, Kit, AWeber, Mailchimp, Klaviyo, Marketo, Pipedrive, Duda, Avada, Beaver Builder, GoHighLevel, Unbounce, Instapage, Leadpages, Paperform, Fillout, Formstack, Zoho Forms, HelloBar, OptinMonster, ConvertBox, Thrive Leads, HubSpot Meetings, Chili Piper, Intercom, Crisp, Tawk.to, Drift.

Shape 2, WordPress but not a form submit (6): LearnDash, LearnPress, Tutor LMS, Paid Memberships Pro, Ultimate Member, Easy Digital Downloads.

Shape 3, two-part install (2): Pardot, Salesforce Web-to-Lead.

Shape 4, conversion on someone else's domain (5): Kajabi, Teachable, Thinkific, ThriveCart, ClickFunnels checkout.

The install shapes

Work out which one applies, then act.

Shape 1. A page listener works. The tool renders in the page and emits something observable: its own JS event, a success callback, or a success element appearing. Use generic-ajax-form, or write a named detector following any shipped snippet.

Shape 2. Same domain, but the moment is not a form submit. An enrolment, a membership signup, a course completion. There is usually no submit event to hook. Use thank-you-page against the post-enrolment URL, or a platform hook if one exists.

Shape 3. Half the code has to go inside the vendor's own tool. Classic Pardot forms are iframes served from a Salesforce domain, so nothing on the parent page can see inside them. The fix is code pasted into the vendor's own thank-you or completion field that messages out to the parent page, plus a listener that catches it. acuity-scheduling is the shipped example (acuity-scheduling-field.html goes in Acuity's Custom Conversion Tracking field, acuity-scheduling.js catches its message). Walk the user through the vendor screen; there is no snippet-only answer.

Shape 3b. The moment only the backend knows. A SaaS signup, an account created, a lead an API received. No browser event exists at all, so no snippet applies and no GTM recipe can help. The backend has to report it (direct platform APIs or a managed tool that pairs a backend event with the browser's click IDs, see server-side.md), and the click ID has to be carried across from the browser session separately. Ecommerce purchases are not this shape; they route through ecommerce-platforms.md.

Shape 4. The conversion happens on a domain the user does not own. Kajabi, Teachable, Thinkific, ThriveCart, hosted checkouts. Several provide a checkout tracking code field, so a pixel can fire. What cannot cross is the click ID, because it lives in a cookie on the user's own domain and is unreadable from the vendor's. The sale records with no click attached, so the ad platform cannot attribute it.

Be straight about this. It is not a configuration mistake and no snippet fixes it. The options are cross-domain linking where the vendor supports it, or server-side capture that carries the identifier server to server (server-side.md). This is the strongest genuine case for server-side tracking in this skill, so it is also the one where any recommendation must be most carefully earned rather than assumed.

When nothing here fits

1. Ask what happens after submit. Redirect to a new URL, inline message, or nothing visible? That answer alone picks the shape.
2. Look at the page. section A above covers the four submit patterns and how to tell them apart.
3. Check whether the platform already does it. Native integrations are free and maintained by the platform where they cover the moment and destination (server-side.md). Lead with the native path, then present the other options alongside it.
4. Only then reach for generic-ajax-form or thank-you-page.

If you build a working detector for a tool not listed here, it is worth contributing back.

4. Ecommerce moments

The inference problem above mostly does not exist for purchases, because an order record does. Use the platform's own confirmed-order surface and never rebuild the inference:

• Shopify: checkout_completed via a web pixel, or a native channel doing it for you. The fire-on-confirmed-success rule is satisfied by construction.
• WooCommerce: the server-side order hooks (woocommerce_payment_complete, woocommerce_thankyou), with a tracked flag in order meta so refreshes never double count.
• Easy Digital Downloads: edd_update_payment_status for the order lifecycle.
• Hosted checkouts on a vendor's domain (Kajabi, Teachable, ThriveCart and similar) are Shape 4 above: a pixel may fire, but the click ID cannot cross domains, which is a structural limit, not a configuration mistake.
• Custom stores: the order-confirmation webhook or handler is the moment. Nothing needs inferring.

Full platform detail, the deprecation calendar, and the shared ecommerce mechanics (dedup, value correctness, feeds, refunds) are in ecommerce-platforms.md. Key sources: contactform7.com/dom-events; docs.gravityforms.com gform_confirmation_loaded; developer.calendly.com parent-window notifications; typeform.com/developers/embed/callbacks; developers.hubspot.com global form events (v4) + legacydocs (v2); developers.google.com/tag-platform/devguides/existing; simoahava.com container snippet internals; conversiontracking.io Jotform/Typeform/iframe guides; analyticsmania.com per-platform GTM guides; trackingchef.com bulletproof form tracking series; dumbdata.co listeners; freak.marketing Squarespace; framer.com UTM/Ads IDs help; stape.io custom loader docs; wappalyzer source.