How do trade show leads get into Marketo?
Three routes end in a person plus a program membership: a vendor connector over REST, a CSV import into the program, or Salesforce first.
Pick the route by what has to exist after the scan. Three things: a person Marketo can identify, membership in the right event program, and a status that says a conversation happened. Judge any route on those resulting records, whichever component writes them. A person upload with no membership and no status passes one of the three.
Vendor connector over REST. The vendor writes the person through Adobe's APIs, and either it writes the membership and status too or a Marketo Smart Campaign does it on the Push Lead activity. Either is fine; the docs or the configuration have to show which. Tendro's connector is built on request from the existing sync layer, typically live within a day, and it gets held to the same test.
CSV import into the program. Open the event program, Members tab, Import Members, map the columns, pick the Member Status before you import. Adobe documents the program import workflow. Keep the real scan time in a mapped column. A database-only import still needs the membership step afterwards.
Salesforce first, then sync. Write the Lead or Contact plus the Campaign Member in Salesforce, and let the native connector and the program pairing carry it into Marketo. The event-to-CRM sync guide covers the surrounding flow. The conditions for this direction are in the sync-direction section below.
Munchkin cannot see a booth. Adobe's Munchkin docs describe JavaScript tracking of page visits and clicks. A badge scan is a separate write. Website tracking never creates the event record.
Should a booth scan be a Marketo lead or a program member?
Both. The person record holds the contact data. The program membership holds the event touch and the status that attribution reads.
Marketo's API still calls person records "leads". That is a naming habit, not a claim that every Marketo person is a Salesforce Lead. Adobe's Lead Database overview lays out the person and its related objects. Keep the two vocabularies apart in your mapping spec or the Salesforce admin will read "lead" and build the wrong thing.
The person write is POST /rest/v1/leads.json with action: createOrUpdate. There is also POST /rest/v1/leads/push.json, which takes a programName and produces a program-associated activity you can trigger on. Adobe documents both in the Leads API guide. A Push Lead activity is a trigger you can build on; it is not the success status being set, so check the membership afterwards.
Membership is its own call: POST /rest/v1/programs/{programId}/members/status.json, with the statusName and the returned leadId. It creates the membership if missing or updates it if present, and it will not move a member backwards to a lower step. Adobe's Program Members reference keeps status writes separate from member-field writes, which matters for the mapping section below.
Each show keeps its own membership. A buyer who scanned at the spring show and again in the fall should hold two memberships, not one overwritten field. Lead Source can say how you acquired them; the per-show history lives in the memberships. The lead retrieval CRM integration guide has the same argument for the other CRMs.
Which program status should a booth scan set?
Use the booth-interaction status on your Trade Show channel (Visited Booth in Adobe's walkthrough); only qualified conversations reach a success step.
Look at the channel before you pick a label. Adobe's Event program template ships Invited, Waitlisted, Registered, No Show and Attended (success). That is the Event channel. Trade Show is a different channel with different steps, and Adobe's own event program guidance shows Influenced as the out-of-box success and walks through one team choosing Visited Booth instead. That walkthrough is one configuration, not a survey of what instances use. Your admin's channel definition is the one that counts.
Registered means pre-show intent. A scan at the booth is not that. Use whatever your instance calls the interaction step. Success works mechanically: a member reaches a status your channel marks as a success step, and that is what the attribution reports count. So a raffle-entry scan and a qualified conversation need to land on different statuses, which means the scan carries a qualifier (a tag, a question answer) that the write or a Smart Campaign maps to the right step. Adobe's membership guidance draws the same line between a webinar registration and actual attendance.
Acquisition and influence are separate ledgers. In Revenue Cycle Analytics, First-Touch credits the program that acquired a new name and Multi-Touch spreads influence across the cycle. Adobe explains both in its attribution overview and its event marketing guide. Leave an existing person's Acquisition Program alone; attendance at your booth does not make you their first touch.
Marketo Measure runs on its own touchpoint rules. Its Programs integration can key off program fields and standard membership fields, exposes the membership date, and sends you to an Activities rule if you need the status-change date. Program member custom fields are not supported by that integration, so the booth and qualifier fields recommended below cannot drive Measure touchpoint rules on their own. Success in the program does not automatically mean the same credit in RCE and Measure, so the test plan below checks both.
Which Marketo fields should an event scan populate?
Identity goes to person fields. Booth, rep, scan time, notes and qualifiers go to program member fields, so one show never overwrites another.
Sign off the mapping before anyone scans. This is a recommended spec, not a description of what every connector does. Confirm the REST names and writable types in your instance's Describe responses first.
| Captured information | Where it should land, and how |
|---|---|
| Email, first name, last name, phone, title, company | Standard person fields where writable. A blank capture never overwrites a trusted existing value. |
| Event name and event identifier | Resolve to the specific program. A person-level "latest event" field is a convenience, never the record. |
| Booth | Program member custom field, so the next show's booth cannot overwrite this one. |
| Capturing rep and assigned rep | Two member custom fields. Who scanned and who owns the deal are different questions. |
| Scan time | Member custom datetime with the real capture time and an agreed timezone rule. |
| Conversation notes | Member custom field if the type and length fit; otherwise an agreed external record reference. |
| Custom qualifiers | Member custom fields for event-specific answers. Person fields only for durable profile facts. |
| Lead Source vs program | Keep your acquisition-source policy. The individual event touch is the membership, not the source. |
Sources: Adobe's person field metadata and program member fields. The placement and overwrite choices are ours.
One capacity check before you approve it. Adobe allows 20 program member custom fields per instance, shared across every program, in a limited set of types. The table above spends four of them (booth, capturing rep, assigned rep, scan time), a fifth if notes live there, and one more per mapped qualifier, so a booth with three qualifiers uses eight. If webinars and field events already use most of the twenty, keep person fields for durable profile facts only and put the overflow event qualifiers in a program-linked external record (the same fallback the notes row uses), with a named owner for that policy.
Member fields have their own endpoint, POST /rest/v1/programs/{programId}/members.json, separate from the status call. In the flow described here a scan is three operations (person upsert, status, member fields). It drops to two only when no member fields are mapped, and the person upsert still runs on a rescan because identity data may have changed. The spec has to say what happens when the person write succeeds and the membership write fails. The failure mode to design against is a person record with no event context that enters the follow-up workflow anyway.
The "latest event" trap is real. If a second scan overwrites a person field while a campaign is still waiting on it, the campaign reads the wrong show. Membership fields keep the context where it belongs. For a Money20/20 booth the qualifiers that end up in member fields are typically the payment products in scope and the integration timeline; the fintech conference capture guide has the show context.
How do you dedupe event leads in Marketo?
Upsert on email as the lookupField, serialize writes for the same address, and decide up front what a personal email or a partition does.
lookupField: email with createOrUpdate is the standard path. Adobe's upsert docs warn that simultaneous calls on the same key can create duplicates, which is exactly what three reps scanning the same prospect produces. Serialize by email and keep the returned person ID for the membership writes.
A personal email is a different key. Gmail on the badge will not match the work address already in Marketo, and no amount of name-plus-company fuzzy matching should merge two people on its own. Decide which address identifies the person, park uncertain captures for review, and write down what to do with the duplicates you already have.
Partitions need a decision too. Adobe documents partitionName on supported creates and partition-access errors on updates, and whether partition is part of your dedupe rule depends on your custom rules. Email lookup alone does not buy global uniqueness across partitions.
Test the returning buyer twice. Expected: the same person, a new membership for this show, the old one intact. Then a second scan of the same person at the same show: notes update, no duplicate. The dedupe rule has to keep both interactions and add one membership.
Which event lead capture apps integrate with Marketo?
Cvent iCapture, Captello, Momencio, Mobly and Popl document a Marketo connection. Few say which status they set. Tendro builds its on request.
The comparison criterion is the documented write: person, membership, status, fields. This is Tendro's blog, so read the Tendro row as the vendor describing itself. The table is what public documentation said on September 10, 2026; where a guide would not load, the cell says so rather than guessing.
| Vendor | Mechanism | What it says lands in Marketo | Source URL |
|---|---|---|---|
| Cvent iCapture | Direct Marketo connection | "Send leads directly." Program status and custom-field mapping are not documented publicly on the product page. | iCapture |
| Cvent LeadCapture | Marketo LeadCapture integration listed in Cvent's learning center | The setup article would not load during research. Person, status and custom-field writes: not documented in what was reachable. | Cvent integration docs |
| Captello | Direct Marketo integration | "New and updated leads", Marketo Custom Objects, adding to campaigns. Program member status and person-field mapping: not documented in the announcement. | Captello Marketo announcement |
| Momencio | Marketo connector with a scheduled contact sync | Contact fields, list selection, "Create Market Program for every momencio Event" (leaflet wording). Membership status and custom-field writes: not documented there. | Momencio Marketo leaflet |
| Mobly | Marketo guide listed in the help center | "How to Connect Marketo Programs to Mobly Events" exists as a title; the guide itself would not load. Writes: not documented in what was reachable. | Mobly integrations index |
| Popl | Vendor-described native connector | Person records and program membership; captured data, qualifier answers and tags map to configured fields. The member status set: not documented on the page. | Popl Marketo integration |
| BoothIQ | No Marketo integration on the reviewed page | The integrations page documents Salesforce and HubSpot. Marketo writes: not documented publicly. | BoothIQ integrations |
| Tendro | Built on request from the existing sync layer, typically live within a day | You specify: person upsert on email, target program, the member status, standard and custom person or member fields. Build requirements, not shipped behaviour. | Tendro Marketo page |
Cvent's broader Marketo connector documents event activity, contact changes and custom data. Work out which Cvent product and configuration produces those writes before you assume booth capture gets them. Captello's "campaign" wording likewise says nothing about which success status you end up with.
The cross-CRM version of this table, HubSpot and Salesforce and Pipedrive included, is in the event lead capture CRM sync comparison. For Marketo specifically, ask any vendor for one sample record showing the person, the membership, the status and the mapped answers together. A screenshot of a person record does not show membership, status or mapped answers, so it does not count.
Marketo or Salesforce first: where should the scan be written?
Marketo first if attribution lives in Marketo programs. Salesforce first if sales governs event membership there. Never both independently.
This is a workflow call, not an Adobe rule. Marketo first lets marketing set membership and success before the CRM handoff. Salesforce first puts routing in the system sales actually lives in, but then needs a deliberate path back into the Marketo program.
The native sync is not instant replication. Adobe says each Salesforce sync cycle pauses five minutes after it completes. Salesforce-created Leads and Contacts enter Marketo through that connector when they are visible to the sync user. A new Marketo person needs an explicit creation action such as Sync Person to SFDC; a database insert is not an export trigger.
Pair the attribution records on purpose. Adobe's program-to-campaign sync keeps members and statuses aligned in both directions, provided the campaign statuses match. A Salesforce-first write with no Campaign Member and no pairing leaves the event invisible in Marketo, which is the failure mode this whole post exists to prevent.
One entry route per scan. Writing to both systems independently doubles the matching and nobody owns the retry. Check the Campaign Member next to the program member using the Salesforce event attribution guide. With Tendro's Salesforce integration, Campaign Member is wired on request, and the email match checks Leads, not Contacts. All of this is the native Marketo CRM connector, not Marketo Sales Connect.
How do you test a Marketo event integration before the show?
Desk-scan a new person, an existing one, and a repeat. Check fields, status, the failed-write recovery, offline replay and the Salesforce handoff.
Test the configuration you will run at the show, with the test people fenced off first. For a show like Money20/20 USA that means the actual program and mapping, test people named as such, and a suppression list that keeps them out of live sends, sales alerts and reporting before the first scan. Run the failure injection in an isolated program, then a bounded verification in the real one. A dashboard that says Connected proves the token works and nothing else.
- Confirm program, channel, allowed statuses, the success definition, API permissions and partition access.
- Scan a new person, an existing person, and the same person again. Include one personal email and one capture with no email.
- Check member fields, the real scan time, acquisition handling and the success flag. Reconcile created, updated, skipped and failed.
- Check attribution in both tools: in RCE, the test person's First-Touch stays with their existing Acquisition Program and the show appears under Multi-Touch with the success date; in Marketo Measure, one touchpoint on the membership date (or the status-change date if you built the Activities rule) and no second touchpoint from a paired Salesforce Campaign.
- Force a failed membership write after a successful person create. Recovery must finish the event record without a second person.
- Capture offline, reconnect, confirm the timestamps survive and the follow-up does not fire twice.
- Look at the Salesforce side and the linked Campaign Member. Time that handoff separately from the Marketo write.
Budget the API. Adobe documents 50,000 calls a day as the base quota, 100 calls per 20 seconds, and 10 concurrent calls per instance, shared by everything else you have plugged in. Queue with controlled retries and read the response body, because a 200 can still carry a failure.
Time the handoff to the rep separately: from scan to a record with email, event, status and notes in the rep's queue. The real-time CRM sync guide covers what delivery looks like on the CRM side, and speed to lead for trade shows has the contact-odds numbers that make the clock matter.
How does Tendro work with Marketo?
Built on request from the existing sync layer, typically live within a day. You specify program, member status and fields, and review a test record.
Ask for the connector from the chat bubble in the app and attach the spec: person object, dedupe key, partition, target program, exact channel status, custom-field destinations, overwrite rules, Salesforce handoff. Make a reviewed test record the acceptance condition before the show. The commitment is built on request from the existing sync layer, typically live within a day; there is no preset Marketo connector today.
Pricing is $499 per event with unlimited team members, unlimited devices and scans. CRM sync starts with the first paid event, not in the free trial; the free trial is for testing capture on your old badge stack. Running several shows? Get a season quote, volume discount from 10+ events.