The Simple Power of Transaction Syncing

Transaction syncing is a simple way for advertisers to exchange custom data with ad tech vendors. Because the mechanics of transaction syncing are flexible, marketers can unlock lots of use cases to solve their brand’s specific marketing problems.

What is Transaction Syncing?

A standard pixel provides only very basic information to an advertiser. Here’s an example of a simple pixel that a retargeting company called Chango places on the Fresh Direct homepage:

https://www.chango.com/c/1428883653753/

When I visit Fresh Direct’s website, this pixel loads, and Chango records the timestamp of my visit. All Chango knows is that I’ve visited freshdirect.com, nothing else.

But when I make a purchase on Fresh Direct, Chango does something much more interesting. On the checkout page, I see a graphic that confirms my order, including an order number I can use in case I ever need to call customer support. I also see the following Chango pixel:

This pixel is a lot more interesting, mostly because of the snippet highlighted in yellow, which sends my order ID to Chango. This “transaction sync” gives Fresh Direct and Chango a common identifier, unlocking information flow between the two companies. Fresh Direct can now send Chango information about my order — the items in my cart, the price of each, and even any issues fulfilling my order. This information flow enables much more precise advertising.

Like most ad tech building blocks, transaction syncing has applications for both targeting and attribution.

Smarter Ad Targeting

One of the most important choices an advertiser can make is what message to present to a customer. Transaction syncing unlocks smarter creative selection.

FreshDirect’s standard ad creative is a message designed to attract new customers with a 15% discount on their first order. With the knowledge that I’m already a customer, Chango can make an informed decision to deliver a retention message instead of the standard acquisition creative. A second and more refined decision is which specific retention message will resonate best, and this is where transaction syncing can be valuable.

Did I buy baby food in my last order? Produce? Pantry items? This can inform a personalized creative choice, driving up response rates and improving campaign effectiveness.

Smarter Attribution

Transaction syncing also unlocks more precise media attribution. By sharing information about the contents of my order, Fresh Direct can refine its advertising techniques in order to reach consumers with specific buying patterns. At the simplest level, Fresh Direct can assign greater value to campaign tactics that drive high value orders. But Fresh Direct can also go deeper — designing and optimizing campaign tactics that drive specific types of purchases. Need to steer a campaign toward consumers who buy high margin private label products? Transaction syncing can help.

It’s Not Just About Groceries

The trick (and the fun) with transaction syncing is that the applications are unique to each brand. Brands in the retail, insurance, and mobile phone spaces have very different marketing needs, but they can all benefit from clever uses of transaction syncing. A few examples:

• An apparel retailer that was sold out of my size can deliver ads with the good news that their stock has been replenished. Just target consumers whose last purchase included a back ordered item.
• An insurance company can optimize campaign tactics to attract safe drivers. Just create an attribution rule that assigns more value to policies with a spotless driving record.
• A sporting goods retailer can promote accessories that are compatible with my new road bike. Just identify product SKUs that complement previous purchases.
• A mobile phone operator can design a campaign to drive new family plan account sign-ups. Just assign greater attribution value to multi-line accounts.

The use cases are just beginning to emerge. It’s a fun time to be a digital marketer.

The Unintended Economics of Facebook’s Unified Ad Auction

At last week’s F8 conference, LiveRail trumpeted the benefits of its unified ad auction, but DSPs will carry a heavy economic burden

Waterfalls vs. Unified Auctions

Traditional publisher ad servers monetize inventory through a waterfall. Direct sold campaigns get first access to an impression. If a direct sold campaign does not fill the impression, the publisher’s ad server then gives access to a remnant demand source like an ad network or an RTB bidder. This process continues until the ad is monetized. The key characteristic of a waterfall is that demand is checked sequentially — priority level 3 is only notified of the ad’s availability after priority level 2 passes on the ad.

By contrast, a unified ad auction seeks demand from all potential buyers simultaneously. Every demand source participates in every ad impression, and the publisher’s ad server makes a yield-optimizing choice of which demand source should be awarded the impression.

Unified auctions drive better monetization than waterfalls because they consider the full range of potential demand sources, potentially awarding an impression to a high priced RTB bidder over a more modestly priced direct sold campaign. Publishers benefit from improved yield (including some very non-obvious optimizations), and advertisers benefit from improved inventory access.

Collateral Damage

