Modernizing Ad Platform Integrations

There are a lot of changes taking place in digital advertising. Third party cookie deprecation. Ad blockers. The shift to AI. Policy changes. Privacy legislation. Maximizing your results requires that you understand these shifts and modernize your integrations between Magento and the ad platforms to adapt and take advantage of the latest features. In this presentation, we discuss what is changing and provide practical tips around how to modernize your integrations and drive more advertising revenue to your Magento site.

DISCLAIMER: This recording had technical issues impacting audio until 3:40. The transcript below includes those portions for your convenience as well as the rest of the presentation.

TRANSCRIPT

[0:00-3:50] Morning. My name is David. My nickname is Psy. So that’s why Alexandra said Psy Deppner. The topic of today’s talk is really going to be about the things that can improve the ad integrations and improve ad performance across a variety of platforms looking at how some things are changing currently. Psyberware is an ad management company. We’re an agency that works with mostly Magento merchants, some people on different platforms as well. We work with all aspects of these things conversion tracking, shopping feeds, data integrations and all this stuff. But primarily managing the actual advertising campaigns for performance.

So our basic agenda today is just going to be to talk a little bit about some of the changing context what’s going on in the world right now. It’s creating a need to make an update and modernize the ad platform integration. We’re going to dive into the topic of shopping feeds, product data, audiences or customer data. We’re going to talk a little bit about conversion tracking what’s changing right now in that space because there’s a lot going on there. We’ll just wrap it up have some questions if anybody has any. I know everybody’s sites are very different so sometimes the general things we talk about on stage need, you know, your particular site might be different and I’d be happy to talk to anybody about your particular situation.

So the things that are changing right now that are just creating the context of the need to update the ad platform integrations really revolve around Privacy & Automation. So privacy technology is changing all sorts of things going on with third party cookie deprecation, web browsing; there’s a lot of legislation going on in the United States. It’s different in every single state, right? So trying to figure out what we even can and can’t do and what’s legal across the whole country over in Florida versus California. It’s getting a little bit more complicated. In general there’s a shift to non-cookie based methods of tracking users and determining the performance of advertising systems. But we also have a lot of things going on with restrictions on the use of personal data as well and that plays into some of these issues. The other good context is that machine learning systems are taking over.

So if you have spent any time in ad platforms lately paying attention to what’s going on in Google and Facebook you’ll hear the buzzwords Performance Max campaigns, right? Or on the Meta platform Facebook and Instagram have the Advantage Plus campaigns. These are the brand names that the ad platforms are giving to their fully automated systems that basically take human control out of the loop and frame the systems based on data. You have a lot of data coming in we have this machine learning sorcery going on in the middle and out the other end pops some profit. In this context we really don’t control the machine learning systems and on these campaigns there aren’t very many controls we can turn on or off. You can’t change a lot of settings. The key point in leverage we have is the inputs to the campaigns and that means that there’s a greater need for better data than ever before, and that falls back onto the Magento platform of needing to be able to get the right data out of the platform into the ad campaigns in order to make them perform better.

[3:50 onward] Most people are pretty familiar with at least the basics of shopping feeds, but the key issue around shopping feeds is that we tend to have a perspective of trying to get products approved so we can advertise them and then we stop.  But there are a whole lot of additional things that can be done to improve the product data and make the ad campaigns perform even better.

So, for example, on the Google shopping feed specification, there’s this minimum. There’s this section of each of the attribute specifications. We have minimum requirements. That’s usually what developers focus on. Let’s get the minimum done to get these products in the feed. But there’s also a section down further below, if you scroll down the page and read through things, where every different attribute has a set of best practices.

And they’re not there for no reason at all. They’re there because if you implement those best practices on all your product data, the machine learning algorithms are going to be able to chomp that up and eat it and digest it and figure out how to make the campaigns perform better. Many of those best practices are things that have a direct impact on ad performance.

And many of those are things where we just need to get some extra data out of the Magento product database and into the ad, into the shopping feed.  Another place to look for areas where you can improve things is to look at, say, Google Merchant Center and all of the warnings. If there are warnings on products, the products still work, right?

They’re not disapproved, they’re being advertised. But warnings, you can think of as being a clue about something that you can do better, that Google is giving you some input on. And of course, on other platforms like Facebook, there are very similar issues, where you can go in and you can look at all the warnings, and input on what you could be doing better.

Most merchants are using a shopping feed extension that uses a template-based approach to just stick certain product data into the feed. Most of those templates, they’ve been using the same template for the last five years. They haven’t updated it for some of the newer portions of the feed specifications that are available.

