Abstractions for Metrics and Targeting – extending OpenSocial

Tonight I attended the MIT/Stanford Venture Lab event “Shaking the Money Tree of Multi-Platform Social Networks” which my friend Jeremiah Owyang moderated. It was a sold out event which drew a very diverse crowd of students, brand advertisers, technologists, entrepreneurs and analysts. The event was great with short presentations and an engaging panel discussion. During the panel discussion I asked a question, which in turn sparked an idea I am exploring in this post. In the next few weeks and months I will be engaging with many people around these ideas and I look forward to comments, criticism and suggestions about how to accomplish these two main ideas.

In the interest of full disclosure, when I asked my question tonight at the event I noted that I was not an impartial questioner – I have a stake in this. To elaborate further, the company I am in the midst of co-founding, Nearness Function, is an ad network working to bring brand advertisers to select applications – including very likely applications running in Social Networks and on OpenSocial. If both of my proposals below happen it certainly will help Nearness Function and our partners and clients – and I hope, will help the entire industry.

Tonight Kevin Marks of Google discussed three important ways in which OpenSocial creates abstractions.

1. Abstracting the Friend networks of the “viewer” and “owner”. Allowing these to queried and traversed.
2. Abstracting data persistence for applications
3. Abstracting the event (“news”) feed which the use of an application can generate

My question and now proposal would add two abstractions – to OpenSocial and likely to more of the web in general.

1. Abstract metrics
2. Abstract targeting data

Taking these points in detail, here is what I am suggesting. These are my initial thoughts – I welcome feedback and further discussions.

Abstract metrics

The web 1.0 metrics resolved around “pageviews” and later, slightly more refined around “impressions” or “uniques”. In the past few years with the rise of pay-per-click advertising both against search results and increasing elsewhere across the web, “clicks” and a resulting calculation of “ecpm” (effective cost per thousand) has been a commonly used metric for success. And terms like “uniques” and “impressions” get used a lot – though exactly how to define and calculate them is not always clear in the least. Even “clicks” have to be recalculated to take into account “ClickFraud” – i.e. automated or malicious attempts to game pay-per-click systems, often by automating clicks on links (sometimes to generate income, but more subtly to exhaust a competitor’s budget).

For OpenSocial, and for much of the web of 2008, I would suggest that we start to think about abstractions for metrics that fit this new environment.

My initial suggestions would be to define active vs. inactive states so that an application can report back when a user is active (and we define what that means) within the application. A further refinement to this abstraction would be to measure the time in each state again with uniform ways to start and stop that clock.

Additionally a defined way to count events within the use of an application potentially including a measure of where within the application attention is paid could be highly useful as well. This might start by building on similar tools that are already used to track web activity and interactions. In the OpenSocial (and widget case more broadly) one complication being how to log and report back these metrics in a standard manner.

Ideally these metrics probably should flow back to the hosting social networks, to the application provider, and potentially (and again this needs clarification) be shareable with third party providers – such as an ad network (like the one I’m building).

Abstract targeting data

In the panel tonight when I asked about this the conversation shifted to a discussion about what an ad network can and can’t store based on the terms of service of a given social network. That is important, but it missed the point of my suggestion.

Here what I would be proposing is a bit more complex than the metrics, it would be a set of abstractions around what data flows to the application (which in turn might flow to the systems used to target advertising) which could be employed for targeting. Abstractions are important because even seemingly “simple” elements can, in many cases, prove complex.

Take “gender” – in many, but not by any means all, social networks this is relatively simple “male” or “female” – however this is not always the case. For one there are often many people who leave the field blank (i.e. undefined) and in at least some networks people of another gender (“transgendered” to take one example) can specify that. An abstraction might not resolve all possible nuances – but, for example, it might require the “undefined” case (and likely an “other” case) to be handled.

The issue that advertisers, marketers, application developers and social networks all face is nearly everyone recognizes that targeting messages – if done well and reasonably – adds greatly to the impact and effectiveness of those messages (however you choose to measure that). But each party also defines what and how they think that targeting should (or could) happen in very different ways.

My suggestion would be to create some standard and abstracted ways to think about a common set of data that could be available at the point when targeting could occur. Note that this would be done in a manner that could also be kept in compliance with a given social network’s terms of service. i.e. on FaceBook that data which is shared would not be retained for more than 24hrs etc.

Here are a few of my suggestions for areas where a discussion could (and should I’d say) happen, I’m sure I’ve missed or overlooked some things – and in some cases the standard may be very simple.

• Gender
• Age – I’d suggest by ranges vs. specifics – with a standard set of ranges
• Geographic location – potentially in two parts a) of viewer, calculated from IP address etc, at time of use and b) “home” (possibly “homes”) as stated in user profile
• New user/viewer of a given application vs. returning user/viewer vs. has application installed on own system (ideally even if “own” profile is on a different social network)
• Path to current session – i.e. via internal to social network search, via link on friend’s page, via link on stranger’s page, via external search, via external deep link
• Technology – browser type, speed of connection, mobile phone vs computer vs console
• Measure of frequency of interaction (with social network, with a given application) – i.e. you could target people who use the site every day and have for the past 6 months differently from people who use that particular site only once a week. You might also want to target users who are in their first X days of using an application or the underlying social network in a different manner than users who have been using it for months.

I’m sure there are others.

The key points here is that what needs to be defined is not just the categories but some abstract and standard ways to pass the relevant data. Keeping in mind that at the end of the day the goal here would be to make:

• The user experience better by presenting more likely to be relevant commercial messages
• The advertiser purchasing opportunities to be more clearly defined so advertisers can compare apples to apples
• The developer have an easier set of tools to understand the users and to offer, if desired, opportunities to advertisers
• and for Third party providers, such as an ad network, to have at least a minimum set of expected to be available data which could be used

These abstract targeting data would not preclude additional information being used to enhance and improve results (where that data can be used if covered under terms of service) but it would help improve targeting especially for OpenSocial applications which cross multiple social networks. The final results (i.e. which specific ad to show if any) might take a variety of additional factors (which ads were shown to that user or to similar users recently, what the actions of those users were, what various advertisers are willing to pay at the moment, etc)

This is very much a work in progress. I’m sure there are some overlaps here with activities of various industry groups. I welcome suggestions, enhancements, and other comments!