Every dealer who runs a Meta Instant Form or a Google lead form extension makes a data-ownership decision in the moment the form goes live. Almost none of them know they're making it. The question isn't which CRM to use. The question is who controls the lead between the ad and the CRM inbox.
The answer, for most dealers, is someone else.
That someone else might be a platform, a third-party routing tool, an agency-managed integration layer, or a vendor that sits between the ad network and the dealer's system of record. The buyer's form response, submission timestamp, vehicle interest, and source channel all flow through that layer first. When the vendor relationship ends, so does the dealer's access to the data inside it.
Where Does the Lead Actually Land?
When a buyer submits a Meta Instant Form, the lead doesn't automatically appear in the dealer's CRM. Meta stores Instant Form submissions in the Meta Leads Center by default, where they can be downloaded manually or routed through an integration. That integration is the decision point nobody examines at onboarding.
The three most common routing paths are: a platform-native download (manual, no real-time delivery), a third-party bridge that maps Meta fields to a CRM schema the vendor controls, or a direct webhook that delivers the lead to the dealer's own routing inbox in the automotive-standard format.
The first two paths have a structural problem. The schema lives in the vendor's system. The field mapping is owned by the vendor. The submission history is stored in the vendor's database. When the dealer switches CRM systems, changes agency relationships, or simply lets a subscription lapse, the historical lead data doesn't follow the dealer. It stays in the system where it landed.
This is not a hypothetical edge case. It is how most lead routing is built today, and most dealers never ask about it because the vendor's onboarding flow doesn't surface the question.
Why Does the Lead Delivery Path Matter More Than the CRM You Choose?
Dealers spend real energy evaluating CRM systems. They compare features, pricing, integrations with the manufacturer, and how well the platform handles follow-up sequences. That evaluation is worth doing. But it starts one step too late.
The lead delivery path is upstream of the CRM. It determines what data the CRM receives, in what format, at what latency, and with what history. A dealer who owns their CRM but routes leads through a vendor-controlled bridge doesn't actually own the lead record. They own the CRM's copy of what the vendor chose to send them.
That distinction matters at two specific moments: when something goes wrong, and when the vendor relationship ends.
When something goes wrong, the dealer who routes through a third-party bridge has to ask the vendor what happened. Did the form submission reach the bridge? Did the bridge fire the CRM webhook? Did the field mapping fail on a new form question? The audit trail lives inside the vendor's system. The dealer can see the CRM record, but they can't see what happened before the record was created, or what was dropped along the way.
When the vendor relationship ends, the gap is more permanent. The historical form responses, the source attribution per lead, the submission timestamps that tie a sale back to a specific campaign and ad, all of that lives in the vendor's database. Dealers who have tried to pull that data on the way out of a contract know how the conversation goes.
What Happens to Your Lead Data When the Vendor Contract Ends?
The industry has a phrase for it: data portability. Most vendor contracts acknowledge it in principle. In practice, what gets exported is a flat file with the fields the vendor decided to capture, in the format the vendor supports, for the time window the vendor's export tool covers.
The buyer's original form response, verbatim, including the specific vehicle they asked about, the trade-in they mentioned, and the contact-preference field they answered, may or may not survive that export. It depends on the vendor's schema, the vendor's export tooling, and whether the dealer knew to ask for it before the contract ended.
Source attribution is usually the first thing to go. The field that ties a CRM lead back to a specific Meta campaign, ad set, and ad is not a standard CRM field. It's a UTM parameter or a platform-specific lead ID that the routing layer either passes through or doesn't. Vendors that don't pass it through consistently leave dealers with a CRM full of leads and no way to trace which campaign generated which sale. This is a documented problem in automotive digital marketing: lead source attribution degrades significantly when leads pass through intermediary routing layers that do not preserve platform-native metadata.
The dealers who feel this most acutely are the ones trying to understand what their ad spend actually produced. If the path from form submission to CRM record ran through someone else's system, the answer to that question is sitting in a database the dealer no longer has access to.
Is the Problem the Platform, or the Layer Between the Platform and Your CRM?
The platforms themselves are not the problem. Meta's Marketing API supports real-time lead delivery via webhook, where a verified endpoint on the dealer's side receives each form submission as a structured payload the moment the buyer hits submit. Google Ads supports lead form assets with webhook delivery to a dealer-controlled endpoint, including a polling backstop via the GAQL API for leads that don't deliver via webhook within the initial window.
The problem is the intermediary layer that most dealers never knew they chose.
When an agency sets up a Meta campaign with a lead form, the default path is typically to route leads through whatever integration tool the agency already has configured. That tool is often a third-party bridge the dealer has never heard of, connected to a vendor account the dealer doesn't own. The dealer gets leads. The bridge gets the data.
The same pattern shows up with third-party lead management platforms, CRM add-ons marketed as "lead routing" tools, and agency-managed pixel configurations that route conversion data to the agency's reporting stack before it reaches the dealer. Each layer is a point where data ownership transfers away from the dealer, usually without a line in the contract that says so explicitly.
This is the same structural problem that shows up across the ad stack. As we've covered in writing about programmatic advertising's opacity layer, and in why agency accountability is structurally impossible to verify, the pattern is consistent: the dealer pays, the vendor captures, and the data lives somewhere the dealer can't reach when the relationship ends.
How Does ADF/XML Lead Delivery Work, and Who Controls It?
ADF/XML (Automotive Data Format, version 1.0) is the automotive-industry-standard lead format, used by nearly every major CRM to ingest incoming leads from digital sources. It is a structured XML schema that carries the prospect's contact information, vehicle interest, source, and lead type in a format the receiving CRM can parse automatically.
The delivery mechanism is email. An ADF/XML lead is an email sent to the dealer's lead-routing inbox, formatted as an XML payload that the CRM parser reads on arrival. No API keys. No platform accounts. No third-party bridge. The lead goes from the ad platform to the dealer's inbox, in a format the dealer's CRM already understands.
That simplicity is the point. ADF/XML delivery has no intermediary. The dealer's lead-routing inbox is controlled by the dealer. The email is delivered directly. The CRM parses it on arrival. The only record of the lead is in the dealer's own CRM and in their own email infrastructure, not in a vendor's database.
The reason most dealers don't use this path by default is that setting it up correctly requires wiring the ad platform's webhook or polling endpoint to a system that composes a valid ADF/XML payload and routes it to the right inbox. That's not a manual task most agencies or marketing coordinators handle during campaign setup. The default is always the vendor's default, which is almost always the vendor's bridge.
How AUTONOMi Delivers Leads Directly to Your CRM
AUTONOMi delivers every captured lead across Meta, Google, and TikTok as ADF/XML directly to the dealer's own lead-routing inbox, with no third-party bridge and no intermediary vendor database in the path. The lead goes from the platform to the dealer's CRM. That's the entire path.
On Google, AEGIS mints a native lead form asset through the Google Ads API, wires a per-dealer webhook for real-time delivery, and runs a GAQL polling backstop every 10 minutes to recover any submission that doesn't deliver via webhook. On Meta, AEGIS self-heals the Page's lead-generation webhook subscription before every form deploy, so a missing subscription fails the deploy closed rather than shipping a form whose submissions Meta would never deliver. On TikTok, leads arrive via a registered webhook with a 15-minute polling backstop. Every path ends at the dealer's inbox as a valid ADF/XML payload.
A store can name more than one routing inbox, and the same lead delivers to each, which means a dealer group can route the same lead simultaneously to a rooftop CRM and a central BDC inbox without any manual copy or re-routing.
The data-ownership implication is direct. The dealer's CRM holds the record. The dealer's email infrastructure holds the delivery receipt. AUTONOMi holds no lead data in a vendor-controlled database that the dealer would lose access to at the end of the relationship. All platform assets, ad accounts, pixels, and analytics properties operate under dealer ownership, with AEGIS holding delegated access via OAuth that the dealer can revoke at any time. The lead data model is an extension of that principle: the dealer owns the destination, so the dealer owns the record.
This is also why the onboarding brief matters. When a dealer's lead capture first starts serving, AEGIS sends a one-time launch brief that includes the actual form questions read live from each platform, a visual mock of the lead as it appears in the CRM, and an annotated sample ADF for the CRM administrator, so the sales floor knows exactly what to expect before the first lead arrives. That brief is built from the dealer's own account, not a template, and it covers every channel that went live in a single document rather than one per platform.
The Stack You Own Is the Only Stack That Compounds
There is a version of the CRM evaluation conversation that is worth having. It starts with the question of data ownership, not feature sets. Which system holds the lead when it first arrives? Who controls the path it travels? What survives if the vendor relationship ends?
Most dealers are evaluating the CRM while a third-party bridge they've never examined is quietly accumulating their buyer-intent data in a vendor-controlled schema. By the time the contract ends, the history of which campaigns produced which leads, mapped to which sold units, lives somewhere the dealer can't reach. The CRM they evaluated so carefully has a clean feature set and an incomplete record.
The lead delivery path is a first-principle decision. It's also one most dealers have never been asked to make, because the vendor's default makes it for them. That's the gap worth closing first, before the CRM comparison matrix, before the agency RFP, and before the next lead form goes live.
If you're evaluating your data stack now, the right starting point is understanding where your leads actually land and who controls that path. Sign up to see how AUTONOMi wires lead delivery directly to your CRM, with no intermediary, and what the rest of your paid acquisition stack looks like when AEGIS runs it.
