(Qualification)
A conversion the algorithm can learn from.
Define accepted requests and qualified leads, write an event contract, and test deduplication, offline feedback, and privacy before optimizing spend.
(Introduction)
A visitor presses Submit. The browser records an event, the server rejects the request, and the ad report still shows a conversion. That illustrative failure leaves the media buyer optimizing against a count that never became a lead.
Define the business event before selecting the campaign goal. For an education-led B2B campaign, a useful conversion definition states what happened, which system verified it, and what evidence makes it relevant to the business. It also states what the event cannot tell you.
(Give each stage a separate name)
Use a shared event dictionary across marketing, engineering, and RevOps. These are proposed internal names, not reserved names accepted by every advertising platform.
- form_submit_attempt: The browser observed a submission attempt. Useful for diagnosing friction. It does not prove server acceptance, delivery, or buyer fit.
- lead_request_accepted: The backend validated the request, passed the agreed abuse checks, and durably saved a request record. It does not prove the person read the asset or qualifies for sales.
- lead_qualified: The CRM recorded that the lead met a written, versioned qualification rule. Store the reason and decision owner in the CRM.
Qualification might require an in-scope company, a supported use case, and a relevant buying responsibility. Define those terms with sales. Keep readiness separate: a suitable researcher who has requested educational material has not necessarily requested a sales conversation.
Do not label a server event “qualified” simply because it is harder to trigger than a browser event. The distinction is a business rule.
(Select a usable optimization signal)
An event existing in analytics does not mean a campaign uses it for bidding. Google Ads, for example, distinguishes primary conversion actions used for bidding optimization from secondary actions used for observation.[1] Check the actual campaign goal configuration; an event name alone proves nothing.
Review each candidate against relevance, integrity, timeliness, and frequency. Can the team explain its connection to a useful business outcome? Is it consistently recorded? How long does it take to arrive? Is there enough observed activity for the platform and campaign setup being used?
A deeper event may be more relevant and arrive too slowly or infrequently for the intended test. An accepted request may be a practical intermediate signal. If you choose it, document the compromise and monitor qualification separately. There is no universal event-volume threshold in this framework.
Avoid counting both acceptance and qualification as interchangeable successes in one undifferentiated lead total. One person progressing through stages should remain traceable as one journey.
(Write an event contract engineering can implement)
The following is an illustrative internal contract for lead_request_accepted. It is not a ready-to-upload ad-platform payload. A destination adapter must map approved fields to that platform's documented schema.
- Trigger and owner: The application backend commits a valid request record. Emit from the durable event queue associated with that commit, never from a Submit button click or thank-you-page load.
- Identity: event_id identifies this occurrence. request_id identifies the accepted request. Both are opaque, system-generated values, not email addresses or hashes of contact details.
- Version and time: schema_version identifies the contract. occurred_at records acceptance time in UTC. sent_at records the delivery attempt time.
- Context: offer_id and form_id come from controlled lists. Include environment so test records cannot enter production reporting.
- Permission: Evaluate current destination-specific permission before dispatch. Keep the permission evidence in the restricted source system; a flag in a payload cannot grant permission.
- Exclusions: No names, email addresses, telephone numbers, message text, full form contents, or unrestricted URLs in the analytics payload.
Keep any request-to-contact mapping in restricted operational storage. Even an opaque identifier can be linkable personal data; apply access, retention, and permission controls accordingly. Use only the minimum approved fields at each destination.
(Make retries safe and stages distinct)
A network timeout should not create another accepted request. Use an idempotency token for a submission operation, persist it with the accepted record, and return the same result when that operation is retried.
Deliver retries with the same event_id. Give a later qualification its own event_id and link it internally to the request. Define whether qualification is emitted once per lead, account, or buying cycle so a CRM edit cannot silently create another conversion.
If browser and server delivery both describe the same accepted occurrence, share its identity and follow the destination's deduplication rules. If that mapping is unavailable, select one authoritative path. Never assume adding event_id makes every vendor deduplicate automatically.
Preserve the original occurrence time during retries. Track delivery attempts and rejected events separately from business-event counts.
(Return offline outcomes without losing the delay)
Google documents offline conversion imports for measuring outcomes that follow an ad click or call, including later sales activity.[2] The platform's matching requirements, supported import method, and time limits still have to be checked for the implementation in use.
In your internal record, retain acceptance time, qualification time, and delivery status. Reconcile CRM-qualified leads against attempted, accepted, rejected, and unmatched destination records. A successful upload does not by itself prove successful matching or inclusion in bidding.
Report recent leads as pending until they have had a fair observation period. Choose that period from your observed qualification lag, then show late arrivals and revisions. Do not mark an immature group as poor quality because yesterday's requests have not reached sales review.
(Keep contact data out of analytics)
Google Analytics explicitly warns against sending personally identifiable information and identifies page URLs, titles, and user-entered fields as leakage risks.[3] Apply a field allowlist to this event contract and inspect the actual outgoing requests.
A separately approved advertising match integration may have different documented requirements. Keep it separate from general analytics, review consent and policy obligations, and do not treat hashing as permission to transmit contact information.
(Test before using the event to steer spend)
Run this acceptance test with production delivery disabled for synthetic records:
- Valid request: one saved request and one accepted occurrence. Invalid or blocked request: neither is created.
- Double-click, retry, and page reload: no duplicate occurrence for the same submission operation.
- Queue outage and recovery: the stored event is delivered with its original identity and occurrence time.
- Qualification and CRM re-save: one qualification event for the agreed business unit; corrections follow a documented adjustment process.
- Permission denied or withdrawn: unauthorized destinations receive nothing. Recheck queued deliveries before sending.
- Payload inspection: only approved fields leave the application; URLs, logs, and error reports contain no leaked form contents.
Reconcile test results across the application, CRM, queue, and destination diagnostics. Assign engineering to event integrity, RevOps to qualification, and the media owner to goal selection. Record who approves changes to each definition.
For the offer those events measure, read Paid media can't fix a weak asset. To discuss the measurement path around your own acquisition system, Get in touch.
(Sources)
Call us.
312-600-8001
Most companies own an acquisition asset they've never distributed. It's trapped in sales calls, support tickets, and one person's head. Send us a note about what you sell and who buys it.