The unified auction feels like a win-win, but DSPs bear an unexpected burden that could meaningfully damage their economics. The basic financial math of a DSP business looks something like this:

A typical DSP charges advertisers a percentage of the media dollars that flow through its platform. An advertiser that spends $10M per year might pay its DSP $1M. At the most basic level, DSPs make more top line revenue by growing advertiser budgets.

DSP expenses, however, have nothing to do with advertiser budgets. After covering overhead like people and facilities, DSP costs scale with the number of bids the platform must process. The core technology of a DSP becomes more expensive to operate as the volume of incoming bid requests grows. Every lost auction is pure cost to a DSP, driving down its profitability.

The trouble with unified auctions is that they drive up bid requests without bringing more revenue into the system. The value proposition of a unified auction hinges on increased bid density — more demand sources participate in every impression. But the byproduct of increased bid density is decreased win rates. Only one demand source can win an impression, so as more bidders participate, more of them lose. A spike in lost auctions is an economic crisis for a DSP.

DSPs are already struggling to prove their economic model in the face of commoditized technology and market saturation. Facebook’s LiveRail is not the first supply side platform to offer a unified auction to publishers, but it is the first that could capture a meaningful inventory footprint. If Facebook is successful in driving market adoption of unified auctions, pure play DSPs may have an even tougher road to profitability.

ID Syncing In Action

In a recent post, I highlighted LiveRamp’s role as a hub in the highly fragmented ad tech ecosystem. Specifically, LiveRamp operates an ID syncing network that enables ad tech providers to exchange data. In this post, I’ll outline how this ID syncing network functions and where you can see LiveRamp execute syncs on the web.

A Refresher on ID Syncing

LiveRamp operates an ID syncing network that maintains a centralized mapping of cookie IDs and device IDs for each real-world consumer. Each ad tech company that participates in LiveRamp’s ID syncing network shares its user IDs with LiveRamp. With a complete mapping of IDs for each consumer, LiveRamp can facilitate data transfers between any two network participants.

To illustrate, here is the process that allows LiveRamp to collect my user ID from Adometry:

1. First, LiveRamp makes a request to Adometry by calling a dedicated Adometry ID syncing URL.
2. When Adometry receives this request, it responds by loading a LiveRamp URL that is populated with my Adometry user ID. This is a signal to LiveRamp that Adometry identifies me as user 54d7f399.006qLR.36e4f3da.

When you load http://log.dmtry.com/liveramp in your browser, you’ll be redirected to a LiveRamp URL that contains your Adometry user ID.

The LiveRamp Syncing Network

More generally, every participant in the LiveRamp network creates a URL that LiveRamp can call to request a user ID. This URL is configured to redirect to a LiveRamp URL that takes the following form:

Partner ID is populated by a code that is unique to each ad tech company, and User ID is populated by the code that the ad tech company assigns to your browser.

Click/tap any of the logos below to retrieve your user ID:

Behind the scenes of your daily browsing of the web, LiveRamp will periodically load these URLs, maintaining a constantly updated map of your user IDs.

Syncing In The Wild

Want to see the whole process in the wild? Head over to Banana Republic’s website and log in. Banana Republic appears to have an agreement in place with LiveRamp, allowing LiveRamp to use Banana’s login page to perform an ID sync with multiple network partners. All Banana Republic has to do is load the following URL:

That URL triggers a process that selectively performs ID syncs with partners in LiveRamp’s network. Install a debugging tool like Ghostery or Firebug, and you’ll be able to see all the ID syncs that are performed in the background. Depending on the freshness of your LiveRamp profile, you might see just a few syncs execute, or you might see dozens. LiveRamp has lots of similar partnerships with other sites, enabling it to constantly perform ID syncs and maintain a fresh mapping of every consumer’s IDs.

The Hidden Value of Acxiom’s LiveRamp

Acxiom recently spent a hefty $310M to buy LiveRamp, a company best known for its offline-to-online “data onboarding” service. But the real value of LiveRamp is its ubiquitous ID syncing network. LiveRamp has positioned itself as the switchboard of digital advertising — the router of marketing data across a hyper-fragmented ad tech ecosystem.

A Brief History of LiveRamp

Back in 2010, Facebook got a pretty serious slap on the wrist after inadvertently sharing personally identifiable information with third party data companies. In particular, a company called RapLeaf found a way to scrape referring URLs to match a cookie ID to a specific Facebook profile. Using this match, RapLeaf could target ads based on consumers’ Facebook profiles. Marketers loved it. Privacy advocates did not.

