What checkout events does DealMaker fire?
DealMaker pushes four events into Google Tag Manager's data layer as an investor moves through checkout, along with extra information about the investor. Its help center also maps each one to a Meta standard event.
| Step | DealMaker GTM event | What triggers it | Meta standard event |
|---|---|---|---|
| 1 | investment_process | Investor submits the first page: email, plus optional name and phone | CompleteRegistration |
| 2 | TOFU | Investor submits the second page, including the investment amount | AddToCart |
| 3 | signed | Investor signs the subscription agreement | AddPaymentInfo |
| 4 | investment_funded | Investor successfully clicks the pay button | Purchase |
Sources: GTM Events on DealMaker and Create a Google Tag Manager account.
Two details are worth knowing before you build anything. DealMaker's two help pages describe step 3 a little differently. One says it fires on signing the subscription agreement, the other ties it to submitting the address and accredited investor section. Check which one your deal actually fires in GTM preview before you rely on it.
The other detail matters more. "Funded" here means the investor clicked pay, not that the money cleared. ACH payments can still fail or get refunded afterward. That's fine for optimization, but it's why the number in Meta should never be your record of capital raised.
How do the events get from DealMaker to Meta?
Through Google Tag Manager, on two paths at once: the browser pixel and the server-side Conversions API. DealMaker already places a GTM container on every investor-facing page. You supply the container ID and build the tags.
- Create a GTM web container. In Google Tag Manager, create an account and a Web container for the raise, then copy the container ID (it starts with GTM-).
- Connect it to DealMaker. In your DealMaker portal, go to Advanced Settings, then Analytics, and paste the GTM ID.
- Add the Meta pixel. In the GTM container, add a Meta pixel base tag that fires on all pages.
- Map the four events. In GTM, create a Custom Event trigger for each DealMaker event name in the table above. Attach a Meta event tag to each, firing the matching standard event. Check in GTM preview what DealMaker sends in the data layer for your deal. If the investment amount is there, pass it as value with currency USD on the Purchase event, and attach an event ID (more on that below).
- Add the server-side path. This is the Conversions API, and it's the part most raises skip. The most reliable route is DealMaker's webhooks: DealMaker posts each funded investment to a server you control, and that server sends it to Meta. The two routes are below.
- Test before spend. Use GTM preview and Meta's Test Events tool in Events Manager to walk a test investment through all four steps.
Route 1: DealMaker webhooks to the Conversions API (recommended)
DealMaker's developer API can send a webhook to a URL you choose when an investor is created, signs, becomes fully funded, or is countersigned. The funded webhook, investor.funded, fires when the investor's funding state actually becomes funded. That's a truer signal than the browser event, which fires on the pay button click.1
The payload carries the investor's email, phone, and investment amount, plus a unique event_id for each event. DealMaker retries a failed delivery five times over roughly an hour, then emails you.
- Get developer permissions. Ask the DealMaker team to enable developer permissions on your deal. Webhooks are set per deal.
- Stand up a receiving endpoint. A server-side GTM container (Stape is a common host) with a webhook data client, a small serverless function, or a no-code tool like Zapier or Make for low volume.
- Turn on webhooks in DealMaker. Open the dropdown menu in the top right corner, select Integrations, enable webhooks, paste your endpoint URL, and set a webhook secret. Choose the deal and an email for error alerts.2
- Verify every request. With a secret set, each request carries an
X-DealMaker-Signatureheader. Reject anything that doesn't match. - Map funded to Purchase. For each
investor.fundedevent, send Meta a Purchase with the investment amount as value, the currency, hashed email and phone, the offering page URL as the event source, and DealMaker'sevent_idas the event ID. Mapinvestor.signedthe same way if you optimize to signatures.
Two things to plan for. A webhook comes from DealMaker's servers, not the investor's browser, so Meta has no cookie or device data to match on. It matches on email and phone, which a funded investor has always given you. And Meta rejects any event with a timestamp more than 7 days old, so a backfill of older funded investors won't go through this way.3
Route 2: DealMaker's built-in server-side tagging
DealMaker also supports server-side tagging inside GTM. You point your GTM tag at DealMaker's server URL (https://analytics.dealmaker.tech) and tick a checkbox in the portal, and GTM's calls route through DealMaker's own server instead of Google's, which keeps browsers from blocking them.4
That helps the browser events arrive. It isn't a Conversions API connection. DealMaker's public documentation doesn't describe adding a Meta Conversions API tag to that server, so if you want to go this way, ask DealMaker support first.
My setup on a raise: the browser path for the first three steps, and the webhook route for funded investments. If you do both for the same step, read the next section before you launch.
Why do the pixel and the Conversions API need the same event ID?
So Meta counts one investment as one investment. When the browser pixel and the server both report the same funded investment, Meta needs a way to tell they're the same event. Its recommended method is a matching pair: the pixel's eventID has to equal the Conversions API's event_id, and the event names have to match too.
When both match and arrive within 48 hours of each other, Meta keeps one and discards the other. When they don't match, Meta sees two investors.5
That sounds like a reporting problem. It's worse than that. Meta optimizes on what it receives, so double-counted funded investments make the campaign look twice as efficient as it is, and Meta goes chasing more of a result that partly doesn't exist.
In GTM, the cleanest way to do this is one unique ID generated when the event fires, passed to both the pixel tag and the server-side tag. Most server-side Meta tag templates have a field for it. Fill it.
The webhook route needs one more decision. The browser's pay-button event and DealMaker's funded webhook happen at different moments and carry different IDs, so if both are sent as Purchase, Meta counts every investor twice. Pick one owner for Purchase. I give it to the webhook, since that's the investment that actually cleared, and send the browser's pay-button click as a custom event such as PaymentSubmitted.
Which event should an investor campaign optimize for?
The deepest one Meta sees often enough to learn from. Ideally that's Purchase, the funded investment, because that's the person you actually want more of.
Volume is the catch. Meta's learning phase guidance talks in terms of about 50 results a week per ad set, and a smaller raise may only see a handful of funded investors a week. Optimize for an event that rarely fires and the campaign never settles.
So walk back up the funnel only as far as you have to. Signed is a far better proxy than a lead, because signing the subscription agreement is real intent. AddToCart, where the investor enters an amount, comes next. Registration is the last resort, and it's the one most likely to fill your funnel with people who never fund.
Whatever you optimize for, keep sending all four events. Meta still uses the deeper ones, and you'll want them when volume grows enough to move the optimization down a step.
How do you know it's working?
Compare Meta's count against DealMaker's. Everything else is a supporting check.
Start in Meta Events Manager on your dataset. Open the Purchase event and look at how it's being received. You want to see both browser and server listed. Server-only or browser-only means one path is broken. Then look at the deduplication details for that event. If Meta reports events coming from both sources but nothing being deduplicated, your event IDs aren't matching.
Event match quality is the next stop. It scores how well Meta can tie each server event to a real person, based on the customer information you send with it, such as hashed email and phone. A funded investor has already given you both, so a low score on Purchase usually means the server tag isn't passing them.
Then do the check almost nobody does. Pick a recent week and count funded investments in DealMaker. Count total Purchase events Meta received in Events Manager for the same days, not the attributed conversions in Ads Manager, which only include people Meta credits to an ad. The two numbers should land close. Meta well above DealMaker usually means double counting. Meta well below usually means the server path is missing events.
Here's what I'd do this week if you're mid-raise: run one test investment through the checkout (ask DealMaker first how they want test transactions handled on a live deal), watch it arrive in Events Manager as a single deduplicated Purchase, and put a standing calendar reminder to reconcile Meta against DealMaker every Monday until the raise closes.
If you'd rather have someone build and verify this before the next flight of ads goes live, that's the kind of setup I take on as a fractional operator. You can tell me about the raise here.
1 DealMaker API documentation, webhooks section
2 Configuring Webhooks, DealMaker
3 Server Event Parameters, Meta for Developers
4 Create a Google Tag Manager account, DealMaker
5 Handling Duplicate Pixel and Conversions API Events, Meta for Developers
Also: Facebook & LinkedIn pixel integration through GTM, DealMaker; Special Ad Categories, Meta for Developers. DealMaker's event names drive this article; they are re-checked against its help pages on every update.