Advertisers love ad platforms that offer retargeting. In a 2018 survey from MarketingCharts.com, advertisers rated it the most effective method to improve social/search performance.
So as you build new features into your ad product, it can be tempting to prioritize this functionality in a V2 or V3. If retargeting is wildly successful for major ad platforms like Facebook, Google, and LinkedIn, why not for you too?
While the draw is certainly there, retargeting is no longer a must-have feature, and this article delves into why that is.
What is retargeting?
Retargeting allows advertisers to reach users as they browse other sites/apps. It’s used to keep their brand top-of-mind for recent visitors and to drive sales via micro-targeted creatives and landing pages.
For instance, if someone visits the Women’s Soccer Shoes subcategory on Nike.com, Nike could show them an ad directing them back to that page when the person is on Facebook.
For retargeting to work, publishers need to build this functionality into their ad platforms (unless you show programmatic ads only, in which case it’s done behind the scenes and you have no control over it).
Like any new feature, you must weigh the costs/benefits compared to other initiatives, like frequency capping, scaling your infrastructure, and so on.
What are the pros of adding retargeting to my ad platform?
Ad performance and feature parity make retargeting an enticing offering to build. As mentioned above, advertisers consistently rate it the best performing marketing tactic, so it makes sense to provide tools that’ll improve the performance of ad spend on your product.
If advertisers don’t see great results with standard campaigns but find success with low-volume retargeting ones, they may keep those on indefinitely, enabling you to maintain relationships you could then upsell down the line.
Since you’ll be competing for ad spend with the major ad platforms out there - Google, Facebook, Amazon, DSPs, etc - feature parity also helps make your product competitive. If advertisers are expecting retargeting tools but yours doesn’t have them, they may be less interested to start advertising with you.
This sounds great - why shouldn’t I build this?
Two reasons: scale and recent industry changes that signal the upcoming end of retargeting’s feasibility.
For scale, you’ll have to decide whether the incremental revenue from retargeting campaigns will offset the resources needed to build it, as well as the opportunity cost of not adding other features like frequency capping or behavioral targeting.
Expected revenue from retargeting largely comes down to the volume of your traffic, the volume of your advertisers’ traffic, and the overlapping percentage.
Perhaps you are able to match 3% of an advertiser’s visitors over the course of a month. If they have a million monthly uniques, that’s 30,000 users. Even a generous CPM of $10 would net just $300/month in revenue (using 1 impression per user for simplicity). This may or may not be interesting - but highlights the importance of knowing these variables.
It’s industry tracking and privacy changes, however, that are of more concern.
To understand why, let’s review how retargeting technically works. Retargeting first requires a way to ingest the advertisers’ user data and then make it actionable in targeting. This is predominantly done in two ways:
Third-party cookies / in-app SDKs
Here, you provide your advertisers with a pixel to drop on their mobile/desktop sites (or have an in-app SDK integration). This pixel fires when somebody visits the advertiser’s site/app, which then either sends cookie data to your servers or stores information in a cookie on the user’s browser. Both methods necessitate having access to browser cookies.
For this to work, there needs to be some type of Persistent ID that matches their browser visit to your targeting data store. No match and you have no way to retarget that user on your site/app.
Often this is done by dropping a first-party cookie when a user is on your site, which includes some hashed ID. If that user visits your advertisers’ site, your pixel would fire, pull the cookie ID, send it to you, and you’d store that information in a first-party DMP for segmenting and retargeting.
Or you could store information in a cookie when it fires on the advertiser’s site and then reference this cookie when they visit your digital property.
For in-app retargeting, this ID will be Apple’s IDFA or Google’s GAID/AAID, which the mobile app developer would collect and send to you manually or in real-time through an in-app SDK or mobile attribution partner.
Usually this method coincides with a way to then segment these visitors and create audience profiles - such as retargeting just users who put an item in the shopping cart but didn’t purchase.
Alternatively you could allow advertisers to upload a list of IDs to retarget on your site/app (Facebook calls these ‘Custom Audiences’). This is an easier method because you don’t need to worry about designing a pixel or segmentation functionality (the advertiser would do this themself).
The IDs used here tend to be email addresses, phone numbers, or mobile IDs - but theoretically could include physical addresses, names, and IP addresses.
This method assumes your system can match those identifiers; there’s no reason to ingest emails if you don’t track the emails of your users.
But industry changes are threatening the feasibility of these approaches.
GDPR/CCPA/other privacy laws
Digital privacy laws have cropped up across the world and share one core tenet: users should have control over their personal data. Nearly every law is opt-in (though CCPA is not), forcing brands to ask permission before they can share or monetize that user’s data with a third-party.
Privacy laws, therefore, impact retargeting, as advertisers will need explicit user consent to share data with you and retarget on your ad product.
If consent rates are low, you’ll receive less data from advertisers, and potential scale and revenue from retargeting will shrink even more.
The semi-good news for US-focused publishers is that (1) there’s no country-wide US equivalent to EU’s GDPR and (2) California’s CCPA is opt-out, not opt-in, so advertisers don’t need to ask permission to share data.
Deprecation of third-party cookies
In order for the pixel method to work, you need to store/pull a Persistent ID from a third-party cookie on the user’s browser. If the browser blocks your access to this cookie, nothing is sent to you (or you can’t drop a cookie), and the advertiser won’t be able to retarget that user.
Unfortunately for many in ad tech, the reign of the third-party cookie is over. Browsers like Safari and Mozilla have already implemented policies for blocking them, but at roughly 20% of the browser market, such changes aren’t crippling publishers.
That’ll change when Google officially ends third-party cookie dropping/access in Chrome - which will happen by 2022. With 60%+ market share, this is the death blow to third-party cookies and will force ad tech tracking/targeting to adapt.
Once that happens nearly all browsers will block, by default, these third-party cookies that power much of retargeting.
Building a feature using this technology may work short-term, but eventually the data will stop flowing.
Slow death of the IDFA and mobile IDs
Moving from the browser world to the in-app one, what’s happening to third-party cookies is also occurring with the in-app tracking equivalent: mobile advertising IDs, specifically Apple’s IDFA and Google’s GAID.
It’s likely you’d use these IDs for in-app retargeting, with the advertiser sending them automatically via an SDK/mobile attribution partner or uploading them manually.
In June 2020 Apple announced that the new iOS 14 would upend this easy flow of data: in order to pull a downloader’s IDFA, the app has to first ask permission. If the user says no (and there’s no reason to assume consent rates will be high), they can’t use this ID for retargeting.
Many industry experts are calling this the end of mobile tracking as we know it. This may or may not be the case, as we don’t know opt-in rates and it’s just iOS. However, given Apple’s third-party cookie stance on Safari and Google’s upcoming Chrome changes, there’s every reason to believe that eventually both Apple and Google will deprecate these advertising IDs entirely.
If your in-app retargeting tools are built around these mobile IDs, you’d again be building a product that likely has an expiration date.
Is there any scenario where adding a retargeting feature makes sense?
Theoretically a retargeting platform based on manual email address uploads (with user consent) may be a viable long-term project, as:
Beyond the less reliable IP address, it’s really the only Persistent ID that both a publisher and an advertiser would have independent access to (assuming the user registered with the same email address across your and the advertiser’s platform).
By forcing the advertiser to compose the segments before uploading them, all you need is a way to ingest a list and retarget it. You don’t have to worry about providing a pixel and then tools for them to create segments based around behavior.
This approach still has limitations. Not only must your users register with an email, but the advertiser’s would too.
This email would also need to match; there’s little point to target work emails on Facebook, for instance.
Alternatively you could use less precise IDs like the IP address or even lat/long for apps, but without the 1:1 accuracy, performance won’t be as good, making this offering less interesting to advertisers.
Finally, one short-term solution is to use Adzerk to build or augment your current ad server. Adzerk offers turnkey retargeting tools via its first-party DMP or third-party advertiser pixel. While retargeting won’t be a revenue-driver long-term, Adzerk’s tools provide a way to at least capitalize on that revenue for the time being.
Advertisers love the ability to retarget, as performance usually beats standard new-user campaigns. But with recent industry changes - privacy laws, third-party cookie deprecation, and the likely end of mobile IDs - building such a feature into your ad platform is not building toward the future.
Join the Ad.Product community
Sign up for our monthly newsletter and to be notified of member-exclusive events and opportunities.
Ad.Product is the first community for product managers, engineers, and others to discover and discuss how to build innovative, user-first ad platforms.