[CALL] Requirement for syndication

[Andy Buckingham]

"Users should be able to see all their tags, from all Devices and across all Service Providers, at any endpoint (Device, Service Provider website) once registered"

In the current specification a Service Provider can only surface tags they hold. Devices can iterate all the Services they know they have delivered tags to, to create an aggregated tags list, but this means that they may not surface tags made on another device to a service provider they are unaware of.

I have received requests that the spec by reviewed to allow the ability for any endpoint to show an aggregated view of all tags relevant to the current user. It was previously discussed that agreements could be made between specific Service Providers to aggregate tags, but depending on implementations adopted at best this can lead to an inconsistent approach and at a worst leads to a very difficult UI to pair up with each other service provider individually.

I am aware that for certain organisations the basic concept of syndication poses specific issues, which I would appreciate those affected detailing here for future reference.

[Ben Husmann]

This issue will require quite a bit of conversation.

As a user, it would be great to see all tags created in a single interface. However, if the only avenue for viewing tags is in the context of a service provider's web site or on a single device that may or may not have an agreement with a radio station or service provider, i think it will be politically impossible to achieve. The idea of logging into to a Clear Channel radio station web site and viewing all radio tags (including tags related to non Clear Channel stations) would not fly in the US. Even if there was a method for a radio station to see a user's activity related to a competitor (displayed to the user or not), that would still be a problem. Tag data collected has a value in the marketplace in terms of user activity/affinity. This could be a factor in getting stations on board with any aggregation plan, even one that would involve a trusted 3rd party (ala authentication clearing house).

Not the most articulate comment, just throwing out some concerns and topics for discussion from my perspective.

[Andy Buckingham]

Thanks for this Ben, gathering alternative viewpoints on this issue (particularly from other markets) is really important.

To ensure I've fully understood the heart of the issue, am I right in understanding you believe the politics around one Service Provider being able to see another Service Providers tags would halt adoption?

One idea mentioned on the call on Thursday was for a client-side way of creating the aggregated tag view, so that the Service Provider's were not directly involved in the exchange and therefore not able to access the data from another provider. Whilst technically I am currently unsure of a way to do this (all the models I've seen involve the Service Provider getting enough information to perform the request themselves), could this overcome the policy issues?

[Chris Lowis]

> One idea mentioned on the call on Thursday was for a client-side way of creating the aggregated tag view,

One thing we discussed while developing the RadioTAG protocol was this ability for listeners to share tags between various broadcasters, or even a third-party service who could offer a richer user experience.

I'd suggest taking a look at how this is achieved by other services with OAuth. For example, if I want Facebook to be able to see my Tweets, I can link the two accounts by authorising one to access the other (using my standard username/password, or 2-factor authentication where supported). The granularity of data access can be controlled using tokens, and revoked by revoking the token. I think it's really important to leave the listener in control of their data here.

I don't speak for my organisation on this point, but, like Ben, I suspect that any system that allows third-parties access to listener data without any prior consent from the listener will be a tough sell.

Cheers,

Chris


-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

[Andy Buckingham]

For the benefit of the wider group, the reason we originally paused on looking at OAuth as a solution for syndication was the issue of scalability.

Lets assume 4 different Service Providers in the UK adopt RadioTAG and all agree to allow syndication between each other. If we followed the OAuth permissions model, each service provider would need to add 3 options in to their UI to begin the OAuth exchange. It would actually likely be more than 3 as most service providers don't have a single public-facing umbrella brand (excluding the BBC), for example Global Radio would need to offer options for Classic FM, Heart, LBC, Gold, Choice FM, Capital FM, Xfm...) I'm really struggling to see an easy-to-use interface based on this methodology.

Furthermore, it is (by design) a one-way process, so assuming the User has connected their Global Radio profile to their BBC profile, they could see both Global and BBC tags on the BBC website, but not do the same on the Global site - without first navigating a logo wall again and following the same process.

I assume the way we would resolve the issue of Service Providers being unhappy to share tagged data with other Service Providers, is simply not implementing this piece of functionality, which would again lead to an inconsistent experience.

My thought process for all of this discussion is what a typical listener expects or would assume when using this system. Having little/no knowledge of the ownership and organisations behind their brands - what experience would they expect when viewing tags? Would it be reasonable for them to see aggregated views on some websites, but not others? Would they understand why it was this way?

[Andy Buckingham]

I'd like to try and draw this thread to a conclusion. My understanding is as follows:

• There is a general consensus that the ability for a User to aggregate tags is a good thing
• Some Broadcasters have concerns about rival Broadcasters being able to see shared Listener's activity
• OAuth has been suggested as an alternative method to enable this, but I believe it would present serious usability issues with reasonable adoption (detailed above)

I can see 2 possible resolutions to this issue:

1. We find a solution that allows client-side aggregation so that broadcaster-to-broadcaster data sharing is not possible - I have so far been unable to find a way that this could be implemented without requiring a methodology similar and therefore equally complicated for the user as OAuth, but there may be alternative proposals on how we may achieve this.
   
   
2. We make the sharing of tags for aggregations optional for broadcasters. Those that wish to take part can do and provide aggregated views with like minded partner broadcasters, those that are unhappy with the arrangement prevent it but offer a reduced experience to their listeners.

I personally favour option 2, as it would allow the market to make decisions at a time beyond a spec publication date and, I believe, keeps both opinions (sharing vs not sharing) happy.

Please share your relevant thoughts on this summary and the proposals above. Are there any alternative angles we could approach this from?