On the heels of that snafu, RapLeaf launched a secondary brand, LiveRamp, which would eventually become the face of the company. The LiveRamp service matched marketers’ offline CRM files with online cookie pools, enabling brands like Ford to deliver ads to drivers whose F150 leases were about to end. To make this work, LiveRamp built data transfer relationships with every major marketing platform — focusing initially on publishers and DSPs, and eventually expanding to a growing list of players in the data management, content marketing, and attribution spaces.

LiveRamp’s bet that data onboarding would be a valuable business proved to be correct, but the far bigger source of value would turn out to be a byproduct of the onboarding service — an ID syncing network that positions LiveRamp at the center of the highly fragmented ad tech ecosystem.

What is ID syncing?

For both technical reasons (every ad tech company operates on a different cookiespace) and privacy reasons (anonymous IDs should be rotated every few months), any real world person will have dozens, sometimes hundreds, of different online identifiers. Yahoo might call me user 1234, and Google might call me user 6789. Knowing that Yahoo’s user 1234 and Google’s user 6789 are the same real world person unlocks lots of interesting marketing use cases. With this match, marketers can:

• measure total ad exposure for each consumer and impose a global frequency cap
• syndicate audience segments to all publisher partners, creating consistent targeting parameters across the web
• deliver sequential creative messages, telling a linear story to each consumer as he moves from awareness to intent
• identify all brand exposures along each consumer’s path to purchase, enabling full-funnel attribution

In the context of a hyper-fragmented ecosystem, marketers often work with many different ad tech partners, and ID syncing enables these partners to operate as an integrated system.

How does it work?

Here’s where things get a little gnarly. Imagine that a brand works with 20 different ad tech companies. In order to create seamless operations, each company must know 19 corresponding IDs, and they must establish these 19 matches for every real world consumer.

By way of example, here is a URL that BlueKai can call to request TubeMogul’s user ID:
http://rtd.tubemogul.com/upi/pid/w8wqx7f2?redir=http%3A%2F%2Ftags.bluekai.com%2Fsite%2F4413%3Fid%3D%24%7BUSER_ID%7D

When you load that link in your browser, you’ll be redirected to a URL that looks something like this:
http://tags.bluekai.com/site/4413?id=6092720069689058834

This URL notifies BlueKai that TubeMogul identifies me as user 6092720069689058834. With the first half of the sync in place, TubeMogul now needs to make a call back to BlueKai to request my BlueKai user ID. Similar two-way syncs need to happen for every pair of ad tech partners. Now do that for hundreds of millions of consumers. And keep the matches updated as each partner rotates its IDs. It’s a big job.

An alternative approach is to designate a single company to be the hub of all ID syncs. The hub can collect IDs from each participating ad tech partner and then form mutual ID syncs as needed. Think of this as a match maker who knows the full universe of eligible singles and can then introduce couples. LiveRamp has established itself as this match maker, and its ID syncing process looks something like this:

Hidden Assets

In hindsight, it’s clear that this match maker role is a coveted position in the ad tech ecosystem — a position that would eventually warrant an 11x revenue multiple. But it wasn’t so obvious when RapLeaf pressed the reset button in 2011 and launched LiveRamp. The bet to pursue a data onboarding service has proven to be a smart move. It enabled RapLeaf to move past its consumer privacy issues and build a new reputation as a connector of the online and offline marketing worlds. It unlocked new revenue streams, allowing LiveRamp to tap into CRM budgets, scale its business, and largely self-fund its growth. But through the process, LiveRamp also backed into becoming the de facto hub of ID syncing, the glue that holds together the ad tech ecosystem. This is the real value of LiveRamp, and it’s the reason Axciom made such a big bet on the company.

Frequency Capping Won’t Get Solved Anytime Soon

State Farm is wasting money because of frequency cap violations… and that’s okay

The ability to implement a universal frequency cap is one of the major selling points of consolidating programmatic buying with a single DSP. And in practice, DSPs are pretty good at frequency cap enforcement. But they are not perfect, and solving those last few fringe cases that cause frequency cap violations just isn’t a priority.

