My pixels aren’t free ad space for your network – ‘Connecting’ needs targeting

MySpace for music, Facebook for friends, LinkedIn & Plaxo for work contacts, Pandora & Last.fm for Music – these are what I call networks and I use them in lots of places. They are sticky and I store my data there. Every “large network” will open up – they want to be “Connected” to web sites – but how do you know which ones to Connect? (thanks Facebook & Google for the term Connect).

Why are they opening up? Aside from providing the people who use their service anywhere access, it also drives engagement minutes, more user data, and more stickiness with users in other places than just their main website (what I call 1^st party web properties).

In this post I am continuing investigation to solve what Chris Messina dubs the Nascar problem (Luke Shepard has also weighed in on this from an Open ID point of view).

The solution below will allow web sites to detect which network’s a user is on. Not only will it drive more Connectedness – people will be connecting the right network to the right web site.

One of my assumptions is: there will be a finite number of large networks < 10. A web site’s visitors are also likely to use at least 1 of 10 pre-defined networks. These networks may change per geography.

The taxonomy I’m using for this post is:

• Networks = places people store chunks of data and always come back to
• Web sites = sites which are “Connecting” to networks (aka Relying Parties)

My sign-in page isn’t a billboard for your network

“Connecting” is a balanced of exchange of value between the websites and the networks. Websites drive off network engagement for the network. The network provides access to data, and a user base for “targeted promotion” e.g. sharing stuff to a user’s friends hoping they’ll click back through to the web site.

Pixels are precious. A web site isn’t going to spend space on promoting someone else’s brand (in this case a network) if they aren’t sure the user will click on it (and there is a way to get value). I think of the ability to “Connect” on a site as an ad for this mutual benefit.

With any ad system, you need to know who you are targeting them to, what the intent is. The solution I propose below would drive a higher degree of “Connectedness” between web sites and networks. Aside from more connections, they would be the right connections: Connecting MySpace to your Monster.com account isn’t really smart, but connecting LinkedIn to monster.com is a great move.

The solution

To reach this nirvana of connectedness there are 3 steps:

1. Detect the sites a user is a member of (from a predetermined per website list)
2. Sell the user why they should connect X network to the current site.
3. Connect whatever the user came there to do (share, sign in, anything else)

Detect

Each web site should understand their user base well enough to estimate the top 10 networks they share their user base with.

When a user goes to “sign in” they can sign in with their traditional forms based username/password, or a simple lightweight call can be made to the networks.

This simple call would be made from the user’s browser (imagine a cross site JSON request) and the network would tell the site “user is signed in”, “user is not signed in but was”, “we don’t know”. The key assumptions I’ve made are:

1. A network allowing web sites to check if their visitor is a user of the network is not a privacy/security hole.
2. Most networks store a semi-persistent cookie which captures the user’s state
3. Something drastic like all browsers going “scorched earth” (E.g. dropping all cookies on close) doesn’t happen

The web site would include a script from the network’s website:

<script src=”http://sn1.com/?connect=www.mysite.com&type=media&callback=ConnectSN1”>

Some web purists may say “I’m not making 10 cross network requests” as it will be bad for performance. My view is this is the only way to get a solution like this off the ground, and 10 cross network requests are more likely to happen than building a centralized service managed by an independent third party.

Sell

If the network tells the web site “Yes, I know that person” some contextual information can be shown to the user. Since the user has not granted this web site permission to access their data, the information needs to be protected, that is possible with an iFrame.

The selling is done by showing the user their profile picture, showing which friends have also “Connected” with the web site and some additional key reasons to connect that site with this network.

One idea is to make the web site tell the network what type of site it is e.g. Video sharing, Media website, eCommerce etc. that way the network could return very specific value propositions in the user experience. For example: if the web site is a finance site it may be “instant message with your significant other” not “share this with your friends”.

Some users may be alarmed that a web site can access their data because they don’t understand the IFrame isolation model (if an IFrame from foo.com is on a page from bar.com, bar.com can’t read the contents of the IFrame). From a technical point of view, to show the IFrame simple JavaScript could be used:

<script language=”JavaScript”>

// this function will be called if the user is a SN1 user.

function ConnectSN1()

{

  // construct the iframe to a standardized width

  url = “http://sn1.com/?connect=www.mysite.com&type=mediawebsite”

  // show the iframe

  showTheIFrame(url);

}

</script>

Connect

Do whatever the functionality provided the network is, sign in, profile, stream writing etc. This post was about the encouraging user’s to connect sites to networks, not what comes after that :)

Summary

Connecting web sites with networks requires a balanced “exchange of value”. For web sites pixels = $$$ and turning the sign in page into a billboard for other networks with little hope of conversion is unreasonable. The networks should be selling end users on “why this network for this web site” as not all networks are created equal.