So within the last few years, like this was probably 2020 or 2021 Google, for example, added some additional attributes and most Magento merchants don’t implement these yet. So one of them allows you to submit key product highlights like bullet point lists about key features of a product. And that could be used by the algorithms for matching search queries to products.

There’s another which is really an extension to the entire feed spec. You can put arbitrary key value pairs in the product detail attribute. So any additional attributes you want to add to the feed you now can. And you can kind of think about how that could be used by the search algorithms to match people with products they’re looking for.

The biggest issue that Magento merchants have with shopping feeds has to do with how configurable products are implemented in Magento. So I’m going to blow through this really fast. But this is something that a lot of people have problems with and I’d be happy to talk about it individually or point you to some more resources.

The key issue is that, well, the Magento implementation on configurable products. We think of a configurable product as a product, right? It is a product with customizations, things you can, variations, things you can select, like different sizes in this example.  There’s a parent SKU, there’s child SKUs, right?

The problem is in all of the shopping feed specs for every ad platform every individual variant of a product needs to be represented on a line item as its own product. So you’re not supposed to add configurable products. If you really think about it, a configurable product in Magento is an interface.

Or it’s almost like a mini category, right? It’s a category, it’s a container for several other specific products. We’re supposed to put the specific products in the feed.  Now, if you get this right on Google, it will work everywhere else. So the Google feed specification, their policy issues are where you should pay attention.

But basically they say that every variant needs to be in the feed, but also when you go to the link to follow to that product landing page that landing page needs to display that product. It needs to display that product price. But they don’t actually say that you have to have the images very specific to every possible variant.

But the price has to always match or you’re going to get price mismatches.  So the way to handle this in the feed is to not only put the configurable parent but to put all the child products. And then you tie them all together with this item group ID field. The item group ID field is usually set to the configurable product, the parent product SKU.

If you actually have your child simple products all individually visible on your site, then it’s easy. You can just put those products there, the links to the individual child products.  There’s not a lot of complexity. But again, most sites turn off the visibility of the child products because they want to funnel all the traffic to the parent product page.

So a default Magento install with like the Luma theme does have this interesting ability to use a hashtag on the end of the URL. Where you put something like this, pound 142 equals 168, and 93 equals 50. And this selects, in JavaScript on the front end, when somebody lands on the configurable page, it selects a particular set of user inputs, just as if the user had clicked on those to select a product.

And if you have, you know, some prices that vary on your various child products, that will display the correct price. The problem is so here’s an example of what that would look like in your feed with the URLs having the hashtags on the end. I will say this doesn’t work everywhere these days because people really do a lot of customization on their front end.

And oftentimes the front end developers break this, right? Because it’s not a feature that they’re actually using or they’re aware of. But out of the box on the Luma theme, this works and it worked on Magento 1 as well.  Since that basically just runs in JavaScript on the front end, though, it causes some problems.

Google Merchant Center doesn’t really process JavaScript when it parses the prices off the page.  So it creates a situation where we need to do some more complicated things to make it so the web crawlers can get the product prices on the simple products.  There’s no single solution to this because it might depend a little bit on how, what SEO extensions you’re using and what customizations, what theme you’re using, what your front end is, and there’s a lot more diversity in that tech than there was a few years ago.

But basically, one way you can make a quick hack to solve these pricing issues is to actually just make it so you’re going to pass the child SKU in an additional parameter that’s an optional parameter that can be passed to the configurable product landing page. And you can just have literally a few lines of code that intercepts that SKU if it exists.

It looks up that child product price and renders the child product price in the schema.org markup instead of whatever is done by default.  Now, there are also some SEO extensions out there that will do this for you as well and actually render all of the products in the schema.org hidden markup on page.

But some of those, I’ve had different experiences with different ones. Some can be a little iffy, and some don’t completely conform to the specifications, but they still work.  So, it’s a little bit of the wild west the way Google actually parses some of this stuff. I’ve seen situations that work on one site and not another that are kind of odd.

I did a big presentation at Magento Imagine a few years ago that covered all of the Magento product types and how they work with shopping feeds. And if you’re at all interested in other issues around grouped products and so on, all of the different kinds of products in Magento, there is a video of that presentation. You can find that by looking at our blog.

Audiences. Another big area to improve the integrations. So the key issue with audiences is that most audience technology is based on third party cookies. And since third party cookies are getting deprecated, maybe we have another year we can use them for, but we don’t know. Google keeps pushing that back, right? But other browser, other browser manufacturers are also making changes here quickly. We just can’t assume we can keep using cookie-based lists, but we should use them for the next year or so while we can.  One of the key issues is that if you send, if you’re creating remarketing audiences based on people coming to your site, and you’re using the cookie-based list, you’re firing the JavaScript tags.