Here’s what’s happening in the screenshot to the left. When I visit weather.com, Weather’s SSP conducts multiple concurrent auctions — one for each ad slot on the page. State Farm’s bidder evaluates each bid request independently without considering the possibility that it might win all four auctions. Because I am in State Farm’s retargeting pool, State Farm bids aggressively and wins all four ad slots. It is entirely possible State Farm implemented a 3-per day frequency cap, and in a single page view, this frequency cap is violated.

Could DSPs solve this problem? Sure. There are lots of potential solutions — sequencing bid responses, checking for concurrent bid requests, or potentially utilizing optional bid parameters to link multiple auctions. But in the context of broader ad tech development opportunities, this fringe case just isn’t a priority. Both buy side and sell side technology developers simply have more interesting problems to solve.

State Farm could probably save some money if its bidder had smarter logic to prevent roadblocks. But it can also unlock lots of new use cases by allowing its technology partners to continue pursuing needle-moving development. For now, let’s focus on real innovation. Tweaking can come later.

16,000 Wasted Pixels

While watching an interview with “Selma” director Ava DuVernay, I opened my phone and visited imdb.com to learn more about her career. At the bottom of the page, I saw an ad promoting Amazon’s new streaming video service, Amazon Prime Instant Video. The ad had a clear call to action and was positioned next to highly relevant content. There’s nothing obviously wrong with the ad unless you know that I’m already an Amazon Prime member and already have the Prime Instant Video app installed on my phone. Why would Amazon waste their money promoting a product that I’ve already purchased?

It turns out that iOS makes it very difficult for advertisers like Amazon to make smart targeting decisions when delivering ads in a mobile web browser. The issue stems from two different tracking mechanisms that coexist on iOS devices.

1. Native iOS apps have access to a mobile device ID (called IDFA, or “ID for Advertising”) that is consistent across all installed apps.
2. Websites that are loaded through a browser cannot access the device’s IDFA, but instead access cookies that operate very similarly to desktop browser cookies.

When I installed Amazon’s Prime Instant Video app, Amazon’s marketing database recorded my iPhone’s IDFA (let’s call this 1234). But when IMDB sold a banner ad within my browser, Amazon’s bidder was passed a cookie ID (let’s call this 6789). To Amazon, cookie ID 6789 is a brand new prospect, not an existing customer. Amazon purchased the 320x50 ad slot and wasted an otherwise productive 16,000 pixels.

The cookie vs. device ID issue is problematic for both for targeting and attribution. Ads like Amazon’s are poorly targeted, resulted in wasted ad spend. In other cases, advertisers miss opportunities to engage warm leads, resulting in poor publisher monetization. And when an impression served in an app drives a conversion on the web, its impact is often not measurable, reducing the perceived effectiveness of mobile advertising.

Start ups like Tapad and Drawbridge are leveraging probabilistic modeling to link multiple IDs, and scaled platforms like Google and Facebook are well positioned to use login data to provide more robust ID matching products. But we are still in the early innings of people-based marketing, and until the industry embraces a consistent ID linking solution, the mobile ad economy will suffer.

It’s Going To Be A Powder Day! A Banner Ad Told Me So

View fullsize

I’m heading to Vail on Wednesday, and according to this banner ad, it’s looking like I timed my trip well. Vail is getting socked with snow, and I’m getting real time updates as I browse the web. I took the screenshot below at 6pm on February 28th. The ads I’m seeing now tell me that the snowfall total is up to 24 inches, and the tally keeps rising.

So how is Vail accomplishing this little bit of marketing magic? Is some poor ad ops soul swapping banner ads every time another inch of snow falls? It turns out Vail has a clever solution for automating these ads. By working with a dynamic creative vendor called Spongecell, Vail is injecting real-time snow report data into their ads. A few components need to come together for this to work:

• Vail’s website has a page that includes the latest snow report. You can find a consumer-facing version of that page here and an XML version of the raw data here.
• Spongecell has a simple tool that retrieves raw data from a third party domain. Combining the Spongecell tool with Vail’s XML document yields a URL that can send live snowfall data to any object hosted on Spongecell’s domain.
• Spongecell can then build a Flash file that retrieves data from Vail’s XML document and uses this data to populate the ad’s message.
• Because the overall process relies on Vail to maintain a live data feed, there is a risk the dynamic snowfall data fails to populate. As a backup, Spongecell also loads a static ad in the background. That static ad can be served if the connection to Vail’s XML document fails.

