Every Ad Can Link Your Customer Like a Form Fill

Your customer data platform (CDP) knows a customer only after the customer tells it who they are. They open an email. They fill in a form. Until something like that happens, the person on your pricing page is a cookie with no name.

An ad can make the same link. Delivr serves your ad to a contact on your customer list, with your CDP's own pixel inside the creative, and writes back on your CDP's session ID. Your CDP links its cookie to the customer record the way it does for an email open or a form fill. The customer never has to click, open or type anything.

Delivr is the first to fire your CDP's own pixel inside an ad, with the link already made. I will walk through the mechanism, then the questions I would ask before believing any of it.

How your CDP links a customer today

On its own, a CDP ties its cookie to a customer record only when the customer identifies themselves in that browser. These are the usual moments, and an ad adds one more:

• An email open. The customer opens your email, and your CDP links its cookie to their record.
• A form fill. The customer types their email into your form, and your CDP links the same way.
• A login. The customer signs in, and your CDP ties that browser to their record.
• An identify call. Your site or app tells your CDP who the visitor is, and your CDP links the same way.
• A Delivr ad. The customer sees your ad. We write it back, and your CDP links it as if the customer had identified themselves another way.

A customer whose browser no identifying event has linked yet stays two things in your CDP: a record with a name, and a session without one. The CDP cannot connect them, so the journeys you built for known customers have nothing to act on for that person.

Social list upload does not close the gap. You upload a list and the platform reports a percentage matched. Google says most advertisers see match rates between 29% and 62%. A percentage tells you how much of your file matched. It never tells you which contacts matched, so your CDP learns nothing about any one of them.

How the ad makes the link

Delivr serves your ad to people on your own customer list, with your CDP's pixel inside the creative. The ad goes to a known contact, so the link is already made when the pixel fires. Your CDP sets its cookie and session ID.

Delivr then writes back on that session ID. That write-back is the link. Your CDP receives it the way it receives an email open or a form fill, and connects the cookie to the customer record.

The four steps in words

• Step 1, you send the list. Emails, mobile numbers or both, as plain text. Delivr hashes them on ingest.
• Step 2, DelivrDSP serves your ad. Your CDP pixel sits in the creative, in the place a social platform would put its own.
• Step 3, your pixel fires on the impression and the link is already made. Your CDP sets its cookie and session ID.
• Step 4, Delivr writes back on that session ID. Your CDP links the cookie to the customer record.

Your part is short: send the list, give Delivr your CDP pixel, approve the creative. Delivr also asks you to add one Delivr tag to your site. This post stops at the write-back and does not claim what happens on a later visit.

What comes back

Every matched contact, by name, linked to your CDP's session ID. Not a percentage.

On one Concussion Media client flight, 93% of the contacts on the client's list came back as named contacts in the client's CDP. That figure and a list-upload match rate measure different things. A match rate counts how much of the file matched. The 93% counts contacts that arrived in the CDP with a name on them.

What I will not claim

I am not quoting a lift. Nobody had fired a CDP's own pixel inside an ad with the link already made before, so no benchmark exists, and I would rather you measure your own. The first customers run it as a pilot with a holdout: a group of contacts, chosen before anything is served, who do not get the ad. The gain is the difference between the two groups.

Two limits are built in. A pixel fires only when an ad renders, so ad blockers and lost consent leave gaps. And browsers decide what a cookie can do, so coverage varies by browser in a way that blended reporting hides. Ask for results by browser, and expect the answer to differ.

What each seat at the table hears

A CDP purchase has more than one signature, and each person reads the same offer differently. The Unifying Message approach starts with one sentence that is true for all of them: every ad can link your customer like a form fill. Then each seat gets its own wording.

• Marketing leader. The audience you load is the audience you can see, by name.
• CDP owner. Your pixel, your cookie, your session ID. The link arrives the way an email open or a form fill does, so your segments and journeys can act on it.
• Data engineering. Plain text in, hashed on ingest. Deterministic matching only, with no modeled or probabilistic matches.
• Privacy. A data processing agreement is available on request, and a SOC 2 Type 2 report has been issued.

Questions to ask before you believe it

• Whose pixel fires in the ad: yours, or the platform that served it?
• Do matches come back by name, or as a percentage?
• Is every match deterministic, or are some modeled?
• What do the results look like by browser?
• Is there a holdout, so the gain is measured against contacts who did not get the ad?

Ask them of us too. Once a customer is named in your CDP, the second half of the system applies: person-level intent shows what that person is researching and when. For the definitions underneath, start with what identity resolution is. To see how the ad side is run, read about DelivrDSP.