Blog

Publisher Traffic and Ad Performance from Social Networks

Posted September 19th, 2013 by admin in Insight

Share:

The Yieldbot platform sees over a billion and a half page-views monthly across leading premium publishers, with a cross-section of the web’s largest and best women’s programming; food/recipe, home/garden and health/wellness. Many of these sites are active programmers on a range of social platforms from Facebook to Pinterest to Tumblr to Twitter. The following data from Yieldbot shows the level of traffic and engagement with ads is highly variable.

Social Media as a Traffic Source

Pinterest is by far the largest source of social media traffic to publishers on the Yieldbot platform. “Pinning” is known to be a common activity in women’s programming verticals, including style, hobbies and projects, like home improvement

Yieldbot Monthly Page Views Index by Original Referrer Source


The above data shows Pinterest dominance as a domain referrer source to publishers. Interesting in that this dominance does not extend to mobile where Facebook greatly outperforms Pinterest. Also interesting is that Publishers are not generating any significant visitors from Tumblr or Twitter.

Ad Engagement from Social Media Traffic

While Pinterest desktop drives the most social platform traffic by far to publishers on the Yieldbot platform the performance of advertisers (as defined by CTR) is below par relative to other sources of social traffic.

Yieldbot Advertiser CTR Index by Original Referrer Source


Key Findings:

1) Social media presents a rich and large opportunity for driving traffic to premium publishers, especially from Pinterest, but publishers need to do a better job of generating volume on Facebook. Both Tumblr and Twitter, despite their large audiences are virtually meaningless to publishers as a traffic source.

2) Ad engagement, as defined by CTR, indexes higher from Facebook than other social platforms. Increases in traffic from Facebook will benefit the publisher’s advertisers given the high CTR levels.

Action Items:

1) Social traffic is not performing well in content because the ads are not geared toward social referrers. Huge upside here. We call this the “inbound social” opportunity.

2) Non social referred traffic is clicking at higher rates so why not push this traffic to social presences of brands. We call this the “outbound social” opportunity.

BYOD – Today’s Driving Force in Ad Targeting

Posted May 3rd, 2013 by admin in Insight

Share:

As we move through the second quarter of the year, the remarkable shift in the balance of power in media buying and selling online continues and the ad side has never been more empowered. But, there are tactics that publishers can deploy to fight back and create value and insights that drive results for their advertisers while satisfying their users.

Today, media buyers are not only defining narrower audiences for media publishers to deliver, but more importantly, they are coming to publishers with defined data sets of their own – hence BYOD (Bring Your Own Data) – and they only want to buy the users they are interested in. No one else – just the users they want. This trend has accelerated tremendously in the past 12 months because of the confluence of two powerful developments that literally have had an exponential effect when combined.

First, new ad side data and insights have come on the market and taken hold with many advertisers. For example, retargeting has proven to be an effective means of driving business from existing customers, especially for retailers, and many companies work to service that need.

Second, the rise of programmatic buying and exchanges has given these new ad side tools efficient access to more and more users to scale, bypassing the typical publisher direct relationship. And the introduction of FBX (the Facebook Exchange) allows BYOD advertisers access to literally billions and billions of impressions at a fraction of the expense of traditional display inventory.

BYOD in online advertising is part of a broader trend toward addressable media that goes well beyond online. For simplicity, let’s define addressable media as the targeting of advertising to a specific consumer or household through data through a media channel. The data can come from either the advertiser side or the publisher side, sometimes a combination of the two, and frequently will include a third-party data provider. For instance, an insurance company ran a TV campaign recently for renter’s insurance in collaboration with two satellite TV providers targeted only to households that had been identified as rentals.

This shift is certainly turning traditional media selling online on its ear. Just a few years ago, a media seller would be touting the content of a site, the overall user demographics of the site and its index against a desired demographic set and it would have been enough to win an advertiser’s business. Today, an advertiser might not care about any of those factors when using their BYOD strategy, and they are likely to want to isolate just a fraction of a site’s users.