The final experience is a dynamic ad that is populated on the fly with Vail’s latest snow report. Fingers crossed for another few inches!

Why Site Should Definitely Not Be A Mandatory Object In A Bid Request

@simonjharris recently argued that the IAB should require publishers to disclose their site URL or app name in RTB bid requests. This would be a bad idea for two reasons:

1. Transparency requirements would push premium publishers out of the market
   The rapid influx of premium publishers to the RTB market is largely driven by the flexibility to provide limited transparency into inventory. Premium publishers with direct sales forces fear that RTB channels will cannibalize revenue from reserved sales. The option to mask inventory details on open exchanges greatly reduces the potential for channel conflict, making RTB testing more palatable for premium publishers. The RTB ecosystem has benefited greatly from the growth of premium inventory, and this growth would have been stifled if publishers were required to provide full URL transparency.
2. Economic incentives are already in place
   Regulating URL disclosure is also simply not necessary because there are already strong economic incentives for publishers to sell inventory transparently, a point Simon acknowledges. Due to brand safety concerns, many advertisers will not bid for blind bid requests (those that don’t disclose URL). With lower bid density comes greater price reduction and therefore lower closing prices. By providing URL transparency in bid requests, publishers benefit from better RTB yield, and as premium publishers become more familiar with the RTB landscape, many are choosing to provide greater transparency in bid requests.

The IAB’s goal should be to enforce the minimum possible level of standards that enable a functioning advertising marketplace. Free market economics should handle the rest. The decision to make site an optional bid request parameter maximizes marketplace freedom, while incentivizing behavior that benefits both buyers and sellers.

Find the complete OpenRTB 2.3 specs here:https://github.com/openrtb/OpenRTB/blob/master/OpenRTB-API-Specification-Version-2-3-FINAL.pdf

Audience Syndication: A Peek Behind The DMP Curtain

In a recent post, I highlighted some strange behavior of retargeting campaigns. One of the more surprising experiences was the way Jeep delivered ads to me following a visit to the jeep.com website. As expected, shortly after my visit to jeep.com, I began seeing ads promoting Jeep’s SUVs. But two things were unusual about these ads. First, the ads were sponsored by a local Jeep dealership (Cherry Hill Jeep), not the national Jeep brand. Second, the ads were served by a company called AdGear, which does not fire retargeting beacons on the jeep.com site.

So how did Cherry Hill Jeep know to target me, and how did AdGear execute the ad buy? While hard to say with certainty, I suspect Jeep is using a data management platform to syndicate audiences for local dealership campaigns. Here’s how audience syndication works:

1. Jeep partners with a data management platform to track visitors to jeep.com. Based on tags that load on Jeep’s website, it appears Adobe is integrated as a DMP. When I visited jeep.com, an Adobe beacon loaded on the site and recorded my visit in an Adobe database.
2. At any time (before or after my visit to jeep.com), Adobe can perform an ID sync with AdGear. The details behind ID syncing are complex, but the outcome is that Adobe and AdGear share with each other the anonymous ID that each company uses to track my online behavior. (“Hey AdGear, it’s Adobe. The guy you call user ID 1234 is our user ID 6789.”) Once an ID sync is in place, Adobe can send information about my jeep.com visit to AdGear, and AdGear can place me in Jeep’s retargeting pool.
3. AdGear can then activate a campaign that targets consumers who (a) recently visited jeep.com and (b) are within driving distance of a particular Jeep dealership. Without any technical integration with the jeep.com website, Cherry Hill Jeep is able to run a retargeting campaign.

Retargeting has been around for a while, and this seems like a complex way to accomplish a relatively simple advertising task. Why not just load the AdGear beacon on jeep.com? Assuming Jeep wants to allow all of its local dealerships to run retargeting campaigns, a traditional approach would quickly overwhelm jeep.com with retargeting beacons. Jeep has 40 dealerships in New Jersey alone. Add another 112 dealerships in New York and 27 in Connecticut, and we’re looking at almost 200 beacons just to cover the tri-state area’s dealerships. Scaling nationally, we quickly hit a point at which jeep.com becomes unusably slow due to the presence of hundreds of retargeting beacons. By adopting a single DMP and then syndicating audiences to each dealership’s preferred media buying partner, Jeep is able to execute local retargeting campaigns while preserving a seamless consumer experience on its national website.