A lot of times people set it up so it also fires the product IDs of products on the site. So if somebody views a product, or their ad card, or they purchase a product, all those sorts of things get associated with people in the list. And that is what, that’s what all of the ad platforms use for doing dynamic remarketing ads showing the products that somebody browsed or products similar to them, other popular products.

The key issue on Magento is that we tend to use two different IDs for products. In some contexts, we’re using a SKU. In some contexts, we’re using an entity ID. And the person who set up the shopping feed may have indexed that feed based on this SKU and the person who set up the remarketing tagging on the front end maybe is sending the entity ID of products that are being browsed.

So then there’s mismatches and we get low match rates. Nobody ever checks this.  So something you should probably look into and just double check.  Google, in particular, has this extra field called the display ads ID. It’s an optional field that usually isn’t implemented. But if you include that as an additional field in your shopping feed, you can put an alternate ID.

And one of the quick fixes for a lot of problems on Magento is that if you’re passing your ID in the remarketing tag for products being passed, if that’s the SKU, well, you could just, you know, add the display ads ID, set your display ads ID to the entity ID and then whatever is, whatever the person on the front is passing as an ID on the remarketing tag is going to match one of those in the feed.

So that’s a quick hack. It’s pretty useful. It only works on Google, but all of the feed specs, well pretty much all ad platforms are going to have an ID and they’re going to have an item group ID. And this is one of those places as well where if you implement the configurable products correctly, all your simple products are going to be in there with their SKU as the ID.

The parent configurable SKUs are going to be in the item group ID and whether somebody’s browsing individual products or the configurable product parent pages, they’re going to be associated correctly to the products in the feed.  That’s how, that kind of tagging is what’s being done for cookie-based remarketing audiences.

We’re moving into this era where if we can’t associate a user with an audience with a cookie, how do we associate them with anything? And what the ad platforms are leaning into is this idea of using hashed customer data to uniquely identify an individual so we can get them into an audience. But to hash the data.

So when we’re comparing, we’re passing Google a list of people that we want to add to an audience. We can compare the hashes without divulging any personally identifiable information about the customer. So this is something that’s done when you’re logging in and you’re typing in a password. It gets hashed and then we’re transmitting the hashed version over the internet frequently to compare that to a hash value in a database.

It’s a way of exchanging information without divulging it. The actual information, a way of comparing if we both know the same secret, basically. So, these customer data-based audiences are actually really simple lists, where we can create a list of folks, say, people who purchased in our Magento store over the last year.

We take their other email addresses, we run it through an SHA 256 hash, and we create a list of those hashed email addresses. Now we pass that over to Google. Google can’t decrypt that and determine what those email addresses are. But if Google knows the same secret, if Google knows the same information, they have those people in their list of people who are Google users.

They can, and those people have their personalized advertising preferences set. So they’re opting into this. Google can compare that against the data we pass them. And they can determine if you know folks can be added to the audience or not. And if there’s a match, they add them to the audience and we can use those in remarketing ads later on.

There’s a lot of opportunity to make interesting lists based on people who purchased certain kinds of products in the past. Past purchasers, people from CRM systems we’re targeting in other marketing. And there’s an interesting, you know, this is an interesting area of the law where we’re not actually sending people email address, emails, right?

So this isn’t subject to spam laws or email specific laws. It does get into some interesting questions of is this personally identifiable information or not?  And that’s something that’s probably going to start to be determined differently in different jurisdictions. Europe’s going to be different than California and that’s going to be different than Florida.

It’s going to be chaotic.  But we can use this right now. It’s a good alternative as cookie-based audiences go away.  So let’s talk a little bit about conversion tracking and wrap this up.

The thing that I think is the most important point about conversion tracking is that we have oftentimes thought about it as reporting on the results of ad campaigns, or financial reporting.  But in the era of machine learning automation, this is the primary signal we’re passing back into the machine learning sorcery to tell it what we want to optimize for.

So it’s both a reporting mechanism, but it’s also the primary feedback loop. The more accurate your conversion tracking is, the more accurate it’s going to be able to train on all the other data inputs we feed into it to determine what is contributing to results and what isn’t.

Because it’s a feedback loop and we get this, you know, it’s like compound interest. If you make a small improvement, that small improvement improves that training more and more and more over time. And if you have a small improvement in what you’re doing versus what your competitors are doing, that becomes a substantial competitive advantage over time.

It builds with time.