And, this trend is even scarier for online publishers with inventory on exchanges where they likely have no idea why the advertiser is buying media from them. The publisher will know the advertiser and the CPM rate but is very removed from the why? Was it a retargeted ad for a golf retailer? Was it a data match for a Caribbean traveler? Was it a user interested in a new car?

Do you want to be a publisher in a business where you don’t know why advertisers are buying your media?

There’s a slippery slope here and many publishers have started to experience the downhill trend – a loss of control, a loss of insights, a loss of advertisers and lower CPM’s overall, not higher.

It’s imperative that the online publishing community embraces a BYOD strategy of their own. Publishers must look to their audience and their behaviors and create meaningful insights that fuel ad matches with the needs of marketers. This BYOD effort by publishers has to begin with truefirst-party data about the site and the user experience. While many publishers are embracing DMP’s (Data Management Platform), consider the data sets being utilized by the DMP.They are often commoditized third-party data sets that advertisers already use on exchanges and elsewhere. And unless you have massive scale as a publisher, this commoditized data won’t really be helpful. Publishers need to create new first-party data that is differentiated and put it to use to meet the needs of advertisers and also their site’s users who are seeking a relevant, timely experience both in the content they seek and the ads they interact with.

There are few companies today that have taken on the BYOD challenge directly to help publishers. Yieldbot is one of those companies and we are working daily to provide our publisher partners incredible intelligence into first-party session-based user intent, the most powerful targeting signal of all. Yieldbot is also creating a new channel of advertising revenue for publishers by matching search advertisers with real-time user intent, creating a highly relevant and satisfying experience for users.

The opportunity has never been greater and by all measures the overall online ad spend will continue to grow. But, the risks are also high and the distribution of dollars between search, social, mobile, display, exchanges and new platforms remains to be determined. Advertisers have a lot of options and if you are a publisher whose data would you prefer to be working with? This isn’t a winner take all market, but publishers that embrace BYOD and create true data and insights into their site experience and users stand a strong chance to create separation in the market and drive value for their advertising partners and their audience.

Why Yieldbot Built Its Own Database

Posted February 4th, 2013 by admin in Insight

Share:

About a year ago we made the decision to switch over all of our configuration to a new database technology that we would develop in-house, which we ended up calling HeroDB.

The motivating principle behind what we wanted in our configuration database was a reliable concept of versioning. We had previously tried to manually implement some concept of versioning in the context of available database technology. This would keep around older versions of objects in a separate area with a version number identifying them, and application logic would move copies of whole objects around as changes were made to them. Data events would contain versions of the objects that they were related to. While this did some of what we wanted, it was clear that this was not the solution we were looking for.

Enter Git

at the core of Git is a simple key-value data store. You can insert
any kind of content into it, and it will give you back a key that you
can use to retrieve the content again at any time.
- Pro Git, Ch 9.2

While we had these challenges thinking about the management of data in our application, we were managing one of our types of data with perfect version semantics. Our source code. Some simple searches told us we weren’t the first to think about leveraging Git to manage data, but there also wasn’t anything serious out there for what we were looking for.

So we thought hard about what Git would be able to provide us as a database (there are definitely both pros and cons) and how it intersected with what we were looking for in versioning our configuration data. A few of the things we liked:

  • every change versioned
  • annotated changes (comments) and history (log)
  • every past state of the database inspectable and reproducible
  • reverting changes
  • cacheing (by commit sha) - specific version of data doesn’t change

There were definitely cons, which we decided would be worth it for the strength of the benefits we’d be getting. A few of the cons we decided to live with:

  • comparatively slow, both reads and writes
  • size concerns, would shard
  • no native foreign keys

Some of these can be mitigated. For instance, read performance can be improved (with caveats) by having cloned repos for read that are updated as changes are made to the “golden” repo. To mitigate size concerns, and because there is no native concept of foreign keys, data can be sharded with no penalty to what can be expressed in the data.

