Stop a Shared Marketo Form From Cross-Firing Alerts

We had two events running the same week. Different audiences, different landing pages, different internal owners watching for registrations. Both landing pages used the same global Marketo form, because reusing one form across programs is cleaner than cloning a new one for every event.

Then I ran a test registration on the first event’s landing page, and the internal alert for the other event fired too. One submission, two notifications, one of them for an event this lead had nothing to do with.

That is a small bug with an annoying blast radius. When you scale it across a real registration flow, the events team stops trusting the alerts, sales gets pinged about the wrong event, and nobody can tell which registrations are real. So I traced it, tried the obvious fix, verified my assumption against actual data, and then got a better pattern from the person who owns our instance. Here is the whole path.

Why This Matters to Marketing Ops

Shared forms are standard practice. One global form is easier to maintain, keeps hidden-field logic consistent, and means you are not chasing the same fix across twenty clones. The trade-off is that a shared form is shared scope. Every program that listens for that form hears every submission to it, no matter which page the visitor was actually on.

If you run events, webinars, or gated content off one form, this is a landmine you will step on eventually. The symptom is subtle: nothing errors, nothing breaks visibly, the right lead still gets created. You just quietly send the wrong internal notification, or count a registration against the wrong program. It is a silent misfire, which is the worst kind, because it looks like everything is working.

The Root Cause: The Trigger Was Listening to the Form, Not the Page

Each event had its own registration smart campaign, and each one triggered on the same thing:

Trigger: Fills Out Form
  Form Name is "[Global Registration Form]"

Both campaigns listened for a fill on that one form. Neither one cared which page the fill came from. So a submission on event A’s landing page qualified event A’s campaign and event B’s campaign at the same time, and both ran their flow, including both “Send Alert” steps.

The form was doing exactly what it was told. The trigger just had no idea the two events were supposed to be separate.

The First Fix, and the Doubt That Came With It

The obvious move is to constrain each trigger to its own landing page. Marketo lets you add a Web Page constraint to the Fills Out Form trigger, so I reached for that first:

Trigger: Fills Out Form
  Form Name is "[Global Registration Form]"
  Web Page is "tcpsoftware.com/lp/event-a/"

Two things gave me pause. First, the Web Page constraint only offers is and is not. There is no contains, so you are locked into an exact match of the full page value. Second, our landing page traffic arrives with UTM parameters and a mkt_tok string on the end. If Marketo compares the entire URL, including query strings, then “is” would never match reliably, because every visitor’s URL is a little different.

I did not want to ship a constraint that works in my clean test and then silently fails the moment a real visitor shows up with tracking parameters. So instead of guessing how Marketo stores the page value, I went and looked.

Verifying the Assumption Against Real Data

I pulled the actual Fill Out Form activity off my test lead’s record through our Marketo integration, rather than eyeballing the campaign. The activity record separates two things I had been treating as one:

Referrer URL: https://tcpsoftware.com/lp/event-a/
Query Parameters: (empty)

That was the answer. Marketo records the clean page URL in one field and stores the query string separately. The UTMs and mkt_tok never touch the page value the constraint compares against. So Web Page is "tcpsoftware.com/lp/event-a/" would in fact match every visitor, clean URL or not, because Marketo strips the parameters off before it ever gets to the comparison.

My worry was wrong, and I could prove it was wrong. That is the part worth internalizing: I did not talk myself into or out of the fix based on how Marketo probably works. I read the record and let the data settle it. When a constraint’s reliability is in question, the form-fill activity log tells you the exact value Marketo captured and compares against, which beats any assumption about URL formatting.

The Better Pattern: Scope by Referrer Contains

Exact match would have worked. But when I flagged the fix to the senior admin who owns our instance, they pointed out a more resilient pattern, and it is the one worth keeping:

Trigger: Fills Out Form
  Form Name is "[Global Registration Form]"
  Referrer contains "event-a"

Referrer contains [slug] beats Web Page is [exact URL] for one reason: it is tolerant of the things that quietly break exact matches. A trailing slash that is there on one page and gone on another. http versus https. A subdomain difference. A query string, if the instance ever does append one to the page value. “Contains” only asks that the unique slug appear somewhere in the referring URL, so it survives all of that. For a form you plan to reuse across dozens of future events, resilient beats precise.

The exact-match version is not wrong. It is just brittle in ways you will not notice until a URL format changes six months from now and a registration alert silently stops firing.

The Fix, End to End

The important detail: you have to scope both programs, not just the one you tested. If you only constrain event A, then event B is still listening to the bare form and will keep firing on event A’s submissions.

Add Referrer contains "event-a" to event A’s Fills Out Form trigger.
Add Referrer contains "event-b" to event B’s Fills Out Form trigger.
Re-test: submit event A’s form and confirm that only event A’s alert fires, and event B’s stays quiet.
Repeat the test on event B’s page for the mirror case.

After the mirrored constraints went in, the test submission on event A’s page fired one alert, to the right owner, for the right event. The cross-fire was gone.

The Reusable Lesson

Two things to take away, one specific and one general.

The specific one: when a single Marketo form is shared across multiple programs, scope each program’s Fills Out Form trigger to its own landing page with Referrer contains [page slug], and always mirror the constraint on every program that shares the form. A shared form is shared scope, and the trigger will hear every submission unless you tell it which page belongs to it.

The general one: when you are unsure whether a constraint will hold in production, do not reason about how the platform probably stores a value. Pull the actual activity record and read the value it captured. The five minutes it takes to check turns a guess into a fact, and it is the difference between a fix that works in your test and a fix that works when a real visitor arrives with a messy URL.

The best version of the fix did not come from me, either. I had a working answer, but the person who lives inside the instance had a more durable one. Bringing a fix to the resident expert as “here is what I did and why, is there a better pattern” is how you turn a one-off patch into something the whole team can reuse.

Have you gotten bitten by a shared form firing across programs? I would like to hear how you scoped it, because there is more than one way to draw that boundary, and I am always collecting the durable ones.