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?
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).
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.
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.
Two reasons: scale and recent industry changes that signal the upcoming end of retargeting’s feasibility.
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.
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:
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.
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.
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.
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.
But with Brazil’s LGPD and Thailand’s PDPA starting soon and the looming possibility that more US states adopt privacy laws, data sharing will only get more risky and less common.
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.
Building a feature using this technology may work short-term, but eventually the data will stop flowing.
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.
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.
Theoretically a retargeting platform based on manual email address uploads (with user consent) may be a viable long-term project, as:
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 Kevel to build or augment your current ad server. Kevel offers turnkey retargeting tools via its first-party DMP or third-party advertiser pixel. While retargeting won’t be a revenue-driver long-term, Kevel’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.
Other features like behavioral targeting, company targeting, and first-party data will reign instead and are likely to return more revenue long-term.