So Magento historically hasn’t really kept up to date with the latest conversion tracking tags from all the ad platforms. We’ve had to use other tools like Google Tag Manager or extensions in order to do this. So, I’ve always said to people, you shouldn’t use the Google tracking in Magento. Many merchants do set this up, but even as late as last summer, Magento 2.4.4 had five year old Google tag, Google tagging built into the core. They just updated that in 2.4.5, but there’s still a lot of people out there running on 2.4.4 or before, for whatever reasons, they can’t upgrade yet.  So, in general, I think it’s probably a best practice to not use the conversion tracking that’s built into the core.

Most people will use an extension like a Welp Pixel, Google Tag Manager extension. They’ll do something like that and then they’ll set up all their tags in Google Tag Manager.  But make sure just on the Google front, make sure you’re using the Google tag. That’s what they call gtag.js until they rebranded it a few months ago, or that you’re setting up tagging in Google Tag Manager that will have some improvements over what the older tags used.  Now one of the newer things that most people really haven’t set up yet. It’s just been out for probably a couple of years now is enhanced conversion tracking.

And pretty much all the ad platforms are doing some form of this. But here’s the Google example. It’s very similar to what I just said about how we pass some hash user data in order to identify somebody without using cookies. So, along with the conversion tracking information, the order ID, and the value that somebody purchased, what we do is we pass maybe their hashed email address or their hashed phone number.

There’s a few pieces of data we can pass.  Again, is that personally identifiable information? Is it going to be covered by various privacy laws? Eh, evolving area, right? We don’t know how this is going to turn out. But by doing this in situations where cookies have been blocked or JavaScript on the front end maybe doesn’t have access to the original click ID from when the person clicked on the original ad.

This is a mechanism of identifying one of Google’s users to them. And Google can then say, okay, that user actually did click on an ad a few minutes ago and we see that they made this purchase. So then they can connect that, connect the dots on that and close that loop.  It’s fairly simple to set up.  Most people haven’t set it up yet.

For an example of the same technology on the Meta platform the first column here is the Meta advanced matching. It’s the automatic matching. And this doesn’t really require a Magento integration. This is just something you configure in the Facebook event manager.  Just checking some sliders about what information the pixel is allowed to look for.

And when that Facebook pixel loads on the various pages on your site, it’s paying attention to input boxes. And if it sees an input box, it says that’s probably their email address. So I’m going to go ahead and grab that. It’s going to hash it, it’s going to pass it over, and then later on if there’s a conversion, it’s going to use that to try to connect the dots if there was other blocking in play that would have blocked the conversion tracking.

They do recommend that you also set up manual advanced matching if possible. And so we’ve got a little JavaScript snippet here that shows what the tagging on that would look like. When we’re initializing the Facebook pixel, we’re passing in some additional data that’s going to be hashed before it goes to the Facebook server.

And it’s very simple, easy to set up. You can do this in Tag Manager pretty quick and easy.

The direction things are going, and this is more of the Wild West stuff, the direction things are going is towards server to server conversion tracking. If cookies are blocked and JavaScript on the front end is unreliable or might be blocked by ad blockers, then let’s just take that all out of the loop.

Let’s just have the e commerce server directly record via an API call, record the information about that conversion when a purchase occurs. So instead of checkout success page firing tags on the front end, you know, the e commerce platform connects to Facebook and sends that on the back end.  This kind of technology is being rolled out across all ad platforms right now, right?

But it’s, you know, in different levels of maturity on the different ad platforms. And sometimes you have to jump through some different hoops in order to get it working. It can be more complicated and difficult. And right now, maybe there’s less of a benefit to doing that, you know? But down the road as a few more things get blocked, there’s going to be a much greater benefit.

So right now there aren’t a lot of good options for doing this. So on Magento we do have a Facebook extension in the marketplace that will implement the Facebook conversion API for you. But it is one of these extensions that’s kind of like a it does everything. It does your shopping feed, it does your conversion tracking, all that sort of stuff.

So sometimes if you just want the server-based conversion tracking, you don’t want all the other stuff that comes along with it. You might have to make some modifications there to accomplish what you’re really trying to do. 

Let’s wrap it up.  Just what matters the most, right? What matters the most is paying attention to what’s going on in trying to eliminate the dependency on cookies by starting to adopt some of these other technologies, trying to improve your data.

So the shopping feed data is just a little bit better. You’re getting better match rates. You’re getting better match rates on your remarketing tags with the products people are browsing and adding to cart and all of that.  Getting your conversion tracking, if you can make it 5 or 10 percent better, just a little bit, some, you know, you probably already 80 percent, 90 percent of the way there, but if you make it just a little bit better, it has the snowball effect of building results over time that can have a huge impact.

And as we move forward into this next year with third party cookie blocking. All of this stuff is going to become a lot more important. So the time to implement this is probably now time to start looking at all these things.  So if any of these slides would be helpful to you, feel free to reach out, contact me.