Ad Conversion Tracking

Despite the massive changes to the ad tracking landscape, Marketers still need to tie their advertising efforts to revenue. Executives (rightly) want to ensure they’re spending money in the right places, and they put a lot of pressure on these teams to accurately measure the impact of their efforts.

At some point, this is going to change and we’ll lose some of the visibility and analysis capabilities we’ve grown accustomed to — the US will pass a data privacy bill, penalties from CCPA/CPRA violations will stack up, and the penalties and risks associated with micro-targeted ads and programmatic advertising will grow too high to ignore. Then we’ll need to find new ways to tie our efforts to revenue.

But that’s not happening quite yet, so I’m going to use this post to outline a frustration I’m running into in the meantime.

But first, let’s talk about join keys and data stitching.

Join Keys and Object Relationships

Data stitching is a key element of good data infrastructure. If we take Salesforce as an example, each Object contains a collection of identifiers that outline the relationship it holds to other Objects in the database. A Campaign Member’s identifiers, for example, looks something like this:

• Campaign ID
• Campaign Member ID
• Contact ID
• Lead ID

Using those identifiers, you can then pull in additional information. Using the Campaign ID, you can retrieve information about whatever Campaign this Member is a part of. Using Contact ID, you can pull in data from the associated Contact. And that Contact has its own set of identifiers, like so:

• Contact ID
• Account ID
• Owner ID

And now you’re really cooking with gas. Because using those id values, Contact ID and Account ID, you can then pull in a whole set of other Objects. And so on and so forth. I’m sure there’s a good term for this, but I refer to it as ‘walking through identifiers’ or ‘traversing associated objects’. It’s a powerful thing, and it’s pretty central to working with databases of any real size or complexity.

But this is just one system. What happens when you have more than one?

Data Stitching across Systems

That’s where we start getting into the exciting world of external identifiers. Lets take Marketo for instance. Each Marketo Person has an ID. And stored on that record (assuming you’re synced to Salesforce), you’ll find a SFDC ID. Assuming that value is filled in, Marketo is able to retrieve information from the Salesforce Object that uses that identifiers.

That’s what the ‘sync’ is; it’s a way of saying “This person in system A is the same as this person in system B (based on this set of identifiers) so, on a regular basis, pull information out of system B and add it to this record in system A.”

What’s on my mind is how this concept relates to advertising platforms.

Ad Conversion Tracking

Traditionally, ad tracking was largely script-based. Someone clicked an ad, hit your site, and the script pinged the ad platform and said “hey this person came from us, let’s track that as a conversion.” Some of this tracking was cookie-based; the site hosting the ad stored information in your browser that said “hey we know this person,” the script parsed that information and, again, pinged it back to home-base. Some of it was based on unique query parameters like GCLID — a unique string of numbers and letters letting the script say “oh, this person came from us.”

Now more and more platforms are building out the ability for businesses to set up something that looks a lot more like the Marketo<>Salesforce connection. Through their Conversion APIs, these platforms are allowing businesses to directly communicate their the platform’s systems, notifying them whenever a conversion action occurs. One of the keys to this system is that each platform has its identifier for individuals. Google has GCLID, LinkedIn has li_fat_id, Twitter/X has twclid, Meta has lead_id, and so on. Traditionally, this functionality has been available through ‘offline conversion’ functionality, but it’s always been a bit of a bonus, a way to eke out a bit more data about which campaigns were driving results. Now, it’s starting to become the default, with platforms encouraging new customers to take this approach right from the start.

So that means when you set up a new form with hidden fields, you’re looking at something like this:

• UTM Campaign
• UTM Medium
• UTM Source
• UTM Content
• UTM Type
• Google Client ID
• LinkedIn ID (li_fat_id)
• GCLID
• twclid
• Meta Lead ID (lead_id)

… and so on and so forth for every ads platform your company uses. Or, alternately, some of these platforms allow you to send over the individual’s email address instead so the platform can use that as their join key.

For anyone who’s interested in digging into this for themselves, heres the docs:

• Google Ads
• LinkedIn Ads
• Facebook/Meta Ads
• Twitter Ads

Everyone’s a Data Broker

Aside from my base frustration with the sheer number of hidden fields we’ll all need to start adding to our forms, a lot of these platforms are also pushing for and encouraging a higher level of data sharing than they have in the past. Previously, when we were working in a cookie-centric paradigm, the ad platform received the conversion info from your site and fed that into their existing profile for that individual. Activity-logging, basically, tracking behavior from that user.

Now these platforms are suggesting that businesses share far more than just conversion activity; they’re actively encouraging the sharing of Personally Identifiable Information (PII) in the process. Each of these conversion API endpoints accepts id or email as a baseline, but most also allow businesses to send over:

• Phone Number
• Gender
• Date of Birth
• Last Name
• First Name
• City
• State
• Zip Code
• Country

A recent example within HubSpot’s Google Ads Offline Conversions Setup

The promise is that sending over this data will help you “understand the impact of your ad spend.” Which, to be fair, it might. But in the process you’ve essentially become a data broker, passing the information of your customers back to these platforms. Deprecating 3rd party cookies doesn’t mean these platforms are collecting less information on users — they’re using this as a chance to collect even more. When you start using these APIs, you’re effectively setting up recurring syncs between your systems and these ad platforms, allowing them to consistently update their user profiles with data pulled from your systems.

So What?

If you want to start using Conversion APIs, go for it. They’ll help you track the impact of your ad spend with greater accuracy, you’ll be better prepared for the death of 3rd-party cookies, and you’ll have far more granular control over when and where conversions are logged. I’ll even help you do it.

But do it with your eyes open, and understand the way it affects your relationships with these platforms. Sephora paid $1.2m in penalties to the state of California for giving “companies access to consumer personal information in exchange for free or discounted analytics and advertising benefits” and for allowing “third-party companies access to its customers’ online activities in exchange for advertising or analytic services.” In other words, for doing exactly what I’ve outlined above.

So understand that you’re selling user data to these platforms when you start using Conversion APIs, ensure you’ve received user consent to do so (I can also help with this), and that you’ve looped in your privacy and/or legal team.

And if you figure out a good way to cut down on the number of form fields, I’d love to hear about it.

---

Written by Jack Segal. Shoot me an email with questions or comments, and if you'd like to support my writing, you can send me a tip using Stripe!

---

---

---

---

Subscribe

Fill out the form to get notified whenever a new post goes live!

Enter your email:

Powered by Buttondown.

---

Comments