What We Did

Once we decided we liked the sound of having Git-like semantics on our data, we went about looking for projects that might aleady be available that provided what we wanted. Not satisfied with what we found our next step was to look for suitable programmatic interface to Git. In the end we found a good solution there in a project named Dulwich (https://github.com/jelmer/dulwich) which is a pure Python implementation of Git interfaces.

With Dulwich as the core, we implemented a REST API providing the data semantics that we wished to expose.

In terms of modeling data, we took Git’s concept of Trees and Blobs, conceiving of Trees as objects and Blobs as attributes, with the content of the Blobs being the values of the attributes. The database itself exists as a Git “bare” repo. Data is expressed in JSON, where ultimately all values are encoded in Blobs and where Trees represent nesting levels of objects.

The following simple example illustrates the JSON representation of a portion of our database realized in Git and what that looks like in a working tree.

Example JSON:

{“alice@example.com”: {“name”: “Alice”, “age”: 18}, “bob@example.com”: {“name”: “Bob”, “age”: 22}}

In cloned repo:

$ find .
alice@example.com
alice@example.com/age
alice@example.com/name
bob@example.com
bob@example.com/age
bob@example.com/name

$ cat alice@example.com/name
“Alice”
$ cat alice@example.com/age
18

What’s magical about representing your data this way is that it has a very understandable and easy to work with when realized in a filesystem view of the repo (i.e., the working tree). The database can literally be interacted with by using the same Git and sytem tools that developers are used to using in their everyday work. The database is copied local by cloning the repo. Navigating through the data is done via `cd` and `ls`, data can be searched using tools like `find` and `grep`, etc. Best of all, data can be modified, committed with appropriate comment, and pushed back to production if need be.

Interesting Directions to Evolve

Thinking about managing your data the same way you manage your source code leads to some interesting thoughts about new things that you can do easily or layer on top of these capabilities. A few that we’ve thought of or done in the last year:

  • Reproduce exactly in a test environment the state of the database at some point in time in production in order to reproduce a problem.
  • Discover the exact state of the database correlating to data events (by including commit sha).
  • Analyze the effect of specific changes to configuration on behavior of the platform over time.
  • Targeted undo (revert) of a specific configuration change that caused some ill effect.
  • Expose semantics in a product UI that map to familiar source control semantics: pull/branch/commit/push

Why We Did It

The short answer of why we did it was because we considered history such an important aspect of the database. Building a notion of history into the database itself was the best way to ensure the ability to correlate data events like clicks on ads back to configuration of monetary settings that drove the original impression in an auditable fashion. Not finding the solution to our problem anywhere we followed one of Yieldbot’s core principles and JFDI’ed.

The simplicity of the approach hit two strong notes for us. First was that the simplicity brought with it a kind of elegance. It is easy to understand how the database handles history and to reason about the form of the data in the database. We also immediately got functionality like audit logging built into the database for free. And ultimately for a technical team that at the time was four developers with our hands full building rich custom intent analytics, performance optimized ad serving, a rich javascript front-end to manage, explore and visualize our custom intent analytics, and a platform that scales out to a worldwide footprint, we could focus on our core mission of building that product.

We’re discussing our work with HeroDB later this week:

Yieldbot Tech Talks Meetup (Feb 7, 2013 @ 7PM):www.meetup.com/Yieldbot-Tech-Talks/events/101101302/


Interested in joining the team? We're hiring!

Data as a Currency

Posted October 8th, 2012 by admin in Insight

Share:

This past week was Advertising Week in New York and Yieldbot did a session with our friends @bitly during the AdMonsters OPS event titled “Data as a Currency.” The main portion of our presentation was the first public demonstration of Yieldbot’s publisher analytics product. Prior to that we led off with a brief overview of how we create currency with our data and by currency we mean real dollars to publishers and advertisers on our platform. Below is the presentation we gave. If you would like to learn more please email info@yieldbot.com

Data as Currency - OPS from yieldbot

Driving Traffic – The Publisher Panacea

Posted September 27th, 2012 by admin in Insight

Share:

The dream of web banners and selling impressions to large brand budgets is over. The value of audience data has surpassed the value of the ad impression. With this backdrop the future for publishers is this simple. They will get one more chance to enter the click based economy on their own terms (meaning owning their media and data) or they will lose control of their own business and become a media tool of Google and Facebook.

The last few years of rapid change in the ad tech world away from ad networks and towards ad exchanges has been a confusing one for premium publishers. First, they turned to the idea of “Private Exchanges” places where advertisers could come with their data and buy directly on the publisher inventory. The reality is there is no demand from advertisers because impressions are cheaper elsewhere. 18 months after being all the rage nobody talks about “Private Exchanges” anymore.

The new shiny object for Publishers is now Data Management Platforms or DMPs. While pubs seem to like the content optimization qualities of these platforms there are real issues using DMPs effectively with their media. DMPs add complexity and publishers are not technologists or marketers. Most important DMPs do not solve the underlying problems for publishers. Audience data is becoming commoditized and the value of their media on an impression basis continues to sink like a stone.

While Publishers have been fumbling the simple Click Economy has grown to the neighborhood of $40-50 Billon in annual revenue. This advertising economy includes Search, Contextual, Email, Affiliate. Everything that drives traffic e.g. clicks to marketers. Its newest entrants are Facebook, Twitter and Retargeting companies like Criteo – all of which are experiencing massive growth. In this economy two things stand out; the ad impressions are free and the performance-based business model drives value higher to those with the best data intelligence.

The businesses that were built to sell impressions to brands - Yahoo, AOL, Microsoft, NYT.com - have been passed by these businesses that drive traffic. Even choruses of “the click is dead” from fearful self-interested impression supporters cannot stop the basic fact that the web has always been monetized one way or another through traffic arbitrage and always will be. To she who sends the most valuable traffic goes the spoils.

The inflection point is now.

What we’re seeing from Yahoo is representative of the change that Publishers must make in order to survive. Bringing in one of the sharpest minds on Search as CEO to help save the struggling web banner company should be a beacon to all publishers. Your business is a utility. You deliver valuable content. That includes advertising. The value of that advertising is based on the quality of your audience to the advertiser as measured by a performance metric. Your ability to increase the value is based on the relevance of the message.

If that sounds a lot like Search it should. Those are the core tenants of that marketplace. A market that started later but has grown roughly twice the size of web banners. Publishers are paying dearly for missing the boat on that.

Think how much revenue the New York Times could be making had instead of web banners its digital revenue focus was to deliver traffic and conversions to sites like Expedia, Amazon, eBay, Bankrate, Home Depot, and on and on and on. It certainly would have been larger than IAC the company that just acquired About.com from them. IAC market value is 4x the New York Times. To give you another perspective the Times will do roughly $300 million this year in digital revenues. IAC will do over $2 billion.

Quietly taking advantage of publisher fumbling is Google. Google has expanded its grip on not only the publisher media through its Ad Exchange and AdSense but also their data through Google Analytics and its DFP ad server. Most publishers will openly admit that Google knows how much money they make and more about their audience then they do. When you don’t know who is coming into your store and you don’t know how much they are paying or what they are leaving with any business will die. That is exactly what is happening. Facebook is soon to take the same approach as it builds out its ad network on the back of all their javascript publishers have installed the past few years on their sites.

The fact is that publishers are already driving valuable traffic they are just not getting paid for it. A few years ago the New York Times said that 25% of its traffic leaves and goes to Google. Doing some back of the napkin math that’s about 20 million exits a month to Google and at estimated Google’s RPM rate of $80 that’s about $20 million a year in ad revenues the Times delivers to Google from intent the NYTimes themselves has generated. There needs to be an endcap.

Better yet, there needs to be a publisher controlled marketplace where the true value of traffic from premium publishers is understood, captured and passed on to marketers. Where the data is transparent and the optimizations generate mutual benefits to the publisher, marketer and site visitor. This would create a new channel. The opportunity is massive and real. Some premium publishers are already doing it and experiencing incredible revenue growth. Let us know if you want to be one of them.

First Page 1 2 3 4 » Last Page
More from Our Blog
Yieldbot's First Annual Super Bowl Intent Scorecard

Posted February 3rd, 2015 by Jonathan Mendez in intent, CTR

Yieldbot 2014 Review by the Numbers

Posted December 22nd, 2014 by Jonathan Mendez in

Rise of the Intelligent Publisher

Posted November 10th, 2014 by Jonathan Mendez in Media, CPC, Performance , Publishers, Data, Analytics, First Party, real-time

TF-IDF using flambo

Posted July 22nd, 2014 by Muslim Baig in Clojure, Data, flambo, Analytics

Marceline's Instruments

Posted June 25th, 2014 by Homer Strong in Clojure, Data, Storm, Analytics

View More

Yieldbot In the News
RTB’s Fatal Flaw: It’s too slow

From Digiday posted September 23rd, 2014 in Company News

Yieldbot Hands Publishers A New Way to Leverage Their First-Party Data

From Ad Exchanger posted September 23rd, 2014 in Company News

Yieldbot Raises $18 Million to Advance Search-Style Display Buying

From AdAge posted September 23rd, 2014 in Company News

Follow Us

Yieldbot In the News

RTB’s Fatal Flaw: It’s too slow

From Digiday posted September 23rd, 2014 in Company News

I have some bad news for real-time bidding. The Web is getting faster, and RTB is about to be left behind. Now, 120 milliseconds is becoming too long to make the necessary computations prior to page load that many of today’s systems have been built around.

Visit Site

Yieldbot Hands Publishers A New Way to Leverage Their First-Party Data

From Ad Exchanger posted September 23rd, 2014 in Company News

Yieldbot, whose technology looks at a user’s clickstream and search data in order to determine likeliness to buy, is extending its business to give publishers a new way to monetize their first-party data.

Visit Site

Yieldbot Raises $18 Million to Advance Search-Style Display Buying

From AdAge posted September 23rd, 2014 in Company News

Yieldbot, a New York based ad-tech company that lets advertisers buy display ads via search-style keywords, has raised a $18 million series B round of funding

Visit Site

Much Ado About Native Ads

From Digiday posted December 5th, 2013 in Company News

The most amazing thing about the Federal Trade Commission’s workshop about native advertising Wednesday morning is that it happened at all. As Yieldbot CEO Jonathan Mendez noted...

Visit Site

Pinterest Dominates Social Referrals, But Facebook Drives Higher Performance [Study]

From Marketing Land posted October 3rd, 2013 in Company News

Publishers in women’s programming verticals such as food and recipes, home and garden, style and health and wellness have found a deep, high volume source of referral traffic from Pinterest.

Visit Site

Pinterest Sends Your Site More Traffic, Study Says, but Maybe Not the Kind You Want

From Ad Age posted October 3rd, 2013 in Company News

Pinterest may have quickly arrived as a major source of traffic to many websites, but those visitors may click on the ads they see there less often than others.

Visit Site

From Our Blog

Yieldbot's First Annual Super Bowl Intent Scorecard

Posted February 3rd, 2015 by Jonathan Mendez in intent, CTR

Read More

Connect With Us

Where to Find Us

New York City

149 5th Ave.
Third Floor
New York, NY
10010

Boston

1 Clock Tower Place
Suite 330
Maynard, MA
01754

Portland

1033 SE Main St.
Suite #4
Portland, Oregon
97202